Summary TOGAF :Using TOGAF to Define & Govern SOAs
0 view 0 purchase
Course
TOGAF
Institution
TOGAF
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 r...
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
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller THEEXCELLENCELIBRARY. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $9.99. You're not tied to anything after your purchase.
