Navigating the SOA Open Standards Landscape Around Architecture – Guidance and Usage of Technical Products

 

Which architecture-related technical products are relevant to you depends on what you are trying to achieve on a project and in your organization. It also depends on your existing experience with SOA and your organization’s experience with SOA (i.e., level of maturity – the SOA maturity model, OSIMM, can provide some insight on this). In this section we provide advice based on what a reader is looking to learn or understand. We recognize that there are other valid approaches to understanding and using these specifications, and that the approach that is most effective depends on the stakeholders, their needs, and particular viewpoints.

Core Concepts

  • Understanding SOA core concepts: The OASIS Reference Model for SOA [5] provides a common vocabulary for understanding the “essence” of SOA. It is, by design, a highly abstract model targeting a large, cross-cutting audience that includes non-technical readers as much as it does technical readers. The Open Group SOA Ontology [14] builds on the OASIS Reference Model for SOA and provides additional SOA concepts and relationships taken from the viewpoints of different stakeholders as well as an enterprise-wide perspective. It also provides as a common language for formally describing SOA concepts that can be leveraged by abstract as well as solution-oriented reference architectures.

    Other specifications [6] [9] [16] [17] also articulate core SOA concepts to provide context for their specifications; these concepts are consistent with the SOA concepts outlined in this document.

Architectures

  • Understanding the different elements of an SOA: The Open Group SOA Reference Architecture [17] defines the key architectural elements in SOA and the key relationships between these elements relevant to enterprises. The OASIS Reference Architecture for SOA Foundation [6] does this as well for the SOA ecosystem and ownership viewpoints.
  • Understanding considerations for cross-ownership boundaries of SOA ecosystems: While both SOA reference architectures provide guidance that is important for SOA implementations that span ownership boundaries, the OASIS Reference Architecture for SOA Foundation [6] is especially focused on this scenario and provides architectural considerations for interacting with services owned by another company.
  • Understanding the completeness of SOA architectures and implementations: The OASIS Reference Architecture for SOA Foundation [6] provides models that function as a checklist that can be used to evaluate architectures and implementations of SOA.
  • Understanding the deployment of SOA in an enterprise: The Open Group SOA Reference Architecture [17] provides a stack organization of SOA architectural building blocks for an enterprise and guidance on the use and deployment of these building blocks.
  • Understanding the basis for an industry or organizational reference architecture: The Open Group SOA Reference Architecture [17] provides guidance on refining this SOA reference architecture into an industry or solution SOA reference architecture.
  • Understanding the implications of architectural decisions: The Open Group SOA Reference Architecture [17] provides guidance to SOA designers and implementers by providing a concrete basis for making architectural and design decisions. It provides a model and framework for evaluating architectural concerns for designing an SOA.
  • Understanding how to position vendor products in an SOA context: The Open Group SOA Reference Architecture [17] provides a layered stack with architectural building blocks and capabilities that map naturally to vendor products available to support SOA.
  • Understanding SOA governance: Both The Open Group SOA Governance Framework [15] and the OASIS Reference Architecture for SOA Foundation [6] contain very similar basic concepts of SOA governance. There are some differences in the targets of SOA governance. The Open Group SOA Governance Framework focuses on governing SOA processes which call into scope the service portfolio and IT infrastructure that the SOA is deployed onto. The OASIS Reference Architecture for SOA Foundation focuses on governing services and IT infrastructure directly. The Open Group SOA Governance Framework also provides guidance on the deployment of SOA governance in an enterprise in an iterative, progressive cycle.

Maturity

  • Understanding the level of SOA maturity in an organization: OSIMM [16] provides an SOA integration maturity model that describes the scope of SOA, so that companies can understand what SOA features they are using and the ones they want to use.

Modeling Languages

  • Understanding representing SOA artifacts in UML: The OMG SoaML [9] provides a profile that extends UML for modeling SOA artifacts and services for your SOA as part of the transformation from a reference architecture to your SOA solution architecture. These models can be considered the result of following governed processes for creating and evaluating the SOA.

 

⇒ Summary