When technologies begin their ascent up the hype curve, typically there’s a lot of opinions, confusion and nonsense. Service Oriented Architecture (SOA) is no different in this regard. I’d like to try and demystify the whole SOA world and debunk some of the myths that are being propagated about how SOA can and cannot help in solving real computing challenges.
The concept of “software as a service” is nothing new. In fact, it has existed almost as long as computing itself. Back in the 1950’s there was a lot of talk about how computing would ultimately become a utility like electricity and gas and that people would simply be able to plug into it.
However, despite, or possibly because of, the furious pace of innovation in computing we still are largely at the stage where most large organisations spurn the grid and instead have their own private generation stations inside their networks. Organizations have spent millions of dollars with large software vendors to help them build their own home grown, large and complex IT “generating” station.
There have been many initiatives over the years to try and deliver an SOA. We can look at DCE, CORBA and DCOM as some recent examples. However, the emergence of the Internet and a set of common agreed software standards has presented an opportunity to overcome the shortcomings of previous attempts. The building blocks are in place to realise the vision of “software as a service”.
One of the major problems we have at the moment is that there is a lot of confusion about what SOA actually means in practice and how it can help solve real-world problems. This confusion isn’t helped, when writers and speakers focus on the wrong end of the SOA spectrum. At a recent industry conference one of the speakers gave the following example of how SOA can help solve technological problems:
“Imagine if, for a moment, every company had a service-oriented architecture, and one of the services in the architecture was date. The Y2k problem could have been solved in 10 minutes for a few dollars just by changing the date from a two-character field to a four-character field — and then every application needing a date could have used that.” Excuse me? What has that got to do with software as a service? Nothing is the answer. It suggests that SOA is the software equivalent of a cure for cancer, which it isn’t. SOA alone will not solve all the world’s problems.
So what is SOA? What will SOA actually solve? Well here’s my attempt at defining it.
A Service Oriented Architecture is a business led approach to creating software that encourages the use of technology to model and automate the high level services that a business delivers to its customers and suppliers.
Let me explain by way of an example. If I am a telecommunications provider, the services I provide to my customers are built around provisioning, billing and customer care. People call me up and ask me to activate a telephone line, they then make calls on that telephone line, I send them a bill for those calls and then they call me when they are having problems with the service or the bill.
There is a lot of technology involved in providing those services to the customer. A lot of different systems need to be connected together to enable the service and historically those services grew from the technology outwards. What I mean by that, is that the way a service was created and delivered to the customer was dictated by the available technology.
The whole goal of SOA is to try and reverse that trend. The premise of SOA is to start with the service, as it is defined by the people who want to provide it and then work backwards into the technology. It is, as it says: A Service Oriented Architecture.
This is a fundamental and profound change in the way we think about information systems and it also the main reason why SOA might succeed this time round.
If you look at any of the previous attempts at a SOA you can see that they were very technology centric. To demonstrate this point let me use a quote from IBM:
“So it (SOA) basically boils down to distributed computing with standards that tell us how to invoke different applications as services in a secure and reliable way and then how we can link the different services together using choreography to create business processes. And then finally so that we can manage these services so that ultimately we can manage and monitor our business performance.”
While this is technologically valid, it is missing the point of SOA. Again we’re focused on the technology that enables SOA and not on SOA itself. This is one of the biggest hurdles in making SOA work.
If we constantly think about what the technology can do, we end building systems that are brittle, make assumptions about what kind of application is on both ends of the wire, are overly complex and ultimately fail to deliver any business value.
It is only by focusing on the actual service we want to create in the first place, in the terms that a business person might understand that we can have any chance of actually making a SOA work and making it work profitably.
Annra O’Toole, CEO, Cape Clear Software
OToole drives the overall vision and corporate strategy for Cape Clear
Software http://www.capeclear.com/. He joined Cape
Clear in November 2000 to participate in the major opportunity being created
by the emergence of the Web Services technologies and the massive benefits
they could bring to the challenges of creating and
integration applications. O’Toole co-founded and served as Chief Technical
Officer of Iona Technologies, prior to joining Cape Clear. He holds an MSc
in Computer Science and an Electronic Engineering degree from Trinity
College, Dublin.
