Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Thoughts from the Integration Consortium:
Service Oriented Architecture The Right Side Up

online columnist  Integration Consortium     Column published in DMReview.com
June 3, 2004
  By Integration Consortium

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 annrai.otoole@capeclear.com.

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.


Check out DMReview.com's resource portals for additional related content, white papers, books and other resources.

The Integration Consortium is a non-profit, leading industry body responsible for influencing the direction of the integration industry. Its members champion Integration Acumen by establishing standards, guidelines, best practices, research and the articulation of strategic and measurable business benefits. The Integration Consortium's motto is "Forging Integration Value." The mission of the member-driven Integration Consortium is to establish universal seamless integration which engages industry stakeholders from the business and technology community. Among the sectors represented in the Integration Consortium membership are end-user corporations, independent software vendors (ISVs), hardware vendors, system integrators, academic institutions, non-profit institutions and individual members as well as various industry leaders. Information on the Integration Consortium is available at www.integrationconsortium.org or via e-mail at info@integrationconsortium.org.

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.