Over the past 25 years, software architecture has grown rapidly as a discipline. With the pioneering work of Bell, Newell, and Sieworek  (Processor Memory Switch (PMS) notation and the birth of Architecture Description Languages (ADLs)), Shaw and Garlan on Software Architecture , 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 . 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 , composition, containers, and configurations. Arsanjani  refers to these as the 6 Cs of an architectural style . 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 , 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  of Quality of Service (QoS) in declarative specifications such as WS-Policy  and related standards.
As a flexible and extensible architectural framework, SOA has the following defining capabilities:
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:
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)” 
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.