Making Sense of SOA Standards

By Heather Kreger

(Back to article)

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” http://www.adobe.com/devnet/livecycle/pdfs/soa_standards.pdf 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.)

Getting locked into a vendor’s proprietary view on SOA could prevent you from being able to select best of breed vendors for your organization in the future as you roll out your SOA solutions.

Types of Architectural Standards

It was helpful to us in developing the whitepaper to understand how the types of architectural standards related to each other in general, without considering any of the specific standards. We found this diagram useful for capturing our understanding:

According to TOGAF, a vendor-neutral, industry standard enterprise architecture framework, architectures exist along an abstraction continuum ranging from foundation architectures of building blocks, to common-systems architectures with highly reusable solutions, to industry specific architectures applicable to most organizations in an given industry, to specific organization architectures. Reference architectures shadow this continuum, ranging from conceptual, which are the most abstract foundation reference architecture concepts to generic, which applies across many industries, to industry, which contains industry specific best practices and standards, and finally concrete, which is a specific, realized reference architecture for an organization.

Reference models and the ontologies that capture them influence the architectures and reference architectures, providing concepts for them all to build upon. Modeling languages are used to capture the architectures and may be specific to a reference architecture. Finally, maturity models allow us to gauge the maturity of an organization’s architecture.

SOA Concepts

After much discussion in the collaboration meetings, we found that while the definitions and expressions of SOA may differ slightly between the specifications, we did agree on the fundamental concepts of SOA and SOA governance. Likewise, the understanding of SOA and SOA governance provided by these works is similar, but they are written from different perspectives. Each specification supports the same range of opportunity and features, but provides different depths of detail for the perspectives they focus on. In the concepts section of the paper we capture the essence of this agreement and in the guidance section we identity the focus area of each of the standards.

The fact that there is a great deal of agreement on the foundational core concepts across so many independently developed specifications for SOA is very encouraging and could be explained by realizing that the developers of the these diverse specifications shared a common experience as users and implementers of SOA. This common, grassroots view is one indicator of SOA’s maturity in the marketplace and should serve as reassurance that SOA-based business and IT transformation initiatives incorporating these specifications and standards help mitigate risks that might compromise a SOA solution.


Which architecture standards are relevant to your organization depends on what you are trying to achieve. It also depends on your personal experience with SOA, as well as your organization’s experience with SOA. To determine the level of maturity, the SOA maturity model, Open Group Service Integration Maturity Model (OSIMM), can provide some insight. That whitepaper provides detailed advice based on what a reader is looking to learn, which can be summarized as follows:

To understand SOA core concepts use the OASIS SOA RM. It provides a common vocabulary for the most basic SOA. It is a highly abstract model targeting a large, cross-cutting audience that includes non-technical readers and technical readers.

The Open Group SOA Ontology formalizes and extends the OASIS SOA RM with additional concepts and relationships taken from an architect’s viewpoint and an enterprise-wide perspective on SOA. It provides a formal OWL representation to enable tools. The reference architectures and The Object Management Group (OMG) SoaML specification (Soa/ML) also articulate core SOA concepts to provide context for their specifications, these concepts are consistent with the SOA concepts outlined in the Navigating SOA paper.

To understand SOA architectures, The Open Group SOA RA and OASIS SOA RA both provide an understanding of the different elements of SOA and considerations for enterprise and cross-ownership boundaries in SOA ecosystems from different viewpoints. The OASIS SOA RA is more abstract and focused on an SOA ecosystem viewpoint and the cross-organizational ownership boundaries that accompany it. It provides models that function as a checklist that can be used to evaluate architectures and SOA implementations.

The Open Group SOA RA is more focused on SOA initiatives in the enterprise; guiding architects to use and deploy SOA architectural building blocks and to evaluate the implications of architectural decisions. It provides a base RA for users to refine industry and organizational RAs and positioning products in an SOA context.

To understand SOA governance, both The Open Group SOA Governance Framework and the OASIS SOA RA contain very similar basic concepts of SOA governance. The Open Group SOA Governance Framework focuses on governing SOA processes in the enterprise. Processes call into scope the service portfolio and IT infrastructure onto which SOA is deployed for governance. The framework also provides guidance on the deployment of SOA governance in an enterprise in an iterative, progressive cycle. The OASIS SOA RA directly focuses on governing services and IT infrastructure and the special consideration of doing governance in the absence of a controlling authority.

To understand your organization’s service maturity, the OSIMM (referenced above) provides a service integration maturity model that describes the broadest scope of service use so that companies can understand what SOA features they are using, which ones they want to use, and an incremental roadmap to get there.

To understand how to model SOA, OMG’s SOA modeling language (SoaML) provides a UML profile for modeling SOA artifacts (starting with OASIS SOA RM concepts) and services for your SOA as part of the transformation from a RA to your SOA solution architecture.


Since the OASIS SOA RA, The Open Group ontology, and the OMG SoaML were all based on the OASIS SOA reference model with refinements and extensions, there is some natural affinity between these works. Having a common "root" certainly helps increase the chances that the standards are consistent. It should be noted that the Open Group SOA RA is not based on or influenced by the OASIS SOA RM. However, from the start of the cross-consortium collaboration on the paper, there has been a bi-directional influence on the content of the SOA RA and governance specifications between OASIS and The Open Group.

The Navigating SOA paper positions the reference architectures along two continuums: level of abstraction (discussed in the Types of Architectures section) and coverage of enterprise architecture. The coverage continuum ranges from narrow, i.e. a particular pattern; to partial, covering on aspect, like governance; to end-to-end, which provides a comprehensive technical RA for IT; to complete, which covers IT and business.

We can position the SOA standards relative to each other along these two continuums in the following diagram:

Technically, the SOA RM and SOA ontology are not RAs, but it is useful to show them as the most abstract works surveyed. The OASIS RM is the most abstract, with The Open Group SOA ontology being slightly less abstract, since it provides a normative expression of the SOA RM with extensions.

The OASIS SOA RA is a conceptual architecture, but it is less abstract than the OASIS SOA RM and ontology since it provides significantly more detail on architectural components and their relationships, and provides less coverage since it details a subset of all of the architectural views available. Although The Open Group SOA RA is a generic architecture that is less abstract than the OASIS SOA RA, it provides architectural building blocks that are valid across industries and offers more coverage of architectural views, since it addresses IT and business concerns for SOA in an enterprise architecture.

The Open Group’s SOA governance framework is a generic, domain specific, partial reference architecture and can be categorized as a generic, partial RA. The OASIS SOA RA also includes SOA governance with a similar positioning. The other standards positioned in this section of the paper are just examples to further illustrate the continuum.


The “Navigating SOA” joint whitepaper accomplished its objectives by providing clarity and reassurance on the very confusing SOA standards landscape. The key concepts for SOA and SOA governance, as agreed on by these standards organizations, can be very helpful in understanding SOA fundamentals. Although they were a bit challenging to agree on, providing an explanation of the types of architecture standards and how they relate to each other is valuable in itself. In addition, the brief summary of the intent of each standard and its position relative to the other standards, acts as a mini “Cliff’s Notes” for these SOA standards.

One of the key, long-range benefits of the collaboration between OMG, OASIS and The Open Group, aside from the recently published paper, is the relationships between the organizations, their work groups, and authors. As these standards evolve, and new standards emerge, these relationships should help keep these SOA architectural standards as consistent as possible and reduce the need for a sequel.

However, there’s no magic here. While these standards are not inherently conflicting and can be used in complimentary ways, you still need to understand them, understand your business, and choose the right ones for your organization. The Navigating SOA whitepaper just makes that a little easier.

Heather Kreger is IBM’s lead architect for SOA Standards in Software Group with 15 years of standards experience. She has led the development of standards for Web services, management and Java in W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles and specifications, the book “Java and JMX, Building Manageable Systems”, and most recently, editor of "Navigating the SOA Open Standards Landscape around Architecture".