SOA and TOGAF: A Good Fit?

By guest contributors Clive Hatton and Paul van der Merwe, Real IRM.

Service-Oriented Architecture (SOA) is a style of architecture and The Open Group Architecture Framework (TOGAF) is an architecture framework. The combination sounds promising, but do they play well together? The Open Group certainly believes they do — Open Group members have invested heavily in efforts to bring these two concepts together. Several members have contributed a great deal of their time and experience to the SOA/TOGAF Practical Guide project, one of many of the SOA Working Group’s projects in The Open Group.

The SOA/TOGAF Practical Guide project aims to develop SOA specific extensions to the TOGAF Architecture Development Method (ADM) that lies at the heart of TOGAF. The idea behind this project is that if SOA is a style of architecture, then it’s possible to extend the style-independent method of the TOGAF ADM with SOA style-specific activities and deliverables, to produce a Service Oriented ADM.

So why should SOA practitioners be interested in TOGAF? If you see SOA as technology (which ZapThink certainly does not), rather than architecture, then you may not see any value in an architecture framework. Even if you correctly see SOA as architecture, you may think that you have been doing just fine developing and implementing SOA without any assistance from TOGAF. So what does TOGAF offer you?

Using the TOGAF Architecture Development Method (ADM) for SOA
From its roots in the US Department of Defense, TOGAF has over the years become the de facto industry standard for architecture development and includes best practices from hundreds of participating Open Group members. TOGAF 9, released this year, offers significant improvements over TOGAF 8, including greater usability, more focus on holistic enterprise change, and more consistency of output. Additions to TOGAF in version 9 include a modular structure, a content framework (which gives structure to architecture models and definitions), and extended guidance on adopting TOGAF within an enterprise.

In particular, TOGAF 9 also gives explicit consideration to architectural styles, SOA in particular. Included in TOGAF 9 is a chapter on using TOGAF to define and govern SOA implementations. This chapter discusses SOA as an architectural style, factors relating to the adoption and deployment of SOA within the enterprise, correspondences between SOA and TOGAF terminology, and the definition and structure of Service contracts.

The TOGAF ADM, fondly represented as the “crop circle” diagram below, starts with the Preliminary phase, where an organization establishes and develops its architecture, and then moves through a requirements-driven architecture development cycle, ending with the Architecture Change Management phase, where the organization establishes changes to the new architecture.

TOGAF Requirements Management

The TOGAF Architecture Development Method

Let’s take a quick guided tour through the ADM, and see what SOA can learn from TOGAF.

  • Preliminary Phase. The preliminary phase prepares an architecture team to do architecture. It allows for customization of the ADM for the particular needs of the enterprise and the architecture team. These needs may include SOA as a style of architecture.
  • Phase A — Architecture Vision. During this phase the team defines an architecture project in terms of scope, stakeholders and Architecture Vision, and obtains approval to continue with the project. This phase is critical for a SOA project in order to clearly articulate the business objectives of the initiative and get the correct buy-in from business stakeholders.
  • Phase B — Business Architecture. During this phase the team develops a baseline and target Business Architecture, and conducts a gap analysis in support of the agreed Architecture Vision. A key focus of this phase from a SOA perspective should be to determine the business requirements and identify Business Services.
  • Phase C — Information Systems Architecture. This phase addresses both the Application and Data Architecture. The team develops a baseline and target Information Systems (IS), and conducts a gap analysis in support of the agreed Architecture Vision. Architecting the IS Services and relating them back to Business Services should be a primary SOA activity in this phase.
  • Phase D — Technology Architecture. During this phase the team develops a baseline and target Technology Architecture, and conducts a gap analysis in support of the agreed Architecture Vision. Determining the SOA infrastructure components, such as the SOA intermediary or SOA governance platform, should be activities during this phase.
  • Phase E — Opportunities and Solutions. The team completes the architecture definition in this phase by identifying delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture they’ve identified in previous phases. Taking an holistic view of the overall SOA design and identifying candidate building blocks should complete the architrecture definition in this phase of a SOA initiative.
  • Phase F — Migration Planning. The main focus of Phase F is the creation of a viable implementation and migration plan in cooperation with portfolio and project managers. This phase should develop a rollout plan for the SOA initiative based on the defined architecture. This phase therefore crosses over from architecture to implementation.
  • Phase G — Implementation Governance. Phase G establishes the connection between architecture and implementation, through an architecture contract that addresses the architectural oversight and review of the implementation. Ensuring that the team implements the architecture as designed is as important for a SOA initiative as for any other architecture initiative. Activities in this phase should align the implementation to the business objectives.
  • Phase H — Architecture Change Management. The goal of architecture change management is to ensure that the architecture achieves its original target business value. This goal includes managing changes to the architecture in a cohesive and architected way. In sustaining the architecture description for a SOA initiative over time by applying change management would enable an organization to respond more quickly to business or technology change that impact the SOA implementation.
  • Architecture Requirements Management Phase. The requirements management process continually drives the ADM. Architecture often deals with business drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), which can produce changes in requirements in an unforeseen manner. The key focus of the ADM on business requirements is critical to the success of any SOA initiative. Aligning the architecture definition and implementation to the business requirements should achieve the business objectives and realize the expected value of the overall initiative.

Don’t expect that TOGAF will give you all the answers to your SOA questions, but do expect the ADM to bring structure your architecture efforts. Some of the most important benefits of using the TOGAF in a SOA environment include:

  • TOGAF brings an architected approach to SOA.
  • The TOGAF ADM covers the full scope of the SOA lifecycle.
  • Using a standard method such as the TOGAF ADM reduces project risk.
  • TOGAF promotes better alignment with business strategy and priorities.

The Role of the TOGAF Content Framework

In addition to the ADM, the latest version of TOGAF includes a Content Framework that provides guidance on how to structure and design architecture deliverables by way of a content metamodel. This content metamodel discusses the concepts of function, Business Service, information system Service, application component and technology component in the context of SOA.

The Content Framework is a valuable resource to reference when defining Service models, catalogues and registries. It provides a metamodel that can guide the team in describing and cataloguing Services, as well as integrating the Service definitions with the business architecture. The separation of Business and IS Services as represented in the metamodel is becoming the norm, but also highlights the importance of deploying IS Services that support the delivery of business value.

TOGAF also provides a Services extension to the content metamodel to allow more sophisticated modeling of the Service portfolio by creating a concept of IS Services in addition to the core concept of Business Services. Applications directly support IS Services, and creating the IS Services layer of abstraction relaxes the constraints on Business Services while simultaneously allowing technical stakeholders to put more formality into an IS Service catalog. The content metamodel also provides guidance to the SOA practitioner on how to define the Service catalogue, and how to integrate the Service definitions into the overall business and solution architectures.

The ZapThink Take
TOGAF is a generic architecture framework that is not specific to any industry, style of architecture, geography or technology. It further recognizes that either business or technical communities can lead the SOA initiative. Each group may have a different focus, but their activities are complementary and intersect at the concept of a Service. Implementing TOGAF therefore requires tailoring to adapt it to the culture and management processes of the organization, as well as the style of architecture and the technology strategy.

The current strategy of The Open Group is to keep the ADM generic as a style-independent method, with SOA and other style-specific extensions confined to separate chapters or even separate documents such as the SOA Source Book that The Open Group’s SOA Working Group has published. There are, however, several aspects of SOA practice included in the ADM, even though it hasn’t yet been fully aligned with SOA best practices.

How would you decide whether to use TOGAF ADM or not for your SOA initiative? If you have already adopted a SOA approach, and its working for you, then the ADM won’t necessarily add value for you in the short term. However it won’t do any harm to evaluate your approach against the ADM. You may find some valuable lessons to be learned from TOGAF. However, if you haven’t yet adopted a SOA approach, or if you are experiencing problems with your approach, then the ADM is certainly worth considering. It would require some initial investment in terms of time and effort in learning and tailoring it, but this should be more than outweighed by its potential benefits.