There is no doubt that evaluating and implementing a service-oriented architecture (SOA) can be an intimidating and overwhelming process. When I first started to work with SOA standards, my first task―understanding what standards are out there―produced a daunting reading list.
After plowing through several lengthy standards, I starting looking for the “Cliff Notes” versions! I heard similar complaints from other architects: “How am I supposed to read all this? How do they relate to each other and my job?” Customers expressed the same angst on similar fronts:
“There are so many views on SOA … conflicting vendor views and now seemingly conflicting standards views. Which one is right?”
“If I learn SOA concepts in one standards organization, will I have to relearn them to understand the specifications in another organization?”
“What if there is disagreement on fundamental SOA concepts that would make using these standards in concert impossible?“
Some customers even felt that maybe they should delay their SOA transformations until “things settled down” in the SOA standards world. It was these questions and concerns from customers and vendors that motivated The Open Group, OASIS, and OMG standards organizations to collaborate and draft the “Navigating the SOA Open Standards Landscape around Architecture” joint whitepaper. The goal was to provide the industry with a trusted and impartial source to understand what types of SOA standards were being developed throughout the industry, how they related to each other, and which ones work best for different organizations.
As one of the contributing writers to the joint whitepaper, my co-writers and I agreed that your understanding of the basics of SOA should be the same regardless of which specification or organization you start with. With this in mind, we set out to map various SOA concepts by summarizing underlying SOA and SOA governance concepts in a neutral manner. The following will provide an overview of the joint paper along with my perspective on motivation and value of these standards.
A Standard Architecture
Before diving into the details of the Navigating SOA paper, I should clarify that the paper focuses on explaining and positioning architecture standards for SOA. Architecture standards address customer architecture considerations and are non-normative and oriented toward consistency. Available SOA architectural standards include reference models (RM), ontology, reference architectures (RA), maturity models, modeling profiles, and governance frameworks. This paper does not tackle SOA implementation and infrastructure standards, which are normative and focused on interoperability. That topic will have to be tackled another day in another paper.
The value of using architecture standards is that it provides a common, vendor-neutral foundation of understanding for SOA. An architectural standard is validated and is more mature than single-vendor architectures because it is developed with the use cases, best practices, and experience from multiple vendors and organizations. Using an architecture standard eliminates the need for you to map concepts between multiple vendors and provides a common “language” to communicate with any of the SOA vendors. (Note that you can also require vendors to map their own concepts and products to the standard.)