TOGAF 9 and SOA

1. Summarised - 2010

2.  Ser vice Oriented Architecture (SOA) as an
architectural style
 Factors relating to the adoption and
deployment of SOA within the enterprise
 Correspondences between SOA and TOGAF
terminology
 The definition and structure of service
contracts

4.  New stress points are created around understanding the
relationships between technology portfolio and service
portfolio
 New stress points are created around SLA definition,
governance, and impact management
 New stress points are created around tracing business to IT
 New stress points are created around communication,
alignment, and semantics
 New stress points are created around platform and
interoperability
 New stress points are created around performance visibility
and optimization

5. Defines Structured
traceable
representations of
business and
technology
shows how ser
vices should be
links SOA
designed and
stakeholders
how platforms
together
must
interoperate
provides consistent
Defines principles,
Enterprise
abstractions of
high-level constraints,
strategies and frameworks,
project Architecture patterns, and
standards
deliverables
shows which
services should
be built and provides a link
how they from business
should be re- to IT
used links many different
perspectives to a
single business
problem providing a
consistent model

7.  Function: A function is a thing that a business does. Ser vices support functions,
are functions, and have functions, but functions are not necessarily services. Ser
vices have more specific constraints than functions.
 Business Service: A business service is a thing that a business does that has a
defined, measured interface and has contracts with consumers of the service. A
business service is supported by combinations of people, process, and
technology.
 Information System Service: An information system service is a thing that a
business does that has a defined, measured interface and has contracts with
consumers of the ser vice. Information system services are directly supported by
applications and have associations to SOA ser vice interfaces.
 Application Component: An application component is a configured and deployed
system, or independently governed piece of a configured and deployed system.
Application components provide information system services. Application
components can be physical applications and also logical applications that group
together applications of a similar type.
 Technology Component: A technology component is a piece of software or
hardware that can be purchased from an internal or external supplier.
Technology components are configured, combined, built on, and deployed in
order to produce application components.

8. TOGAF Phase SOA Concept Benefits to a SOA Initiative
Preliminary The TOGAF framework provides a meta model Using TOGAF will provide a direct linkage
and process that is capable of incorporating both between business-led and developer-led
business-led and developer-led SOA concepts in communities, initiatives and benefits within
a holistic framework an organization
Architecture Vision The TOGAF ADM includes specific steps to TOGAF Business Capability Assessments
address SOA concerns, including: provide an opportunity to look at the
• Consideration of business capability — which business services that exist or are desired
capabilities are most valuable, volatile, and and how these business services can be
differentiating for the business? realized.
•Consideration of technology capability — how The TOGAF Technology Capability
technically mature is the organization and how Assessment provides an opportunity to
mature does it desire to be? look at technology risk and maturity,
•Consideration of IT governance impacts — what The TOGAF IT governance assessment
impacts is the Architecture Vision going to have provides an opportunity to identify SOA
on current IT governance models? related governance impacts.
Business Architecture The Business Architecture phase elaborates the Business services are explicitly identified
capabilities of the business and defines explicit and tied to ownership, usage, and business
portfolios of business services, accompanied value, forming the detail of a business led
by ser vice contracts that formalize ser vice SOA strategy in a way that can be linked
consumption into a developer led world.
Information Systems The Information Systems Architectures phase Information system services are explicitly
Architectures shows how the identified business services identified and tied to business service, data
map to applications and data encapsulation, and applications,
elaborating a high-level framework for
developer-led SOA implementation.

9. TOGAF Phase SOA Concept Benefits to a SOA Initiative
Technology Architecture The Technology Architecture phase shows how SOA technology architectures are
application capabilities identified in the developed with traceable reference to:
Information Systems Architecture are mapped •Business ownership and value
onto SOA platforms and off-the-shelf SOA •A defined organizational position on
services, providing a blue print for baseline and target technology maturity
implementation •Service contracts that identify service
consumers, SLAs, and non-functional
requirements for services
•Landscape visibility of how technologies
will support deliver y of applications and
information system services
•Consideration of the IT governance model,
requirements, and issues
Opportunities & Solutions The TOGAF ADM allows for identification of Development of a multi-disciplinary
Migration Planning improvement opportunities and then selection, Architecture Roadmap allows SOA
prioritization, and sequencing of those capability to be incrementally developed,
opportunities according to architectural analysis including proof-of-concept, pilot, and
and stakeholder need. mainstream SOA enabling.
Implementation Governance TOGAF provides specific processes for design TOGAF identifies the need for design
governance during the implementation of an governance, which can include SOA design
architecture. governance. This approach provides a
framework in which to apply an
organization’s standards, guidelines, and
specifications to implementation projects.
Architecture Change TOGAF allows for implementation issues and Lessons learned from proof-of concept
Management external factors to be incorporated into the and pilot activities can be leveraged and
architecture, allowing the overall approach to be used to shape the strategy from a bottom-
refined. up perspective.

10. Service
Qualities and
TOGAF
Service Purpose of a
Governance Service
Considerations Contract

11. Governance Operational
Contract Contract
between two business entities which which specifies the actual communication
specifies what interaction is needed, inputs, protocols and message formats
outputs, SLAs, OLAs, and KPIs
The service contract specifies the quality and integrity of the interaction
between services. This specification allows the development of service-
level objectives (irrespective of whether they are formalized into an SLA).
Ser vice contracts for m an important insight to developing the critical
operational path, and they set the quality and security benchmarks for
Application and Technology Architecture components.

12. Attribute Type Attribute Description
General Reference A unique identifier within the architecture information for cross-reference, clarity,
and differentiation from other similar artifacts.
General Name A suitable, preferably unique, short form name for the artifact
General Description Name of the service. Should indicate in general terms what it does, but not be the
only definition. A narrative of what the artifact is, what it does, and its relevance to
the architecture.
General Source The source of the artifact, which may be a person or a document, along with a date
to support traceability of the architecture
General Owner The owner of the artifact is the name (person or group) who validated the details of
this artifact; the person/team in charge of the service.
General Type The type of the service to help distinguish it in the layer in which it resides; e.g.,
data, process, functionality, presentation, functional.
General Version The version of the service contract.
Business RACI Responsible: The role is the person/team responsible for the deliverables of this
contract/ser vice. Accountable: Ultimate decision-maker in terms of this
contract/ser vice. Consulted: Who must be consulted before action is taken on this
contract/ser vice. This is two-way communication. These people have an impact on
the decision and/or the execution of that decision. Informed: Who must be
informed that a decision or action is being taken. This is a one-way
communication. These people are impacted by the decision or execution of that
decision, but have no control over the action.
Business Ser vice name ‘‘caller’’ Name of the consuming service.
Business Functional Requirements The functionality in specific bulleted items of what exactly this service accomplishes.
The language should be such that it allows test cases to prove the functionality is
accomplished
Business Importance to the What happens if the service is unavailable
process

13. Attribute Type Attribute Description
Business Contract control How the contract will be monitored and controlled.
requirements
Business Result control How the results of the service will be monitored and controlled
requirements
Business Quality of service Deter mines the allowable failure rate
Business Ser vice Level Deter mines the amount of latency the service is allowed to have to perform its
Agreement actions.
Non-Functional Throughput Volume of transactions estimated; e.g., 100,000
Requirements
Non-Functional Throughput period The period in which those transactions are expected, e.g., 100,000 per day
Requirements
Non-Functional Growth The growth rate of transactions over time (estimated based on service take-up and
Requirements business growth); e.g., 10,000.
Non-Functional Growth period The period in which the growth is estimated to occur ; e.g., 10,000 per year
Requirements
Non-Functional Ser vice times The available hours/days the service is needed; for example, 9 to 5 Monday to
Requirements Friday (excluding Bank Holidays).
Non-Functional Peak profile short term The profile of the short-term level of peak transactions; for example, 50% increase
Requirements between hours of 10 to 12 am.
Non-Functional Peak profile long term The profile of the long-term level of peak transactions; for example, 50% increase
Requirements at month end.
Non-Functional Security requirements Who can execute this service in terms of roles or
Requirements individual partners, etc. and which invocation
mechanism they can invoke
Non-Functional Response requirements The level and type of response required
Requirements

14. Attribute Type Attribute Description
Technical Invocation The invocation means of the service. This includes the URL, interface, etc. There
may be multiple invocation paths for the same service. There may be the same
functionality for an internal and an external client, each with a different invocation
means and interface. For example, Sales App, events triggers, receipt of a written
request for m. The service end point address to which the invocation is directed
should be included.
Technical Invocation preconditions Any pre-conditions that must be met by the consumer (authentication, additional
input, etc.).
Technical Business objects Business objects transferred by the service
Technical Behaviour characteristics The criteria and conditions for successful interaction and any dependencies (on
other ser vice interactions, etc.). This should include any child services that will be
invoked/spawned by this service (in addition to dependencies on other services).

15.  TOGAF Version 9, The Open Group
Architecture Framework (TOGAF), 2009

16. If you have one last breath
use it to say...