TOGAFv10 Notes

“ISO/IEC/IEEE 42010:2011 defines “architecture” as:
“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”

The TOGAF Standard embraces but does not strictly adhere to ISO/IEC/IEEE 42010:2011 terminology. In addition to the ISO/IEC/IEEE 42010:2011 definition of “architecture”, the TOGAF Standard defines a second meaning depending upon the context:
“The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.””
https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=ISO/IEC/IEEE,evolution%20over%20time.%22

The Preliminary Phase describes 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 describes 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 describes the development of a Business Architecture to support the agreed Architecture Vision
  
• Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision
  
• Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision
  
• Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
  
• Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan
  
• Phase G: Implementation Governance provides an architectural oversight of the implementation
  
• Phase H: Architecture Change Management establishes procedures for managing change to the new architecture
  
• Requirements Management operates the process of managing architecture requirements throughout the ADM”
  https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Phases%20within%20the,throughout%20the%20ADM
  

Table 3-1: Service Categories and Descriptors

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Figure%203%2D2%3A-,Relationships%20between%20Deliverables%2C%20Artifacts%2C%20and%20Building%20Blocks,-For%20example%2C%20an

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Example%20%E2%80%94%20Architecture%20Definition%20Document

can be divided into four distinct abstraction levels that cross the Business, Data, Application, and Technology domains to answer fundamental questions about an architecture:

• Why — why is the architecture needed?
  
• What — what functionality and other requirements need to be met by the architecture?
  
• How — how do we structure the functionality?
  
• With what — with what assets shall we implement this structure?”
  https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Architecture%20effort%20can,implement%20this%20structure%3F
  

Many organizations find it useful to categorize interoperability as follows:

• Operational or Business Interoperability defines how different parts of the enterprise work together at the business level
  
• Information Interoperability defines how information is to be shared
  
• Technical Interoperability defines how technical resources are to be shared or at least connect to one another”
  https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Many%20organizations%20find,to%20one%20another
  

TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository.”
https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=TOGAF%20ADM%20can%20be%20regarded%20as%20describing%20a%20process%20lifecycle%20that%20operates%20at%20multiple%20levels%20within%20the%20organization%2C%20operating%20within%20a%20holistic%20governance%20framework%20and%20producing%20aligned%20outputs%20that%20reside%20in%20an%20Architecture%20Repository.

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=TOGAF%20Architecture%20Repository%20Structure

The major components within an Architecture Repository are as follows:

• The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content
  
• The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository
  
• The Architecture Landscape is the architectural representation of assets deployed within the operating enterprise at a particular point in time — the landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
  
• The Standards Library captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization
  
• The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise
  
• The Governance Repository provides a record of governance activity across the enterprise
  
• The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
  
• The Solutions Landscape presents an architectural representation of the SBBs supporting the Architecture Landscape which have been planned or deployed by the enterprise”
  https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=The%20major%20components,by%20the%20enterprise
  

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Content%20Framework%20by%20ADM%20Phase

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=Applying%20the%20Enterprise%20Continuum

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=The%20TOGAF%20Core%20Enterprise%20Metamodel

https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=TOGAF%20Architecture%20Capability%20Overview

“The role of architecture views is shown in Figure 3-10 , adapted from more formal definitions contained in ISO/IEC/IEEE 42010:2011 and ISO/IEC/IEEE 15288:2015.”
https://pubs.opengroup.org/togaf-standard/introduction/chap03.html#:~:text=The%20role%20of%20architecture%20views%20is%20shown%20in%20Figure%203%2D10%20%2C%20adapted%20from%20more%20formal%20definitions%20contained%20in%20ISO/IEC/IEEE%2042010%3A2011%20and%20ISO/IEC/IEEE%2015288%3A2015.

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (Source: ISO/IEC/IEEE 42010:2011)
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

https://pubs.opengroup.org/togaf-standard/introduction/chap04.html#:~:text=primary%20architecture%20domains%3A%20business%2C%20data%2C%20application%2C%20and%20technology

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.

An architecture that describes the abilities that an enterprise possesses.

The discipline of monitoring and guiding the management of a business (or IS/IT landscape) to deliver the business outcomes required.

Implementation-independent.
Note:
A logical architecture is an implementation-independent definition of the architecture.

https://pubs.opengroup.org/togaf-standard/introduction/chap04.html#:~:text=A%20logical%20architecture%20is%20realized%20through%20a%20physical%20architecture

https://pubs.opengroup.org/togaf-standard/adm/chap01.html#:~:text=Figure%201%2D1%3A-,Architecture%20Development%20Cycle,-The%20phases%20of

Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time.
https://pubs.opengroup.org/togaf-standard/adm/chap01.html#:~:text=Typically%2C%20the%20scope%20of%20an%20architecture%20is%20first%20expressed%20in%20terms%20of%20breadth%2C%20depth%2C%20and%20time.

https://pubs.opengroup.org/togaf-standard/adm/chap01.html#:~:text=Architecture%20Alternatives%20Method

https://pubs.opengroup.org/togaf-standard/adm/chap01.html#:~:text=Integration%20of%20Architecture

The objectives of the Preliminary Phase are to:

• Determine the Architecture Capability desired by the organization
  

• Establish the Architecture Capability
  

  https://pubs.opengroup.org/togaf-standard/adm/chap02.html#:~:text=Establish%20the%20Architecture%20Capability
  

• Reference Materials External to the Enterprise
  
  • The TOGAF Library
    
  • Other architecture framework(s), if required
    
• Non-Architectural Inputs
  
  • Board strategies and board business plans, business strategy, IT strategy, business principles, business goals, and business drivers, when pre-existing
    
  • Major frameworks operating in the business; e.g., project/portfolio management
    
  • Governance and legal frameworks, including Architecture Governance strategy, when pre-existing
    
  • Architecture capability
    
  • Partnership and contract agreements
    
• Architectural Inputs
  Pre-existing models for operating an Enterprise Architecture Capability can be used as a baseline for the Preliminary Phase. Inputs would include:
  
  • Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
    
    • Scope of organizations impacted
      
    • Maturity assessment, gaps, and resolution approach
      
    • Roles and responsibilities for architecture team(s)
      
    • Budget requirements
      
    • Governance and support strategy
      
  • Existing Architecture Framework, if any, including:
    
    • Architecture method
      
    • Architecture content
      
    • Configured and deployed tools
      
    • Architecture Principles
      
    • Architecture Repository
      

https://pubs.opengroup.org/togaf-standard/adm/chap02.html#:~:text=2.3-,Steps,-The%20TOGAF%20ADM

“The steps within the Preliminary Phase are as follows:

• Scope the enterprise organizations impacted (see 2.3.1 Scope the Enterprise Organizations Impacted )
  
  • Identify core enterprise (units) — those who are most affected and achieve most value from the work
    
  • Identify soft enterprise (units) — those who will see change to their capability and work with core units but are otherwise not directly affected
    
  • Identify extended enterprise (units) — those units outside the scoped enterprise who will be affected in their own Enterprise Architecture
    
  • Identify communities involved (enterprises) — those stakeholders who will be affected and who are in groups of communities
    
  • Identify governance involved, including legal frameworks and geographies (enterprises)
    
• Confirm governance and support frameworks (see 2.3.2 Confirm Governance and Support Frameworks )
  
• Define and establish Enterprise Architecture team and organization (see 2.3.3 Define and Establish Enterprise Architecture Team and Organization)
  
  • Determine existing enterprise and business capability
    
  • Conduct an Enterprise Architecture/business change maturity assessment, if required
    
  • Identify gaps in existing work areas
    
  • Allocate key roles and responsibilities for Enterprise Architecture Capability management and governance
    
  • Define requests for change to existing business programs and projects:
    
    • Inform existing Enterprise Architecture and IT architecture work of stakeholder requirements
      
    • Request assessment of impact on their plans and work
      
    • Identify common areas of interest
      
    • Identify any critical differences and conflicts of interest
      
    • Produce requests for change to stakeholder activities
      
  • Determine constraints on Enterprise Architecture work
    
  • Review and agree with sponsors and board
    
  • Assess budget requirements
    
• Identify and establish Architecture Principles (see 2.3.4 Identify and Establish Architecture Principles)
  
• Tailor the TOGAF framework and, if any, other selected architecture frameworks (see 2.3.5 Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s))
  
• Develop a strategy and implementation plan for tools and techniques (see 2.3.6 Develop a Strategy and Implementation Plan for Tools and Techniques)”
  https://pubs.opengroup.org/togaf-standard/adm/chap02.html#:~:text=The%20steps%20within,and%20Techniques)
  

The outputs of the Preliminary Phase may include, but are not restricted to:

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Architecture Principles (see the TOGAF Standard — Architecture Content)
    
  • Configured and deployed tools
    
• Initial Architecture Repository (see the TOGAF Standard — Architecture Content), populated with framework content
  
• Restatement of, or reference to, business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
  
• Request for Architecture Work (optional) (see the TOGAF Standard — Architecture Content)
  
• Architecture Governance Framework (see the TOGAF Standard — EA Capability and Governance)
  
• The Architecture of the Enterprise Architecture Capability (see the TOGAF Standard — EA Capability and Governance)
  

This Preliminary Phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned. The main aspects are as follows:

• Defining the enterprise
  
• Identifying key drivers and elements in the organizational context
  
• Defining the requirements for architecture work
  
• Defining the Architecture Principles that will inform any architecture work
  
• Defining the framework to be used
  
• Defining the relationships between management frameworks
  
• Evaluating the Enterprise Architecture maturity
  

https://pubs.opengroup.org/togaf-standard/adm/chap02.html#:~:text=Management%20Frameworks%20to%20Co%2Dordinate%20with%20the%20TOGAF%20Framework

Management Frameworks to Co-ordinate with the TOGAF Framework

Interoperability and Relationships between Management Frameworks:

The objectives of Phase A are to:

• Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture
  
• Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Re-use requirements
    
  • Budget requirements
    
  • Requests for change
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Architecture Principles (see the TOGAF Standard — Architecture Content), including business principles, when pre-existing
    
  • Configured and deployed tools
    
• Populated Architecture Repository (see the TOGAF Standard — Architecture Content) — existing architectural documentation (framework description, architectural descriptions, baseline descriptions, Architecture Building Blocks (ABBs), etc.)”
  https://pubs.opengroup.org/togaf-standard/adm/chap03.html#:~:text=Non%2DArchitectural%20Inputs,Blocks%20(ABBs)%2C%20etc.)
  

The steps in Phase A are as follows:

• Establish the architecture project (see 3.3.1 Establish the Architecture Project)
  
• Identify stakeholders, concerns, and business requirements (see 3.3.2 Identify Stakeholders, Concerns, and Business Requirements)
  
• Confirm and elaborate business goals, business drivers, and constraints (see 3.3.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints)
  
• Evaluate capabilities (see 3.3.4 Evaluate Capabilities)
  
• Assess readiness for business transformation (see 3.3.5 Assess Readiness for Business Transformation)
  
• Define scope (see 3.3.6 Define Scope)
  
• Confirm and elaborate Architecture Principles, including business principles (see 3.3.7 Confirm and Elaborate Architecture Principles, including Business Principles)
  
• Develop Architecture Vision (see 3.3.8 Develop Architecture Vision)
  
• Define the Target Architecture value propositions and KPIs (see 3.3.9 Define the Target Architecture Value Propositions and KPIs)
  
• Identify the business transformation risks and mitigation activities (see 3.3.10 Identify the Business Transformation Risks and Mitigation Activities)
  
• Develop Statement of Architecture Work; secure approval (see 3.3.11 Develop Statement of Architecture Work; Secure Approval)”
  https://pubs.opengroup.org/togaf-standard/adm/chap03.html#:~:text=The%20steps%20in%20Phase%20A%20are,of%20Architecture%20Work%3B%20Secure%20Approval)
  

The outputs of Phase A may include, but are not restricted to:

• Approved Statement of Architecture Work (see the TOGAF Standard — Architecture Content), including in particular:
  
  • Architecture project description and scope
    
  • Overview of Architecture Vision
    
  • Architecture project plan and schedule
    
• Refined statements of business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
  
• Architecture Principles (see the TOGAF Standard — ADM Techniques)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content) (for the engagement), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Architecture Vision (see the TOGAF Standard — Architecture Content), including:
  
  • Problem description
    
  • Objective of the Statement of Architecture Work
    
  • Summary views
    
  • Business scenario (optional)
    
  • Refined key high-level stakeholder requirements
    
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
  
• Communications Plan (see the TOGAF Standard — Architecture Content)
  
• Additional content populating the Architecture Repository (see the TOGAF Standard — Architecture Content)
  

https://pubs.opengroup.org/togaf-standard/adm/chap03.html#:~:text=3.5.2-,Creating%20the%20Architecture%20Vision,-The%20Architecture%20Vision
This exercise should examine and search for existing materials on fundamental Business Architecture concepts such as:

• Business Capabilities, which represent a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome
  In this phase, the architect should determine whether a framework exists in the organization to represent business capabilities. If one does not exist, the architect should consider whether developing a framework is within the scope of the project. For an introduction to business capabilities, see TOGAF® Series Guide: Business Capabilities.
  
• Value Streams, which represent an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user
  For an introduction to value streams, see the TOGAF® Series Guide: Value Streams.
  
• Organization Maps, which depict the relationships between the primary entities that make up the enterprise, its partners, and stakeholders
  As traditional organizational charts often lack the necessary detail to reflect the full scope of the enterprise’s activities, the architect can help to identify and understand the complex web of relationships between business entities as well as where business capabilities are used and connection to value stream stages. These are refined and extended in subsequent phases. For an introduction to organization maps, see the TOGAF® Series Guide: Organization Mapping.
  

In addition, the Architecture Vision explores other domains which are appropriate for the Enterprise Architecture in hand. These domains may include elements of the basic domains, yet serve an additional purpose for the stakeholders. Example domains may include:

• Information
  
• Security
  
• Digital
  
• Network Management
  
• Knowledge
  
• Industry-specific
  
• Services
  
• Partnership
  
• Cybersecurity
  https://pubs.opengroup.org/togaf-standard/adm/chap03.html#:~:text=This%20exercise%20should,Cybersecurity
  

The objectives of Phase B are to:

• 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
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  
• Communications Plan (see the TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Approved Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Principles (see the TOGAF Standard — Architecture Content), including business principles, when pre-existing
  
• Enterprise Continuum (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Architecture Vision (see the TOGAF Standard — Architecture Content), including:
  
  • Problem description
    
  • Objective of the Statement of Architecture Work
    
  • Summary views
    
  • Business Scenario (optional)
    
  • Refined key high-level stakeholder requirements
    
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain”
  https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=Non%2DArchitectural%20Inputs,any%20architecture%20domain
  

The steps in Phase B are as follows:

• Select reference models, viewpoints, and tools (see 4.3.1 Select Reference Models, Viewpoints, and Tools)
  
• Develop Baseline Business Architecture Description (see 4.3.2 Develop Baseline Business Architecture Description)
  
• Develop Target Business Architecture Description (see 4.3.3 Develop Target Business Architecture Description)
  
• Perform gap analysis (see 4.3.4 Perform Gap Analysis)
  
• Define candidate roadmap components (see 4.3.5 Define Candidate Roadmap Components)
  
• Resolve impacts across the Architecture Landscape (see 4.3.6 Resolve Impacts Across the Architecture Landscape)
  
• Conduct formal stakeholder review (see 4.3.7 Conduct Formal Stakeholder Review)
  
• Finalize the Business Architecture (see 4.3.8 Finalize the Business Architecture)
  
• Create/Update the Architecture Definition Document (see 4.3.9 Create/Update the Architecture Definition Document)”
  https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=The%20steps%20in%20Phase%20B%20are,Update%20the%20Architecture%20Definition%20Document)
  

Techniques described in 4.5 Approach can be utilized to progressively decompose a business:

• Business Capability Mapping: identifies, categorizes, and decomposes the business capabilities required for the business to have the ability to deliver value to one or more stakeholders
  
• Information Mapping: collecting the information concepts and their relationships that matter most to the business
  
• Organization Mapping: a representation of the organizational structure of the business (including third-party domains), depicting business units, the decomposition of those units into lower-level functions, and organizational relationships (unit-to-unit and mapping to business capabilities, locations, and other attributes)
  
• Process Modeling: the activity of articulating business processes of an enterprise, to enable analysis and improvement
  
• Structured Analysis: identifies the key business capabilities within the scope of the architecture, and maps those capabilities onto business functions and organizational units within the business
  
• Use-case Analysis: a technique used to identify the requirements of a system or task to be completed, from a user’s perspective
  
• Value Stream Mapping: the end-to-end breakdown of activities that an organization performs to create the value being exchanged with stakeholders
  Value stream maps illustrate how an organization delivers value and are in the context of a specific set of stakeholders, and leverage business capabilities in order to create stakeholder value and align to other aspects of the Target Business Architecture.”
  https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=techniques%20described%20in,Target%20Business%20Architecture.
  

The outputs of Phase B may include, but are not restricted to:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  
  • Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
    
  • Validated business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content), updated if necessary
    
  • Architecture Principles (see the TOGAF Standard — Architecture Content)
    
• Draft Architecture Definition Document (see the TOGAF Standard — Architecture Content), including:
  
  • Baseline Business Architecture, Approved, if appropriate
    
  • Target Business Architecture, Approved, including:
    
    • Organization structure — identifying business locations and relating them to organizational units
      
    • Business goals and objectives — for the enterprise and each organizational unit
      
    • Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
      
    • Business capabilities — the abilities that a business needs to possess or exchange to achieve its goals and objectives
      
    • Business services — the services that support the business by encapsulating a unique “elements of business behavior”; a service offered external to the enterprise may be supported by business services
      
    • Products — output generated by the business to be offered to customers; products include materials and/or services
      
    • Business processes, including measures and deliverables
      
    • Business roles, including development and modification of skills requirements
      
    • Business data model
      
    • Correlation of organization/business functions and business capabilities — relate business capabilities to organizational units in the form of a matrix report
      
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
    
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including such Business Architecture requirements as:
  
  • Gap analysis results
    
  • Technical requirements — identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (e.g., guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)
    
  • Updated business requirements
    
• Business Architecture components of an Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  

https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=4.5.7-,Applying%20Modeling%20Techniques,-The%20modeling%20and

In addition to the techniques described above (capability maps, value streams, and organization maps), a variety of other modeling techniques may be employed, if deemed appropriate. For example:

• Activity Models (also called Business Process Models) describe the enterprise’s business activities, the data and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other activities that are outside the scope of the model (external exchanges)
  Activity models are hierarchical in nature. They capture the activities performed in a business process, and the Inputs, Controls, Outputs, and Mechanisms/Resources (ICOMs) of those activities. Activity models can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs. One technique for creating activity models is the Integrated Computer Aided Manufacturing (ICAM) DEFinition (IDEF) modeling technique.
  

  The Object Management Group (OMG) has developed the Business Process Modeling NotationTM (BPMNTM), a standard for business process modeling that includes a language with which to specify business processes, their tasks/steps, and the documents produced.
  

• Use-Case Models describe the business process of an enterprise in terms of use-cases and actors corresponding to business processes and organizational participants (people, organizations, etc.)
  The use-case model is described in use-case diagrams and use-case specifications.
  
• Logical Data Model (or Class Model)
  Logical data models describe the entities, their attributes, and the acceptable values for these attributes as well as the relationships between the various entities. Particularly useful is the “is-a” relationship for analyses. For example, if a sedan is a type of car which is a type of vehicle, then a general business rule for all vehicles can be written once and automatically picked up for all types of cars and trucks.”
  https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=In%20addition%20to,cars%20and%20trucks.
  

As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository (see the TOGAF Standard — Architecture Content), in particular:

• Industry reference models relevant to the organization’s industry sector
  
• Enterprise-specific Business Architecture views (capability maps, value stream maps, organization maps, etc.)
  
• Enterprise-specific building blocks (process components, business rules, job descriptions, etc.)
  
• Applicable standards”
  https://pubs.opengroup.org/togaf-standard/adm/chap04.html#:~:text=4.5.8-,Architecture%20Repository,Applicable%20standards,-return%20to%20top
  

The objectives of Phase C are to:

• Develop the Target Information Systems Architectures, describing how the enterprise’s Information Systems Architecture 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
  

https://pubs.opengroup.org/togaf-standard/adm/chap06.html#:~:text=Phase%20C%3A%20Information%20Systems%20Architectures%20%E2%80%94%20Data%20Architecture

https://pubs.opengroup.org/togaf-standard/adm/chap07.html#:~:text=Phase%20C%3A%20Information%20Systems%20Architectures%20%E2%80%94%20Application%20Architecture

The objectives of Phase D are to:

• 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
  

Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)
  
• Product information on candidate products
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  
• Communications Plan (see the TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Technology principles (see the TOGAF Standard — ADM Techniques), if existing
  
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
  
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Gap analysis results (from Business, Data, and Application Architectures)
    
  • Relevant technical requirements from previous phases
    
• Business, Data, and Application Architecture components of an Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  

The steps in Phase D are as follows:

• Select reference models, viewpoints, and tools (see 8.3.1 Select Reference Models, Viewpoints, and Tools)
  
• Develop Baseline Technology Architecture Description (see 8.3.2 Develop Baseline Technology Architecture Description)
  
• Develop Target Technology Architecture Description (see 8.3.3 Develop Target Technology Architecture Description)
  
• Perform gap analysis (see 8.3.4 Perform Gap Analysis)
  
• Define candidate roadmap components (see 8.3.5 Define Candidate Roadmap Components)
  
• Resolve impacts across the Architecture Landscape (see 8.3.6 Resolve Impacts Across the Architecture Landscape)
  
• Conduct formal stakeholder review (see 8.3.7 Conduct Formal Stakeholder Review)
  
• Finalize the Technology Architecture (see 8.3.8 Finalize the Technology Architecture)
  
• Create/Update the Architecture Definition Document (see 8.3.9 Create/Update the Architecture Definition Document)”
  https://pubs.opengroup.org/togaf-standard/adm/chap08.html#:~:text=The%20steps%20in%20Phase%20D%20are,Update%20the%20Architecture%20Definition%20Document)
  

• Define a taxonomy of technology services and logical technology components (including standards)
  
• Identify relevant locations where technology is deployed
  
• Carry out a physical inventory of deployed technology and abstract up to fit into the taxonomy
  
• Look at application and business requirements for technology
  
• Is the technology in place fit-for-purpose to meet new requirements (i.e., does it meet functional and non-functional requirements)?
  
  • Refine the taxonomy
    
  • Product selection (including dependent products)
    
• Determine configuration of the selected technology
  
• Determine impact:
  
  • Sizing and costing
    
  • Capacity planning
    
  • Installation/governance/migration impacts
    

In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the technology service. The areas where the Technology Architecture may be impacted will include the following:

• Performance: the granularity of the service will impact on technology service requirements
  Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
  
• Maintainability: if service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered
  
• Location and Latency: services might interact with each other over remote links and inter-service communication will have in-built latency
  Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
  
• Availability: service invocation is subject to network and/or service failure
  High communication availability is an important consideration during service decomposition and defining service granularity.”
  https://pubs.opengroup.org/togaf-standard/adm/chap08.html#:~:text=The%20process%20to,defining%20service%20granularity.
  

• Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
  
• Fully document each building block
  
• Conduct a final cross-check of overall architecture against business goals; document the rationale for building block decisions in the architecture document
  
• Document the final requirements traceability report
  
• Document the final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
  
• Finalize all the work products, such as gap analysis
  

Prepare the technology sections of the Architecture Definition Document, comprising some or all of:

• Fundamental functionality and attributes — semantic, unambiguous including security capability and manageability
  
• Dependent building blocks with required functionality and named interfaces
  
• Interfaces — chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
  
• Map to business/organizational entities and policies”
  https://pubs.opengroup.org/togaf-standard/adm/chap08.html#:~:text=Prepare%20the%20technology,entities%20and%20policies
  

The outputs of Phase D may include, but are not restricted to:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  
  • Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
    
  • Validated technology principles, or new technology principles (if generated here)
    
• Draft Architecture Definition Document (see the TOGAF Standard — Architecture Content), including:
  
  • Baseline Technology Architecture, Approved, if appropriate
    
  • Target Technology Architecture, Approved, including:
    
    • Technology Components and their relationships to information systems
      
    • Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology “stack”
      
    • Environments and locations — a grouping of the required technology into computing environments (e.g., development, production)
      
    • Expected processing load and distribution of load across technology components
      
    • Physical (network) communications
      
    • Hardware and network specifications
      
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
    
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including such Technology Architecture requirements as:
  
  • Gap analysis results
    
  • Requirements output from Phases B and C
    
  • Updated technology requirements
    
• Technology Architecture components of an Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  

The objectives of Phase E are to:

• 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
  

Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)
  
• Product information
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  
• Communications Plan (see the TOGAF Standard — Architecture Content)
  
• Planning methodologies
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Governance models and frameworks for:
  
  • Corporate Business Planning
    
  • Enterprise Architecture
    
  • Portfolio, Program, Project Management
    
  • System Development/Engineering
    
  • Operations (Service)
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
  
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Architectural requirements
    
  • Gap analysis results (from Business, Data, Application, and Technology Architecture)
    
  • IT Service Management requirements
    
• Change Requests for existing business programs and projects (see the TOGAF Standard — Architecture Content)
  
• Candidate Architecture Roadmap components from Phases B, C, and D
  

The steps in Phase E are as follows:

• Determine/confirm key corporate change attributes (see 9.3.1 Determine/Confirm Key Corporate Change Attributes)
  
• Determine business constraints for implementation (see 9.3.2 Determine Business Constraints for Implementation)
  
• Review and consolidate gap analysis results from Phases B to D (see 9.3.3 Review and Consolidate Gap Analysis Results from Phases B to D)
  
• Review consolidated requirements across related business functions (see 9.3.4 Review Consolidated Requirements Across Related Business Functions)
  
• Consolidate and reconcile interoperability requirements (see 9.3.5 Consolidate and Reconcile Interoperability Requirements)
  
• Refine and validate dependencies (see 9.3.6 Refine and Validate Dependencies)
  
• Confirm readiness and risk for business transformation (see 9.3.7 Confirm Readiness and Risk for Business Transformation)
  
• Formulate Implementation and Migration Strategy (see 9.3.8 Formulate Implementation and Migration Strategy)
  
• Identify and group major work packages (see 9.3.9 Identify and Group Major Work Packages)
  
• Identify Transition Architectures (see 9.3.10 Identify Transition Architectures)
  
• Create the Architecture Roadmap & Implementation and Migration Plan (see 9.3.11 Create the Architecture Roadmap & Implementation and Migration Plan)”
  https://pubs.opengroup.org/togaf-standard/adm/chap09.html#:~:text=The%20steps%20in%20Phase%20E%20are,Roadmap%20%26%20Implementation%20and%20Migration%20Plan)
  

• Refined and updated version of the Architecture Vision phase deliverables, where applicable, including:
  
  • Architecture Vision, including definition of types and degrees of interoperability
    
  • Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
    
• Draft Architecture Definition Document (see the TOGAF Standard — Architecture Content), including:
  
  • Baseline Business Architecture, Approved, updated if necessary
    
  • Target Business Architecture, Approved, updated if necessary
    
  • Baseline Data Architecture, Approved, updated if necessary
    
  • Target Data Architecture, Approved, updated if necessary
    
  • Baseline Application Architecture, Approved, updated if necessary
    
  • Target Application Architecture, Approved, updated if necessary
    
  • Baseline Technology Architecture, Approved, updated if necessary
    
  • Target Technology Architecture, Approved, updated if necessary
    
  • Transition Architecture, number and scope as necessary
    
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
    
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Consolidated Gaps, Solutions, and Dependencies Assessment
    
• Capability Assessments, including:
  
  • Business Capability Assessment
    
  • IT Capability Assessment
    
• Architecture Roadmap (see the TOGAF Standard — Architecture Content), including:
  
  • Work package portfolio:
    
    • Work package description (name, description, objectives)
      
    • Functional requirements
      
    • Dependencies
      
    • Relationship to opportunity
      
    • Relationship to Architecture Definition Document and Architecture Requirements Specification
      
    • Relationship to any capability increments
      
    • Business value
      
    • Implementation Factor catalog
      
    • Impact
      
  • Identification of Transition Architectures, if any, including:
    
    • Relationship to Architecture Definition Document
      
  • Implementation recommendations:
    
    • Criteria measures of effectiveness
      
    • Risks and issues
      
    • Solution Building Blocks (SBBs)
      
• Implementation and Migration Plan, Draft, including:
  
  • Implementation and Migration Strategy
    

• 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
  

Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  
• Communications Plan (see TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Governance models and frameworks for:
  
  • Corporate Business Planning
    
  • Enterprise Architecture
    
  • Portfolio, Program, Project Management
    
  • System Development/Engineering
    
  • Operations (Service)
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain, and/or Transition Architectures
  
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Architectural requirements
    
  • Gap analysis results (from Business, Data, Application, and Technology Architecture)
    
  • IT Service Management requirements
    
• Change Requests for existing business programs and projects (see the TOGAF Standard — Architecture Content)
  
• Architecture Roadmap, Draft (see the TOGAF Standard — Architecture Content), including:
  
  • Identification of work packages
    
  • Identification of Transition Architectures
    
  • Implementation Factor catalog
    
• Capability Assessment (see the TOGAF Standard — Architecture Content), including:
  
  • Business Capability Assessment
    
  • IT Capability Assessment
    
• Implementation and Migration Plan, Draft (see the TOGAF Standard — Architecture Content), including the high-level Implementation and Migration Strategy
  

• Confirm management framework interactions for Implementation and Migration Plan (see 10.3.1 Confirm Management Framework Interactions for the Implementation and Migration Plan)
  
• Assign a business value to each work package (see 10.3.2 Assign a Business Value to Each Work Package)
  
• Estimate resource requirements, project timings, and availability/delivery vehicle (see 10.3.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle)
  
• Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation (see 10.3.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation )
  
• Confirm Architecture Roadmap and update Architecture Definition Document (see 10.3.5 Confirm Architecture Roadmap and Update Architecture Definition Document)
  
• Complete the Implementation and Migration Plan (see 10.3.6 Complete the Implementation and Migration Plan)
  
• Complete the architecture development cycle and document lessons learned (see 10.3.7 Complete the Architecture Development Cycle and Document Lessons Learned)”
  https://pubs.opengroup.org/togaf-standard/adm/chap10.html#:~:text=The%20steps%20in%20Phase%20F%20are,Cycle%20and%20Document%20Lessons%20Learned)
  

This step is about co-ordinating the Implementation and Migration Plan with the management frameworks within the organization. There are typically four management frameworks that have to work closely together for the Implementation and Migration Plan to succeed:

• Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes
  
• Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain
  
• Project/Portfolio Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes
  
• Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes
  

Establish and assign a business value to each of the work packages. The intent is to first establish what constitutes business value within the organization, how value can be measured, and then apply this to each one of the projects and project increments.

There are several issues to address in this activity:

• Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation
  
• Return-on-Investment Criteria have to be detailed and signed off by the various executive stakeholders
  
• Business Value has to be defined as well as techniques, such as the value chain, which are to be used to illustrate the role in achieving tangible business outcomes
  
• Business value will be used by portfolio and capability managers to allocate resources and, in cases where there are cutbacks, business value in conjunction with return on investment can be used to determine whether an endeavor proceeds, is delayed, or is canceled.
  
• Critical Success Factors (CSFs) should be established to define success for a project and/or project increment
  These will provide managers and implementers with a gauge as to what constitutes a successful implementation.
  
• Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs
  Where they are treated discretely, it should be clear as to how these criteria are to be grouped.
  
• Strategic Fit based upon the overall Enterprise Architecture (all tiers) will be the critical factor for allowing the approval of any new project or initiative and for determining the value of any deliverable
  

• Implementation and Migration Plan, Approved (see the TOGAF Standard — Architecture Content), including:
  
  • Implementation and Migration Strategy
    
  • Project and portfolio breakdown of the implementation:
    
    • Allocation of work packages to project and portfolio
      
    • Capabilities delivered by projects
      
    • Relationship to Target Architecture and any Transition Architectures
      
    • Milestones and timing
      
    • Work breakdown structure
      
  • Project charters (optional):
    
    • Related work packages
      
    • Business value
      
    • Risk, issues, assumptions, dependencies
      
    • Resource requirements and costs
      
    • Benefits of migration
      
    • Estimated costs of migration options
      
• Finalized Architecture Definition Document (see the TOGAF Standard — Architecture Content), including:
  
  • Finalized Transition Architectures, if any
    
• Finalized Architecture Requirements Specification (see the TOGAF Standard — Architecture Content)
  
• Finalized Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  
• Re-Usable ABBs (see the TOGAF Standard — Architecture Content)
  
• Requests for Architecture Work (see the TOGAF Standard — Architecture Content) for a new iteration of the ADM cycle (if any)
  
• Implementation Governance Model (if any) (see the TOGAF Standard — Architecture Content)
  
• Change Requests for the Architecture Capability arising from lessons learned
  

• Ensure conformance with the Target Architecture by implementation projects
  
• Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
  

Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Capability Assessment (see the TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Architecture Definition Document (see the TOGAF Standard — Architecture Content)
  
• Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Architectural requirements
    
  • Gap analysis results (from Business, Data, Application, and Technology Architectures)
    
• Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  
• Architecture Governance Framework (see the TOGAF Standard — EA Capability and Governance)
  
• Implementation Governance Model (see the TOGAF Standard — Architecture Content)
  
• Architecture Contract (standard) (see the TOGAF Standard — EA Capability and Governance)
  
• Request for Architecture Work (see the TOGAF Standard — Architecture Content) identified during Phases E and F
  
• Implementation and Migration Plan (see the TOGAF Standard — Architecture Content)
  

• Confirm scope and priorities for deployment with development management (see 11.3.1 Confirm Scope and Priorities for Deployment with Development Management)
  
• Identify deployment resources and skills (see 11.3.2 Identify Deployment Resources and Skills )
  
• Guide development of solutions deployment (see 11.3.3 Guide Development of Solutions Deployment )
  
• Perform Enterprise Architecture Compliance reviews (see 11.3.4 Perform Enterprise Architecture Compliance Reviews)
  
• Implement business and IT operations (see 11.3.5 Implement Business and IT Operations)
  
• Perform post-implementation review and close the implementation (see 11.3.6 Perform Post-Implementation Review and Close the Implementation)”
  https://pubs.opengroup.org/togaf-standard/adm/chap11.html#:~:text=The%20steps%20in%20Phase%20G%20are,Review%20and%20Close%20the%20Implementation)
  

• Review migration planning outputs and produce recommendations on deployment
  
• Identify Enterprise Architecture priorities for development teams
  
• Identify deployment issues and make recommendations
  
• Identify building blocks for replacement, update, etc.
  
• Perform gap analysis on Enterprise Architecture and solutions framework
  The gaps in the existing enterprise solutions framework need to be identified and the specific SBBs required to fill these gaps will be identified by the Solution Architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The Solution Architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the Solution Architects need to ensure that they can leverage best value from these investments.
  
• Produce a gap analysis report
  

The project resources will include the development resources which will need to be educated in the overall Enterprise Architecture deliverables and expectations from the specific development and implementation projects.

The following considerations should be addressed in this step:

• Identify system development methods required for solutions development
  Note:
  There are a range of systems development methods and tools available to the project teams. The method should ideally be able to interoperate with the architecture outputs; for example, generate code from architecture artifacts delivered to date. This could be achieved through the use of modeling languages used for the Enterprise Architecture development that may be captured as inputs to the systems development tools and thereby reduce the cost of solutions development.
  
• Ensure that the systems development method enables feedback to the architecture team on designs
  

• Formulate project recommendation
  For each separate implementation and deployment project, do the following:
  
  • Document scope of individual project in impact analysis
    
  • Document strategic requirements (from the architectural perspective) in impact analysis
    
  • Document Change Requests (such as support for a standard interface) in impact analysis
    
  • Document rules for conformance in impact analysis
    
  • Document timeline requirements from roadmap in impact analysis
    
• Document Architecture Contract
  
  • Obtain signature from all developing organizations and sponsoring organization
    
• Update Enterprise Continuum directory and repository for solutions
  
• Guide development of business & IT operating models for services
  
• Provide service requirements derived from Enterprise Architecture
  
• Guide definition of business & IT operational requirements
  
• Carry out gap analysis between the Solution Architecture and operations
  
• Produce Implementation Plan
  

• Review ongoing implementation governance and Architecture Compliance for each building block
  
• Conduct post-development reviews
  
• Close development part of deployment projects
  

• Carry out the deployment projects including: IT services delivery implementation; business services delivery implementation; skills development & training implementation; communications documentation publication
  
• Publish new Baseline Architectures to the Architecture Repository and update other impacted repositories, such as operational configuration management stores
  

• Conduct post-implementation reviews
  
• Publish reviews and close projects
  

Closure on Phase G will be when the solutions are fully deployed once.

• Architecture Contract (signed) (see the TOGAF Standard — EA Capability and Governance), as recommended in the architecture-compliant implemented architectures
  
• Compliance Assessments (see the TOGAF Standard — Architecture Content)
  
• Change Requests (see the TOGAF Standard — Architecture Content)
  
• Architecture-compliant solutions deployed including:
  
  • The architecture-compliant implemented system
    Note:
    The implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the ADM. The direct involvement of architecture staff in implementation will vary according to organizational policy, as described in the TOGAF Standard — EA Capability and Governance.
    
  • 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
    
  • Architecture Building Blocks (ABBs)
    

• Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase
  
• Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
  
• Follow the organization’s standard for corporate, IT, and Architecture Governance
  
• Use the organization’s established portfolio/program management approach, where this exists
  
• Define an operations framework to ensure the effective long life of the deployed solution
  

Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.
Project details are developed, including:

• Name, description, and objectives
  
• Scope, deliverables, and constraints
  
• Measures of effectiveness
  
• Acceptance criteria
  
• Risks and issues”
  https://pubs.opengroup.org/togaf-standard/adm/chap11.html#:~:text=the%20overall%20approach,Risks%20and%20issues
  

• 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
  

Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)
  

Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
  

Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  
  • Re-usable building blocks
    
  • Publicly available reference models
    
  • Organization-specific reference models
    
  • Organization standards
    
• Architecture Definition Document (see the TOGAF Standard — Architecture Content)
  
• Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  
  • Gap analysis results (from Business, Data, Application, and Technology Architectures)
    
  • Architectural requirements
    
• Architecture Roadmap (see the TOGAF Standard — Architecture Content)
  
• Change Request (see the TOGAF Standard — Architecture Content) — technology changes:
  
  • New technology reports
    
  • Asset management cost reduction initiatives
    
  • Technology withdrawal reports
    
  • Standards initiatives
    
• Change Request (see the TOGAF Standard — Architecture Content) — business changes:
  
  • Business developments
    
  • Business exceptions
    
  • Business innovations
    
  • Business technology innovations
    
  • Strategic change developments
    
• Change Request (see the TOGAF Standard — Architecture Content) — from lessons learned
  
• Implementation Governance Model (see the TOGAF Standard — Architecture Content)
  
• Architecture Contract (signed) (see the TOGAF Standard — EA Capability and Governance)
  
• Compliance Assessments (see the TOGAF Standard — Architecture Content)
  
• Implementation and Migration Plan (see the TOGAF Standard — Architecture Content)
  

The level of detail addressed in Phase H will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase H as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.

• Establish value realization process (see 12.3.1 Establish Value Realization Process)
  
• Deploy monitoring tools (see 12.3.2 Deploy Monitoring Tools)
  
• Manage risks (see 12.3.3 Manage Risks)
  
• Provide analysis for architecture change management (see 12.3.4 Provide Analysis for Architecture Change Management)
  
• Develop change requirements to meet performance targets (see 12.3.5 Develop Change Requirements to Meet Performance Targets)
  
• Manage governance process (see 12.3.6 Manage Governance Process)
  
• Activate the process to implement change (see 12.3.7 Activate the Process to Implement Change”
  https://pubs.opengroup.org/togaf-standard/adm/chap12.html#:~:text=The%20steps%20in%20Phase%20H%20are%20as,12.3.7%20Activate%20the%20Process%20to%20Implement%20Change
  

Ensure monitoring tools are deployed and applied to enable the following:

• Monitor technology changes which could impact the Baseline Architecture
  
• Monitor business changes which could impact the Baseline Architecture
  
• Business value tracking; e.g., investment appraisal method to determine value metrics for the business objectives
  
• Monitor Enterprise Architecture Capability maturity
  
• Track and assess asset management programs
  
• Track the Quality of Service (QoS) performances and usage
  
• Determine and track business continuity requirements
  

Manage Enterprise Architecture risks and provide recommendations for IT strategy.

• Architecture updates (for maintenance changes)
  
• Changes to architecture framework and principles (for maintenance changes)
  
• New Request for Architecture Work (see the TOGAF Standard — Architecture Content), to move to another cycle (for major changes)
  
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
  
• Architecture Contract (see the TOGAF Standard — EA Capability and Governance), updated if necessary
  
• Compliance Assessments (see the TOGAF Standard — Architecture Content), updated if necessary
  

• 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
  

• A populated Architecture Repository (see the TOGAF Standard — Architecture Content)
  
• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  
  • Scope of organizations impacted
    
  • Maturity assessment, gaps, and resolution approach
    
  • Roles and responsibilities for architecture team(s)
    
  • Constraints on architecture work
    
  • Budget requirements
    
  • Governance and support strategy
    
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  
  • Tailored architecture method
    
  • Tailored architecture content (deliverables and artifacts)
    
  • Configured and deployed tools
    
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
  
• Architecture Vision (see the TOGAF Standard — Architecture Content)
  
• Architecture requirements, populating an Architecture Requirements Specification (see the TOGAF Standard — Architecture Content)
  
• Requirements Impact Assessment (see the TOGAF Standard — Architecture Content)
  

Requirements Management Steps (RM)
ADM Phase Steps (ADM)

• Step 1 – ADM: Identify requirements (typically by analyzing how business goals/objectives can be met through the design of value streams, business scenarios, user experiences, or the provision of management information) and document them in the Architecture Requirements Specification and Requirements Repository.
  
• Step 2 – RM: Establish baseline requirements: determine priorities, confirm stakeholder agreement to priorities, and document them in the Architecture Requirements Specification and Requirements Repository.
  
• Step 3 – RM: Monitor baseline requirements.
  
• Step 4 – ADM: Identify new and changed requirements:
  a. Remove or re-assess priorities
  b. Add requirements and re-assess priorities
  c. Modify existing requirements
  
• Step 5 – RM: Identify changed requirements and record priorities:
  a. Identify changed requirements and ensure the requirements are prioritized by the architect(s) responsible for the current phase, and by the relevant stakeholders
  b. Record new priorities
  c. Ensure that any conflicts are identified and managed through the phases to a successful conclusion and prioritization
  d. Generate Requirements Impact Statement (see the TOGAF Standard — Architecture Content) for steering the architecture team
  Notes:
  
  • Changed requirements can come in through any route
    To ensure that the requirements are properly assessed and prioritized, this process needs to direct the ADM phases and record the decisions related to the requirements.
    
  • The Requirements Management phase needs to determine stakeholder satisfaction with the decisions
    Where there is dissatisfaction, the phase remains accountable to ensure the resolution of the issues and determine next steps.
    
• Step 6 – ADM:
  a. Assess impact of changed requirements on current (active) phase
  b. Assess impact of changed requirements on previous phases
  c. Determine whether to implement change, or defer to later ADM cycle; if decision is to implement, assess timescale for change management implementation
  d. Issue Requirements Impact Statement, Version n+1
  
• Step 7 – ADM: Implement requirements arising from Phase H.
  The architecture can be changed through its lifecycle by the Architecture Change Management phase (Phase H). The Requirements Management process ensures that new or changing requirements that are derived from Phase H are managed accordingly.
  
• Step 8 – RM: Update the Architecture Requirements Repository with information relating to the changes requested, including stakeholder views affected.
  
• Step 9 – ADM: Implement change in the current phase.
  

• Step 10 – ADM: Assess and revise gap analysis for past phases.
  The gap analysis in the ADM Phases B through D identifies the gaps between Baseline and Target Architectures. Certain types of gap can give rise to gap requirements.
  The ADM describes two kinds of gap:
  

  • Something that is present in the baseline, but not in the target (i.e., eliminated — by accident or design)
    
  • Something not in the baseline, but present in the target (i.e., new)
    

  A “gap requirement” is anything that has been eliminated by accident, and therefore requires a change to the Target Architecture.
  If the gap analysis generates gap requirements, then this step will ensure that they are addressed, documented, and recorded in the Architecture Requirements Repository, and that the Target Architecture is revised accordingly.
  

• Requirements Impact Assessment (see the TOGAF Standard — Architecture Content)
  
• Updated Architecture Requirements Specification (see the TOGAF Standard — Architecture Content: Architecture Requirements Specification), if necessary
  

In each relevant phase of the ADM the architect should identify types of requirement that must be met by the architecture, including applicable:

• Functional requirements
  
• Non-functional requirements
  

When defining requirements the architect should take into account:

• Assumptions for requirements
  
• Constraints for requirements
  
• Domain-specific principles that drive requirements
  
• Policies affecting requirements
  
• Standards that requirements must meet
  
• Organization guidelines for requirements
  
• Specifications for requirements”
  https://pubs.opengroup.org/togaf-standard/adm/chap13.html#:~:text=In%20each%20relevant,Specifications%20for%20requirements