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.
Guidance
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.