ADM Phases

Mapping of ADM and Agile

ADM Phases

More detailed view is shown below

The TOGAF Architecture Development Method (ADM) is a central feature of the TOGAF standard. The ADM cycle describes an incremental and iterative method for designing Business, Data, Applications, and Technology architectures. It progresses from high-level concept diagrams, to detailed domain architectures, all the way to the development of solution architectures, architecture roadmaps and implementation plans.

What is Architmate?

The ArchiMate® language is an Open Group standard that provides an Enterprise Architecture modeling language. The Archimate® language views the model as a set of layers (Business, Application, and Technology) as well as some specialized extensions (Motivation, and Implementation and Migration

Preliminary Phase

Requests for Architecture Work is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Requests for Architecture Work can be created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning.

The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services.

The steps within the Preliminary Phase

These steps are:

1. Scope the Enterprise Organizations Impacted
2. Confirm Governance and Support Frameworks
3. Define and Establish Enterprise Architecture Team and Organization
4. Identify and Establish Architecture Principles
5. Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)
6. Develop a Strategy and Implementation Plan for Tools and Techniques

Deliverables of Phase A

1. Tailored Architecture Framework
2. Organizational Model for Enterprise Architecture
3. Architecture Principles
4. Business Principles, Goals, and Drivers
5. Request for Architecture Work

Phase A (Vision)

The Architecture Vision Phase (Phase A) focuses on defining the scope of the project, creating and embracing the vision, and obtaining approvals to move forward. It develops the foundation by:

• Ensuring recognition and endorsement of the project
• Validating the business principles, goals and drivers
• Prioritizing the Baseline Architecture effort

The vision provides the first attempt to provide a high-level description of the Baseline and Target Architectures.

The Architecture Vision is documented within the Statement of Architecture Work, which is signed by the sponsoring organization and provides the consensus required to move forward.

• During the Architecture Vision phase, new requirements generated for future architecture work within the scope of the selected requirements need to be documented within the Architecture Requirements Specification
• A Business Transformation Readiness Assessment can be used to evaluate and quantify the organization's readiness to undergo a change. This assessment is based upon the determination and analysis/rating of a series of readiness factors.
• Understand that the baseline and target need not be described at the same level of detail. In many cases, the baseline is described at a higher level of abstraction, so more time is available to specify the target in sufficient detail.
• Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures.
• The Architecture Vision typically covers the breadth of scope identified for the project, at a high level.

• The Architecture Vision includes a first-cut, high-level description of the baseline and target environments, from both a business and a technical perspective.

  Objective of Phase A

  • To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management
  • To validate the business principles, business goals, and strategic business drivers of the organization
  • To define the scope of, and to identify and prioritize the components of, the Baseline Architecture effort
  • To define the relevant stakeholders, and their concerns and objectives
  • To define the key business requirements to be addressed in this architecture effort, and the constraints that must be dealt with
  • To articulate an Architecture Vision that demonstrates a response to those requirements and constraints
  • To secure formal approval to proceed
  • To understand the impact on, and of, other enterprise architecture development cycles ongoing in parallel.

Deliverables of Phase A

1. Statement of Architecture Work
2. Architecture Vision
3. Communications Plan
4. Capability Assessment
5. Architecture Definition Document

Stakeholder Mangement

Stakeholder management provides a discipline for gaining support between architecture practitioners and benefits the enterprise by:

• Identifying powerful stakeholders early for their input to shape the architecture.

• Obtaining support from powerful stakeholders to enable more resources to be available during engagement of architectures.

• Early and frequent communications with stakeholders allowing better understanding of the architecture process.

• Reaction to architecture models and reports can be more effectively anticipated

Stakeholder analysis is used in the Architecture Vision phase (Phase A) to identify the key players in the engagement and updated with each subsequent phase of the ADM. The complexity of architecture can be difficult to manage and obtain agreement from large numbers of stakeholders. TOGAF addresses these issues throughout the ADM using the concepts of:

• Stakeholders
• Concerns
• Views
• Viewpoints

View and ViewPoints

Architecture Views are formal representations of the overall architecture that hold some significance or meaning to one or more stakeholders. This allows a particular architecture to be communicated and understood by all stakeholders in order to facilitate that the system is addressing their concerns. The views chosen are usually at the discretion of the architecture.

Some of the most common views to be developed within architecture are:

1. Use Case View — Find out various use cases that we need to work on for a project/phase/pod etc.

2. Business View — This view is used to addresses the concerns of the users. It can consist of

   • BPMN Diagrams by BA and Business.
   • Process Flow diagrams (per process agreed with SME and BA)
   • Project Scope and Timeline/Gantt Chart diagrams by Delivery lead

3. SHLC/VHLC/HLC View — Create a high level view of the system

4. Logical View/s — addresses the VHLs, API VHL's (usually per API). Usually these consist of

   • Sequence diagrams
   • Class diagrams
   • Component diagams
   • State Machine Diagrams
   • Activity Diagrams

5. Network View — addresses the structuring of network and communication elements in order to simplify network design and planning.

6. Deployment View — addresses the deployment view of the system.

7. Data Flow View — addresses the data requirements of processing, storage, retrieval, archiving and security

8. DevOps View — addresses the DevOps view for the complicated CI and CD's.

9. HA and DR View — addresses the HA and DR requirements of the system.

10. Implementation View — addresses the detailed implementation view of various components.

11. Security View — addresses the security aspects of a system.

12. Data View — addresses the data aspects of a system. Various diagrams used are:

13. Business data model
14. Logical data model
15. Data management process model
16. Data Entity/Business Function matrix

17. Data Interoperability requirements

18. Enterprise Manageability View — addresses the operations, administration, and management of a system

Phase B (Business)

Objective of Phase B

• Establish a Baseline Business Architecture
• Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
• Analyze gaps between Baseline and Target
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures

Deliverables of Phase B, C and D

1. Architecture Definition Document
2. Architecture Requirements Specification
3. Architecture Roadmap
4. Architecture Building Blocks

Architecture Defination Document

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, interim state(s), and target).

The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:

• The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.
• The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

It is suggested that this document reference the various deliverables in the container. For instance, the Architecture Principles will be documented in an Architecture Principles document and that document referenced here. It may be that this container is implemented using a wiki or as an intranet rather than a text-based document. Even better would be to use a licensed TOGAF tool that captures this output.

Architecture Requirements Specification

Why we need Architecture Requirements Specification?

The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective:

• The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect.
• The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

Architecture Roadmap

• The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture.
• The Architecture Roadmap highlights individual work packages' business value at each stage.
• Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps.
• The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM.

Phase C (Information System)

The Information Systems Architecture Phase (Phase C) handles the development of the Data and Application aspects of the architecture, specifically creating Target Architectures for business processes supported by IT implementations

Bottom up or Top Down

Implementation of architecture is commonly approached by top-down design and performing bottoms-up implementation, though the steps for implementing can follow any order.

Deliverables of Phase B, C and D

1. Architecture Definition Document
2. Architecture Requirements Specification
3. Architecture Building Blocks

Phase D (Technology)

The Technology Architecture Phase (Phase D) focuses on the technical aspect of the architecture, specifically those available within the Architecture Continuum.

The decisions made in previous phases of the Architecture Development Method may have implications on the technology components and platform, particularly those decisions around service granularity and service boundaries.

The areas of impact within the Technology Architecture include:

• Hardware, Software and communication technology: All techs needs to be looked at, their relationships to each other and the environment.
• Performance — platform service requirements can contain services with several functionality units with varying non-functional requirements and more services than required by the requesting system
• Maintainability — if service granularity is too general, the introduction of change to the system may be too difficult and costly
• Latency — inter-service communication may be impacted by the inappropriate setting of service boundaries and granularity
• Availability — when defining service composition and service granularity, high availability concerns may be a key determiner

Deliverables of Phase B, C and D

1. Architecture Definition Document
2. Architecture Requirements Specification
3. Architecture Roadmap
4. Architecture Building Blocks

Phase E (Opportunities & Solutions)

The Opportunities and Solutions phase is where the architecture team starts to be concerned with the actual implementation of the Target Architecture, looking into the best path for implementing the architecture, from both the corporate business and technical perspectives.

The activities are logically grouped into project work packages.

This phase can use Transition Architecture

Transition/Tactical/Band-aid Architectures allow changes to architecture without too extensive of an impact on the organization in any single increment. It also allows simultaneous work on several architectures to be conducted on different levels of detail.

Deliverables of Phase E

1. Architecture Definition Document
2. Architecture Building Blocks
3. Architecture Roadmap
4. Solution Building Blocks
5. Implementation and Migration Plan
6. Transition Architecture
7. Implementation Governance Model

Objective for E

• Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D.
• Phase E is the initial step on the creation of the Implementation and Migration Plan which is completed in Phase F. It provides the basis of a well considered Implementation and Migration Plan that is integrated into the enterprise's portfolio in Phase F.

ABB's to SBB's

Finally, in Phase E the SBB's (building blocks) become more implementation-specific as SBBs, and their interfaces become the detailed architecture specification. The output of Phase E is the building block architecture, both in ABB (i.e., functionally defined) and SBB (i.e., product-specific) forms.

Phase F (Migration Planning)

The primary focus of the Migration Planning approach is to create a viable Implementation and Migration Plan with the assigned portfolio and project managers. This includes assessing the dependencies, costs, and benefits of the transition architecture and migration projects

Generally, there are 3 basic approaches: - Greenfield — starting from the beginning - Revolutionary — radical change to the environment - Evolutionary — phased approach to introduce capabilities

ABB

Architecture Building Blocks (ABBs) relate to the Architecture Continuum, and are defined or selected as a result of the application of the ADM. Characteristics are:

• Capture architecture requirements, e.g., business, data, application, and technology requirements.
• Direct and guide the development of SBBs.

Architecture Contract

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective architecture governance (see TOGAF Part VII, Architecture Governance). By implementing a governed approach to the management of contracts, the following will be ensured:

• A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
• Adherence to the principles, standards, and requirements of the existing or developing architectures
• Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
• A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
• A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body This is a signed statement of intent to conform with the enterprise architecture, issued by enterprise business users. When the enterprise architecture has been implemented (at the end of Phase F), an Architecture Contract will normally be drawn up between the architecting function (or the IT governance function, subsuming the architecting function) and the business users who will subsequently be building and deploying application systems in the architected environment.

Implementation Governance Model

Why do we need the implementation governance model?

Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.

The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate architecture governance.

Phase G (Implementation & Governance)

Phase G focuses on providing an oversight of the implementation, ensuring that there is adherence to the defined architecture during the development and deployment of solutions. This phase involves managing and governing the implementation process, thus maintaining alignment with the architectural vision and requirements.

• Conformance & Compliance Review is in Phase G.
• Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.

Compliance Assessment

Compliance Assessment: Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process.

Periodic compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives.

SBB

Solution Building Blocks (SBBs) relate to the Solutions Continuum and may be either procured or developed.SBB characteristics are:

• Define what products and components will implement the functionality.
• Define the implementation.
• Fulfil business requirements.
• Be product or vendor-aware

Phase H (Change Management)

The objective of Phase H is to establish an continual monitoring and architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G.

3 types of change managements

The approach is based on classifying required architectural changes into one of three categories:

1. Simplification change: This change to an architecture is often driven by a requirement to reduce investment. A simplification change can normally be handled via change management techniques.
2. Incremental change: This change is driven by a requirement to derive additional value from existing investment. An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change.
3. Re-architecting change: This change is driven by a requirement to increase investment in order to create new value for exploitation. A re-architecting change requires putting the whole architecture through the architecture development cycle again.

Steps done are: - Provide analysis for architecture Change Management - Conduct Enterprise Architecture performance reviews with service management. - Assess Change Requests and reporting to ensure that the expected value realization and Service-Level Agreement (SLA) expectations of the customers are met. - Undertake a Gap Analysis of the performance of the Enterprise Architecture. - Ensure change management requests adhere to the Enterprise Architecture Governance and framework. - If the change is at an infrastructure level — for example, ten systems reduced or changed to one system — this may not change the architecture above the physical layer, but it will change the Baseline Description of the Technology Architecture; this would be a simplification change handled via change management techniques. - Establish 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

Change Request

During the implementation of an architecture, as more facts become known, it is possible that the original architecture definition and requirements are not suitable or are not sufficient to complete the implementation of a solution.

In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions. Additionally, external factors – such as market factors, changes in business strategy, and new technology opportunities, may open up opportunities to extend and refine the architecture.

In these circumstances, a Change Request may be submitted in order to kick-start a further cycle of architecture work.Typical contents of a Change Request are:

• Description of the proposed change
• Rationale for the proposed change
• Impact assessment of the proposed change, including:

Requirements Management

Note

It is important to note that the Requirements Management circle denotes not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases, and also between cycles of the ADM.

Note also that the requirements management process itself does not dispose of, address, or prioritize any requirements: this is done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM.

Deliverables of Requirement Phase

1. Architecture Requirement Spec Document
2. Requirements Impace Assessment

Requirements Impace Assessment

Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture.

A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.

---

Was this page helpful?

Yes No