ADM in Detail


ADM forms the core of the TOGAF framework. It helps derive organization specific enterprise architectures - by addressing the business requirements. It is a time tested method based on the contributions from many architecture practitioners.

It defines 4 levels (Business, Application, Data and Technology) of architecture; along with 10 phases of architecture development.

ADM Phases


The ADM is defined in 10 phases that cycle through a range of architecture domains. It enable the architect to ensure that a complex set of requirements is adequately addressed. The ADM is applied iteratively, and each iteration refines the outcome of the phase.

ADM supports iteration on three levels:

  • Cycling around the ADM
  • Iterating between phases
  • Cycling around a single phase

Throughout the ADM cycle, the results should be validated against the original requirements (of the phase as well as the whole ADM). The validation should review and refine the scope, detail, schedules, and milestones. Each phase should consider assets produced from previous iterations of the process and external assets from the marketplace, such as other frameworks or models.

With this background, let us look into each phase in detail. TOGAF defines each phase in terms of its objectives, inputs, outputs and steps.

Preliminary Phase


The purpose of the preliminary phase is to prepare the organization for successful TOGAF architecture projects. Here, we undertake the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, selection of tools, and the definition of Architecture Principles.

In essence, the preliminary phase is a very generic way of ensuring we are ready for a project. It takes very little (not zero) input from the actual business requirement.

Objectives


The objective of the preliminary phase to ensure we are ready to go.

Desired Architecture Capability


The first objective is to determine the Architecture Capability desired by the organization:

  • Review the organizational context for conducting Enterprise Architecture
  • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
  • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
  • Establish Capability Maturity target

Establish the Capability


Next, we establish the Architecture Capability

  • Define and establish the Organizational Model for Enterprise Architecture
  • Define and establish the detailed process and resources for Architecture Governance
  • Select and implement tools that support the Architecture Capability
  • Define the Architecture Principles

Steps


In order to attain the objective of determining and establishing the architecture capability, the TOGAF recommends these steps

  • Scope the enterprise organizations impacted
  • Confirm governance and support frameworks
  • Define and establish the Enterprise Architecture team and organization
  • Identify and establish Architecture Principles
  • Tailor the TOGAF framework and, if any, other selected architecture frameworks
  • Develop strategy and implementation plans for tools and techniques

Inputs


The preliminary phase is the basis for all the development. Hence, it starts with very generic inputs. These are:

  • The TOGAF Library
  • Other architecture framework(s)
  • Board strategies, business plans, business strategy, IT Strategy, business principles, business goals, and business drivers
  • Major frameworks operating in the business
  • Governance and legal frameworks
  • Architecture Capability
  • Partnership and contract agreements
  • Existing organizational model for Enterprise Architecture
  • Existing architecture framework, if any - and its Architecture method, content, tools, Architecture Principles and the overall Architecture Repository

Outputs


The Preliminary phase uses these inputs as it goes through the defined steps, to produce the following outputs

  • Organizational Model for Enterprise Architecture
  • Tailored Architecture Framework, including Architecture Principles
  • Initial Architecture Repository
  • Restatement of, or reference to, business principles, business goals, and business drivers
  • Request for Architecture Work
  • Architecture Governance Framework

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 A is about project establishment and initiates an iteration of the architecture development cycle, setting the scope, constraints, and expectations for the iteration. It is required in order to validate the business context and to create the approved Statement of Architecture Work.

Note that the Preliminary phase creates a "Request for Architecture Work", whereas the Phase A creates a "Statement of Architecture Work".

Objectives


The objective of the Phase A is to develop a high-level aspirational vision. To create a vision of the capabilities and business value - that should be delivered as a result of the proposed Enterprise Architecture. Based on this, generate an approved Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision

Steps


The way to go with this phase is to follow these steps. These steps are focused on the particular iteration of the ADM rather than the entire enterprise project.

  • Establish the architecture project
  • Identify stakeholders, concerns, and business requirements
  • Confirm and elaborate business goals, business drivers, and constraints
  • Evaluate capabilities
  • Assess readiness for business transformation
  • Define scope
  • Confirm and elaborate Architecture Principles, including business principles
  • Develop Architecture Vision
  • Define the Target Architecture value propositions and KPIs
  • Identify the business transformation risks and mitigation activities
  • Develop Statement of Architecture Work; secure approval

Inputs


The inputs to this phase come from the outputs of the preliminary phase or those of the previous ADM cycle, or the enterprise requirements

  • Request for Architecture Work
  • Business principles, business goals, and business drivers
  • Organization Model for Enterprise Architecture
  • Tailored Architecture Framework, including tailored architecture method, architecture content, Architecture Principles, configured and deployed tools
  • Populated Architecture Repository; that is, existing architecture documentation (framework description, architecture descriptions, existing baseline descriptions, etc.)

Outputs


Based on the inputs, the Phase A generates an architecture vision for that ADM cycle.

  • Approved Statement of Architecture Work
  • Refined statements of business principles, business goals, and business drivers
  • Architecture Principles. Note that the architecture principle was also an input to the Phase A. That was a generic set of principles to be followed. This is specific to the enterprise and ADM iteration.
  • Capability assessment
  • Tailored Architecture Framework
  • An Architecture Vision, including refined key high-level stakeholder requirements
  • Communications Plan
  • Additional content populating the Architecture Repository

Along with these, the Phase A also generates the basic template drafts for the eight architecture definition documents to be produced in the following phases:

  • Baseline & Target Business Architecture
  • Baseline & Target Application Architecture
  • Baseline & Target Data Architecture
  • Baseline & Target Technology Architecture

Phase B/C/D


There is a lot of similarity in the flow of the phases B, C and D. Hence it is best to understand them together.

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.

Objectives


In simple words, the objective of each of these phases is to define the corresponding baseline and target architectures, and then identify the gaps between them. The baseline architecture describes the current status of things and the target architecture is what we want it to be. The target architectures are developed based on the architecture vision, statement of architecture work and the stakeholder concerns - for this particular iteration of ADM.

The Business Architecture describes how the enterprise needs to operate in order to achieve the business goals defined in the architecture vision and statement of architecture work. Data and Application architectures define how the data rests and flows and is processed in the enterprise, in order to enable the business architecture. Whereas the Technology architecture provides the technology components and services that enable the data and application architectures.

Steps


All three phases have very similar steps.

  • Select reference models, viewpoints, and tools
  • Develop Baseline and Target Architecture Descriptions
  • Perform Gap Analysis
  • Define candidate roadmap components
  • Resolve impacts across the Architecture Landscape
  • Conduct formal stakeholder review
  • Finalize the Architecture
  • Create Architecture Definition Document

Inputs


All three phases have a similar set of inputs. A lot of inputs to each architecture phase come from the architecture vision phase and the phases before it.

  • Request for Architecture Work
  • Statement of Architecture Work
  • Capability Assessment
  • Communications Plan
  • Organization Model for Enterprise Architecture
  • Tailored Architecture Framework
  • Architecture Vision
  • Architecture Repository
  • Enterprise Continuum
  • Draft Architecture Definition Document, containing the target and baseline architectures - populated in the Phase A(high level) and in the previous phases(detailed). For example, the Technology architecture will get the detailed business, data and application architectures (populated in the individual phases) and a high level technology architecture (populated in the Phase A).
  • Architecture roadmap for the previous phases.
  • Draft Architecture Requirements Specification, including: Gap analysis results and Relevant technical requirements
  • The relevant principles: Business principles, business goals, and business drivers / Data principles / Application Principles / Technology principles

Outputs


The outputs of the three phases are similar to each other.

  • Statement of Architecture Work, updated if necessary
  • Refined, updated or new Architecture Principles for that phase - if any
  • Draft Architecture Definition Document containing content updates:
    • Relevant Baseline Architecture (detailed), if appropriate
    • Relevant Target Architecture (detailed with Business Capabilities, Value Streams, and Organization Map as core artifacts)
    • Architecture views corresponding to the selected viewpoints, addressing key stakeholder concerns
  • Components of an Architecture Roadmap related to that phase
  • Draft Architecture Requirements Specification including content updates:
    Business
    • Gap analysis results
    • Technical requirements
    • Updated business requirements
    Data
    • Gap analysis results
    • Data interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture
    • Updated business requirements
    • Updated application requirements
    Application
    • Gap analysis results
    • Application interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture
    • Updated business requirements
    • Updated data requirements
    Technology
    • Gap analysis report
    • Requirements output from Phases B and C
    • Updated technology requirements

Phase E: Opportunities and Solutions


This is where we come down to the ground level and start talking about implementation. This phase describes the process of identifying delivery vehicles (projects, programs, or portfolios) that can deliver the Target Architecture that we identified in previous phases.

Objectives


The objective of this phase is to create an complete architecture roadmap - based on the gap analysis and the candidate architecture roadmap components that were produced in the Phases B, C, and D. Here, we determine whether an incremental approach is required. If the gap to cover is big enough to demand an incremental approach, we identify the Transition Architectures that will deliver continuous business value.

Define the SBBs and ABBs required to realize the Target Architecture.

Steps


In order to achieve the above objectives, we need to follow these steps

  • Determine and confirm key corporate change attributes - the exact measurable attributes that need to change.
  • Determine the business constraints that we need to work along, for implementation of the defined architecture
  • Review and consolidate the results of gap analysis performed in the Phases B, C and D
  • Review and consolidate the requirements across related business functions and their interoperability
  • Refine and validate the dependencies
  • Confirm the readiness and risk for business transformation
  • Formulate the Implementation and Migration Strategy
  • Identify and group major work packages
  • Identify Transition Architectures
  • Create Architecture Roadmap & Implementation and Migration Plan

Inputs


As one would expect, the Phase E requires all that was created in the previous phases, along with the relevant inputs from the enterprise.

  • Product Information
  • Request for Architecture Work (From Preliminary Phase)
  • Capability Assessment (From Phase A)
  • Communications Plan (From Phase A)
  • Planning Methodologies
  • Organizational Model for Enterprise Architecture (Preliminary Phase)
  • Governance Models and Frameworks
  • Tailored Architecture Framework (Preliminary Phase, Phase A)
  • Statement of Architecture Work (Phase A)
  • Architecture Vision (Phase A)
  • Architecture Repository (From enterprise, enriched by the previous phases)
  • Draft Architecture Definition Document (updated in Phases B, C, D)
  • Draft Architecture Requirements Specification (updated in Phases B, C, D)
  • Change Requests for existing programs and projects
  • Candidate Architecture Roadmap components (from Phases B, C, D)

Outputs


The Phase E looks into what can be done and how. It updates and refines the outputs of the previous phases, with the considerations for practical implementation. The output of this phase is an input to the following phases that go about the details of implementation.

  • Statement of Architecture Work, updated if necessary
  • Architecture Vision, updated if necessary
  • Draft Architecture Definition Document, including Transition Architectures, number and scope, if any
  • Draft Architecture Requirements Specification
  • Capability Assessment, including Business Capability and IT Capability
  • Architecture Roadmap, including:
    • Work package portfolio
    • Identification of Transition Architectures, if any
    • Implementation recommendations
  • Implementation and Migration Plan (outline), including Implementation and Migration Strategy

Phase F: Migration Planning


This phase addresses migration planning. It looks into how we should move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.

Objectives


Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan. We have been updating the draft roadmap since the Phase B. This phase finalizes it. Along with that , we ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise's overall change portfolio. And ofcourse, we should never forget the stakeholders. An important objective of this phase is to ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

Steps


In order to achieve these objectives, TOGAF recommends the following steps:

  • Confirm management framework interactions for the Implementation and Migration Plan
  • Assign a business value to each work package
  • Estimate resource requirements, project timings, and availability/delivery vehicle
  • Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation
  • Confirm Architecture Roadmap and update Architecture Definition Document
  • Complete the Implementation and Migration Plan
  • Complete the architecture development cycle and document lessons learnt

One may find the last step a bit out of place. Well the cycle is not complete as yet! What about Phase G and H? Well, the thing is done for the architect. What remains is the realization of the architecture - the not so glamorous parts.

Inputs


The inputs to this phase are the outputs of the previous phases and some from the enterprise.

  • Request for Architecture Work (Preliminary Phase)
  • Organization Model for Enterprise Architecture (Preliminary Phase)
  • Governance Models and Frameworks
  • Tailored Architecture Framework (Preliminary Phase, Phase A)
  • Communications Plan (Phase A)
  • Statement of Architecture Work (Phase A)
  • Architecture Vision (Phase A)
  • Architecture Repository
  • Draft Architecture Definition Document, including Transition Architectures, if any (Phase B-E)
  • Draft Architecture Requirements Specification (Phase B-E)
  • Architecture Roadmap (Phase E)
  • Capability Assessment, including Business & IT Capability (Phase E)
  • Implementation and Migration Plan (outline), including High-level Implementation and Migration Strategy (Phase E)
  • Change Requests for existing programs and projects

Outputs


This phase provides us all that we need to jump into the implementation.

  • Implementation and Migration Plan (detailed), including:
    • Implementation and Migration Strategy
    • Project and portfolio breakdown of the implementation
    • Project charters (optional)
  • Finalized Architecture Definition Document, including the Finalized Transition Architectures, if any
  • Finalized Architecture Requirements Specification
  • Finalized Architecture Roadmap
  • Re-usable Architecture Building Blocks
  • Requests for Architecture Work for a new iteration of the ADM cycle (if any)
  • Implementation Governance Model
  • Change Requests for the Architecture Capability arising from lessons learned

This is the final phase before we start implementing. We finalize all the architecture documents that we had started and populated in the previous phases. We define the individual architecture blocks that will be realized in the implementation phase. We push aside for the next ADM cycle, the things that may not be feasible this time. And we define the strategy, breakdown, plan and the governance model that will be used while implementing.

Phase E and Phase F might seem similar to each other. But there are some subtle differences. The focus in phase E is in identifying what and how it can be implemented - splitting in terms of components and building blocks. The focus in phase F is on the process of moving from baseline to target.

Phase G: Implementation Governance


This is where the action begins. We have been planning all along and now we try to put things in place, to get something work. Phase G defines how the architect should constrain the implementation projects, monitor them, and produces a signed Architecture Contract.

Objectives


The objective here is simple. We need to ensure that the implementation projects conform with the Target Architecture by implementation projects. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests.

Steps


To achieve these objectives, TOGAF defines the following steps:

  • Confirm scope and priorities for deployment with development management
  • Identify deployment resources and skills
  • Guide development of solutions deployment
  • Perform Enterprise Architecture compliance reviews
  • Implement business and IT operations
  • Perform post-implementation review and close the implementation

Inputs


All the draft documents from the previous phases are finalized by now. All of them form an input to this phase

  • Request for Architecture Work (Preliminary Phase)
  • Capability Assessment (Phase A)
  • Organization Model for Enterprise Architecture (Phase A)
  • Tailored Architecture Framework (Preliminary Phase and Phase A)
  • Statement of Architecture Work (Phase A)
  • Architecture Vision (Phase A)
  • Architecture Repository
  • Architecture Definition Document (Built over all phases and finalized in Phase F)
  • Architecture Requirements Specification (Built over all phases and finalized in Phase F)
  • Architecture Roadmap (Built over all phases and finalized in Phase F)
  • Implementation Governance Model (Phase F)
  • Architecture Contract (Draft)
  • Request for Architecture Work identified in Phases E and F
  • Implementation and Migration Plan (Phase E, F)

Outputs


Based on all the hard work here, we generate a Signed Architecture Contract. The implementation is assessed based on the governance requirements to generate a Compliance Assessment. And the formal Change Request is defined.

Finally, architecture compliant solutions are deployed. That includes

  • The architecture-compliant implemented system
  • Populated Architecture Repository
  • Architecture compliance recommendations and dispensations
  • Recommendations on service delivery requirements
  • Recommendations on performance metrics
  • Service Level Agreements (SLAs)
  • Architecture Vision, updated post-implementation
  • Architecture Definition Document, updated post-implementation
  • Business and IT operating models for the implemented solution

Phase H: Architecture Change Management


Change is a part of life. Everything from the low level code requirements up to the enterprise-wide requirements will continue to change. This phase is dedicated to handling and managing such changes.

Objectives


The objective of this phase is to ensure that the architecture lifecycle is maintained in the ever changing environment. It is to ensure that the Architecture Governance Framework is not messed up and executed as it should be. And to ensure that the Enterprise Architecture Capability meets current requirements.

Steps


In order to achieve these objectives, TOGAF recommends these steps

  • Establish the value realization process
  • Deploy monitoring tools
  • Manage risks
  • Provide analysis for architecture change management
  • Develop change requirements to meet performance targets
  • Manage governance process
  • Activate the process to implement change

Inputs


Similar to the Phase G, this phase takes in all the finalized inputs from the previous phases, along with the specific change related inputs

  • Request for Architecture Work (Preliminary Phase)
  • Organization Model for Enterprise Architecture (Phase A)
  • Tailored Architecture Framework (Preliminary Phase, Phase A)
  • Statement of Architecture Work (Phase A)
  • Architecture Vision (Phase A)
  • Architecture Repository
  • Architecture Definition Document (Built over all phases and finalized in Phase F)
  • Architecture Requirements Specification (Built over all phases and finalized in Phase F)
  • Architecture Roadmap (Built over all phases and finalized in Phase F)
  • Implementation and Migration Plan (Phase E, F)
  • Implementation Governance Model (Phase F)
  • Signed Architecture Contract (Phase G)
  • Compliance Assessments (Phase G)
  • Change Requests due to technology changes
  • Change Requests due to business changes
  • Change Requests from lessons learned

Outputs


The change management process generates the following outputs:

  • Architecture updates
  • Changes to architecture framework and principles
  • New Request for Architecture Work, to initiate another cycle of the ADM
  • Statement of Architecture Work, updated if necessary
  • Architecture Contract, updated if necessary
  • Compliance Assessments, updated if necessary

Requirements Management


We exist because the requirements exist. That is our bread and butter!

The process of architecture requirements management is relevant to all phases of the ADM cycle. Requirements Management is a dynamic process. It addresses the identification of requirements for the enterprise, storing them, and then feeding them in and out of the relevant ADM phases. Hence, the ADM chart shows it as central to driving the ADM process.

Objectives


The objective of this phase is to ensure that Requirements Management process is sustained and operates for all relevant ADM phases - to manage architecture requirements identified, and made available during any execution of the ADM cycle or a phase.

Steps


For achieving this goal, TOGAF recommends the following steps

  • Identify/document requirements
  • Baseline requirements
  • Monitor baseline requirements
  • Identify changed requirements; remove, add, modify, and re-assess priorities
  • Identify changed requirements and record priorities; identify and resolve conflicts; generate requirements impact statements
  • Assess impact of changed requirements on current and previous ADM phases
  • Implement requirements arising from Phase H
  • Update the Architecture Requirements Repository
  • Implement change in the current phase
  • Assess and revise gap analysis for past phases

Inputs


The inputs to the Requirements Management process are the requirements-related outputs from each ADM phase. The first high-level requirements are produced as part of the Architecture Vision. Each architecture domain then generates detailed requirements. Deliverables in later ADM phases contain mappings to new types of requirements (for example, conformance requirements).

Outputs


The output of the requirements management phase include the Changed requirements; and the Requirements Impact Assessment. The impact assessment identifies the phases of the ADM need to be revisited to address a given changes. The final version of this assessment must include the full implications of the requirements (e.g. costs, timescales, and business metrics).