Using TOGAF to Define & Govern SOAs

Chapter 22 <<< Previous | Next >>>

22.1 Overview

This chapter discusses:

Service-Oriented Architecture (SOA) as an architectural style
Factors relating to the adoption and deployment of SOA within the enterprise
Using the TOGAF Architecture Development Method (ADM) to develop your SOA

This chapter, where appropriate, includes references to Technical Standards and Guides developed by The Open Group SOA Work Group.

22.2 Introduction

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, silo’ed 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 more granular services that operate in open and interoperable ways, while extracting commodity capability into a virtualized infrastructure platform of shared re-usable utility services.

22.3 SOA Definition

Note:: This section is provided for reader convenience. Part I, 3. Definitions should be referred to for the formal definitions.

Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.) and:

Is self-contained
May be composed of other services
Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed.

22.4 SOA Features

SOA is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-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. An SOA-specific Directory Service and an Enterprise Service Bus (ESB) 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.

22.5 Enterprise Architecture and SOA

Enterprise architecture provides frameworks, tools, and techniques to assist organizations with the development and maintenance of their SOAs. Some of the key benefits that enterprise architecture provides include:

Consistent abstractions of high-level strategies and deliverables to support planning and analysis
Linkage of different perspectives to a single business problem (e.g., business, information systems, technology, breadth, depth, level of detail, 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

Enterprise architecture becomes a foundation for service-orienting an organization, 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 re-use.

Through its linking of the business context to IT, enterprise architecture readily identifies and provides justification for the cost of change programs in relation to the business value to be derived from the effort. Enterprise architecture 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

22.6 SOA and Levels

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, with the exception of the Internet and the World-Wide Web, that can be applied across the whole of a large organization. Even these provide only a basic level of support for business processes. Generally, it may not be appropriate to develop a single, integrated SOA for a large and complex enterprise.

For such an enterprise, assuming an architecture landscape as shown in Figure 20-1, the architect 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 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.

The architect 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.

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 it is assumed that the scope is an enterprise of this kind. It could be self-standing or a segment of a larger enterprise.

22.6.1 Level of Detail of Implementation Specification

How completely should the architecture define what to implement? At one extreme, it could specify the future of the enterprise, and define all the changes to reach the target, including the projects that will produce the changes, and a detailed time plan. At the other extreme, it could just indicate areas where work is needed, and suggest priorities for addressing them.

Architecture 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.

22.6.2 SOA Activities at Different Levels

At the level of Strategic Architecture the basic SOA issue is identifying whether you need SOA and in which Segments. In the Strategic Architecture we identify:

The high-level relationships and boundaries within the organization
Cross-segment SOA capability requirements (what information and functionality is needed across segments)
Key capabilities best addressed by SOA
Key capabilities required for SOA
Segments best addressed by SOA
Principles and patterns of SOA service development and description, which may be defined at the Segment and Capability levels
The roles, responsibilities, processes, and tools of SOA governance
The organization-specific Reference Architecture

At the Segment level the basic SOA issue is describing the structure of SOA. In the Segment Architectures we define:

Which capabilities will use SOA as an architecture style
Cross-capability relationships (what information and functionality is needed across capabilities)
More detailed cross-segment relationships (what information and functionality is needed across Segment)
Cross-capability SOA service re-use possibilities
Principles and patterns of SOA service development and description, which may be defined at the Strategic and Capability levels; it is most common to define these as part of Segment Architecture

For Capability Architecture the basic SOA issue is which services will be available. In the Capability Architectures we will describe:

The functional and non-functional requirements of the capability
Cross-capability SOA service requirements
SOA services that enable cross-capability re-use
SOA services that enable the capability
Principles and patterns of SOA service development and description, which may be defined at the Strategic and Segment levels

Regardless of the level of architecture being pursued it is possible to identify SOA solutions that will best service the requirements of the enterprise.

22.7 Using TOGAF for SOA

This section describes, for each phase of the TOGAF ADM, what should be considered when looking to apply the principle of service-orientation, and how this affects the phase. This is not intended as a self-standing description and should be read in conjunction with other sections of this document.

22.7.1 Preliminary Phase

The Preliminary Phase is where the Architecture Capability is adapted to support SOA. The key outputs of this phase are the principles, organizational structure, governance, and initial content of the Architecture Repository.

22.7.1.1 Principle of Service-Orientation

The starting point for SOA development with TOGAF is that the enterprise adopts service-orientation as an architecture principle (see Principle 6: Service Orientation). 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.

If the architect is 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 straightforward. If, on the other hand, SOA is being introduced 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. The organization can conduct an SOA maturity assessment during the Preliminary Phase, using The Open Group Service Integration Maturity Model (OSIMM) 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.

Even though an enterprise may be committed to SOA, it is not always appropriate to use the SOA style to address every architectural problem. As the section on levels identified specific segments, or capabilities may be best served by SOA in an organization not otherwise committed; or specific segments or capabilities may not be well suited to SOA in an organization committed to SOA.

From here on it is assumed that the principle of service-orientation is adopted.

22.7.1.2 Governance and Support Strategy

A review should occur of the existing governance procedures, confirming that they are appropriate for SOA. If they are not, then recommendations should be made for change to make them appropriate.

The Open Group has a standardized governance framework that focuses on SOA and may be used to enhance existing governance frameworks (see The Open Group SOA Governance Framework Technical Standard). This provides a high-level reference model of how SOA governance extends and supports both enterprise architecture and IT governance. It also includes an SOA Governance Vitality Method (SGVM) that can be used to define a specific SOA governance regimen adapted to the organization’s view of governance.

Figure 22-1: The Open Group SOA Governance Framework

22.7.1.3 Partitions and Centers 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. It is suggested that the team start with a focused initiative before implementing on a wide scale. The team responsible for SOA should initially be structured as a Center 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 KPIs 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 center 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.

22.7.1.4 Architecture Repository

There are a number of SOA resources that should be considered when initially populating the Architecture Repository as described in The Open Group SOA Reference Architecture (see The Open Group SOA Source Book). These include:

The Building Blocks of SOA, which describes a set of ABBs 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
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 (ABBs) that correspond to infrastructure products that are available today to support service-oriented applications
Industry SOA Standards, such as the TeleManagement Forum Integration Framework

A high-level graphic that describes The Open Group SOA Reference Architecture follows:

Figure 22-2: The Open Group SOA Reference Architecture

22.7.2 Phase A: Architecture Vision

The high-level description produced in Phase A will reflect the service-oriented nature of the architecture that is envisaged. One obvious difference between an SOA architecture description and a description of an architecture of another style is the language. The SOA description uses different language, with words such as “policy”, “composition”, and “task”, and it has different models, such as matrices showing use of services by business processes and use of applications by services. The Open Group SOA Ontology provides a taxonomy and ontology for SOA.

In an SOA project it is important to ensure that stakeholders understand the implications of SOA and are prepared for the organizational impacts of composable SOA services. This impact is applicable whether SOA services are made available as wrapped legacy applications, using exposed services on purchased products, bespoke services, Cloud Computing Software as a Service (SaaS), etc.

22.7.2.1 Stakeholders, Concerns, and Business Requirements

The stakeholders to consult, the requirements to address, and the models, artifacts, and views to develop vary from one architecture engagement to another. There are some concerns that are specific to SOA, or are more likely to arise in SOA developments. The Addressing Stakeholder Concerns in SOA section of The Open Group SOA Source Book is a good resource for addressing this topic.

22.7.3 Architecture Development: Phases B, C, and D

In this section we consider the SOA impact on Phases B, C, and D, the architecture development domains. The following graphic of the TOGAF Content Metamodel identifies (outlined in red) entities that are key to SOA.

Figure 22-3: SOA Entities in the Content MetamodelKey entities include:

Event
Process
Business Service
IS Service
Platform service
Logical Application and Technology Component
Physical Application and Technology Component
Data entity
Role
Service Quality
Contract
Location
Business Information (not in metamodel)
Logical Information Components (not in metamodel)
Business Rules (not in metamodel)

Extensions of the metamodel are typically necessary to fully support SOA. What follows for each domain is a description of artifacts that are appropriate for the enterprise architect’s development of an SOA.

Phase B: Business Architecture

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 following artifacts should be considered for SOA because they contribute to the definition of SOA building blocks in Phase C and Phase D.

Artifact	Purpose	Metamodel 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 re-used by other business services indicating opportunities for possible re-use of supporting IS services. The diagram will also be used to define business processes and the relationships between those business processes since each process is composed by a subset of this model.	Business Services, Contracts, Business Information (Business Information is mentioned in Phase B, but there is not a metamodel entity.)
Business Process Diagram	This is a set of diagrams that show the business processes and their decomposition, their interactions, and the information with which they are concerned.	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 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 Open Group Source Book, and a catalog of business terms is an important part of this context. The business vocabulary can be derived 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 metamodel entity.)
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 need 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/Information 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 metamodel entity.)
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 metamodel.)

The appropriate views should be produced to enable demonstration to stakeholders of how their SOA-specific concerns relating to the Business Architecture are addressed. In doing this the architect addresses the requirements that can be satisfied by the Business Architecture. The remaining architecture requirements will be addressed in Phase C and Phase D.

Phase C: Information Systems Architectures

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

SOA-Specific Phase C Artifacts

Artifact	Purpose	Metamodel Entity Usage
IS 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/IS 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)
IS 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 are included.
IS Service/Application (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 SOA Services.	IS Services and its related Data Entities
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 and Business Drivers (used to find criteria to do grouping) A Logical SOA Component (Logical Application Component) would be a candidate for an 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 fulfil 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

Using the artifacts, the architect should develop views that demonstrate to stakeholders how their SOA-specific concerns relating to the Applications Architecture are addressed. Models that enable discussion of 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, this addresses the requirements that can be satisfied by the Information Systems Architectures. The remaining architecture requirements will be addressed in Phase D: Technology Architecture.

In each of Phases B, C, and D a gap analysis should be performed 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 the gap analysis is performed.

The ABBs 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.

Phase D: Technology Architecture

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 platform services possible for an SOA infrastructure. Each organization will need to customize the SOA Reference Architecture to their needs.

SOA-Specific Phase D Artifacts

Artifact	Purpose	Metamodel 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 technology components.	Logical Application Components and their relations to Logical Technology Components, including derivations of the Service Qualities

The Open Group has produced additional information concerning adapting an organization’s infrastructure for service-orientation, including The Open Group Service-Oriented Infrastructure (SOI) Reference Model (consult The Open Group SOA Source Book for guidance).

Using the artifacts and SOI Reference Model, the architect should develop views that demonstrate to the stakeholders how their SOA-specific concerns relating to the Technology Architecture are addressed.

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 it is necessary to 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.

Phase E: Opportunities and Solutions

The identification of SOA solutions is a key task for SOA. The questions of what SOA solutions the enterprise will have, and how they will be managed, should be considered in this phase.

Solution delivery options are normally considered as part of this phase. 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.

SOA-Specific Phase E Artifacts

Artifact	Purpose	Metamodel 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 need to be developed as wrappings of new/existing applications and which need 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 guidelines on how to develop SOA solutions and services. Suggestions of possible guidelines can be found in Appendix A of The Open Group SOA Governance Framework.
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 and to ensure that the non-functional requirements are derived properly and understood.	Physical Application Components 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.	Physical Application Components and their relation with Service Qualities
Technology Guidelines	This document provides guidelines on how to use SOA infrastructure. Suggestions of possible guidelines can be found in Appendix A of The Open Group SOA Governance Framework.

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.

Phase F: Migration Planning

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. This should use the same resources identified in 22.7.1.2 Governance and Support Strategy.

Phase G: Implementation Governance

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. During the Implementation Governance phase, the monitoring part of the SGVM should be put in operation to ensure that the SOA governance activities are performed at the correct level.

Phase H: Architecture Change Management

It is at this point that the architect should determine whether it is necessary to revisit the Preliminary Phase to adjust the Architecture Capability. Where SOA has not previously been used within an enterprise, Phase H of an architecture development is an opportunity to assess the contribution that SOA could make, and to consider adopting the principle of service-orientation.

22.8 Summary

There are a number of SOA methods, tools, and reference materials available to help the Enterprise Architect develop SOA. The Open Group standards and publications are suggested. Some are directly focused on SOA – such as the SOA Source Book, OSIMM, or the SGVM – others are not directly focused but regularly useful, such as outputs of The Open Group Security Forum.

Using TOGAF to create SOA requires adapting TOGAF to address the requirements of a particular style. Addressing a style will require:

Identifying key metamodel entries
Identifying extensions to the content metamodel
Identifying key artifacts
Identifying style-specific reference 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 Work Group tools include:

Adapting the principle of service-orientation
Determining organization readiness for SOA: OSIMM
Governance: The Open Group SGVM
Partitions: Utilize a specialist Center of Excellence to support SOA

In the rest of the TOGAF ADM phases, what changes is how an architecture is described, analyzed, and documented. During an iteration of the ADM the practitioner needs to consider the key metamodel entities identified, and the artifacts identified. At different levels of granularity the purpose of the ADM cycle will vary. In Strategic-level work the purpose is identifying whether SOA is needed, and in which Segments. In Segment-level work the purpose is 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 lose sight of the final objective: SOA solutions that address managing the enterprise’s complexity and provide business agility.

return to top of page

<<< Previous

Home

Next >>>

Account Context Diagram

The purpose of the Account Context Diagram is to enable financial risk management by illustrating which processes create transactions on a given account, and which risks are related to this transaction.

Ontologies in QualiWare

The Repository Compare functionality has the potential to aid all types of users. Quality Managers can for example promote the right subsets of their work from a project repository to the base configuration – thus ensuring that all of the Quality Team’s work has been considered.