Informatica Enterprise Data Management

SOA has nothing to do with technology. It has everything to do with defining and managing the business as a collection of service functions and information exchanges. A business may be viewed as an internal organizational unit within a large company that provides services to other other units and consumes services from yet other groups. Or if you view the business as the company overall at the macro level, then you could define and manage the business as a collection of services consumed from its supply chain and provided to its customers.

All of these service interactions require information to be exchanged. The information may be verbal or written, structured or unstructured, and is governed by service level agreements which may be explicit (contracts) or implicit (based on past behavior or industry norms). For example, a customer orders a hamburger (verbal information exchange), receives the order within a few minutes (implicit service level in a fast food restaurant), and pays with a credit card (structured information exchange).

All of the service flows inside a company or outside in the supply chain can be described (modeled) as functions with information inputs and outputs. Furthermore, a holistic model of all the functions in an enterprise or supply chain and the information exchanges between them will quickly identify which services are used by more than one consumer and therefore are opportunities for re-use and for investment in process improvements. This is a service oriented architecture.

Note that to this point I have not said anything about technology. Technology is an implementation detail which by most definitions is not “architecture”. Architectures are the plans and models – not the systems that result from them. There is of course such a thing as “technology architecture” which, in the case of service-based information exchanges may include protocols and standards such as SOAP, XML, WSDL, HTTP, MQ and REST among others.
When IT professionals speak of SOA, many of them are actually talking about technology architecture. My point is this – unless you take a business view of service orientation (which has nothing to do with technology) you shouldn’t call it a service-oriented architecture. If the focus of your SOA is on the technical implementation details, then you should call it application integration architecture or something like that.

This is the root cause of the trough of disillusionment when it comes to SOA. SOA has been promising lower costs and agile business processes for years, but the enabling technologies alone won’t provide the benefits (except by accident). Business flexibility and service re-use arises from a clear view of the business as a set of service functions and information exchanges. Once you understand the business in this context, the opportunities for technology solutions to support the business become clear and the path out of the trough of disillusionment and onto the plateau of productivity is illuminated.