Analysts often criticize organizations for buying into one vendor's definition of service-oriented architecture, thereby essentially locking themselves into proprietary systems, which frankly, defeats one of the purposes of SOA. The SOA community refer to this as "trying to buy a SOA" or "SOA in a box." The underlying thought is companies that do this are trying to buy their way into the latest buzzword, rather than do the hard work of re-architecting their infrastructures.
Maybe that's fair. But CDBI SOA consultant Lawrence Wilkes believes the standards bodies also bear part of the blame .
"In most organizations, users have little choice but to pick a single vendor's proprietary solution to such requirements that complies with no relevant SOA standards," writes Wilkes in "A Unified SOA," which posted last Friday.
Wilkes, along with his colleague, David Sprott, are taking aim at the competing SOA standards, which they say use different definitions for the same terms and offer conflicting methods so that it's impossible to develop a common approach for SOA's life cycle.
Worse, notes Sprott in "The Failure of SOA Standards," none of the standards have actually achieved widespread adoption:
We must judge any standard in its support for the user community and crucially user adoption. The primary purpose of these standards under discussion is achieving common definitions of important concepts and simply put, they have failed to achieve widespread adoption because of the competing efforts have confused the user community.
In the rest of the post, he outlines how he thinks each group has fallen short of producing standards usable in the real world.
To help users sort through their SOA standards, the Open Group, OASIS and OMG collaborated on a 27-page white paper, "Navigating the SOA Open Standards Landscape Around Architecture." I wrote a post about it when the SOA standards paper was released in July.
UK enterprise architect and ebizQ blogger Michael Poulin called the effort "a tremendously important and significant move in the Industry that gives us a hope on the 'end of standard wars and madness' and a chance to communicate about SOA in 'common' language.' "
But in his post on Oct. 3, Wilkes criticizes the paper:
It seems to us and many others that this is an attempt on the part of the authors to gloss over the fact [that] they have managed to produce three alternative SOA standards when the world really only needs one. Saying that OASIS SOA RA is similar' to the Open Group SOA Ontology is a bit like saying Cricket is similar to Baseball. Because they both involve similar concepts of bat and ball presumably this means a cricket team could play a baseball team?
Of course, these bodies aren't the only ones offering SOA standards. Wilkes notes the government and defense sectors are also creating "unique perspectives on SOA" by through their own frameworks.
Wilkes believes the only answer to this problem is to create a unified SOA standard and he spends the bulk of his post exploring what it might take to make this happen.
The CBDI actually developed its own SOA meta model, which Sprout says predates most of the standards work and was made available to the standards bodies. He writes:
Frankly we fully expected that our work would be superseded by the standards work and that we would progressively align our SAE models to a converged standard.
That hasn't happened, of course. So the group soon plans to release version 3 of its CBDI-SAE Meta Model for SOA, which is free to CBDI subscribers. (Individuals can become subscribers for free-simply choose the Bronze option.)
Of course, I suspected that CBDI promoting its own approach would cause some to cry foul - and, in fact, it did. In a Steve Jones of the Yahoo SOA Group did just that in his response to the posts, which were pointed out by Yahoo SOA Group member Gervas Douglas. Said Jones:
Shooting down things and finishing with the line "you should use ours instead" sort of betrays the level of objectivity that has gone into both their effort and their assessment of the other standards.