Summarised - 2010

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

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

Enterprise

Architecture

Defines Structured

traceable

representations of

business and

technology

Defines principles,

constraints,

frameworks,

patterns, and

standards

links many different

perspectives to a

single business

problem providing a

consistent model

provides consistent

abstractions of

high-level

strategies and

project

deliverables

links SOA stakeholders

together

provides a link from business

to IT

shows which services should

be built and how they

should be re-used

shows how ser vices should be designed and how platforms

must interoperate

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.

TOGAF Phase SOA Concept Benefits to a SOA Initiative

Preliminary The TOGAF framework provides a meta model and process that is capable of incorporating both business-led and developer-led SOA concepts in a holistic framework

Using TOGAF will provide a direct linkage between business-led and developer-led communities, initiatives and benefits within an organization

Architecture Vision The TOGAF ADM includes specific steps to address SOA concerns, including:• Consideration of business capability — which capabilities are most valuable, volatile, and differentiating for the business?•Consideration of technology capability — how technically mature is the organization and how mature does it desire to be?•Consideration of IT governance impacts — what impacts is the Architecture Vision going to have on current IT governance models?

TOGAF Business Capability Assessments provide an opportunity to look at thebusiness services that exist or are desired and how these business services can berealized. The TOGAF Technology Capability Assessment provides an opportunity to look at technology risk and maturity,The TOGAF IT governance assessment provides an opportunity to identify SOA related governance impacts.

Business Architecture The Business Architecture phase elaborates thecapabilities of the business and defines explicit portfolios of business services, accompaniedby ser vice contracts that formalize ser vice consumption

Business services are explicitly identified and tied to ownership, usage, and business value, forming the detail of a business ledSOA strategy in a way that can be linked into a developer led world.

Information SystemsArchitectures

The Information Systems Architectures phase shows how the identified business servicesmap to applications and data

Information system services are explicitly identified and tied to business service, dataencapsulation, and applications, elaborating a high-level framework for developer-led SOA implementation.

TOGAF Phase SOA Concept Benefits to a SOA Initiative

Technology Architecture The Technology Architecture phase shows how application capabilities identified in the Information Systems Architecture are mapped onto SOA platforms and off-the-shelf SOA services, providing a blue print for implementation

SOA technology architectures are developed with traceable reference to:•Business ownership and value•A defined organizational position on baseline and target technology maturity•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 & SolutionsMigration Planning

The TOGAF ADM allows for identification of improvement opportunities and then selection, prioritization, and sequencing of those opportunities according to architectural analysis and stakeholder need.

Development of a multi-disciplinary Architecture Roadmap allows SOA capability to be incrementally developed,including proof-of-concept, pilot, and mainstream SOA enabling.

Implementation Governance TOGAF provides specific processes for designgovernance during the implementation of anarchitecture.

TOGAF identifies the need for design governance, which can include SOA designgovernance. This approach provides aframework in which to apply an organization’s standards, guidelines, and specifications to implementation projects.

Architecture Change Management

TOGAF allows for implementation issues andexternal factors to be incorporated into thearchitecture, allowing the overall approach to be refined.

Lessons learned from proof-of conceptand pilot activities can be leveraged and used to shape the strategy from a bottom-up perspective.

Service

Qualities and

TOGAF

Purpose of a

Service

Contract

Service

Governance

Considerations

Governance Contract

Operational Contract

between two business entities which

specifies what interaction is needed, inputs,

outputs, SLAs, OLAs, and KPIs

which specifies the actual communication

protocols and message formats

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.

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 thiscontract/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 process

What happens if the service is unavailable

Attribute Type Attribute Description

Business Contract control requirements

How the contract will be monitored and controlled.

Business Result control requirements

How the results of the service will be monitored and controlled

Business Quality of service Deter mines the allowable failure rate

Business Ser vice Level Agreement

Deter mines the amount of latency the service is allowed to have to perform its actions.

Non-Functional Requirements

Throughput Volume of transactions estimated; e.g., 100,000

Non-Functional Requirements

Throughput period The period in which those transactions are expected, e.g., 100,000 per day

Non-Functional Requirements

Growth The growth rate of transactions over time (estimated based on service take-up andbusiness growth); e.g., 10,000.

Non-Functional Requirements

Growth period The period in which the growth is estimated to occur ; e.g., 10,000 per year

Non-Functional Requirements

Ser vice times The available hours/days the service is needed; for example, 9 to 5 Monday to Friday (excluding Bank Holidays).

Non-Functional Requirements

Peak profile short term The profile of the short-term level of peak transactions; for example, 50% increasebetween hours of 10 to 12 am.

Non-Functional Requirements

Peak profile long term The profile of the long-term level of peak transactions; for example, 50% increase at month end.

Non-Functional Requirements

Security requirements Who can execute this service in terms of roles orindividual partners, etc. and which invocationmechanism they can invoke

Non-Functional Requirements

Response requirements The level and type of response required

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 directedshould 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).

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

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