Home > Enterprise Architecture > Articles > Using TOGAF® to Develop and Implement Enterprise Architecture in Government - U.S. Federal Agencies as Example

Using TOGAF® to Develop and Implement Enterprise Architecture in Government - U.S. Federal Agencies as Example

John Polgreen, Ph.D., Chief Architect, Architecting the Enterprise

Introduction

The Situation

The Federal Enterprise Architecture (FEA) has well defined reference architectures which are readily understandable by architects familiar with such frameworks as Zachman and the Department of Defense Architectural Framework5 (DODAF). The Federal CIO Council has provided high level advice on process in its FEA Practice Guidance and the Federal Segment Architecture Methodology (FSAM).

However, the frameworks and process guidance by themselves do not seem adequate. Architecture teams are spending much too much time in unnecessary planning because they lack process information at the proper level of granularity. Architects lack a common language with which to speak to vendors, consultants and even among themselves as EA teams.

A Potential Solution Augment Federal EA practice with TOGAF

The Open Group Architecture Framework (TOGAF) is rapidly growing worldwide. Eighty percent of Fortune 50 corporations have adopted TOGAF as their architecture framework. Four hundred entities within the UK government use TOGAF, with three of the largest ministries making the heaviest use. In the United States, New York State has recently committed to TOGAF. Given this success, architects working within the Federal government may wish to consider using TOGAF to supplement the FEA Practice Guidance and the FEA.

The uptake of TOGAF is a direct result of its ability to address specifically those difficulties faced by architects attempting to work with the FEA. The TOGAF Architecture Development Method (ADM) is a well defined, granular process which guides architects through major phases (and steps within each phase) with objectives, inputs and outputs clearly specified. Artifact templates and examples are available. TOGAF provides a common language with which team members from diverse backgrounds can communicate. Communication with vendors and consultants is also greatly simplified.

TOGAF maps well to the FEA, the FEA Practical Guidance and to FSAM, and some popular EA tools have both FEA and TOGAF modules. The TOGAF ADM can also be mapped to DODAF. A proposed mapping has recently been provided in an Open Group white paper₁ . This is significant because many architects working with the FEA have had previous experience with DODAF.

This paper will discuss both TOGAF and US Federal EA practice at a high level, and then use the Vision and Business Architecture Phases of the TOGAF ADM to show the potential value of TOGAF in describing government business architecture. The approach will be descriptive rather than critical, as a way to open discussion on the subject.

What is TOGAF?

The Open Group Architectural Framework actually has very strong Federal roots. The U.S. Department of Defense (DOD) developed the Technology Architecture For Information Management (TAFIM) in the 80s. Deciding to retire TAFIM in the early 90s, DOD approached members of the EA community because DOD thought the intellectual property was valuable and worth maintaining. The Open Group accepted and renamed TAFIM. It released the first version of TOGAF in 2001.

TOGAF is maintained and updated by a consensus process in The Open Group’s Architecture Forum. TOGAF Version 8 was released in 2006, updating TOGAF from a technology architecture to an enterprise architecture with much greater emphasis on understanding business imperatives before developing more technical architectures. Version 9, released in 2009, increases this business orientation and provides further process and content detail.

The Architecture Continuum

In producing architectures using TOGAF, the architect proceeds from a very generic Foundation Architecture (e.g. the five reference models of the FEA) to a very specific organization architecture (e.g. the Grant segment architecture of a specific agency). The work proceeds through what TOGAF calls the Architecture Continuum, narrowing the Foundation Architecture by looking at Common Systems Architectures (e.g. email or security architectures) and vertical industry architectures (e.g. housing or finance industry architectures). Architects find building blocks (depicted as blocks in figure 1) as they proceed through the continuum and assemble them into their own Organization Architecture.

Figure 1 - TOGAF Architecture Continuum

The Architecture Development Method

The actual means of choosing and assembling these building blocks – of proceeding through the continuum – is the Architecture Development Method. The ADM begins with a Preliminary Phase in which architects set up the overall architecture program and goes into cycles of eight phases in which individual architecture projects (e.g. a data center consolidation or the grant segment architecture for a particular agency) are undertaken (figure 2 ).

Figure 2 - TOGAF Architecture Development Method

Figure 2 - TOGAF Architecture Continuum

The Content Framework

One of the innovations in TOGAF 9 is the addition of a Content Framework, which is tied both to an explicit metamodel and to the well proven ADM. Federal TOGAF users gain considerable leverage by linking the ADM to the Reference Models of the FEA and will be able to more easily and flexibly create metamodels. They can also tie artifacts defined in the Content Framework to their own metamodels and to the phases of the ADM as they populate their versions of the five Reference Models of the FEA. Because the TOGAF Metamodel is modular, it is ideally suited to assisting architects to define and model within segments.

Looking at the Metamodel will help aid understanding of the final presentation of the content framework.

Figure 3 - TOGAF Metamodel

The Metamodel is closely related to the ADM. Figure 3 shows how the highest level building blocks map into the structure. This is useful to Agency architects because it is consistent with component-based architecture, an essential element of Federal EA practice.

Figure 4 - Modularity of the TOGAF Metamodel

The modularity of the TOGAF Metamodel also helps achieve component‐based architecture. Figure 4 shows how the core of the Metamodel can be augmented by extensions. If your Agency is doing a SOA implementation, then adding the ‘Services’ and ‘Governance’ extensions may help you develop a workable metamodel without using every possible element.

In this Taxonomy of Views diagram (Figure 5), all artifacts described in TOGAF 9 are mapped to the Phases of the ADM and to Core and Extension portions of the Metamodel. It gives the architect a starting point from which to add Federal or Agency specific artifacts.

Figure 5 - Taxonomy of Artifacts

Using TOGAF for Enterprise Architecture in the Federal Government

This section describes how EA teams can use the TOGAF ADM to develop and implement FEA‐based architecture projects within Federal Agencies.

Many architects see EA in the Federal Government as comprised of the five reference architectures published in 2007 as the Consolidated Reference Model 6(CRM). Although these models are central to architecture in the Federal space, other structures and processes are also important. In terms of structure, the Federal Enterprise Architecture Framework, based closely on the work of Zachman and Spewak, provides high level guidance. The FEA Practice Guidance, published in 2006, gives process advice, also at a high level, and fits the FEA into the context of other activities such as capital planning. Federal bodies, notably Department of Interior [DoI), have created more granular process descriptions, and templates for many artifacts. DoI’s Methodology for Business Transformation (MBT) forms the basis for a cross‐agency initiative called the Federal Segment Architecture Methodology (FSAM).

Federal Enterprise Architecture

“Led by OMB, the purpose of this effort is to identify opportunities to simplify processes and unify work across the agencies and within the lines of business of the Federal government. The outcome of this effort will be a more citizen‐centered, customer‐focused government that maximizes technology investments to better achieve mission outcomes.”

FEAPMO

The FEA defines five Reference Architectures as shown in Figure 6. Like TOGAF, the approach is business‐driven and component‐based (TOGAF building blocks are similar in concept to FEA components).

Figure 6 - FEA Reference Models

Mapping the FEA Practice Guidance to the TOGAF ADM

The FEA Practice Guidance provides a high level process which is expressed in the upper portion of Figure 7. The Phases of the TOGAF ADM map directly to this process as shown in the lower portion of the diagram. If EA teams within an Agency are in the position of having good management support, they will be able to use the ADM to create a high level roadmap to a future state for the entire Agency. Fortunately such a roadmap is required by the White House Office of Management and Budget (OMB). Agencies are assessed yearly against its presence and quality. After describing this roadmap, the EA team would then begin a number of targeted projects, using the ADM, which either describes segments of the Agency EA or some high value project at a lower level.

Figure 7 - Performance Improvement Lifecycle FEA Practice Guidance

Mapping FSAM to TOGAF

The Federal Segment Architecture Methodology (FSAM) promises a practical path to guide agency architects as they develop segment architectures. The TOGAF ADM, with its accumulation of industry best practices, offers a level of process detail that can save FSAM implementers planning time and result in architectures and solutions that are more responsive to agency strategy. The TOGAF Content Metamodel, new in TOGAF 9, offers touch points to FSAM regarding content. It describes more than fifty discreet artifacts (each having variations) that map to the metamodel and to the ADM.

The conceptualization of segments in TOGAF 9 (Figure 8) helps show how segments fit into the overall EA effort of an agency or department. The cube represents the whole of an agency’s EA. The top level is a strategic overview of the EA, including all subject matter and through the full planning horizon ‐ but at the shallowest level of detail. The Segment level looks at chunks of subject matter at a high level of granularity. It also looks at ‘as is’, ‘to be’ and ‘transitional’ states for the segment. All of this is done at a deeper level of detail than the strategic architecture. The lowest level is that of Capability (FSAM calls this level “Solution”). This is closely tied to the notion of Capability Based Planning, already in use by agencies such as FEMA. Subject matter within segments is described here, so granularity is lower. ‘As is’, ‘to be’ and ‘transitional’ states are described. The level of detail is much more granular.

Figure 8 - Architecture Landscape

Figure 9 shows how a first high level, strategic sweep of the agency using an ADM cycle, spawns several cycles describing Segments. Although these Segment cycles are shown in the diagram as being ADM cycles, they could just as well be FSAM cycles. These FSAM cycles can be modified to make maximum use of the accumulated experience of TOGAF. The Segment cycles then spawn Capability cycles, using the ADM again.

Figure 9 - Using the ADM at 3 Levels

The ADM should be considered for both that Strategic sweep (a cycle which few agencies ever get around to doing) and for the architecting of Capabilities, whether these be ones discovered during the Segment definition, or are 'low hanging fruit' that are described to meet specific stakeholder concerns. Describing segments themselves can be done using FSAM, tailored with TOGAF specifics.

There are two approaches to using TOGAF with FSAM.One is to use the FSAM five steps as the basic model and map the ADM and the Content Metamodel to it. The other is to use the process of the ADM as the basic process model (already mapped to the Content Metamodel) and map the five FSAM steps to it. The former approach will fit almost all agencies. Figure 10 shows a high level mapping of the ADM to FSAM.

Figure 10 - Mapping FSAM to the TOGAF ADM

Using TOGAF to Describe a Federal Business Architecture

TOGAF can be used to describe any of the five FEA domains. This section shows how Phases A and B can be used to describe an agency’s business architecture at the strategic, segment or solution level, aligning with the agency’s BRM. Although it is beyond the scope of this paper, these ADM phases can be mapped in detail against FSAM Steps 1 and 2. When implementing FSAM, it may be a good practice to cross check against the TOGAF ADM steps in the corresponding Phases.

To focus the discussion here, the example of grants offered through Agency X to eligible residents will be used. The assumption is that Agency X has already developed a strategic roadmap in an initial ADM iteration. It then developed a Grants segment architecture using either an ADM cycle, an FSAM cycle or some combination of the two. This segment architecture was based on Grants.gov, the first of many cross‐agency architectures described by the OMB. The agency will now conduct a solution level (or what TOGAF calls “capability” level) iteration of the ADM to describe, build and deploy the capability to disburse grants. The capability to disburse grants is a capability distinct from, for instance, the capability to process grant applications.

Architecture Vision Phase

Figure 11 shows the discreet steps of the ADM Vision Phase. All architecture projects start at this phase, whether they are conducted at the strategic, segment or solution (capability) level.

Figure 11 - Steps for the Vision Phase

The second step results in the Stakeholder Map artifact, a matrix common to TOGAF and FSAM. It shows stakeholders in the grant disbursement capability, their concerns; how they rate in terms of power and interest, and the artifacts and deliverables they will need to be able to fulfill their roles. Most, if not all, of these artifacts can be chosen from the Taxonomy of Artifacts (Figure 5) – this is one of the great tools of TOGAF 9.

Figure 12 - Value Chain Diagram

In the ‘Development of Architecture Vision’ step, architects will typically conduct a workshop with stakeholders, the result of which will be Vision Document. This will include the Stakeholder Map and a Value Chain Diagram (Figure 12). This diagram shows how primary activities or capabilities contribute to grants - or whatever goals the agency is aiming for. It will also include a Solution Concept Diagram.

Figure 13, showing a pencil sketch concept of the proposed architecture. Information related to the steps on business transformation and risk will also be documented in the Vision Document.

Figure 13 - Solution Concept Diagram

Business Architecture Phase

Now that a vision of the target state – in this case the capability of Agency X to disburse grants – has been defined, architects can describe the business elements of the capability in detail. (Figure 14) shows the detailed steps involved.

Figure 14 - Steps of the Business Architecture Phase

In the first step architects refer back to the Stakeholder Map, validate its conclusions regarding the artifacts stakeholders will need to see, and consider what modeling techniques to utilize. Process flow can be described equally well with the Unified Modeling Language (UML) or Business Process Modeling Notation (BPMN). The choice of which to use depends mainly on its usefulness for the stakeholder, although other technical issues of interest to the architect may be considered also. TOGAF is modeling language and tool agnostic.

Using the selected artifact templates – and many are available from the Open Group for download – the architects now model the chosen artifacts for the baseline architecture, but only to the extent needed to support the target descriptions. The team then describes the target state of the grants disbursement capability to as great a level of detail as required by the stakeholders.

Having both baseline and target views of a set of artifacts, the team can now conduct a gap analysis between each of the artifacts. This will be combined with gap analyses in Application (Service Component in FEA terminology), Data, Technology and Performance Architectures and used in Phase E, Opportunities and Solutions, to create a meta-gap analysis. This will be used as the basis for choosing technologies to outsource, buy or build.

The team then creates a high level roadmap which shows how the building blocks (a key concept in TOGAF and equivalent to “components” in FEA) are to be moved from the baseline to the target state. They resolve impacts this new business architecture may cause, and they conduct a stakeholder review to validate models and ensure continued buy-in.

It is easy to see the usefulness of many of the TOGAF artifacts. Catalogs are lists that form the source material for Matrices and Diagrams. These are the catalogs, for which descriptions and templates are available for download, specifically geared toward the business architecture:

Organization/Actor Catalog
Role Catalog
Business Service/Function Catalog
Process/Event/Control/Product Catalog
Contract/Measure Catalog
Driver/Goal/Objective Catalog

It is easy to see how a list of organizations with all the roles associated with them would be Indispensible in describing a grants disbursement capability. The same is clear with a list of locations.

Matrices show the relationships between entities listed in catalogs. Figure 15 shows an Actor/Role Matrix. This artifact shows which actors perform which roles, supporting definition of security and skills requirements.

Figure 15 - Actor/Role Matrix

The Business Function/Data Entity Matrix (Figure 16) shows relationship between data entities and business functions. Using this artifact enables architects to assign ownership of data entities to organizations and understand the data/information exchange.

Figure 16 - Business Functions to Data Entity Matrix

For the grant disbursement capability, this artifact will support gap analysis. It will assist in determining whether any data entities are missing and need to be created.

The Business Interaction Matrix (Figure 17) depicts the interactions between organizations and business functions across the enterprise. It highlights value chain and dependencies across organizations. Showing how business services relate to each other across organization units will help architects identify how application services and components will trace to business functions.

Figure 17 - Business Interaction Matrix

The Business Footprint Diagram (Figure 18) is a very useful artifact for use with the highest level stakeholders. It describes the links between business goals, organizational units, business functions and business services. It then maps these to technical components delivering the desired capability. In the case of the grants disbursement capability, architects could show high level business stakeholders the relationship between their highest level goal and the technology components that would be needed to actually achieve it.

Figure 18 - Business Footprint Diagram

The Service/Information Diagram (Figure 19) shows information needed to support business services. It also shows what data is consumed by or produced by a business service. It forms the basis of elaboration in Phase C. If architects understand how information flows through business services needed for the grants disbursement capability, they will be in a better position to describe it later in logical and physical terms as they describe the data and service component architectures.

Figure 19 - Serive Information Diagram

Other artifacts described in the Taxonomy include some with which most architects are familiar, including Organization Decomposition Diagram, Functional Decomposition Diagram, Process Flow Diagram and Business Use Case Diagram. There is also considerable overlap with artifacts called out by FSAM and DODAF.

In the last step of the Business Architecture Phase, the team will write the business portion of the Architecture Document, which will include all baseline and target artifacts and gap analyses.

The Remainder of the ADM

The Agency X EA team will have described the vision for a grants disbursement capability. They have also described the business architecture using artifacts that stakeholders both want to use and are able to understand. Now they are ready to describe the Service Component Architecture and the Data Architecture (Phase C). After this they are able to describe the technical infrastructure on which applications will rest. Phases A-D have been conducted as much as possible on a black box, technology and vendor neutral basis. At this point the team has a fully architected the grants disbursement capability.

In Phase E, Opportunities and Solutions, the team will place all the gaps relevant to the grants disbursement capability identified in a single matrix, and choose technology/vendor options to fill the gaps. Once these solutions are identified, the team places them in priority order and identifies transition architectures – interim projects which reduce the risk of delivering all capabilities at once. Phase F is when detailed migration planning is carried out, including cost/benefit and risk analysis, as well as creation of a detailed plan.

In Phase G the team writes a contract to assist solution teams and carries out compliance reviews against the contract. The completed grants disbursement capability is deployed in this phase. Phase H is dedicated to Change management. The Agency X EA team helps the Architecture Board determine whether change requests are major enough to require re-entry into the ADM, or whether they can be sent back to solution teams for minor fixes.

Conclusion

The use of TOGAF in government could create considerable improvement in present practice. The TOGAF ADM maps well to FEA/FSAM, and provides needed process detail. It supplies, in a well defined taxonomy, templates and examples which supplement those available currently to Federal architects. Because of this, TOGAF simplifies communication within architecture teams, and with vendors and consultants.

TOGAF is currently the de facto industry standard for enterprise architecture in the private sector, and is growing rapidly in influence in the public sector. It is an open standard, and is technology and vendor neutral. It is largely descriptive rather than prescriptive, and is purposely intended to be tailored. It is also inexpensive to use. It is free to download and considerable consulting resources are available with little ramp-up time needed. Towards the end of 2010 there are more than 12,000 TOGAF Certified Architects globally, many of these within the community of Federal contractors.