Introduction to the TOGAF ADM


The TOGAF standard provides an architecture framework. It provides the required tools and methods that can assist in the different phases of an Enterprise Architecture, including acceptance, production, use, and maintenance. The TOGAF standard is based on an iterative process model. It is supported by defined best practices along with a set of reusable architecture assets.

Architecture


The TOGAF standard defines architecture as:

"The fundamental concepts or properties of a system and its environment, embodied in its elements, relationships, and in the principles of its design and evolution"

"The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time"

There are four aspects to an enterprise architecture, referred as the four domains

Business Architecture


This deals with the business aspects of the architecture. It includes the business strategy, governance, organization and other key business processes. The enterprise architecture has to be in line with the way of the organization's business policies; and the business policies have to be in line with the enterprise architecture. Hence the Business architecture is a fundamental component of the enterprise architecture.

Data Architecture


The core vision of the Open Group is "Boundary-less information flow". This requires the organization's logical and physical data assets and data management resources to be aligned in a way that would allow such information flow. A good data architecture is required to ensure this.

Application Architecture


Data alone is not sufficient. Applications that accesses this data have to be streamlined with the enterprise - in order to allow the information flow. An Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization

Technology Architecture


The underlying technology carries the load of any development. The choice of technology has to be aligned with the enterprise goals. Hence the technology architecture forms the basis of any enterprise architecture. It describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services; this includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Architecture Development Method


The ADM can be considered the heart of the TOGAF standard. It provides a tested and repeatable process for developing architectures. It provides a method for developing an architecture framework, architecture content, and processes for transitioning, and governing the realization of architectures. All of these activities are carried out within an iterative cycle of continuous architecture.

The ADM is defined in form of 10 phases that iteratively define the development method.

Preliminary Phase


The preliminary phase defines the beginning. This phase describes the methods and tools for preparation and initiation activities required to create an Architecture Capability. It can include fundamental components like customization of the TOGAF framework and definition of Architecture Principles. This forms the basis for all the further effort in the architecture definition.

Phase A: Architecture Vision


This describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative. Here, we identify the stakeholders and the goals. We create an Architecture Vision. This vision is approved and signed off. Based on this, we proceed with the further architecture development phases

Phase B/C/D: Business, Information System and Technology Architecture


As we saw above, the architecture has four main components - Business Architecture, Data Architecture, Application Architecture and Technology Architecture. These are defined during the phase B, C and D.

The phase B provides methods and tools for development of the business architecture that is in line with the agreed architecture vision. The phase C describes the development of information system (data as well as application) to support the agreed architecture vision and the business architecture. Finally, phase D describes the development of the technology architecture to support the vision and the business, data and information system architectures.

Phase E: Opportunities & Solutions


The architectures are meaningless without an evaluation of feasibility, and a solutions to possible hindrances. This phase describes initial implementation planning, along with the identification of delivery vehicles for the architecture defined in the previous phases.

Phase F: Migration Planning


One cannot just jump from the current legacy systems to a wonderful enterprise architecture. The process is quite elaborate and takes time. When it takes time, we have to plan for the duration that is spent while we migrate. This typically requires a detailed plan for the intermediate phases as well. The migration planning phase addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.

Phase G: Implementation Governance


All plans are meaningless unless they are followed by implementation. The implementation process is quite elaborate. Implementation requires not just management of resources and finances. It requires a detailed architectural support to ensure the implementations are aligned with the enterprise. This phase provides an architectural oversight of the implementation.

Phase H: Architecture Change Management


Change is an integral part of life. Situations and needs change over time and so does the enterprise and its target architecture. This phase describes the methods and tools required to handle these changes without disturbing the flow.

Outputs of the ADM


As we work iteratively on different phases of the ADM, we produce several outputs that retain the progress of our work in form of documents. The TOGAF Architecture Content Framework provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.

On the top level, these work products are classified in the following types:

Deliverable


A deliverable is something that is reviewed, finalized, agreed and signed off by the stakeholders. A deliverable marks the completion of a particular activity in the ADM.

Deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.

Artifact


An artifact is a work product describing a particular aspect of the architecture. Artifacts are typically created as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things): for example, requirements catalog, business interaction matrix, and a use-case diagram.

An artifact can form a particular aspect of the deliverable - hence a part of the deliverable. An architectural deliverable may contain many artifacts. Artifacts form the content of the Architecture Repository.

Building Block


Any sensible enterprise would avoid "reinventing the wheel". This is achieved by use of building blocks. A building block represents a potentially reusable component of the enterprise capability that can be combined with other building blocks to deliver architectures and solutions. A building block may be composed of several supporting building blocks.

TOGAF describes two types of building blocks - Architecture Building Block and Solution Building Blocks.

ABBs typically describes the required capability and shape the specification of SBBs. SBBs represent components that will be used to implement capability required by the given ABB. A Solution is more concrete compared to an Architecture. Architecture is a specification of what rather than how. For example, a customer services capability may be required within an enterprise, supported by many SBBs such as processes, data, and application software.