• Introduction
• Service Oriented Architecture
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• Introduction
• Motivation
• Key Principles
• Basic Concepts
• Overview of the SOA RA Layers
• Capabilities and the SOA RA
• Description of Layers
• Operational Systems Layer
• Service Component Layer
• Services Layer
• Business Process Layer
• Consumer Layer
• Integration Layer
• Quality of Service Layer
• Information Layer
• Governance Layer
• Related Work and Usages of the SOA RA
• Relationship to Other SOA Standards
• Relationship to Open Group Guide: Using TOGAF to Define and Govern SOA
• Acknowledgements
• Referenced Documents
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• SOA Ontology Technical Standard
• Navigating the SOA Open Standards Landscape Around Architecture White Paper

SOA Work Group

SOA Work Group Members Page

SOA Reference Architecture Technical Standard : Motivation

Over the past 25 years, software architecture has grown rapidly as a discipline. With the pioneering work of Bell, Newell, and Sieworek [9] (Processor Memory Switch (PMS) notation and the birth of Architecture Description Languages (ADLs)), Shaw and Garlan on Software Architecture [7], and later additions, we recognize the need for architectural patterns and styles. An architectural style is the combination of distinctive features in which architecture is performed or expressed [8]. This can be visualized as a set of components (we will call Architecture Building Blocks (ABBs) to distinguish the generic nature of these), connectors, constraints [5], composition, containers, and configurations. Arsanjani [1] refers to these as the 6 Cs of an architectural style [6]. We know that a software system often has a predominant architectural style for its design. It has been shown that modularity or decoupling facilitates the creation of complex systems [4], such as that required by today’s business applications.

In recent years, the decoupling of interface from implementation at the programming level has been elevated to an architectural level by loosely coupling based on open standards the interface of a service consumed by a service consumer from its implementation by a service provider and by decoupling the implementation from its binding. This concept is reflected in a layer in the architecture corresponding to each of these notions; i.e., a layer for services and a layer for the runtime operational systems.

This style of architecture has come to be known as Service-Oriented Architecture (SOA), where rather than the implementations of components being exposed and known, only the service interfaces provided are published and consumers are insulated from the details of the underlying implementation by a provider.

Thus, an SOA enables business and IT convergence through agreement on a (contract consisting of a) set of business-aligned IT services that collectively support an organization’s business processes and business goals. Not only does it provide flexible decoupled functionality that can be re-used because it is based on open standards, but it also provides the mechanisms to externalize variations [6] of Quality of Service (QoS) in declarative specifications such as WS-Policy [12] and related standards.

Key Business Benefits of SOA

As a flexible and extensible architectural framework, SOA has the following defining capabilities:

• Reducing Cost:Through providing the opportunity to consolidate redundant application functionality and decouple functionality from obsolete and increasingly costly applications while leveraging existing investments.
• Agility:Structure business solutions based on a set of business and IT services in such as way as to facilitate the rapid restructuring and reconfiguration of the business processes and solutions that consume them.
• Increasing Competitive Advantage: Provide the opportunity to enter into new markets and leverage existing business capabilities in new and innovative ways using a set of loosely-coupled IT services. Potentially increase market share and business value by offering new and better business services.
• Time-to-Market:Deliver business-aligned solutions faster by allowing the business to decide on the key drivers of a solution and allowing IT to rapidly support and implement that direction.
• Consolidation:Integrate across silo’ed solutions and organizations, reduce the physical number of systems, and enable consolidation of platforms under a program of “graceful transition” from legacy spaghetti dependencies to a more organized and integrated set of coexisting systems.
• Alignment: SOA enables organizations to better align IT to business goals, enabling the business to associate IT with capabilities that an organization wants to achieve in alignment with its strategic plan, leading to both sustained agility and re-use over time.

However, significant challenges in creating an SOA solution still remain: correct service identification, selection, design, solution element selection and combination, modeling of services, governance, interoperability, and the ability to identify different components key to the effective design, usage, and evolution of SOA. For example, from a technical perspective, the architect needs to answer questions such as:

• What are the considerations and criteria for producing an SOA solution?
• How can an SOA solution be organized as an architectural framework with inter-connected architectures and transformation capabilities?
• How can an SOA solution be designed in a manner that maximizes asset re-use?
• How can automated tools take the guesswork out of architecture validation and capacity planning?

In order to address these issues, this standard presents a reference architecture for SOA-based solutions. It provides a high-level abstraction of an SOA partitioned and factored into layers, each of which provides a set of capabilities required to enable the working of an SOA. Each layer addresses a specific subset of characteristics and responsibilities that relate to unique value propositions within an SOA. As stated above, underlying this layered architecture is a meta-model consisting of layers, capabilities, ABBs, interactions, patterns, options, and architectural decisions and the relation between capabilities, ABBs, and layers. These will guide the architect in the creation and evaluation of the architecture. Note that per TOGAF, Chapter 3 (Definitions):

“(Capabilities) … are an ability that an organization, person, or system possesses (to deliver a product or service)” [10]

Likewise, an ABB represents a basic element of re-usable functionality, providing support for one or more capabilities, that can be realized by one or more components or products; examples of the responsibilities of an ABB include: service definition, mediation, routing, etc.