SOA - What is it again?

SOA - What is it?

In the past two years I have been asked multiple times by both technical and business people alike one question more than any other - “What is this SOA thing?” I think this is a common question because the marketing and press folks have done a very good job of muddying the water when it comes to tagging every piece of software as SOA-enabled, SOA-certified, etc.

The challenge is to explain what SOA is to the client - the people that pay the bills. SOA stands for Service Oriented Architecture and to start with, it is easy to define what SOA is not. SOA is not a single product you simply install and are done with it. I have had customers tell me not to worry about business requirements for a new system because “the SOA will handle all that”. Their understanding was that “the SOA” was a product you installed and it magically solved all the business problems. Hmmmm…..where is that salesperson? SOA is also not web services. It is true that web services are usually employed as part of a modern SOA solution, but in of themselves, they are not SOA.

So what is it and how do you explain it to your business customer?

SOA is a philosophy or vision of how software should be developed. Those that adhere to this philosophy believe that the most efficient way to build software is through a series of re-usable services. By “service” I mean any type of function that accomplishes a specific task. The idea is to build a layer of fine-grained functions and then begin building out more coarse-grained functions on top of that layer. A great business example is to imagine offering a coarse grained business service called AcceptPayment that within itself calls two services that are more fine-grained - AuthorizeCreditCard and PostPaymentToAR. At a recent conference, the speaker compared this composition of services to Legos and I agree that is a good analogy.

This service architecture promotes re-use, reduces maintenance, and is a more efficient way to design. The apex of SOA occurs once all the fine-grained services have been built and are easily available to coordinate into new coarse-grained business services as needed. This philosophy has been around for decades, but with the emergence of web services, it became much more popular and started to receive press and marketing attention.

So why is the term “SOA” in every article I have read in the past 2 years?

The reason for this surge is two-fold. First, with the introduction of web services, architects can now expose their services/functions in an accepted standard that is platform/language agnostic. Before web services, one could build using an SOA driven design and expose services within the firewall via RMI/EJB or JMS (assuming J2EE shop). To expose services outside the firewall to vendors for instance, one used CORBA or perhaps some custom format between the service producer and service consumer over HTTP.

The second reason for the increase in press was that a “look-up” technology known as UDDI was introduced. Before UDDI, one could build a business function as a service and expose it, but no one else could know about it. UDDI solved that problem by providing an agreed upon standard for marketing services to potential clients. Think of UDDI as a library for services. Because web services and UDDI are both open standards that began to get traction (web services much more than UDDI), this allowed software vendors to begin to make tools based on these standards.

The major software vendors started creating tools to easily expose web services and create web service clients for developers. They also began providing registry software based on the UDDI standard. These tools made the development of SOA driven design easier and MUCH more efficient. At that point, things really started to take off.