Michael Kuhbock would like to thank Annraí O'Toole, chief executive officer, Cape Clear Software Inc. (www.capeclear.com), a member of the Integration Consortium (formerly the EAI Industry Consortium) for contributing this month's column. O'Toole began his career working with international standards bodies to develop standards for software interoperability. With these and other initiatives, he has helped contribute to the direction of the computer industry. He can be contacted at firstname.lastname@example.org.
When technologies begin their ascent up the hype curve, typically there are 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 1950s there was a lot of talk about how computing would ultimately become a utility, such as 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 organizations 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 a 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 realize the vision of software as a service.
One of the major problems we have at the moment is the amount 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.
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 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 to enable the service, and historically those services grew from the technology outwards. What I mean 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 is 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 are 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.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access