WHAT IS TOGAF ADM ("CRIB NOTES")?

TOGAF ADM (Architecture Development Method)

TOGAF ADM is the core of TOGAF. It is the only part of the TOGAF body of knowledge that is considered mandatory, if an architecture organization wants to be « TOGAF compliant ». 

The ADM describes the 10 activities that are required for developing and managing an Enterprise Architecture. The figure reproduced below presents an overview of TOGAF ADM. 

TOGAF ADM

Phase C activity is typically split in two : Data Architecture and Application Architecture.

It is expected that the generic ADM be customized for a particular organization. 

Open Group TOGAF working group’s materials describe ADM in full detail and in shortened forms. These « crub notes » briefly describe the purpose and outcomes of each activity, in my own words.

TOGAF ADM Approach  

One of the corner stones of TOGAF is the « ADM cycles ». In TOGAF, in a mature architecture practice, most of architecture work is organized in a succession of engagements, each one with its specific objectives and scope.

Two workstreams, though, are performed in a more continuous mode : the ADM activities tagged as « Preliminary » and « Phase H : Architecture Change Management ». The former encompasses the building and the management of the basic capabilities required for executing the architecture engagements. The latter encompasses the monitorization of the organization needs and of the stakeholders, in order for capturing new needs leading to new architecture engagements. 

In short, for TOGAF’s authors: 

• the changes and the added value come from the specific and unique architecture engagements,  framed by their objectives, scope, budget and callendar
• the continuous activities of the architecture team are essential, but they are enablers and do not generate change and new value by themselves

ADM : Preliminary Phase

The Preliminary Phase can be understood in two ways : 

• the initial setup of the architecture capability in the organization and the later evolution and management of this capability
• the update of such architecture capability, in order to complement it with the specific aspects required for a new architecture engagement  

In other parts of TOGAF (specifically in « Part VII - Architecture Capability Framework », «Establishing an Architecture Capability ») the initial setup of the architecture capability is presented as a full execution of the ADM cycle. However, in the description of the Preliminary Phase, both goals are combined. This minor overlapping is not a big issue and can be easily handled during the customization of TOGAF.

The maintenance and evolution of the architecture capabilities are continuous activities. On the other hand, before a particular engagement, it should be expected to spot certain capabilities related to the new engagement that should be reinforced, before the new ADM cycle starts.

In its « continuous process » version, the scope of the Preliminary Phase encompasses : 

• to identify the « architecture footprint » for the organization (i.e., the people executing architecture work and their responsibilities)
• to define and establish the architecture framework (i.e., to tailor the ADM, the Content Framework and the Enterprise Continuum)
• to define and establish the architecture governance model
• to integrate the enterprise architecture processes with the rest of management frameworks in the organization
• to select and implement supporting tools (such as the tool for implementing the Architecture Repository)
• to define the architecture principles, the standards and the reference models
• to assess the enterprise architecture maturity level

On the other hand, in its more sctrict « preliminary » version, previous to a specific new engagement, the scope of the Preliminary Phase encompasses : 

• to identify the key drivers and elements in the organizatonal context
• to identify the stakeholders and their concerns
• to define the requirements for architecture work
• to identify the areas of the current architecture capability that have to be updated or increased

Phase A: Architecture Vision

Purpose. Phase A has two groups of actors : the architecture team and the stakeholders. It is aimed at getting a clear understanding among both groups of the context, the business drivers and the business goals that are claiming for a new architecture engagement. The goals of Phase A are: 

• to establish the vision and the scope for the architecture engagement 
• to get buy-in and commitment of the stakeholders 

According to the spirit of TOGAF, the develoment work of the enterprise architecture team (Phases B to F) should not start until there is a clear understanding with the stakeholders, formalized by their signature of the outcomes of Phase A.

Outcomes of Phase A :

• Capability Assessment

o  Identifies the business goals and strategic drivers of the organization.  

o Defines what business capabilities (i.e. business functions) the organization will need to develop in order to fulfill its business goals and strategic drivers.

o Assesses the current capabilities and the implications of the new requirements for the organization.  

• Architecture Vision

o Defines the purpose of the new architecture engagement (i.e., how the new engagement will allow the organization to meet the new capability requirements). 

o « The Architecture Vision provides a first-cut, high level description of the Baseline and Target Architectures, covering the business, data, application and technology domains. » (that is, « pencil-sketches » or « version 0.1 » of these architectures).

o « A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise ».

o Architecture vision aims at the communication with the stakeholders ; completeness and exactitud will come later, in the following phases B, C and D.  

• Statement of Architecture Work 

o Defines the scope of the engagement  

o Defines the target architecture value proposition and KPI’s (i.e., an agreement on how to assess the success of the architecture engagement, after it is completed)

o Identifies the business transformation risks and mitigation activities

o Develops initial high level plans

• Communications plan:  

o Identifies all stakeholders and their information needs

o Shows where, how and when the architects will communicate with them  

All Phase A deliverables are aimed at the stakeholders, whose understanding, buy-in and commitment must be granted, if the new architecture engagement is to be successful.

 

Phase B: Business Architecture

Purpose. Phase B defines the target business architecture and the roadmap components that are related to the business domain.

The business architecture is the structured collection of the following building blocks : 

• Business services (bound by a service contract) and business functions (not bound)
• Drivers/goals/objectives
• Organizations/actors/roles
• Locations
• Business processes (i.e. Process/Event/Control/Product)
• Contracts/Measures  

In Phase B, the following views of the business architecture are developed :  

• Baseline business architecture
• Target business architecture
• Gap analysis between the two
• Business roadmap for prioritizing activities

Outcomes of Phase B :

• Architecture Definition Document (chapters related to the business domain)  

o  Business footprint (high level description of people and locations involved)

o Business functions and their information needs

o Baseline business architecture v1.0

o Defines criteria for prioritizing these activities

• Architecture Requirements Specification (chapters related to the business domain)

o Functional requirements

o   Non-functional requirements

o   Assumptions, constraints, domain specific Business Architecture principles

o Policies, Standards and Guidelines

Phase C: Information Systems Architectures — Data Architecture

Purpose. Phase C (Data Architecture) defines the major types and sources of data necessary to support the business. It is NOT concerned with database design – what comes on a later phase, during software engineering.

All data management issues are of interest, including :

• Processes, services and application components that create and use the data
• Corporate standards
• Data transformations
• Data interfaces (with internal and external systems)
• Data migration
• Data governance

The data architecture is concerned with the following building blocks :

• Data entity / data component

In Phase C (Data Architecture), the following views of the data architecture are developed : 

• Baseline data architecture
• Target data architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Data Architecture) :

• Architecture Definition Document (chapters related to the data domain)
• Baseline data architecture v1.0
• Target data architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (chapters related to the data domain)
• Identifies the activities related to the data architecture domain
• Defines criteria for prioritizing these activities
• Architecture Requirements Specification (chapters related to the data domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Business Architecture principles
• Policies, Standards and Guidelines

Phase C: Information Systems Architectures — Application Architecture

Purpose. Phase C (Application Architecture) defines the « application landscape » needed to support the business. It is NOT concerned with application systems design. The goal is to identify the logical application components, their relationships, and to describe each one with enough detail. 

All issues related to the applications are of interest, including :  

• Application and user location
• Application communication
• Manageability
• Process/system realization
• Application migration
• Software engineering

The application architecture is concerned with the following building blocks : 

• Application components
• Interface catalog

In Phase C (Application Architecture), the following views of the application architecture are developed :  

• Baseline application architecture
• Target application architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Application Architecture) :

• Architecture Definition Document (chapters related to the application domain)
• Baseline application architecture v1.0
• Target application architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (chapters related to the application domain)
• Identifies the activities related to the application architecture domain
• Defines criteria for prioritizing these activities
• Architecture Requirements Specification (chapters related to the application domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Architecture principles
• Policies, Standards and Guidelines  

Phase D: Technology Architecture

Purpose. Phase D defines the « technology landscape » needed to support the business. As technology architecture defines the physical realization of an architecture solution, it has strong links to implementation and migration planning.

The technology architecture supports the cost assessment of different scenarios.

All issues related to the technology domain are of interest, including : 

• Physical locations
• Sizing and capacity planning
• Installation, governance and migration
• Performance
• Maintainability
• Availability

The technology architecture is concerned with the following building blocks :

• Technology standards
• Technology portfolio

In Phase D, the following views of the technology architecture are developed :

• Baseline technology architecture
• Target technology architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Application Architecture) :

• Architecture Definition Document (complete, including the technology domain)
• Baseline architecture v1.0
• Target architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (complete)
• Identifies the activities related to all domains
• Defines criteria for prioritizing the activities
• Architecture Requirements Specification (complete, including the technology domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Architecture principles
• Policies, Standards and Guidelines  

Phase E: Opportunities & Solutions

Purpose. Phase E addresses the scope of the projects that will deliver the new architecture. Phase E is not concerned with the delivery aspects, which are examined in Phase F.  

In Phase E, the architecture team:

• reviews and consolidates the gap analysis done in Phases B, C and D
• identifies all work packages and organizes them into projects and portfolios
• develops a series of transition architectures, for moving incrementally from the baseline architecture to the target architecture
• creates portfolio and project charters

Phase F: Migration Planning 

Purpose. Phase F addresses the formulation of an implementation and migration plan, for executing the transaction architectures and the target architecture identified in Phase E. 

In Phase F, the architecture team : 

• estimate resource requirements, project timings and delivery vehicles for each project
• prioritize the migration projects (assessing cost, benefits and risks)
• generates the architecture implementation roadmap (time lined)  

Main outcomes of Phase F : will guide the implementation projects in Phase G 

• Architecture Definition Document (reviewed version)
• Architecture Requirements Specification
• Architecture Contracts
• Implementation and Migration Plan

  

Phase G: Implementation Governance

Purpose. To guide and monitor the implementation of the projects defined in Phase F. 

In Phase G, the architecture team:  

• guides development of solutions deployment and formulate recommendations
• governs and manages the Architecture Contracts
• performs enterprise architecture compliance reviews
• implements business and IT operations

Phase H: Architecture Change Management

Purpose : Though it appears as Phase H of the ADM cycle, Architecture Change Management can be better seen as a continuous activity, monitoring the new architecture resulting of the current architecture engagement in its entirety (that is, the whole enterprise architecture, not only the building blocks that were altered by the last engagement).

Phase H objectives are : 

• to monitor whether the baseline architectures are fit for purpose
• to assess the performance and business value of the architecture and to make recommendations for improvement
• to run the architecture change management process
• to operate the architecture governance framework

 

ADM Architecture Requirements Management

The requirements management process is executed on a continuous basis, meaning that it interacts with all processes in the ADM cycle.

The initial set of requirements in a new engagement (Phase A) is aimed at the architecture team, who needs to make sure they had good communication with the stakeholders.

The requirements generated in Phases B to F are aimed at the implementation teams in Phase G. They are formalized in the « Architecture Requirements Specification », one of the key inputs delivered to the implementation teams.

TOGAF does not mandate a specific process or tool. It is up to the organization to select their own options.

[END OF POST]