It seems that I am not as flexible as I believed I could be on my thinking regarding SOA. I attempted to categorize various SOA engagements in my SYS-CON article entitled “A Classification Scheme for Defining SOA” . I believed that I could hide my dissatisfaction with the lack of clarity surrounding SOA by lumping SODA/application development into its own subcategory. I was wrong! When it comes down to it, there’s still just too much ambiguity surrounding the term service.

So, you might ask, “What is the big deal if we call everything running on a computer a service?” The answer is that not all services are created equally and there’s no way to determine the type or extent of services when a single term is used as a catch-all.

For me, SOA is defined precisely as follows:

Service-Oriented Architecture (SOA) is an archetype—an architectural pattern —that focuses on design of systems from the perspective of providers and consumers as defined by a contract. SOA-based designs introduce agility by enabling interchangeability of service providers without requiring process changes in the consumers. Hence, the SOA is applied at the system level, not just at a single component within a system.

Because I define SOA as an archetype, you can not have a direct instance of SOA, you can use SOA to define a new architecture, which can then be used to create instances of systems. For example, Service-Oriented Integration (SOI), Web 2.0 and Cloud Computing are all architectural types based on the SOA archetype. However, to put things in context, FedEx and UPS, as businesses, are also SOA architectures. Needless to say, if you follow the laws of object-orientation, it’s not invalid to identify an object by it’s topmost ancestor, but in doing so you lose the object’s essence. This is a great technique for lumping things together in a collection, but horrible if you want the richness and value of the object to come through.

Of the three technology-related architectures based on SOA listed above, SOI and Web 2.0 clearly have a strong software connection. Some identify the the software component that has a SOAP or HTTP interface as a service. Well, just as SOA is an archetype, service is an archetype as well, and, indirectly, these software components are services given that they derive from the service archetype.

To better understand my point we need to explore the technical ramifications of this for a moment. With the growth of TCP/IP as a ubiquitous networking protocol, so grew the concept of client/server computing. In client/server computing, a user interface application consumes networked software services to provide data on demand versus having the application exist as a monolithic entity on a single computer. Client/Server computing enabled networked shareable resources.

If I didn’t use the term Client/Server in the above paragraph, 9 out of 10 technical people today would say I was talking about SOA. So, is everyone who is developing systems using Web services today really just doing Client/Server? I believe so, but that wouldn’t be popular, after all, there aren’t hundreds of job openings for client/server architects right now.

[Sidebar Note: What are these people asking for SOA architects really looking for if it’s not client/server experience? From what I’ve seen, it’s typically experience with a particular vendor’s software for building distributed applications. But, to those people I warn you “big mistake”. The underlying standards will not make it significantly less expensive to switch from that tool to another one.]

To summarize, no one who claims to be doing SOA would openly admit they’re just really doing client/server. There is a subset of people doing SOA that are actually focusing on modeling the business as a set of functional service areas (these people are really doing SOA). Then, there’s a bunch of people developing software components using a client/server design pattern claiming they’re doing SOA.

So, I ask you, do you still think that a common definition of SOA is not needed in the industry?