SOA Soup? Hardly.

I came across this ridiculous blog post complaining about SOA standards initiatives and implying that all of us who worked on standards (well over 1000 people) have failed. This article has been curiously categorized under "Men's Health," which leads me to believe the ill-informed author is doing nothing more than trying to make some ad revenue.

Since the author decided not to reveal his or her identity, allow comments, or factually state matters related to SOA and provide a complete story, I decided to comment on it here.

First - the article itself is obviously short of one effort - the Open Group's SOA Reference Architecture. This really means we have 4 standards and figuring out how to use them and how they fit together can be daunting to an outsider (I'll concede this point). Here is how they work.

The OASIS SOA Reference Model is an abstract model for services. As such, it is a set of guiding principles on what SOA is. It is not the definitive definition of SOA, it is simple a definition. Also - since it is abstract, no one can claim their product is implementing it (if this was possible, it would be concrete rather than abstract). Here is a chart of how software architects generally capture and preserve knowledge. A longer version of this is explained in this SOA White Paper.

At the next level down, there are two SOA Reference Models currently being worked on in standards consortia. There are also many others that have been completed. It was always envisioned by the OASIS SOA RM Technical Committee that there would be numerous Reference Architectures based upon the Reference Model. A Reference Architecture is a generic blueprint for a class of items that may be further specialized to meet a specific set of requirements. The Open Group and OASIS both are working on standards based SOA Reference Models and having noted such, are already looking at ways to harmonize and work together (I will be at the Open Group meeting with my (very smart) OG friends Heather Kreger and Chris Harding to discuss this in San Diego in one week's time). In the meantime, Adobe (and a ton of other vendors), the US Justice Department, the European Broadcasting Union and a number of other groups have harmonized around the Reference Model. Its purpose has been to provide a common point of reference about what SOA is, noting the elements that are common in all SOA. If you were to make such a RM for a "House", at this level of abstraction, you would include things like the foundation, the walls, the doors, the roof etc, and define each one, its purpose, and how it interfaces or works with other components or entities. This does not prevent people from designing specific houses to add in other elements (like skylights, tunnels, fireplaces etc.), but merely gives the industry a point of reference.

One of the most valuable things a Reference Model brings us is the ability to note differences in definitions of the thing or class of thing.

The other effort mentioned (run by Cory Casanave) is OMG's SoaML. Cori is a good friend of mine and one of the most brilliant minds around. As is usual in OMG activities, the goals of SoaML are to support the activities of service modeling and design and to fit into an overall model-driven development approach. As such, it provides a valuable piece of work to the overall SOA set of standards. One of the most common questions people ask is "How do I identify a candidate for a service?". A model-driven approach (even like OMG's MDA) will help in this respect.

Now back to the ill conceived, anonymous spew of hatred and misleading venom. The author has gotten confused on the use of UML. Waaa! Too bad - UML is here to stay and it is an unambiguous and consistent approach to capturing and preserving knowledge (which is why most of the smarter standards groups use it). The 4 standards I have mentioned in this blog post have been participated in or contributed to by at least 1,000 people from most of the top software companies in the world (check out the references on the various documents and websites).

So who is right here? Actually no one. Perhaps we (the various standards consortia) have failed to simplify the delivery of SOA to the level of the gradeschool mind. Maybe this is something we need to table for the meeting in San Diego.

But I will state with absolute conviction that SOA is not something designed to sell products; it is a valid architectural and business paradigm of matching needs and capabilities via services. It is widely used and services are here to stay in modern computing. I also believe these four standards and others are important pieces of work for our industry to avoid confusion and add clarity.