SOA Reference Architecture – Capabilities and the SOA RA

 

A capability, as defined by The Open Group, is: “an ability that an organization, person, or system possesses” [10]. From a TOGAF context: capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. Marketing, customer contact, outbound telemarketing, etc. are illustrative examples for capabilities. The term capability can represent pure business capability such as Process Claim or Provision Service Request and can also represent technical capability such as Service Mediation or Content-Based Routing. Both business and technical capabilities are represented in SOA and enabled and supported by SOA. Using a capability modeling as part of the approach has some major advantages:

  1. Allows us to focus on the “what” rather than the “how”. This supports an abstract approach that is focused on the requirements of the solution.
  2. Enables business capabilities to be aligned to the technical capabilities required to service them. Through the use of the SOA RA the associated enterprise-level and solution architectures can then be derived.
  3. Enables us to derive and re-balance the SOA roadmap in an agile fashion. For example, if an organization foresees the need for integrating services across different business units, it might require a certain set of SOA layers and Architecture Building Blocks (ABBs) to be enabled.

The capability mapping process itself is out of scope of this document, and is normally a part of the organizational service modeling methodologies. The ability to derive the solution architecture from the SOA RA itself is within the scope of the SOA RA.

For example, the business capability to cross-sell requires a technical capability to have a common shareable set of data, where the data is from different systems in an enterprise. This in turn requires shareable metadata about data, supporting “information services” in some form and the ability to transport, mediate, and share data from the disparate systems in a common “enterprise” form. Thus, a business capability (cross-selling) is dependent on technical capabilities (the need to be able to have a common view of data (information services), the need to mediate, integrate, and transport the data, etc.). Each of these capabilities maps to ABBs supported by the layers of the SOA RA.

A capability-based approach enables us to answer the question: “When do we need a particular SOA RA layer?” and to help facilitate making decisions when organizational priorities change. The SOA RA further helps us by determining whether there are inter-dependencies and technical requirements for a layer and its constituent building blocks, beyond those defined by business capabilities, to create a holistic set of capabilities which the SOA RA needs to satisfy.

Relationships among Requirements, Capabilities, Building Blocks, and Layers below shows the relationships among the core constructs of the SOA RA.

Relationships among Requirements, Capabilities, Building Blocks, and Layers

The layers in the SOA RA provide a convenient means of consolidating and categorizing the various capabilities and building blocks that are required to implement a given SOA. Below we will explore the details of these layers and their constituent elements.