SOA Explained - Seven Steps

This page looks at some definitions of SOA and describes the steps an organization must take before it can be truly successful in realizing the cost and agility benefits offered by enterprise service-oriented architecture. It discusses the various stages of SOA adoption describing the technologies, processes, and best-practices available to help companies succeed in their SOA initiatives.

Steps 2 through 6 describe cross-enterprise concerns that should be addressed with a centralized SOA infrastructure platform. Steps 1 and 7 address specific needs and are often delivered as part of an existing enterprise application stack. Following these steps will lead an organization down the right path to realizing the benefits of SOA.

Wikipedia defines SOA as follows:

In computing, the term Service-Oriented Architecture (SOA [pronounced “es-?-?”]) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network[1] are made available as independent services that can be accessed without knowledge of their underlying platform implementation[1]

Service Oriented Architecture was first proposed by Gartner analysts Roy W. Schulte and Yefim V. Natis. They specified SOA as “a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.” [2]

SOA is usually based on Web services standards (e.g., using SOAP or REST) that have gained broad industry acceptance. These standards (also referred to as Web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. However, one can implement SOA using any service-based technology.

This provides a concise and accurate definition of SOA, but it does not describe the reasons why an organization would want to move towards an SOA, or the benefits such architecture can offer. The value and core tenets of SOA are described well in business terms in the book Understanding Enterprise SOA, by Eric Pulier and Hugh Taylor of SOA Software.

Also from Wikipedia’s definition of SOA:

Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to the changing market conditions[3] . This style of architecture promotes reuse at the macro (service) level rather than micro levels (eg. Objects). It can also simplify interconnection to and usage of existing IT (legacy) assets.

In some respects, SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. In communications systems, for example, there has been little development in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing an SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces. This should greatly decrease integration costs and allow for much more dynamic solutions to be deployed.

Drilling into these concepts we can see that there is a set of basic capabilities that are required to achieve the potential benefits of SOA. Wikipedia discusses a number of these guiding principals, amongst which are:

Reuse – the ability to encapsulate and expose coarse grained business functions as services

Loose-coupling – ensuring that service consumers are sufficiently abstracted from the physical implementation of a service

Identification and categorization (discoverability) – making sure that potential consumers can find the services they need

These fundamental principals lead to a natural order of activities an organization must complete to incrementally realize the benefits of service-oriented architecture.

For a detailed explanation of the seven steps to SOA please download the whitepaper.