Using TOGAF to Define & Govern SOAs http://p
You are here: TOGAF® 9.1 > Part III: ADM Guidelines & Techniques > Using TOGAF to define and Govern SOAs
<<< Previous Home
22. Using TOGAF to Define & Govern SOAs
Chapter Contents
22.1 Overview | 22.2 Introduction | 22.3 SOA Definition | 22.4 SOA Features | 22.5 Enterprise Architecture and SOA | 22.6 SOA and Leve
22.1 Overview
This chapter discusses:
Service-Oriented Architecture (SOA) as an architectural style
Factors relating to the adoption and deployment of SOA within the enterprise
Using the TOGAF Architecture Development Method (ADM) to develop your SOA
This chapter, where appropriate, includes references to Technical Standards and Guides developed by The Open Group S
22.2 Introduction
As the business environment becomes more sophisticated, the challenges facing organizations are shifting away from ques
towards questions of complexity management and business agility.
Complex webs of existing applications and interfaces create highly complex landscapes where change becomes more and
become harder to predict and understand.
The concept of SOA provides an architectural style that is specifically intended to simplify the business and the interoperati
structuring capability as meaningful, granular services as opposed to opaque, silo'ed business units, it becomes possible to
an organization, avoid duplicating similar capabilities across the organization and quickly assemble new capabilities.
By standardizing the behavior and interoperation of services, it is possible to limit the impacts of change and also to unders
impacts.
From a software development perspective, SOA focuses on structuring applications in a way that facilitates system flexibilit
complex and fast-moving business environment. SOA aims to break down traditional application silos into portfolios of more
and interoperable ways, while extracting commodity capability into a virtualized infrastructure platform of shared re-usable u
22.3 SOA Definition
Note:
This section is provided for reader convenience. Part I, should be referred to for the formal definitions.
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.
Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer cr
drilling reports, etc.) and:
Is self-contained
May be composed of other services
Is a "black box" to consumers of the service
An architectural style is the combination of distinctive features in which architecture is performed or expressed.
22.4 SOA Features
SOA is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter
representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface,
SOA places unique requirements on the infrastructure. Because of this, it is recommended that implementations use open
location transparency. For instance, the availability of services must somehow be documented in a place easily accessible
services. An SOA-specific Directory Service and an Enterprise Service Bus (ESB) are two examples of technology impleme
relevant open standards to achieve the interoperability that SOA promises.
,Using TOGAF to Define & Govern SOAs http://p
Show how services should be designed
Without enterprise architecture, the negative effects may include one or more of the following:
Limited agility
Difficulty identifying and orchestrating SOA services
Service sprawl
Exponentially growing governance challenges
Limited SOA service interoperability
Limited SOA service re-use
Multiple silo'ed SOAs
Difficulty evolving and changing SOA implementations
22.6 SOA and Levels
The size and complexity of an enterprise affects the way the Enterprise Architect develops its architecture. Where there are
business models, it is not practical to integrate them within a single architecture. There are very few infrastructure items, wi
World-Wide Web, that can be applied across the whole of a large organization. Even these provide only a basic level of sup
may not be appropriate to develop a single, integrated SOA for a large and complex enterprise.
For such an enterprise, assuming an architecture landscape as shown in , the architect should look first at deve
a summary formal description of the enterprise, providing an organizing framework for operational and change activity, and
direction setting. This might, for example, identify particular segments where SOA should be used, and call for use of servic
it is highly unlikely to specify particular services or groups of services, or to prescribe a detailed infrastructure for SOA.
The architect could then develop segment architectures, each of which gives a detailed, formal description of areas within a
portfolio level to organize and align change activity. Each of these segment architectures could be a single, integrated SOA
For a smaller and less complex enterprise whose business operations can share a common infrastructure, you can use TO
groups of services that support the business activities.
From here on it is assumed that the scope is an enterprise of this kind. It could be self-standing or a segment of a larger en
22.6.1 Level of Detail of Implementation Specification
How completely should the architecture define what to implement? At one extreme, it could specify the future of the enterpr
the target, including the projects that will produce the changes, and a detailed time plan. At the other extreme, it could just
suggest priorities for addressing them.
Architecture development could fall anywhere between these two extremes. For the kind of enterprise SOA that we are con
specify the infrastructure and define the projects to implement it, with a detailed time plan. You might do the same for some
particularly where agility is important, you might identify solutions, and perhaps specify initial versions of them, but allow for
and for implementation projects to develop further versions of the solutions without having to ask for changes to the archite
22.6.2 SOA Activities at Different Levels
At the level of Strategic Architecture the basic SOA issue is identifying whether you need SOA and in which Segments. In t
The high-level relationships and boundaries within the organization
Cross-segment SOA capability requirements (what information and functionality is needed across segments)
Key capabilities best addressed by SOA
Key capabilities required for SOA
Segments best addressed by SOA
Principles and patterns of SOA service development and description, which may be defined at the Segment and Capab
The roles, responsibilities, processes, and tools of SOA governance
The organization-specific Reference Architecture
At the Segment level the basic SOA issue is describing the structure of SOA. In the Segment Architectures we define:
Which capabilities will use SOA as an architecture style
Cross-capability relationships (what information and functionality is needed across capabilities)
More detailed cross-segment relationships (what information and functionality is needed across Segment)
Cross-capability SOA service re-use possibilities
Principles and patterns of SOA service development and description, which may be defined at the Strategic and Capab
as part of Segment Architecture
For Capability Architecture the basic SOA issue is which services will be available. In the Capability Architectures we will de
You are here: TOGAF® 9.1 > Part III: ADM Guidelines & Techniques > Using TOGAF to define and Govern SOAs
<<< Previous Home
22. Using TOGAF to Define & Govern SOAs
Chapter Contents
22.1 Overview | 22.2 Introduction | 22.3 SOA Definition | 22.4 SOA Features | 22.5 Enterprise Architecture and SOA | 22.6 SOA and Leve
22.1 Overview
This chapter discusses:
Service-Oriented Architecture (SOA) as an architectural style
Factors relating to the adoption and deployment of SOA within the enterprise
Using the TOGAF Architecture Development Method (ADM) to develop your SOA
This chapter, where appropriate, includes references to Technical Standards and Guides developed by The Open Group S
22.2 Introduction
As the business environment becomes more sophisticated, the challenges facing organizations are shifting away from ques
towards questions of complexity management and business agility.
Complex webs of existing applications and interfaces create highly complex landscapes where change becomes more and
become harder to predict and understand.
The concept of SOA provides an architectural style that is specifically intended to simplify the business and the interoperati
structuring capability as meaningful, granular services as opposed to opaque, silo'ed business units, it becomes possible to
an organization, avoid duplicating similar capabilities across the organization and quickly assemble new capabilities.
By standardizing the behavior and interoperation of services, it is possible to limit the impacts of change and also to unders
impacts.
From a software development perspective, SOA focuses on structuring applications in a way that facilitates system flexibilit
complex and fast-moving business environment. SOA aims to break down traditional application silos into portfolios of more
and interoperable ways, while extracting commodity capability into a virtualized infrastructure platform of shared re-usable u
22.3 SOA Definition
Note:
This section is provided for reader convenience. Part I, should be referred to for the formal definitions.
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.
Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer cr
drilling reports, etc.) and:
Is self-contained
May be composed of other services
Is a "black box" to consumers of the service
An architectural style is the combination of distinctive features in which architecture is performed or expressed.
22.4 SOA Features
SOA is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter
representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface,
SOA places unique requirements on the infrastructure. Because of this, it is recommended that implementations use open
location transparency. For instance, the availability of services must somehow be documented in a place easily accessible
services. An SOA-specific Directory Service and an Enterprise Service Bus (ESB) are two examples of technology impleme
relevant open standards to achieve the interoperability that SOA promises.
,Using TOGAF to Define & Govern SOAs http://p
Show how services should be designed
Without enterprise architecture, the negative effects may include one or more of the following:
Limited agility
Difficulty identifying and orchestrating SOA services
Service sprawl
Exponentially growing governance challenges
Limited SOA service interoperability
Limited SOA service re-use
Multiple silo'ed SOAs
Difficulty evolving and changing SOA implementations
22.6 SOA and Levels
The size and complexity of an enterprise affects the way the Enterprise Architect develops its architecture. Where there are
business models, it is not practical to integrate them within a single architecture. There are very few infrastructure items, wi
World-Wide Web, that can be applied across the whole of a large organization. Even these provide only a basic level of sup
may not be appropriate to develop a single, integrated SOA for a large and complex enterprise.
For such an enterprise, assuming an architecture landscape as shown in , the architect should look first at deve
a summary formal description of the enterprise, providing an organizing framework for operational and change activity, and
direction setting. This might, for example, identify particular segments where SOA should be used, and call for use of servic
it is highly unlikely to specify particular services or groups of services, or to prescribe a detailed infrastructure for SOA.
The architect could then develop segment architectures, each of which gives a detailed, formal description of areas within a
portfolio level to organize and align change activity. Each of these segment architectures could be a single, integrated SOA
For a smaller and less complex enterprise whose business operations can share a common infrastructure, you can use TO
groups of services that support the business activities.
From here on it is assumed that the scope is an enterprise of this kind. It could be self-standing or a segment of a larger en
22.6.1 Level of Detail of Implementation Specification
How completely should the architecture define what to implement? At one extreme, it could specify the future of the enterpr
the target, including the projects that will produce the changes, and a detailed time plan. At the other extreme, it could just
suggest priorities for addressing them.
Architecture development could fall anywhere between these two extremes. For the kind of enterprise SOA that we are con
specify the infrastructure and define the projects to implement it, with a detailed time plan. You might do the same for some
particularly where agility is important, you might identify solutions, and perhaps specify initial versions of them, but allow for
and for implementation projects to develop further versions of the solutions without having to ask for changes to the archite
22.6.2 SOA Activities at Different Levels
At the level of Strategic Architecture the basic SOA issue is identifying whether you need SOA and in which Segments. In t
The high-level relationships and boundaries within the organization
Cross-segment SOA capability requirements (what information and functionality is needed across segments)
Key capabilities best addressed by SOA
Key capabilities required for SOA
Segments best addressed by SOA
Principles and patterns of SOA service development and description, which may be defined at the Segment and Capab
The roles, responsibilities, processes, and tools of SOA governance
The organization-specific Reference Architecture
At the Segment level the basic SOA issue is describing the structure of SOA. In the Segment Architectures we define:
Which capabilities will use SOA as an architecture style
Cross-capability relationships (what information and functionality is needed across capabilities)
More detailed cross-segment relationships (what information and functionality is needed across Segment)
Cross-capability SOA service re-use possibilities
Principles and patterns of SOA service development and description, which may be defined at the Strategic and Capab
as part of Segment Architecture
For Capability Architecture the basic SOA issue is which services will be available. In the Capability Architectures we will de
