Day 2
ADM Phases
- Output of Preliminary phase: Request for architecture framework
- Output of Architecture Vision phase: Statement of architecture work
Architect Areas of Interest
The TOGAF® ADM
- The ADM is a tested and repeatable process for developing architectures.
- All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to Business Goals and opportunities.
ADM Phases Summary
- The Preliminary Phase: The preparation and initiation activities required to create an Architecture Capability including customization of the TOGAF framework and definition of Architecture Principles
- Phase A: Architecture Vision: The initial phase of an architecture development cycle It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
- Phase B: Business Architecture: Development of a Business Architecture to support the agreed Architecture Vision
- Phase C: Information Systems Architectures: Development of Information Systems Architectures to support the agreed Architecture Vision
- Phase D: Technology Architecture: Development of the Technology Architecture to support the agreed Architecture Vision
- Phase E: Opportunities & Solutions: Initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
- Phase F: Migration Planning: How to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan
- Phase G: Implementation Governance: Architectural oversight of the implementation
- Phase H: Architecture Change Management: Procedures for managing change to the new architecture
- Requirements Management: Operates the process of managing architecture requirements throughout the ADM
ADM Phases
- The phases of the ADM cycle are further divided into steps, which are defined in the detailed description of each phase.
- The Requirements Management phase is a continuous phase that ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases.
“Draft” versus “Approved” Status
- In the ADM, documents which are under development and have not undergone any formal review and approval process are designated “draft”.
- In the ADM, documents which have been reviewed and approved are designated “approved” in accordance with the organization’s governance practices. Approved does not necessarily mean finalized.
Iteration and the ADM
The ADM is iterative, over the whole process, between phases, and within phases.
- For each iteration of the ADM, a fresh decision must be taken as to:
- The breadth of coverage of the enterprise to be defined
- The level of detail to be defined
- The extent of the time period aimed at, including the number and extent of any intermediate time periods
- The architectural assets to be leveraged
Essential Information Flows
- Information flows also result in iteration.
- Every time the Enterprise Architecture team is undertaking any activity within the scope of the ADM it is executing a phase and developing the contents of the Enterprise Architecture Landscape.
- The inter-dependent nature of developing a Target Architecture requires considering the entire architecture, resulting gaps, and resulting work to clear the gap simultaneously.
Iteration via Information Flow
Applying Iteration to the ADM
The ADM cycle is iterative. It is possible to cycle through phases or groups of phases several times looping back as needed.
Governing the ADM
- The ADM is a key process to be managed in the same manner as other architecture artifacts.
- The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration.
- Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.
Governing the Architecture
- The practitioner is directed to develop an architecture within a controlled scope.
- Within that controlled scope, the practitioner is directed to the stakeholder’s preferences.
- The governance test will ask whether the practitioner is addressing the stakeholder’s concerns.
Governing Change
- Every Architecture Requirements Specification enables control of the implementation team.
- Design, implementation, and other change choices can be tested against the Architecture Requirements Specification.
- The implementation team is directed to create changes with intentional value-based outcomes.
- Best practice governance enables the organization to control value realization.
Why Constrain the Scope of Architectural Activity?
There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:
- The organizational authority of the team producing the architecture
- The objectives and stakeholder concerns to be addressed within the architecture
- The availability of people, finance, and other resources
Scoping Dimensions
Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed.
Dimensions: Breadth & Depth
Breadth: what is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?
Depth: to what level of detail should the architecting effort go?
Dimensions: Time Period and Architecture Domains
Time Period: what is the time period that needs to be articulated for the Architecture Vision, and does it make sense for the same period to be covered in the detailed Architecture Description?
Architecture Domains: a complete Enterprise Architecture Description should contain all four architecture domains (Business, Data, Application, Technology).
Why Consider Architecture Alternatives?
- There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements.
- By identifying and considering alternative Target Architectures an understanding can be built of the different possibilities and trade-offs identified between the alternatives.
- Presenting different alternatives and trade-offs to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final Target Architecture.
Architecture Alternatives Method
Preliminary Phase: Purpose
- The purpose of the Preliminary Phase is to develop the Enterprise Architecture Capability.
- It is designed as a customized journey of the TOGAF ADM.
The Objectives of the Preliminary Phase
- Determine the Architecture Capability desired by the organization
- Establish the Architecture Capability
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 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
Phase A: Purpose
To identify key stakeholders, and reach agreement in the Architecture Vision document on a summary of the target and the work to reach the target
Phase A: The Starting Point
The set-up essentials are:
- Define the scope of the Architecture Project
- Identify stakeholders, concerns, and associated requirements
- Assess the capability of the Enterprise Architecture team
The completion essentials are:
- Key stakeholder agreement on a summary of the target and the work to reach the target
Essential ADM Output and Knowledge
The Objectives of Phase A
- Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture.
- Obtain and ve foy a earmiet chiet in the Archite ere is program of works to develop and deploy the architecture outlined in the Architecture Vision.
Essential ADM Output and Knowledge
The Objectives of Phase B
- 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 Statement of Architecture Work and stakeholder concerns.
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures.
The Objectives of Phase C
- Develop the Target Information Systems Architectures, describing how the enterprise’s Information Systems Architectures will enable the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns.
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures.
The Objectives of Phase C - Data Architecture
- Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns.
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Data Architectures.
The Objectives of Phase C - Application Architecture
- Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns.
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures.
The Objectives of Phase D
- Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns.
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures.
Essential ADM Output and Knowledge
The Objectives of Phase 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.
- Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
- Define the overall Solution Building Blocks (SBBs) to finalize the Target Architecture based on the ABBs.
Essential ADM Output and Knowledge
The Objectives of Phase F
- Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan.
- Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio.
- Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders.
Essential ADM Output and Knowledge
The Objectives of Phase G
- Ensure conformance with the Target Architecture by Implementation Projects.
- Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests.
Essential ADM Output and Knowledge
The Objectives of Phase H
- Ensure that the architecture development cycle is maintained.
- Ensure that the Architecture Governance framework is executed.
- Ensure that the Enterprise Architecture Capability meets current requirements.
The Objectives of the Requirements Management Process
- Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases.
- Manage Architecture Requirements identified during any execution of the ADM cycle or a phase.
- Ensure that relevant Architecture Requirements are available for use by each phase as the phase is executed.
Requirements Management - the Center of Architecture Development
- The TOGAF framework places requirements management and stakeholder engagement at the center of architecture development.
- Stakeholders own the architecture and the value preference and priority the architecture is expected to enable.
- Effective requirements management is dependent upon clear traceability from the organization’s vision, mission, business model, and strategies through the most detailed statement of requirement.
Information Flow and the TOGAF® ADM
- The TOGAF ADM is a logical method that places key activity steps together for the purpose of understanding relationship of activity and clarifying information flow.
- The graphic is a stylized path that demonstrates essential information flow.
How Developing Architecture can be Applied to Support Agile Software Development
The TOGAF® Standard Aligns to Agile Software Development in Phase G
- Architecture can be used to identify what products the enterprise needs, the boundary of the products, and what constraints a product owner has.
- Architecture can also be used to set of constraints that limit the choices of the Agile team.
- In Phase G (Implementation Governance) the practitioner serves the stakeholders guarding the mission, vision, goals, and investment roadmap.
Keywords to remember ADM Phases
- Preliminary phase: Architecture capability, RfAW, Architecture Govenrnance board
- Phase A: Stakeholders, scope, SoAW (outcome of Architecture vision)
- Phase B: Business Architecture
- Phase C: Information (data, application)
- Phase D: Technology
- Phase E: work package, transition or implementation approach
- Phase F: finalizing approval, project, priorities, the project roadmap
- Phase G: Compliance review, direct and control, governance, architectural contracts, agile, change requests
- Phase H: change management (RfC), shortfalls
Definitions
Application Architecture
- A description of the structure and interaction of the applications that provide key business capabilities and manage the data assets
Architecture Landscape
- The architectural representation of assets in use, or planned, by the enterprise at particular points in time
Architecture Model
- A representation of a subject of interest
Artifact
- An architectural work product that describes an aspect of the architecture
Business Architecture
- A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, processes, initiatives, and stakeholders
Business Model
- A model describing the rationale for how an enterprise creates, delivers, and captures value.
Capability
- An ability that an organization, person, or system possesses.
Capability Architecture
- An architecture that describes the abilities that an enterprise possesses
Data Architecture
- A description of the structure of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources
Deliverable
- An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders
Gap
- A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified
Metamodel
- A model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between those entities.
Modeling
- A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.
Requirement
- A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.
Role
- The usual or expected behavior of an actor, or the part somebody or something plays in a particular process or event. An actor may have a number of roles.
- The part an individual plays in an organization and the contribution they make through the application of their skills, knowledge, experience, and abilities.
Segment Architecture
- A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.
Stakeholder
- An individual, team, organization, or class thereof, having an interest in a system.
Strategic Architecture
- A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.
Technology Architecture
- A description of the structure and interaction of the technology services and technology components.
Transition Architecture
- A formal description of one state of the architecture at an architecturally significant point in time.
Work Package
- A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.