TOGAF as an Enterprise Architecture Framework

Introduction Role of TOGAF Using TOGAF with Other Frameworks Summary TOGAF and Architecture Governance

Introduction

The TOGAF FAQ explains that there are four kinds of "architecture" that are commonly accepted as subsets of an overall Enterprise Architecture:

Business Architecture;
Data Architecture;
Application Architecture; and
Technology Architecture.

The combination of Data Architecture and Application Architecture is also referred to as the Information System Architecture.

TOGAF was originally designed to support the last of these - the Technology Architecture. Over its years of evolution, however, it has acquired many of the facets of a framework and method for Enterprise Architecture. As of TOGAF Version 8, these different facets have been integrated, and TOGAF has undergone a major redevelopment, with the result that it is now a fully-fledged enterprise architecture framework.

With Version 8.1, the numbering scheme for successive releases of TOGAF has been modified, to include a major and minor release indicator. Version 8.1 builds on the base established in Version 8, by adding new information in a number of areas. See the Version 8.1 Release Notice for a summary of the changes in this Release of TOGAF.

The Role of TOGAF

TOGAF in its Enterprise edition remains what it has always been, namely an architectural framework - a set of methods and tools for developing a broad range of different IT architectures. It enables IT users to design, evaluate, and build the right architecture for their organization, and reduces the costs of planning, designing, and implementing architectures based on open systems solutions.

The key to TOGAF remains a reliable, practical method - the TOGAF Architecture Development Method (ADM) - for defining business needs and developing an architecture that meets those needs, utilizing the elements of TOGAF and other architectural assets available to the organization.

A number of enterprise architecture frameworks already exist and are widely recognized, each of which has its particular advantages and disadvantages, and relevance, for enterprise architecture. They are discussed in Part IV, Other Architectures and Frameworks.

Although a number of enterprise frameworks exist, there is no accepted industry standard method for developing an enterprise architecture. The Open Group's goal with TOGAF is to work towards making the TOGAF architecture development method just such an industry standard method, which is neutral towards tools and technologies, and can be used for developing the products associated with any recognized enterprise framework, such the Zachman Framework, FEAF, TEAF, C4ISR/DoD Framework, that the architect feels is appropriate for a particular architecture.

The TOGAF Architecture Development Method therefore does not prescribe any specific set of enterprise architecture deliverables - although it does describe a set, by way of example. Rather, TOGAF is designed to be used with whatever set of deliverables the TOGAF user feels is most appropriate. That may be the set of deliverables described in TOGAF itself; or it may be the set associated with another framework, such as Zachman Framework, FEAF, etc.

In fact, TOGAF has always done this: it does not prescribe a specific set of "Architecture Views", but describes an example taxonomy of the kinds of views that an architect might consider developing, and why; and it provides guidelines for making the choice, and for developing particular views, if chosen.

With the migration of TOGAF to an enterprise architecture framework, this flexibility becomes even more important. TOGAF is not intended to compete with these other frameworks: rather, it is intended to perform a unique role, in distilling what these other frameworks have to offer, and providing a generic Architecture Development Method that can be adapted for use with any of these other frameworks.

The Open Group's vision for TOGAF is as a vehicle and repository for practical, experience-based information on how to go about the process of enterprise architecture, providing a generic method with which specific sets of deliverables, specific reference models, and other relevant architectural assets, can be integrated.

TOGAF and Architecture Governance

As governance has become an increasingly visible requirement for organisational management, the adoption of governance into TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.

The benefits of Architectural Governance include:

Increased transparency of accountability, and informed delegation of authority
Controlled risk management
Protection of existing asset base through maximizing re-use of existing architectural components
Proactive control, monitoring and management mechanisms
Process, concept, and component reuse across all organisational business units
Value creation through monitoring, measuring, evaluation, and feedback
Increased visibility supporting internal processes and external parties' requirements
- In particular, increased visibility of decision-making at lower levels - ensuring oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
Greater shareholder value
- In particular, Enterprise Architecture increasingly represents the core Intellectual Property of the enterprise.
- Studies have demonstrated a correlation between increased shareholder value and well governed enterprises.
Integrates with existing processes and methodologies and complements functionality by adding control capabilities.

Further detail on Architecture Governance is given on Part IV of TOGAF.

Using TOGAF with Other Frameworks

Overview

Two of the key elements of any enterprise architecture framework are:

a definition of the deliverables that the architecting activity should produce; and
a description of the method by which this should be done.

With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases.)

Because TOGAF is a generic framework, as mentioned above, and intended to be used in a wide variety of environments, it does not prescribe a specific set of deliverables; rather it talks in general terms about the types of deliverable that need to be produced, and focuses instead on the methods by which these should be developed.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced by a more specific set, defined in any other framework that the user architect considers relevant.

In the latter case, the user architect will adapt and build on the TOGAF ADM in order to define a tailored method and process for developing these more specific deliverables. Guidelines for adapting the TOGAF ADM in such a way are given under Adapting the ADM in Part II.

As a generic framework and method for Enterprise Architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains, specific horizontal technology areas such as Security or Manageability, or specific application areas such as e-Commerce. The concept of leveraging other relevant architectural assets in this way is known within TOGAF as the Enterprise Architecture Continuum.

The Enterprise Architecture Continuum

TOGAF embodies the concept of the Enterprise Architecture Continuum (described in Part III), to reflect different levels of abstraction in an architecture development process. In this way TOGAF facilitates understanding and co-operation between actors at different levels. It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF ADM. By means of the Enterprise Architecture Continuum, architects are encouraged to leverage all other relevant architectural resources and assets, in addition to the TOGAF Foundation Architecture, in developing an organization-specific IT architecture.

In this context, the TOGAF ADM can be regarded as describing the process of moving from the TOGAF Foundation Architecture to an organization-specific architecture (or set of architectures), leveraging the contents of the Enterprise Architecture Continuum along the way, including the TOGAF Foundation Architecture and other relevant architectural frameworks, models, components and building blocks.

Summary

TOGAF thus does not seek to compete with or duplicate other frameworks. What TOGAF does seek to provide is a practical, industry standard method of doing enterprise architecture, leveraging all relevant assets in the process, that is freely available and supported by a number of different architecting consultancies, and that is sufficient for an organization to use "as-is" or to adapt as the basis of an enterprise architecture method for other, deliverables-focused frameworks.