The Open Group Architecture Framework (TOGAF) is quickly emerging as one of the most widely accepted methods for developing enterprise architecture. Originating as the Technical Architecture for Information Management (TAFIM) in the US Department of Defense, the framework was adopted by the Open Group in the mid-1990s. The first TOGAF specification was introduced in 1995, and the latest version, TOGAF 8 (the Enterprise Edition), was released early in 2004.
TOGAF is an open framework. The Open Group freely disseminates the TOGAF specification and all related documentation on its Web site, and encourages the use of it by any organization embarking on enterprise architecture. It is highly customizable, enabling companies to tailor it to their particular challenges.
The core components of TOGAF are its Architecture Development Method (ADM) and the TOGAF Foundation Architecture. The ADM defines a process for developing and maintaining the organization’s enterprise architecture, and for implementing the architecture through a planned program of work. It is non-prescriptive about how to build the models that represent the architecture, and supports all standard modeling technologies, such as the Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), and Integrated Computer-Aided Manufacturing (ICAM) DEFinition (IDEF). The Foundation Architecture describes an Enterprise Continuum through which the developing architecture progresses from the general (foundation) to the organization-specific.
What Is Enterprise Architecture and Why Are Companies Doing It?
Enterprise architecture is the capture of all behavior that goes on in an organization: the data that is processed, who does what, where everything is, and why everything is done. In a sentence, the who, what, why, when, where, and how of the business at every level from high-level corporate goals to the code of low-level programs that implement business processes used to achieve those goals.
Recent technologies have made this possible and enabled the benefits of enterprise architecture to be realized. New legislation such as Sarbanes-Oxley has made it almost mandatory. Enterprise architecture is now being seen as an asset to the organization, and a key enabler for achieving alignment between business and IT.
Obstacles to Enterprise Architecture
The need for enterprise architecture has been around for a long time, but several obstacles existed, for example:
- difficulty in disseminating the information
- difficulty in maintaining this information
- lack of standard tools for capturing, developing, and managing models
- lack of a standard notation and consistent vocabulary for enterprise architecture
Enablers of Enterprise Architecture
In recent years, new technologies have arrived to help make enterprise architecture achievable:
- Corporate intranets and the Internet offer a medium to disseminate information to everyone in the organization.
- A new generation of enterprise architecture modeling tools, capable of:
- supporting a broad spectrum of modeling notation;
- providing a scalable and flexible underlying repository capable of storing and integrating models across all architecture domains;
- offering sophisticated reporting and publication facilities.
- The evolution of TOGAF into a framework for developing enterprise architecture. This has overcome the one remaining obstacle, the lack of a clear, practical, and well-defined approach to architecture development.
What TOGAF Is and Why Companies Are Now Starting to Use It
What makes TOGAF popular is that it is a definitive and proven step-by-step method for developing and maintaining enterprise architecture. It covers the four principal architecture domains of business, information systems (application and data), and technology infrastructure, and focuses strongly on the need for architecture to support business objectives and requirements. It also takes into account establishing the goals and objectives of the enterprise architecture effort itself, guiding users on determining how much of the enterprise is needed to model to realize significant gains, and the realities of getting buy-in from throughout the organization.
The TOGAF Framework
A number of definitions of frameworks are being used in IT today. Microsoft .NET, for example, uses the word framework to describe a large-scale code template. TOGAF and the Zachman Framework define a framework as a tool for thinking about the information that needs to be captured about an organization, to understand how everything works, and to enable the building of information systems that efficiently support the business.
The Zachman Framework is considered the granddaddy of frameworks, a reference framework against which others can position or map themselves. Zachman is method neutral and is concerned with content rather than process and does not prescribe the steps for building enterprise architectures.
TOGAF provides a detailed, step-by-step method on how to build, maintain, and implement enterprise architecture. This method is the Architecture Development Method (ADM). Unlike the Zachman rectangular grid of cells, the TOGAF graphic is dynamic—a set of circles representing the progression through the phases of the ADM and the architecture models used and created during the phases of enterprise architecture development (see Figure 1).
Figure 1: TOGAF Enterprise Framework. Source: The Open Group
These phases are navigated iteratively in a cycle. The circles represent the major phases of building and maintaining the enterprise architecture using the ADM.
The Architecture Development Method (ADM)
The ADM forms the core of TOGAF. It is the result of continuous contributions from a large number of architecture practitioners in The Open Group’s Architecture Forum. At the heart of ADM is requirements management. The business, information systems, and technology architectures are always aligned with the business goals and requirements.
During preliminary work and Stage A, the architecture vision and the scope of the enterprise architecture effort are established, and key questions about the architecture are answered—how much information will be captured, how it will be maintained, how it will be used, and what kind of management buy-in is needed. Other questions include:
- How does an organization begin the process of modeling their enterprise?
- What notations should they use, and what is the method for building the models?
- What if a company only wants to do a slice of enterprise architecture—enough to meet their needs?
- How can existing architecture models be re-used?
In Stage B, we define the Baseline and Target Business Architectures. In this stage, we are able to use methods such as BPMN, IDEF, or UML to develop the required models.
In Stage C, we focus on the Information System (Data and Application) Architectures. TOGAF describes detailed steps for defining the application architecture, and how the applications use and manage the data and present information to users. For data architecture, TOGAF describes steps for defining the data entities relevant to the enterprise, using any appropriate data modeling technique (for example object role modeling, or traditional relational data modeling).
Stage D is concerned with developing the Technology Architecture (for which completion of the Business and IS architectures is a pre-requisite). It is represented by its own mini-framework, detailing how to architect the technology underpinnings of the organization.
One of the strengths of TOGAF is that the ADM also covers architecture implementation. During Stages E and F, you identify and prioritize the projects that will implement the target architecture, and in Sstage G, the projects are undertaken as a planned program of work and deliver the agreed architecture as an integrated set of architecture-compliant solution components.
The Enterprise Continuum
While the ADM specifies a process for building enterprise architecture, TOGAF also offers the Enterprise Continuum as a resource and philosophy for developing enterprise architecture through reusable building blocks. TOGAF’s Enterprise Continuum (see Figure 2) specifies a progression for developing architectures and solutions using architecture building blocks (ABBs) and solution building blocks (SBBs), in a continuous, iterative fashion.
The Enterprise Continuum is composed of the Architecture and Solution Continuums. The Architecture Continuum provides guidance, direction, and support to use the Solutions Continuum to build your technology architecture. The Solutions Continuum defines the solutions that deliver the architecture, and include off-the-shelf solutions and an organization’s own in-place solutions.
The TOGAF ADM guides users through the left to right progression from the general architectures and solutions (on the left), to organization-specific ones (on the right). The Architecture Continuum specifies the Foundation Architecture as the starting point for the architecture effort, then moves through common systems architectures (for example, a generic security architecture), and industry-specific architectures (for example, a Retail Industry Architecture), to reach the organization-specific architecture (on the right).
During the preliminary stage of ADM, users establish how much of its Foundation Architecture can be established from what is already in place in the organization. TOGAF provides a Foundation Architecture to help users get started, embodied in the Technical Reference Model (TRM) and Standards Information Base (SIB). Once an organization has been through its first TOGAF ADM iteration, its own Technology Architecture forms part of its Foundation Architecture for the next cycle.
Figure 2. TOGAF Enterprise Continuum, showing the progression that leads to the increasing refinement of the organization-specific architecture. Source: Popkin Software & The Open Group
Why TOGAF Works
As an enabler of enterprise architecture, TOGAF provides the following benefits:
- Proven Method—TOGAF offers a proven method that is the result of years of research and development by the world’s leading enterprise architects.
- Common Vocabulary—TOGAF guides architects in using a standard taxonomy for business, information systems, and technology modeling. This shared vocabulary means that everyone in an organization can read and understand the information.
- Communication—Models of the enterprise architecture give visual representation to business concepts, and, when published on the corporate intranet, disseminate knowledge of the business to the workforce.
- Command Decisions—A business-focused enterprise architecture provides knowledge about an organization and enables managers to make better-informed decisions.
- Reduced complexity—A well developed architecture leads to a better integrated solution portfolio, fewer interfaces, increased data sharing, improved reliability of the solutions, and easier maintenance.
- Business-IT alignment—The business focus of the architecture development process and the strong emphasis on the need for the implemented solution to be architecture-compliant together will help ensure that IT solutions are aligned to the needs of the business.
TOGAF: Key to a Competitive Advantage
In summary, TOGAF 8 (Enterprise Edition) is becoming widely accepted as the definitive method for building and maintaining enterprise architectures. A number of technology enablers, such as more powerful, repository-based modeling tools that publish information to corporate intranets, have made enterprise architecture achievable. This combination of tool and methodology enables companies to use their enterprise architecture to help them make better decisions about technology investments and business process improvement. With its comprehensive and detailed methodology approach to enterprise architecture, TOGAF offers companies a proven way to align their technology to their business goals and reap the competitive advantages of corporate agility, governmental compliance, and improved cost management and resource allocation.
TOGAF is freely available at http://www.opengroup.org/architecture/togaf8-doc/arch/.
About the Authors
Dave Harrison is a senior consultant for Popkin Software, with the responsibility of helping clients design and implement enterprise architectures using TOGAF and other frameworks.
Lou Varveris leads the communications group at Popkin Software. He also serves as UML product manager and was a co-writer on the UML Bible book.