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. These are:

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

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.

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.

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:

• The architecture is based on a design of services which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.

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 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 SOA maturity model described in this Source Book, 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.

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.

Governance and Support Strategy

TOGAF does not describe architecture, implementation or operational governance. It assumes that a governance framework is in place. The Preliminary phase includes confirming the governance and support strategy, as part of the Organizational Model for Enterprise Architecture. You 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.

Initial Architecture Repository

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.

Your initial repository can include the high-level SOA model, the detailed models for SOA features, and the building blocks of the infrastructure for SOA described in this Source Book.

Architecture Requirements Management

Requirements management is not so much a phase as an ongoing process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases. It is not significantly altered by a decision to use SOA.

Phase A: The Architecture 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.

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

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.

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.

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

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.

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.

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. The section of this Source Book on addressing stakeholder concerns in SOA lists some areas of concern that you are likely to encounter.

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 starting point for the models that you develop 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, you should consider the following models. They are appropriate for any architectural style, but they are particularly important for SOA because they contribute to the definition of SOA building blocks in Phase C and Phase D.

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

• Business Roles Catalog

  This is a list of the human and organizational users of the system. They are potential consumers of the portfolio services. They are identified by role in relation to the business processes, rather than by actual identity or position on the organization chart.

• Business Vocabulary

  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 this Source Book, and a catalog of business terms is an important part of this context. You can derive the business vocabulary while developing the business process model.

• 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.”).

• Business Services Catalog

  This is a list of the enterprise's business services showing their providers, their potential consumers, the effects that have value to the consumers, and the service contracts. Opinion is divided on whether a service-oriented business architecture is essential for SOA. If you believe that it is essential, then you should analyse the business processes as services, and produce a business services catalog in addition to the business process model.

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 your responsibility as architect 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.

Using the models, you should develop views that enable you to demonstrate to stakeholders how their SOA-specific concerns relating to the Business Architecture are addressed.

In doing this, you add further business requirements to those identified in Phase A, and you address 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: 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, to address these two objectives. SOA makes little difference to the Data Architecture sub-phase, but it has a major impact on the Applications Architecture.

This is the second of the three TOGAF phases that produce detailed architecture descriptions for the Architecture Definition Document. As well as affecting the models that you develop, the views that you produce, the concerns that you discuss, and the requirements that you identify, SOA affects the way that you do the gap analysis between baseline and target architectures in Phase C.

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 further business requirements identified in Phase B.

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 should be added, 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.

For the kind of enterprise SOA that we are discussing here, you should consider the following models. They are specific to SOA: you would probably not consider them for this phase for other architectural styles. You should consider them in addition to the models that you would consider for an architecture based on software applications.

• Service Interaction Model

  This is a set of diagrams that show portfolio services, the interactions between them, and their use of data.

• Business Process/Service matrix

  This shows which business processes include which groups of portfolio services.

• Service Consumers Matrix

  This shows which humans and external systems consume which portfolio services, interfacing via which portals, channels, etc.

• Service Contract and Policy Catalog

  This is a catalog of service contracts, and policies for service contracts.

• Service Access Control Model

  This is a set of diagrams that show how access to services is controlled.

• Service Configuration and Provisioning Model

  This is a set of diagrams that show how services will be configured and provisioned with resources.

• Service Loading Model

  This is a model that shows expected loading on services, including time patterns for service use.

• Service/Applications Matrix

  This shows which service building blocks result from “wrapping” which applications.

For an enterprise architecture, these models 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.

Using the models, you should develop views that enable you to demonstrate to stakeholders how their SOA-specific concerns relating to the Applications Architecture are addressed. (You should of course also develop models that enable you to discuss concerns relating to the Data Architecture. These are similar to the models that you would develop for a traditional architecture based on software applications.)

In doing this, you add further requirements to those identified in Phase A and Phase B, and you address the requirements that can be satisfied by the information systems architectures. The remaining architecture requirements will be addressed in Phase D.

In each of phases B, C and D you perform 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 that a group of services is intended to 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: 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 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 this 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 further business requirements identified in Phase B and the information systems requirements identified in Phase C.

For the kind of enterprise SOA that we are discussing here, you should consider the following models. You would probably consider similar models for this phase for other architectural styles, but SOA affects their form and content.

• Technology portfolio

  This is a catalog 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.

• Service/Physical System Matrix

  This shows which physical systems host the programs that perform the services.

• Service/Technology Matrix

  This shows which items in the technology portfolio are used in the performance of which services.

The sections of this Source Book on SOA features and benefits and infrastructure for SOA will help you identify elements of the target technology portfolio.

Using the models, you should develop views that enable you to demonstrate to stakeholders how their SOA-specific concerns relating to the Technology Architecture are addressed.

In doing this, you add further requirements to those identified in Phase A, Phase B and Phase C, and you address the requirements that can be satisfied by the technology architecture. All architecture requirements should have been addressed in by the end of this phase. If there are still outstanding architecture requirements then you 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.

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.

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 you scope the architecture development in Phase A.

Phase F: Migration Planning

This phase results in a detailed plan, produced in cooperation with departments responsible for concerned enterprise activities (such as 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.

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 you scope the architecture development in Phase A.

See the Introduction to SOA Governance and related sections of this Source Book for further information on SOA governance.

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.