Soa and togaf practical guide

Technical Guide
Using TOGAF to Define & Govern Service Oriented
Architectures

Copyright © 2011, The Open Group
All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by
any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the
copyright owner.
It is fair use of this specification for implementers to use the names, labels, etc. contained within the
specification. The intent of publication of the specification is to encourage implementations of the
specification.
This specification has not been verified for avoidance of possible third-party proprietary rights. In
implementing this specification, usual procedures to ensure the respect of possible third-party intellectual
property rights should be followed.
Technical Guide
Using TOGAF to Define & Govern Service Oriented Architectures
ISBN: TBA
Document Number: TBA
Published by The Open Group, Month Year.
Comments relating to the material contained in this document may be submitted to:
The Open Group
Thames Tower
37-45 Station Road
Reading
Berkshire, RG1 1LX
United Kingdom
or by electronic mail to:
ogspecs@opengroup.org
Using TOGAF to Define & Govern Service Oriented Architectures Guide
iii

Contents
Contents................................................................................................................iv
Preface..................................................................................................................vi
Trademarks.........................................................................................................viii
Acknowledgements...............................................................................................ix
Referenced Documents..........................................................................................x
1 Introduction and Objective...................................................................................2
2 Overview..............................................................................................................3
2.1 The Open Group SOA Work Group.............................................3
3 Service Oriented Architecture Defined................................................................5
4 Using TOGAF for Enterprise SOA .....................................................................7
4.1 The Preliminary Phase ................................................................8
4.2 Phase A: Vision.........................................................................16
4.3 The Architecture Development Domains of TOGAF 9: Phases B:
Business Architecture, C: Systems Architectures and D: Technology
Architecture........................................................................................20
4.4 Phase B: The Business Architecture..........................................22
4.5 Phase C: The Information Systems Architectures......................26
4.6 Phase D: The Technology Architecture.....................................30
4.7 Phase E: Opportunities and Solutions........................................33
4.8 Phase F: Migration Planning......................................................36
4.9 Phase G: Implementation Governance.......................................36
4.10 Phase H: Architecture Change Management............................37
5 Summary............................................................................................................38
Table of Figures
Figure 1 TOGAF 9 ADM.........................................................................................7
iv Technical Guide (2010)

Figure 2. Open Group SOA Maturity Model..........................................................10
Figure 3. SOA Governance Supports IT and EA Governance................................11
Figure 4. SOA Governance Reference Model........................................................12
Figure 5. SOA Governance Vitality Method..........................................................13
Figure 6. SOA Reference Architecture...................................................................14
Figure 7. Scoping the Enterprise Architecture........................................................18
Figure 8. TOGAF 9 Metamodel with Relationships of Primary Entities................21
Figure 9. Phase B: Business Architecture Metamodel Extensions.........................23
Figure 10. Phase C: Information Systems Architecture Metamodel Extensions.....27
Figure 11. Technology Architecture Metamodel Extensions..................................31
Figure 12. Service Oriented Infrastructure Reference Model.................................32
Figure 13. Opportunities and Solutions Metamodel Extension..............................34
v

Preface
The Open Group
The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of
Boundaryless Information Flow™ will enable access to integrated information within and
between enterprises based on open standards and global interoperability. The Open Group works
with customers, suppliers, consortia, and other standards bodies. Its role is to capture,
understand, and address current and emerging requirements, establish policies, and share best
practices; to facilitate interoperability, develop consensus, and evolve and integrate
specifications and Open Source technologies; to offer a comprehensive set of services to
enhance the operational efficiency of consortia; and to operate the industry's premier
certification service, including UNIX®
certification.
Further information on The Open Group is available at www.opengroup.org.
The Open Group has over 15 years' experience in developing and operating certification
programs and has extensive experience developing and facilitating industry adoption of test
suites used to validate conformance to an open standard or specification.
More information is available at www.opengroup.org/certification.
The Open Group publishes a wide range of technical documentation, the main part of which is
focused on development of Technical and Product Standards and Guides, but which also
includes white papers, technical studies, branding and testing documentation, and business titles.
Full details and a catalog are available at www.opengroup.org/bookstore.
As with all live documents, Technical Guides require revision to align with new developments
and associated international standards. To distinguish between revised specifications which are
fully backwards-compatible and those which are not:
• A new Version indicates there is no change to the definitive information contained in the
previous publication of that title, but additions/extensions are included. As such, it replaces the
previous publication.
• A new Issue indicates there is substantive change to the definitive information contained
in the previous publication of that title, and there may also be additions/extensions. As such,
both previous and new documents are maintained as current publications.
Readers should note that updates – in the form of Corrigenda – may apply to any publication.
This information is published at www.opengroup.org/corrigenda.
vi Technical Guide (2010)

This Document
This document is the Technical Guide for Using TOGAF to Define & Govern Service Oriented
Architectures. It has been developed and approved by The Open Group.
vii

Trademarks
Boundaryless Information Flow™
and TOGAF™
are trademarks and Making Standards Work®
,
The Open Group®
, UNIX®
, and the “X” device are registered trademarks of The Open Group in
the United States and other countries.
The Open Group acknowledges that there may be other brand, company, and product names
used in this document that may be covered by trademark protection and advises the reader to
verify them independently.
viii Technical Guide (2010)

Acknowledgements
The Open Group gratefully acknowledges the contribution of the following people in the
development of this document:
• Awel Dico, Bank of Montreal
• Ed Harrington, Architecting the Enterprise
• Dave Hornford, xxx
• Additional contributors???
ix

Referenced Documents
The following documents are referenced in this Technical Guide:
• Business Process Modeling Notation (BPMN), Version 1.1, Object Management Group;
available from www.omg.org.
• Definition of SOA: The Open Group; available from
www.opengroup.org/soa/soa/def.htm#_Definition_of_SOA.
• IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of
Software-intensive Systems (adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007); available
from standards.ieee.org.
• IETF RFC 2119: Key Words for use in RFCs to Indicate Requirement Levels, March
1997; refer to www.ietf.org.
• ISO/IEC 42010:2007: Systems and Software Engineering – Recommended Practice for
Architectural Description of Software-intensive Systems; available from www.iso.org.
• Navigating the SOA Open Standards Landscape Around Architecture (W096), White
Paper published by The Open Group, November 2009.
• OASIS Reference Model for Service-Oriented Architecture, Version 1.0, Organization for
the Advancement of Structured Information Standards (OASIS); available from www.oasis-
open.org.
• OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004,
World-Wide Web Consortium; available from www.w3.org/TR/owl-ref.
• Service-Oriented Architecture Modeling Language (SoaML), Object Management Group;
available from www.omg.org.
• The Open Group Architecture Framework (TOGAF), The Open Group; available from
www.opengroup.org.
• OTHER REFERENCES – to include SOA Source Book, OSIMM, SOA Reference
Architecture, etc.
x Technical Guide (2010)

1

1 Introduction and Objective
The purpose of this Technical Guide is to contribute to The Open Group mission of
Boundaryless Information Flow, by providing guidance on how the Architect can use The Open
Group Architecture Framework (TOGAF – now in Version 9) to develop, manage and govern
Service Oriented Architectures (SOA). This should facilitate the common understanding of the
process for the development of SOAs in and greatly improve alignment between the business
and information technology communities. Utilization of the process, metamodel, references and
other TOGAF facilitate will lead to the further adoption of SOA as an architectural style.
TOGAF adoption for SOA provides a number of facilities to assist the architect:
1. This Guide adapts the well-recognized set of best process for the development,
management, governance and adoption of Enterprise Architecture and applies it
specifically to SOA
2. This Guide provides specific information on the adaption of TOGAF to develop SOA in
the following areas:
o Use of the Architecture Development Method (ADM) to develop SOAs
o Modification of the TOGAF Content metamodel for SOAs
o Modification of the TOGAF Content Relationship metamodel for SOAs
o Adoption of SOA specific general and technical reference models and their use
within a TOGAF environment
o Adoption of SOA specific Governance requirements for a TOGAF environment
o Adoption of SOA specific Maturity models for application within a TOGAF
environment
This Guide is designed for use by:
• Business people and business analysts to develop/identify/analyze the inherent linkage of
business services delivered as information technology services
• Solutions/Data/Security/Technology Architects for the recognition of stakeholder
viewpoints and the delivery of views/artifact that address stakeholder concerns specific to
business and technology services
• Enterprise Architects for the recognition of the re-usability of services across the
organization and the prevention of the proliferation of information silos
• System and software designers for guidance in the delivery of architecture compliant SOA
solutions
2 Technical Guide (2010)

2 Overview
As the business environment becomes more sophisticated, the challenges facing organizations
are shifting away from questions of efficiency and automation towards questions of complexity
management and business agility.
Complex webs of existing applications and interfaces create highly complex landscapes where
change becomes more and more difficult and the impacts of change become harder to predict
and understand.
The concept of SOA provides an architectural style that is specifically intended to simplify the
business and the interoperation of different parts of that business. By structuring capability as
meaningful, granular services as opposed to opaque, siloed business units, it becomes possible
to quickly identify functional capabilities of 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 understand in advance the likely chain of impacts.
From a software development perspective, SOA focuses on structuring applications in a way
that facilitates system flexibility and agility — a necessity in today’s complex and fast-moving
business environment. SOA aims to break down traditional application silos into portfolios of
granular services that operate in open and interoperable ways, while extracting commodity
capability into a virtualized infrastructure platform of shared re-usable utility services.
2.1 The Open Group SOA Work Group
The Open Group SOA Work Group was formed in October 2005 to develop and foster a
common understanding of SOA. This was (and remains) fully aligned with the Open Group’s
strategic objective to develop “Boundaryless Information Flow” through the production of
definitions, analyses, recommendations, reference models and standards. This activity is
specifically directed at ensuring that the information technology utilized by the enterprise is
specifically in place to support the requirements of the business. For more information, see:
http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1313 in the
SOA Source Book.
The SOA Work group is open to all Platinum, Gold and Silver Open Group members and since
its start-up has had participation from over 400 individuals from over 60 member companies.
Information concerning the work of the SOA Work Group can be obtained at:
www.opengroup.org/projects/soa.
The SOA Work Group has undertaken numerous projects that provide valuable input to those
who may be interested in utilizing TOGAF in developing their Service Oriented Architectures. At
a summary level, these include:
3

► Completed Projects
■ Definition of SOA
■ SOA Case Studies
■ Value That The Open Group Can Add to SOA
■ SOA Governance
► Current Work Program
■ Ontologies for SOA
■ SOA/TOGAF Practical Guide
■ Service-Oriented Cloud Computing Infrastructure
■ SOA Reference Architecture
■ Security for the Cloud and SOA
■ Legacy Evolution to SOA
► Other Open Group SOA Activities
■ SOA Maturity Model – OSIMM (Board project)
■ SOA Source Book
■ SOA Tutorials
The following sections will discuss each of these, emphasizing their relevance to developing
Service Oriented Architectures using TOGAF.

3 Service Oriented Architecture Defined
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 credit; provide weather data, consolidate drilling reports, etc.)
and is:
• 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.
3.1.1 SOA Features
SOA is based on the design of the services – which mirror real-world business activities –
comprising the enterprise (or inter-enterprise) business processes. Service representation
utilizes business descriptions to provide context (i.e., business process, goal, rule, policy,
service interface, service component, etc.).
SOA places unique requirements on the infrastructure. Because of this, it is recommended that
implementations use open standards to realize interoperability and location transparency. For
instance, the availability of services must somehow be documented in a place easily accessible
by those requiring the use of those services. A SOA specific Directory Service and an
Enterprise Service Bus are two examples of technology implementations that require adherence
to relevant open standards to achieve the interoperability that SOA promises.
Implementations are enterprise environment-specific – they are constrained or enabled by
context and must be described within that context. Given that, SOA requires strong governance
of service representation and implementation.
3.1.2 How Enterprise Architecture Supports Service Orientation
Enterprise Architecture provides frameworks, tools and techniques to assist organisations with
the development and maintenance of their Service Oriented Architectures. Some of the key
benefits that Enterprise Architecture provides include:
• Consistent abstractions of high-level strategies and deliverables to support planning and
analysis
5

• Linkage of different perspectives to a single business problem (e.g., business, data,
application, technology, abstract, concrete, etc.) providing a consistent model to address
various domains and tests for completeness
• Identification of clear roadmaps to achieve future state.
• Traceability that links IT and other assets to the business they support.
• Support for impact assessment, risk/value analysis and portfolio management
• Identified and documented principles, constraints, frameworks, patterns, and standards
• Governance frameworks and processes that ensure appropriate authority for decision
making
EA becomes a foundation for service-orienting an organisation, because it links stakeholders
together, ensuring that the needs of each stakeholder community are met and that each
stakeholder community is aware of appropriate context. This linkage is the foundation for
interoperability and reuse.
Through its linking of the business context to IT, EA readily identifies and provides justification for
the cost of change programs in relation to the business value to be derived from the effort. EA
may provide the context and analysis capabilities to:
• Show how SOA solutions can be effectively architected to support business capabilities
• Show which services should be built and which should be re-used
• 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

4 Using TOGAF for Enterprise SOA
An effective enterprise architecture is critical to business survival and success, and is
the indispensable means to achieving competitive advantage through IT. The Open
Group Architecture Framework (TOGAF) is a detailed method and a set of supporting
tools for developing enterprise architectures. It codifies the good practice that has
evolved in the work of enterprise and IT architects over many years. It will help you to
decide where and how to use SOA.
The TOGAF Architecture Development Method (ADM) breaks the complex process of
architecture development into a number of simpler steps, or phases, in which you
consider different aspects of the overall problem. Those familiar with TOGAF will
recognize the following graphical depiction of the ADM:
• The Preliminary Phase
• Architecture Requirements
Management
• Phase A: The Architecture Vision
• Phase B: The Business Architecture
• Phase C: The Information Systems
Architectures
• Phase D: The Technology Architecture
• Phase E: Opportunities and Solutions
• Phase F: Migration Planning
• Phase G: Implementation Governance
• Phase H: Architecture Change
Management
This section describes, for each
phase of the TOGAF ADM, what
you should consider particularly
when looking to apply the principle
of service orientation, and how this
affects the outputs of the phase. In
short, it explains how to use
TOGAF to do SOA.
7
Figure 1 TOGAF 9 ADM

This is not a self-standing description. It assumes knowledge of TOGAF, and leaves out
everything that is not related to SOA. To follow it, you must know about TOGAF. You
can find all the information you need on the TOGAF website.
4.1 The Preliminary Phase
TOGAF’s Preliminary phase is about defining “where, what, why, who, and how we do
architecture” in the enterprise concerned. It does the preparation needed for new
enterprise architecture work.
TOGAF provides for incremental architecture development. Each cycle through phases
A-H creates an increment to the enterprise architecture. (The cycles typically overlap,
with Phases A-F of each new cycle being carried out in parallel with the implementation
governance phase - Phase G - of the previous cycle.) The Preliminary Phase does
what is needed before the cycles can start. It is usually carried out when TOGAF is first
adopted by a particular architecture team for a particular enterprise. Its activities may
be re-visited as needed for subsequent architecture engagements.
The Preliminary Phase is where you adopt the principle of service orientation. This
affects two other outputs of the phase: the governance and support strategy, and the
content of the Initial Architecture Repository.
4.1.1 The Principle of Service Orientation
The starting point for SOA development with TOGAF is that the enterprise adopts
service orientation as an architecture principle.
Architecture principles define the underlying general rules and guidelines for the use
and deployment of all IT resources and assets across the enterprise. They reflect a
level of consensus among the various elements of the enterprise, and form the basis for
making future IT decisions. The Preliminary Phase defines the architecture principles
that will form part of the constraints on any architecture work undertaken in the
enterprise. They are typically developed by the lead enterprise architect, in conjunction
with the enterprise CIO, Architecture Board, and other key business stakeholders. They
are included in the Tailored Architecture Framework, which is an output of the
Preliminary Phase.
TOGAF Version 9 has an example set of architecture principles, which includes a
principle of service orientation, number 6 in the Business Principles examples:
Principle: Service Orientation
Statement: The architecture is based on a design of services which mirror real-world
business activities comprising the enterprise (or inter-enterprise) business
processes.
Rationale: Service orientation delivers enterprise agility and Boundaryless Information Flow

Implications: - Service representation utilizes business descriptions to provide context (i.e.,
business process, goal, rule, policy, service interface, and servicecomponent)
and implements services using service orchestration.
- Service orientation places unique requirements on the infrastructure, and
implementations should use open standards to realize interoperability and
location transparency.
- Implementations are environment-specific; they are constrained or enabled by
context and must be described within that context.
- Strong governance of service representation and implementation is required.
- A ‘‘Litmus Test’’, which determines a ‘‘good service’’, is required.
An enterprise wishing to use TOGAF for SOA should include this principle, either as it
stands or in modified form, in its set of architecture principles.
4.1.2 SOA Maturity Assessment
If you are introducing TOGAF to an enterprise that is already committed to SOA, or that
is part of a larger enterprise that has made a strategic decision to use SOA, then
adoption of the principle of service orientation is a no-brainer. If, on the other hand, you
are introducing SOA to an enterprise that is not already committed to it, then the
decision to adopt this principle should not be taken lightly.
Successful SOA depends in part on the readiness of the enterprise to become service-
oriented. You can conduct a SOA maturity assessment during the Preliminary phase,
using the Open Group Service Integration Maturity Model (OSIMM) described in the
SOA Source Book (see: http://www.opengroup.org/projects/soa-book/ ), and specifically
available at: http://www.opengroup.org/soa/projects/osimm.htm as part of the review of
the organizational context for conducting enterprise architecture. This will help to
establish the rationale for the enterprise to adopt the principle of service orientation.
OSIMM examines seven areas potential maturity and helps to categorize these into
seven levels of maturity. Graphically, it is briefly depicted as follows:
9

Figure 2. Open Group SOA Maturity Model
As with the introduction of any significant new idea, it is good to start with a small
project, and learn from your mistakes, before implementing on a wide scale. You can
undertake a complete but rapid TOGAF cycle, provisionally assuming service
orientation, without spending too much effort on detailed analysis, to define a pilot SOA
project. Successful implementation of that project will then lead to final adoption of the
principle.
From here on we assume that the principle of service orientation is adopted.
4.1.3 Governance and Support Strategy
TOGAF does not describe implementation or operational governance. It assumes that a
governance framework is in place. The Preliminary phase includes confirming the
architecture governance and support strategy, as part of the Organizational Model for
Enterprise Architecture. The Architect should review the existing governance
procedures, and confirm that they are appropriate for SOA. If they are not, then you
should make recommendations for changing them.

It may not be appropriate to undertake the detailed development of governance rules
and procedures as part of the Preliminary Phase. It could be better to confirm the
architecture governance procedures (which are not much affected by SOA), and to
commission a separate project to define implementation and operational governance
procedures before implementation starts.
Since SOA Governance is considered critical to its success and as an aid to the
Enterprise Architect, the Open Group SOA Work Group has developed a governance
framework that focuses on SOA and may be used to enhance existing governance
frameworks. A summary of The Open Group SOA Governance work is available at:
http://www.opengroup.org/soa/source-book/gov_summary/index.htm with the detailed
SOA Governance Technical Standard available at:
http://www.opengroup.org/soa/source-book/gov/index.htm .
A high level view of how SOA Governance extends and support both Enterprise
Architecture and IT governance is below:
EA Governance
Business Governance
IT Governance
Supports
SOA Governance
Extends
Supports
Extends
Aligns
Figure 3. SOA Governance Supports IT and EA Governance
There is also a Governance Reference Model that is depicted below:
11

Figure 4. SOA Governance Reference Model
In addition to describing in detail the various aspects of SOA Governance, the Model
also suggests a “Vitality Method” (SGVM) which is a process that utilizes the SOA
Governance Reference Model (SGRM) as a baseline and then follows a number of
phased activities to customize this baseline model to cater to the organization’s variants.
SOA governance should be viewed as a process and not a project; therefore, the phases
of the SGVM should be viewed as a continuous improvement loop, whereby progress is
measured, and course-correction and updates to the SOA Governance Regimen and
SOA Governance Roadmap are performed when needed. Below is a high level graphic
of the SGVM:

Figure 5. SOA Governance Vitality Method
4.1.4 Initial Architecture Repository and the SOA Reference Architecture
The enterprise's Architecture Repository contains a collection of models, patterns,
architecture descriptions, and other artifacts that are available for the development of its
architectures. They may result from previous architecture work in the enterprise or from
work in other enterprises, or in industry bodies. The Preliminary phase of TOGAF
includes the establishment of an architecture repository with an initial collection of
material.
The SOA Work Group has compiled numerous materials that may be relevant in initially
populating the Architecture Repository. The Source Book describes the Service-
Oriented Architecture (SOA) Reference Architecture (see:
http://www.opengroup.org/soa/source-book/ra/index.htm ), which is a significant underlying
logical structure for the development and assessment of architectures designed and
built using a combination of traditional and service-oriented computing principles and
concepts. It contains the following sections:
► The Building Blocks of SOA, which describes a set of architecture building
blocks that represent the key elements of SOA
► A High-Level Perspective of the SOA Reference Architecture, which gives an
overview of the nine layers of the reference architecture, with examples and
rationale describing the main responsibilities of the layers and their primary
building blocks
13

► Detailed Building Blocks of the SOA Reference Architecture, which presents
detailed models that show how some of the features of SOA can be
implemented using the reference architecture
► Infrastructure for SOA, which describes architecture building blocks that
correspond to infrastructure products that are available today to support
service-oriented applications
A high level graphic that describes the SOA Reference Architecture follows:
Figure 6. SOA Reference Architecture
The nine “layers” are described as follows:
► Operational Systems Layer
■ Programs and data of the operational systems of the enterprise
■ The new and existing infrastructure needed to support the SOA solution.
► Service Components Layer
■ Software components, each of which provides the implementation or
“realization” for a service, or operation on a service, and binds the service
contract to the implementation of the service in the operational systems
layer.
► Services Layer

■ Services, with their descriptions, contracts, and policies, and the containers
that contain the service components.
► Business Processes Layer
■ Business processes , and compositions in which business processes are
composed of other business processes and of services.
► Consumer Interfaces Layer
■ The programs by which the users interface to the services
► Integration Layer
■ Integration of and communication between other building blocks, including
messaging, message transformation, complex event processing, service
composition and service discovery.
► Quality of Service Layer
■ Monitoring and management of the quality of service of the architected
system, including its performance, reliability, availability, scalability, security,
and manageability.
► Information Layer
■ Management, analysis, interpretation and transformation of data
► Governance Layer
■ Governance rules and procedures; and
■ Services and programs that support the application of the rules and the
operation of the procedures.
4.1.5 Partitions & Centers of Excellence: Establishing the Architecture “Team”
TOGAF establishes the Architecture “Footprint” – team structure, roles, responsibilities, etc. in
the Preliminary Phase. With SOA we suggest a specific method of establishing that footprint:
the SOA Center of Excellence.
Different teams will work on different elements of architecture at the same time. Partitions allow
for specific groups of architects to own and develop specific elements of the architecture (see
Particians and Scoping in Phase A). It is suggested that the team start with a focused initiative
before implementing on a wide scale.
15

The team responsible for SOA should initially be structured as a Centre of Excellence (CoE).
A successful CoE will have several key attributes:
• A clear definition of the CoE’s mission: why it exists, its scope of responsibility and what the
organization and the architecture practice should expect from the CoE.
• Clear goals for the CoE including measurements and key performance indicators (KPIs). It is
important to ensure that the measures and KPI’s of the CoE do not drive inappropriate
selection of SOA as the Architecture style.
• The CoE will provide the ‘litmus test’ of a good service.
• The CoE will disseminate the skills, experience and capabilities of the SOA Centre to the
rest of the architecture practice.
• Identify how members of the CoE, and other Architecture practitioners will be rewarded for
success.
• Recognition that, at the start, it is unlikely the organization will have the necessary skills to
create a fully functional CoE. The necessary skills and experience must be carefully
identified, and where they are not present, acquired. A fundamental skill for leading
practitioners within the CoE is the ability to mentor other practitioners transferring
knowledge, skills and experience.
• Close-out plan for when the CoE has fulfilled its purpose.
4.1.6 Preliminary Phase Summary
In summary, when developing the TOGAF Preliminary Phase, there are a number of
methods, tools and reference materials that have been developed by the SOA Work
Group to help the Enterprise Architect develop their Service Oriented Architecture.
These include:
► Principles: Service Orientation
► Determining Orgainization Readiness for SOA: OSIMM
► Governance: The Open Group SOA Governance Model and Vitality Method
► Adapting TOGAF to the Organization: The SOA Reference Architecture
► Establishing a SOA Center of Excellence as an initial “Footprint”
4.2 Phase A: Vision
The Architecture Vision phase is concerned with establishing the architecture project
and obtaining approval to proceed.
This phase captures the scope of the architectural initiative, which depends on the
nature of the enterprise and the level of detail of implementation specification. It creates
a compelling vision of what you will have at end-of-job, after all the projects necessary

to instantiate the architecture have been completed. And it identifies the key
stakeholders, concerns and business requirements.
4.2.1 The Nature of the Enterprise
The scope of an enterprise architecture development depends on the size and structure
of the enterprise.
TOGAF defines “enterprise” as any collection of organizations that has a common set
of goals. For example, an enterprise could be a government agency, a whole
corporation, a division of a corporation, a single department, or a chain of
geographically distant organizations linked together by common ownership. An
“enterprise architecture” can encompass all of the information and technology services,
processes, and infrastructure of an entire enterprise, or just cover a specific domain
within an enterprise. In both cases, the architecture crosses multiple systems and
functional groups.
The size and complexity of an enterprise affects the way the Enterprise Architect
develops its architecture. Where there are many different organizational and business
models, it is not practical to integrate them within a single architecture. There are very
few infrastructure items, such as the Internet and the World-Wide Web that can be
applied across the whole of a large organization and they provide only a basic level of
support for business processes. It is therefore generally not appropriate to develop a
single, integrated SOA for a large and complex enterprise.
For such an enterprise, you should look first at developing a strategic architecture that
gives a summary formal description of the enterprise, providing an organizing
framework for operational and change activity, and an executive-level, long-term view
for direction setting. This might, for example, identify particular segments where SOA
should be used, and call for use of web services for interaction between segments, but
it is highly unlikely to specify particular services or groups of services, or to prescribe a
detailed infrastructure for SOA. You could then develop segment architectures, each of
which gives a detailed, formal description of areas within an enterprise, used at the
program or portfolio level to organize and align change activity. Each of these segment
architectures could be a single, integrated SOA. This concept is depicted below:
17

Figure 7. Scoping the Enterprise Architecture
For a smaller and less complex enterprise whose business operations can share a
common infrastructure, you can use TOGAF to create an integrated SOA with groups of
services that support the business activities.
From here on we assume that your scope is an enterprise of this kind. It could be self-
standing or a segment of a larger enterprise.
4.2.2 Level of Detail of Implementation Specification
How completely should the architecture define the implementation? At one extreme, it
could specify all of the systems to be produced, define all the projects that will produce
them, and create a detailed time plan for those projects. At the other extreme, it could
just indicate areas where work is needed, and suggest priorities for addressing them.
An SOA development could fall anywhere between these two extremes. For the kind of
enterprise SOA that we are considering here, it is likely that you would specify the
infrastructure and define the projects to implement it, with a detailed time plan. You
might do the same for some or all of the solutions. Alternatively, particularly where
agility is important, you might identify solutions, and perhaps specify initial versions of
them, but allow for additional solutions to be identified later, and for implementation
projects to develop further versions of the solutions without having to ask for changes to
the architecture.
In the first case, solution project definition and planning is carried out in TOGAF Phase
E (Opportunities and Solutions) and Phase F (Migration Planning), and the architecture
team has a supervisory role for those projects in Phase G (Implementation

Governance). In the second case, the architecture team supervises solution project
definition and planning, other than for those specified initially, in Phase G rather than
doing that definition and planning in Phases E and F. (This, however, is not the TOGAF
preferred methodology.)
Where the architecture does not specify all solutions in detail, you may wish to create
an architecture that provides a detailed definition of common infrastructure that can be
referenced by solution developments. There is a subtle distinction between such an
architecture - an enterprise reference architecture - and an enterprise architecture. The
enterprise architectecture applies to a whole enterprise and identifies its components.
The enterprise reference architecture applies to each of the components of the
enterprise and describes aspects that they have in common. You would produce the
enterprise reference architecture in parallel with the enterprise architecture, but as a
separate set of artifacts. The Open Group SOA Work Group Reference Architecture,
referred to above, is an example of a potential enterprise reference architecture.
4.2.3 The Vision
The Architecture Vision includes a high-level description of the final architecture that is
envisaged.
There is an obvious difference between an SOA architecture description and a
description of an architecture of another style. The SOA description uses different
language, with words such as “service”, “composition”, and “contract”, and it has
different models, such as matrices showing use of services by business processes and
use of applications by services. The recently published SOA Ontology (a free .pdf
download is available at: http://www.opengroup.org/bookstore/catalog/c104.htm ) can
provide taxonomical and ontological assistance with the language of SOA.
Although it may not include the kinds of detailed model produced in Phase B, Phase C
and Phase D, the high-level description produced in Phase A will reflect the service-
oriented nature of the architecture that is envisaged.
4.2.4 Stakeholders, Concerns and Business Requirements
Phase A is followed by the three TOGAF phases that produce detailed architecture
descriptions for the Architecture Definition Document. In each of these phases, you:
• Develop models of the target system in the light of requirements;
• Discuss concerns with stakeholders, using views of the system that are derived
from the models;
• Refine the models; and
• Identify further requirements to be addressed.
19

This is an iterative process, repeated until you are satisfied that the concerns relevant
to the phase have been discussed and the requirements relevant to the phase are
addressed.
The requirements to address, the stakeholders to consult, and the models and views to
develop vary from one architecture engagement to another. In Phase A of each
engagement you identify the key stakeholders and their concerns, state the key
business requirements to be addressed, and consider which architecture views and
viewpoints to develop.
There are concerns that are peculiar to SOA, or are more likely to arise in SOA
developments. A section of the SOA Source Book on lists some areas of concern that
you are likely to encounter. This is available at: http://www.opengroup.org/projects/soa-
book/page.tpl?CALLER=page.tpl&ggid=1338
4.3 The Architecture Development Domains of TOGAF 9: Phases B:
Business Architecture, C: Systems Architectures and D:
Technology Architecture
In this section we consider the SOA impact on Phases B, C and D, the Architecture
Development Domains.
The following graphic depicts the TOGAF 9 Metamodel and its entity relationships.
TOGAF is already well suited for the adoption of SOA as it takes a very services-centric
approach to developing its architecture domains. Here we specifically identify (outlined
in red) those TOGAF entities that already align with the SOA Work Group concepts.

© 2009 The Open Group, All Rights Reserved1
Figure 8. TOGAF 9 Metamodel with Relationships of Primary Entities
Key entities include:
• Event
• Process
• Business Service
• IS Service
• Platform service
• Logical Application and Technology Component
• Physical Application and Technology Component
• Data entity
21

• Role
• Service Quality
• Contract
• Location
• Business Information (not in meta-model)
• Logical Information Components (not in meta-model)
• Business Rules (not in meta-model)
Extensions of the meta-model are typically necessary to fully support SOA. What
follows for each domain is a description of artefacts that are appropriate for the
Enterprise Architect’s development of a Services Oriented Architecture.
What follows is a diagram and description, for each Architecture development domain,
of the potential additional Metamodel elements and associated artifacts that may be
appropriate for the Enterprise Architect’s development of a Services Oriented
Architecture.
4.4 Phase B: The Business Architecture
The Business Architecture aligns the enterprise's business processes, people,
operations and projects with its overall strategy, providing a foundation on which to
build the Information Systems Architectures and the Technology Architecture. This is
the first of the three TOGAF phases that produce detailed architecture descriptions for
the Architecture Definition Document.
The TOGAF 9 metamodel has been expanded to include a SOA “Information” specific
entity – Information Element – from which are derived a Conceptual Information Model
and a Logical Information Component. From the Logical Information Component, the
Architect will additionally derive a Logical Information Model. These are depicted in the
following graphic:

Figure 9. Phase B: Business Architecture Metamodel Extensions
The starting point for the artifacts that are developed in this phase is the set of key
business requirements identified in Phase A. For the kind of enterprise SOA that we are
discussing here, the architect should consider the following artifacts which are
particularly important for SOA because they contribute to the definition of SOA building
blocks in Phase C and Phase D.
Artifact Purpose Meta model entities
Business Service
Interaction
Diagram
This diagram shows all the business
services in scope and their relations
and the information flowing between
the business services. It will indicate
what business services are
commonly reused by other business
services indicating opportunities for
possible re-use of supporting IS
services.
The diagram will also be used to
Business services, Contracts,
Business Information,
(Business Information is
mentioned in phase B, but
there is not a meta-model
entity.)
23

define business processes and the
relationships between those
business processes since each
process is composed by a subset of
this model
Business Process
Model
This is a set of diagrams that show
the business processes and their
decomposition, their interactions,
and the information with which they
are concerned. The Business
Process Modeling Notation (BPMN)
defined by The Object Management
Group (OMG) is an appropriate
notation for these diagrams.
Subset of business service
model showing the Business
services and Contracts
involved in the processes and
the Business information
passed between the Business
services.
Business Roles
Matrix
This matrix shows the relations
between the human and
organizational users of the system
and the business
processes/services. They are
identified by role in relation to the
business processes/services, rather
than by actual identity or position on
the organization chart.
Business Service, Business
Process, Role
Business
Vocabulary
Catalog
This is a list of the key terms used in
describing the business processes
and information. It is important that
the Business Architecture phase
establishes the information context
for the software services, as
described in the Information
Architecture for SOA section of the
Source Book (see:
http://www.opengroup.org/projec
ts/soa-book/page.tpl?
CALLER=page.tpl&ggid=1339 ),
and a catalog of business terms is
an important part of this context.
You can derive the business
vocabulary while developing the
business service model.
This is a list of Business
Information elements and
descriptions of those
elements. (Business
Information is mentioned in
phase B, but there is not a
meta-model entity.)
Business Rules
Catalog
This is a list of business rules,
including rules related to
organizational governance (for
example, “All purchase requisitions
must be approved in accordance
with the purchase approvals
policy.”).
This could be a new entity
connecting two or more
information elements stating
rules of their relation. In the
example to the left the
business rule defines ONE
relation between the

information elements
“purchase requisitions” and
“the purchase approvals
policy”
Business Services
Catalog
This is a list of the enterprise's
business services and their non-
functional requirements. It is used to
analyze the non-functional
requirements
List of Business services
and their Service Qualities
Business
Service/Location
catalog
To understand where the business
services needs to be executed.
Business Service, Location
Event/Process
catalog
To understand which process is run
in relation to an event
Lists Event and their effected
Business process
Contract/Service
Quality Catalog
To understand the non-functional
properties of a contract
Lists Contracts and their
relevant Service Qualities
Business Service
Interaction Matrix
To show relations between
Business Services
Business services on both
axis and contracts in the
cross point
Business
Service/Informatio
n matrix (CRUD)
To show how information elements
are used by business services and
to find faults in that model
Business services and
Business Information
elements. (Business
Information is mentioned in
phase B, but there is not a
current TOGAF meta-model
entity.)
Logical
information
component model
To define the logical structure of the
information in the organization. It
can be used as an input to the
exchange model defining the input
and outputs from SOA services
Business Information
Elements, Logical Information
Components and their
relations.
(None of these exist in the
current meta-model.)
In addition, the standard TOGAF 9 models and artifacts should be considered.
It is vital that the appropriate views are produced that enable the architect to
demonstrate to stakeholders how their SOA-specific concerns relating to the Business
Architecture are addressed.
The level of detail of the business process analysis will depend on the circumstances of
the architectural engagement. The projects that develop solutions that instantiate the
architecture will perform the business analysis at the most detailed levels. It is the
architect’s responsibility to select an appropriate level of detail for the enterprise
architecture business analysis, first as a basis for specifying solutions, and then to
enable their successful development.
25

In doing this the architect address the requirements that can be satisfied by the
business architecture. The remaining architecture requirements will be addressed in
Phase C and Phase D.
4.5 Phase C: The Information Systems Architectures
The objectives of Phase C are to define the major types and sources of data necessary
to support the business, and define the major kinds of application system necessary to
process the data and support the business.
The phase is split into two sub-phases, Data Architecture and Applications Architecture.
SOA makes little difference to the Data Architecture sub-phase, but it has a major
impact on the Applications Architecture.
As well as affecting the artifacts that are developed, the views that are produced, the
concerns that are discussed, and the requirements that are identified, SOA affects the
way that the architect does the gap analysis between baseline and target architectures
in Phase C.
With SOA, the traditional software applications are replaced by sets of loosely-coupled
services. Existing applications should still be described, as should any new applications
of a traditional kind that you decide are required, and these applications should be
included in the applications portfolio. In addition, areas of application functionality that
are covered by services should be identified. These will (probably as part of the
implementation) be decomposed into services, which will be included in the services
portfolio.
But SOA is not only about services, it is also the solutions created by using
combinations of services. These solutions are usually structured using the Business
Processes and Business Services defined in phase B.
For SOA, as with Phase B, the Business Architecture, the Systems Architecture, Phase
C, has extended the TOGAF 9 metamodel to include SOA specific entities. These
include:
► An IS Service Contract, from which is derived an IS Service Model
► Conceptual Data Model that is derived from TOGAF’s Data Entity
These are depicted in the following diagram.

Figure 10. Phase C: Information Systems Architecture Metamodel Extensions
Using the artifacts described in the table below, the architect should develop views that
enable the demonstration to stakeholders of how their SOA-specific concerns relating
to the Applications Architecture are addressed. (Models that enable the architect to
discuss concerns relating to the Data Architecture should also be developed as part of
Phase C. These are similar to the models that would be developed for a traditional
architecture based on software applications.)
In doing this, the architect addresses the requirements that can be satisfied by the
information systems architectures. The remaining architecture requirements will be
addressed in Phase D, Technology Architecture.
27

Artifact Purpose Meta-model entity usage
Service
Interaction
Diagram
This shows requirements for
potential SOA services (IS
Services) and the interactions
between them, and their use of
information. It is used to show
the full set of requirements for
the solution and the relationships
between the requirements.
IS Services and the Contracts
between them. The contracts
indicate what Business
information is communicated.
Preferably the Service Quality
entity for both IS Services and
Contracts are derived from the
Business Services and their
Contracts and related Service
Qualities
Business
Process/Service
Matrix
This matrix shows the relation
between each Business Process
and the IS Services supporting
the process. It is used to show
the full set of requirements for
SOA services for a given
Business Process.
Business Process and its relation
to IS Service(s).
Service Contract
Catalog
The catalog lists all IS Services,
their Contracts and the related
Service Qualities to enable
analysis of the non-functional
requirements (e.g. security,
performance, loading,
availability, policies, etc.) for
potential SOA Services. This
catalog is an important input to
the Service Portfolio
Management process in SOA
Governance.
List of IS Services and their
related Service Qualities.
Additionally IS Service Contracts
for each IS Service is included.
IS
Service/Applicatio
n (existing)
catalog
This catalog connects IS
Services (potential SOA
Services), Contracts and Service
Qualities with existing
applications (as-is Physical
Application Components). It is
used to specify wrapping
scenarios on existing
applications and to analyze non-
functional requirements.
IS Service(s), related Contracts
and Service Qualities connected
with as-is Physical Application
Components.
IS Service/Data
entity matrix
This matrix shows what data is
handled by potential SOA
Services (IS Services). It is used
to identify potential data handling
IS Services and its related Data
Entities

SOA Services.
Logical SOA
Component Matrix
This matrix shows the
relationship between the logical
SOA Components (Logical
Application Components) and
the potential SOA Services (IS
Services). It is used to structure
Logical Components from the
requirements.
IS Services, Logical Application
Components and Principles &
Business Drivers (used to find
criteria to do grouping).
A Logical SOA Component
(Logical Application Component)
would be a candidate for a SOA
Service on Capability level
architectures.
Logical SOA
Solution Diagram
This diagram shows the relations
between the logical SOA
components (Logical Application
Components) and other logical
solutions (Logical Application
Components). It is used to show
and analyze the functional and
non-functional requirements of
the interfaces between solutions
Logical Application Components
and Contracts and their Service
Qualities. Logical Technology
components and their mapping to
Contracts are used for the
interface mechanisms.
Service
Distribution Matrix
This matrix shows the services
distributed on physical locations
to fulfill legal or other
requirement. The purpose is to
show and analyze if there are
any location requirements on
services. This can be done on
either IS Services or Logical
Application Components.
IS Service, Logical Application
Component, Physical Application
Component and Location.
Service
Consumers Matrix
This matrix shows which humans
and external systems consume
which IS services, interfacing via
which portals, channels, etc.
IS Services, Roles.
For an enterprise architecture, these models and artifacts would typically show groups
of services that support the business processes identified in Phase B, rather than
individual services, and the Service Contract and Policy Catalog would list generic
contracts and policies that apply to different types of service. You will generally leave
the identification of individual services to the projects that develop solutions that
instantiate the architecture.
29

In each of phases B, C and D the architect performs a gap analysis between the
baseline and target architectures to determine what needs to be done to move from the
baseline to the target. For phases B and D, and the Data Architecture sub-phase of
Phase C, this is not much affected by SOA. For the applications architecture sub-phase
of Phase C, however, SOA makes a difference to the way that you perform the gap
analysis.
The architecture building blocks defined in Phase C will include traditional applications
and groups of services covering areas of application functionality. Both kinds of building
block should be included in the gap analysis. However, it may be the intent that a group
of services be implemented as a “wrapper” over existing applications. This situation,
which is special for SOA, should be indicated in the gap analysis, as well as situations
where old applications are to be removed or replaced, or new applications are to be
added.
4.6 Phase D: The Technology Architecture
The Technology Architecture phase seeks to map application components defined in
the Application Architecture phase into a set of technology components, which
represent software and hardware components, available from the market or configured
within the organization into technology platforms. For SOA, this means defining the
software and hardware infrastructure needed to support the portfolio of services.
Note that the description of Phase D in TOGAF refers to “services” and “services
portfolios” in a number of places, but it does not by this mean the “portfolio services” or
the “service portfolio“ described in the SOA Source Book. The word “service” has been
in use in IT for many years, and with a broad range of meanings. It is used in the
description of Phase D in TOGAF to refer to the concept of service of the TOGAF
Technical Reference Model, which was developed long before SOA. For SOA, portfolio
service building blocks should be defined in Phase C.
This is the last of the three TOGAF phases that produce detailed architecture
descriptions for the Architecture Definition Document. The starting point for the models
that you develop in this phase is the set of key business requirements identified in
Phase A plus the detailed and elaborated business requirements identified in Phase B
and the information systems requirements identified in Phase C.
As with Phases B and C, The SOA Work Group has extended the TOGAF 9 metamodel
for SOA specific entities. In this case, only a Logical Technology Component Model
has been added as depicted in the following diagram:

Figure 11. Technology Architecture Metamodel Extensions
For SOA, the Technology Architecture defines the software and hardware infrastructure
needed to support the portfolio of services. A starting point for the Technology
Architecture is the Open Group SOA Reference Architecture which contains most
possible platform services possible for a SOA infrastructure. Each organization will
need to customize the SOA RA to their needs.
The Open Group has produced additional information concerning adapting an
organizations infrastructure for services orientation, including the Service Oriented
Infrastructure Reference Model (see: http://www.opengroup.org/projects/soa-book/page.tpl?
CALLER=page.tpl&ggid=1358) which can be consulted for guidance. The SOI
Reference Model, which, for SOA focused organizations can be used, in combination
with the SOA Reference Model refered to above in Phase A, as the Technical
Reference Model required by Phase D of TOGAF 9. The SOI Reference Model is
depicted below:
31

Figure 12. Service Oriented Infrastructure Reference Model
Infrastructure architecture is regarded by many as one of the three pillars of information
technology, together with business architecture and application architecture. Service-
oriented infrastructure results from applying the principles of service-orientation to this
technology architectural pillar. It is related to service-oriented architecture (SOA) which
is most commonly refered to as part of the application architecture pillar.
Using the models, artifacts and SOI Reference Model, the architect should develop
views that enable you to demonstrate to stakeholders how their SOA-specific concerns
relating to the Technology Architecture are addressed. Some SOA-specific models and
artifacts are suggested below:
Artifact Purpose Meta model entity usage
Logical
Technology
Architecture
Diagram
This diagram is used to show
and analyze the instance of the
Open Group SOA Reference
Architecture. It will contain all
ABBs and Capabilities deemed
necessary for the SOA Solution.
Platform Service (Capability),
Logical Technology Component
(ABB)

Logical
Application and
Technology Matrix
This matrix is used to show and
analyze the relations between
the Logical Application
Components and the Logical
Technology Components to
ensure the architect understands
what technology will be used for
the Logical Application
Components. It will also be used
to derive and validate the non-
functional requirements for the
Technical Components.
Logical Application Components
and their relations to Logical
Technology Components
including derivations of the
Service Qualities.
In doing this, the architect adds further requirements to those identified in Phases A, B
and C, and addresses the requirements that can be satisfied by the technology
architecture.
All architecture requirements should have been addressed by the end of this phase. If
there are still outstanding architecture requirements then the architect should go back
to Phase B or Phase C to address them. Implementation requirements will be
addressed by the projects that are identified in Phase E.
4.7 Phase E: Opportunities and Solutions
The Opportunities and Solutions phase identifies delivery vehicles (projects, programs,
or portfolios) that effectively deliver the target architecture defined in previous phases. It
reviews the target business objectives and capabilities, consolidates the gaps from
Phases B to D, and organizes groups of building blocks to address these capabilities. It
then generates an outline implementation and migration strategy.
The identification of service and solution portfolios is a key task for SOA. The questions
of what service and solution portfolios the enterprise will have, and how they will be
managed, should be considered in this phase. (For the kind of enterprise SOA that we
are considering here, it is quite possible that there would be a single service portfolio
and a single solution portfolio.)
A delivery option that should be considered particularly for SOA is the use of services
provided by external companies, as opposed to the development of services in-house
or the acquisition of software products that perform the services.
33

The specific SOA Solution is an addition to the TOGAF 9 metamodel that crosses both
Phases E and F and is depicted below.
Figure 13. Opportunities and Solutions Metamodel Extension
The implementation projects that are identified, and the implementation and migration
strategy, will depend on the decisions taken on the level of detail of implementation
specification when the architect team scoped the architecture development in Phase A.
As with the previous phases, there are a number of models, artifacts and guidelines
that are SOA specific. Those for Phase E might include:
Artifact Purpose Meta model entity usage
Physical SOA
Solution Matrix
This matrix shows the
relationship between the physical
SOA Solutions (Physical
Application Components) and
the logical SOA components. It is
used to define the physical
structure of the SOA Solution.
IS Services, Logical Application
Components, Physical
Application Components and
Principles & Business Drivers
(used to find criteria to do
structuring).
Physical SOA
Solution Diagram
This diagram shows the relations
between the physical SOA
solution (Physical Application
Components) and other solutions
(Physical Application
Components). It is used to show
and analyze the functional and
non-functional requirements of
the interfaces between solutions.
Physical Application Components
and Contracts and their Service
Qualities. Physical Technology
components and their mapping to
Contracts are used for the
interface mechanisms.

Physical Service
Solution Matrix
This matrix shows which existing
services are re-used, which
services could be provided by
external services (SaaS) and
which services needs to be
developed as wrappings of
new/existing applications and
which needs to be developed.
It is an input to the SOA
Governance Service Portfolio
Management process.
IS Services, Physical Application
Components (as-is SOA services
for re-use), other Physical
Application Components (new
and existing applications to be
wrapped) and new Physical
Application Components (new
services to be developed or
purchased externally)
Application
Guidelines
This document provides the
guidelines on how to develop the
SOA Solution and Services.
Suggestions of possible
guidelines can be found in the
Appendix A of the SOA
Governance Framework
(http://www.opengroup.org/so
a/source-
book/gov_summary/index.htm
).
Physical
Technology
Architecture
diagram
This diagram is used to show
and analyze the physical
technical solution for the SOA
infrastructure.
Platform Service, Logical
Technology Component, Physical
Technology Component
Physical
Application and
Technology Matrix
This matrix is used to show and
analyze the physical
infrastructure used to run the
physical application on and to
ensure that the non-functional
requirements are derived
properly and understood.
and their relations to Physical
Technology Components
including derivations of the
Service Qualities.
Technology
Portfolio Catalog
This is a list of products and
kinds of product that will be used
in the implementation, including
SOA run-time infrastructure,
SOA development environment,
service component technology,
and service interface (portal,
channel, etc.) technology. It will
also include non-functional
requirements
and their relation with Service
Qualities
35

Technology
Guidelines
This document provides the
guidelines on how to use SOA
infrastructure. Suggestions of
possible guidelines can be found
in the Appendix A of the SOA
Governance Framework
(http://www.opengroup.org/so
a/source-
book/gov_summary/index.htm
).
4.8 Phase F: Migration Planning
This phase results in a detailed plan, produced in cooperation with departments
responsible for concerned enterprise activities (such as the PMO, Operations, Sales
and Production, Delivery, etc.), for the implementation of the architecture.
The implementation governance model is reviewed in Phase F in order to ensure that it
is in place before the next phase – Implementation Governance – commences. SOA
requires particular governance rules and procedures. The governance and support
strategy is reviewed in the Preliminary phase. If it needs to be updated for SOA, then
this should be done before implementation starts. You should check in Phase F that the
governance model is fit for SOA, and ensure that it has been updated if necessary
before proceeding to Phase G.
4.9 Phase G: Implementation Governance
This phase involves participation of architects in implementation governance, to
improve the quality of the implementations generally and in particular to ensure
conformance with the architecture.
The activities performed in the Implementation Governance phase will depend in part
on the decisions taken on the level of detail of implementation specification when the
architect team scoped the architecture development in Phase A.
Again, as in the Preliminary Phase, the Architect has a wealth of information available
from the Open Group SOA Governance Reference Model. See:
http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1340 for the
Introduction to SOA Governance and related sections of this Source Book for further
information on SOA governance.

4.10 Phase H: Architecture Change Management
Phase H is concerned with reviewing and updating the architecture and the architecture
process itself. This includes assessing the performance of the architecture and making
recommendations for change.
It is at this point that you are likely to decide to re-visit the activities of the Preliminary
Phase. Where SOA has not previously been used within an enterprise, Phase H of an
architecture development is an opportunity to assess the contribution that it could
make, and to consider adopting the principle of service orientation.
37

5 Summary
In summary, there are a number of SOA methods, tools and reference materials available to
help the Enterprise Architect develop Service Oriented Architecture. The Open Group
standards and publications are suggested. Some are directly focused on SOA, such as the SOA
Source book, OSIMM or the SOA Governance Vitality Method, others are not directly focused
but regularly useful, such as outputs of the Security Forum and the Jericho Forum in areas of
Security.
Using TOGAF to create SOA requires adapting TOGAF to address the requyirements of a
particular style. Addressing a style will require:
• identifying key meta-model entiries
• identifiying extensions to the content meta-model
• identifying key artificats
• iidentifying style-specific refernce materials and maturity models
The adaption of an architecture capability to support SOA requires considerable activity in the
Preliminary Phase of TOGAF. These activities and SOA specific Open Group SOA Working
Group tools include:
• Adapting the Principle of Service Orientation
• Determining Orgainization Readiness for SOA: OSIMM
• Governance: The Open Group SOA Governance Model and Vitality Method
• Partitions: Utilize a specialist Centre of Excellence to support SOA
In the rest of the TOGAF ADM phases what changes is how an architecture is described,
analysed and documented. During an iteration of the ADM the practitioner needs to consider the
key meta-model entities iddentified above, and the arctifacts identified above.
At different levels of granulatity the purpose of the ADM cycle will vary. In Strategic-level work the
purpose is iidentifying whether SOA is needed, and in which Segments. In Segment-level work
describing the structure and capability requirements of SOA. Finally, in the Capability-level work
to identify and describe the requirements of the SOA Services that will be available.
When delivering SOA with TOGAF, the practitioner should never loses sight of the final objective:
SOA Solutions that address managing the enterprise's complexity and provide business agility.

Soa and togaf practical guide

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Soa and togaf practical guide (20)

More from Sandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW (20)

Recently uploaded (20)

Soa and togaf practical guide