ADM Deliverables

This chapter describes a typical baseline of architecture deliverables, in order to better define the activities required in the ADM and act as a starting point for tailoring within a specific organization.

Table 1 shows the ADM phase in which the deliverables are typically created, used, or enriched providing a roadmap for this chapter.

Table 1. Roadmap to ADM Deliverables
ADM Phase	Reference(s)
Preliminary Phase	Tailored Architecture Framework Organizational Model for Enterprise Architecture Architecture Principles Business Principles, Goals, and Drivers Request for Architecture Work
Phase A: Architecture Vision	Statement of Architecture Work Architecture Vision Communications Plan Capability Assessment Architecture Definition Document
Phase B: Business Architecture	Architecture Definition Document Architecture Requirements Specification Architecture Roadmap Architecture Building Blocks
Phase C: Information Systems Architectures	Architecture Definition Document Architecture Requirements Specification Architecture Roadmap Architecture Building Blocks
Phase D: Technology Architecture	Architecture Definition Document Architecture Requirements Specification Architecture Roadmap Architecture Building Blocks
Phase E: Opportunities and Solutions	Architecture Definition Document Architecture Building Blocks Architecture Roadmap Solution Building Blocks Implementation and Migration Plan Transition Architecture Implementation Governance Model
Phase F: Migration Planning	Architecture Roadmap Implementation and Migration Plan Transition Architecture Implementation Governance Model
Phase G: Implementation Governance	Implementation Governance Model Architecture Contracts Change Request Compliance Assessment
Phase H: Architecture Change Management	Implementation Governance Model Architecture Contracts Change Request Compliance Assessment Request for Architecture Work Requirements Impact Assessment
ADM Architecture Requirements Management	Architecture Requirements Specification Requirements Impact Assessment

Tailored Architecture Framework

Before the TOGAF framework can be effectively used within an Architecture Project, tailoring at a number of levels is necessary and should occur in the Preliminary Phase. It is necessary to tailor the framework for integration into the enterprise. This tailoring will include integration with management frameworks, customization of terminology, development of presentational styles, selection, configuration, and deployment of architecture tools, etc. The formality and detail of any frameworks adopted should also align with other contextual factors for the enterprise, such as culture, stakeholders, commercial models for Enterprise Architecture, and the existing level of Architecture Capability. Once the framework has been tailored to the enterprise, further tailoring is necessary in order to tailor the framework for the specific Architecture Project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.

The following contents are typical within a Tailored Architecture Framework:

Tailored architecture method
Tailored architecture content (deliverables and artifacts)
Configured and deployed tools
Interfaces with governance models and other frameworks:
- Corporate Business Planning
- Enterprise Architecture
- Portfolio, Program, Project Management
- System Development/Engineering
- Operations (Services)

Organizational Model for Enterprise Architecture

An important deliverable produced in the Preliminary Phase is the Organizational Model for Enterprise Architecture.

In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different Enterprise Architecture practitioners and the governance relationships that span across these boundaries.

Typical contents of an Organizational Model for Enterprise Architecture are:

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

Architecture Principles

Architecture Principles are general rules and guidelines that relate to architecture work. They are an output of the Preliminary Phase. See the TOGAF Standard – ADM Techniques document (Architecture Principles ) for guidelines and a detailed set of generic Architecture Principles, including business, data, application, and technology principles.

Architecture Principles are typically developed by the Enterprise Architects, in conjunction with the key stakeholders, and are approved by the Architecture Board. Architecture Principles will be informed by principles at the enterprise level, if they exist.

The following factors typically influence the development of Architecture Principles:

Enterprise mission and plans: the mission, plans, and organizational infrastructure of the enterprise
Enterprise strategic initiatives: the characteristics of the enterprise; its strengths, weaknesses, opportunities, and threats; and its current enterprise-wide initiatives (such as process improvement and quality management)
External constraints: market factors (time-to-market imperatives, customer expectations, etc.), existing and potential legislation
Current systems and technology: the set of information resources deployed within the enterprise, including systems documentation, equipment inventories, network configuration diagrams, policies, and procedures
Emerging industry trends: predictions about economic, political, technical, and market factors that influence the enterprise environment

Defining Architecture Principles

The TOGAF Standard includes a recommended template for describing principles, as shown in Table 2. In addition to a definition statement, each principle should have associated rationale and implications statements, both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made.

Table 2. TOGAF Template for Defining Principles
Name	Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the name and in the statement, such as: “support”, “open”, “consider”, and, for lack of good measure, the word “avoid” itself. Be careful with “manage(ment)”, and look for unnecessary adjectives and adverbs (fluff).
Statement	Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar among organizations. It is vital that the principles statement be unambiguous.
Rationale	Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications	Should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact on the business and the consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: “How does this affect me?”. It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

There are five criteria that distinguish a good set of principles, as shown in Table 3.

Table 3. Recommended Criteria for Quality Principles
Criteria	Description
Completeness	Every potentially important principle governing the management of information and technology for the organization is defined. The principles cover every situation perceived.
Robustness	Principles should enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.
Understandability	The underlying tenets of a principle can be quickly grasped and understood by individuals throughout the organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
Consistency	Strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.
Stability	Principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.

Business Principles, Goals, and Drivers

A statement of the business principles, goals, and drivers has usually been defined elsewhere in the enterprise prior to the architecture activity. They are restated as an output of the Preliminary Phase and reviewed again as part of Phase A: Architecture Vision. The activity in Phase A is to ensure that the current definitions are correct and clear. The TOGAF Standard – ADM Techniques document (Architecture Principles) contains an example set of nine business principles that are a useful starting point.

Request for Architecture Work

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

In general, all the information in this document should be at a high level. The typical contents of this document are as follows:

Organization sponsors
Organization’s mission statement
Business goals (and changes)
Strategic plans of the business
Time limits
Changes in the business environment
Organizational constraints
Budget information, financial constraints
External constraints, business constraints
Current business system description
Current architecture/IT system description
Description of developing organization
Description of resources available to developing organization

Statement of Architecture Work

The Statement of Architecture Work is created as a deliverable of Phase A, and is effectively a contract between the architecting organization and the sponsor of the Architecture Project. This document is a response to the Request for Architecture Work input document (see Request for Architecture Work). It should describe an overall plan to address the request for work and propose how solutions to the problems that have been identified will be addressed through the architecture process.

The typical contents of this document are as follows:

Title
Architecture Project request and background
Architecture Project description and scope
Overview of Architecture Vision
Specific change of scope procedures
Roles, responsibilities, and deliverables
Acceptance criteria and procedures
Architecture Project plan and schedule
Approvals

Architecture Vision

The Architecture Vision is created in Phase A and provides a high-level summary of the changes to the enterprise that will follow from the successful deployment of the Target Architecture. The purpose of the vision is to agree at the outset what the desired outcome should be for the architecture, so that architects can then focus on the detail necessary to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing a summary version of the full Architecture Definition. Business scenarios are an appropriate and important technique that can be used as part of the process in developing an Architecture Vision document.

The typical contents are as follows:

Problem description:
- Stakeholders and their concerns
- List of issues/scenarios to be addressed
Objective of the Statement of Architecture Work
Summary views necessary for the Request for Architecture Work and the draft Business, Data, Application, and Technology Architectures
Mapped requirements
Reference to the Draft Architecture Definition Document

Communications Plan

Enterprise Architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. Development of a Communications Plan for architecture in Phase A allows for this communication to be carried out within a planned and managed process.

Typical contents of a Communications Plan are:

Identification of stakeholders and grouping by communication requirements
Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and CSFs
Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.
Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location

Capability Assessment

Before embarking upon a detailed architecture definition, it is valuable to understand the baseline and target capability level of the enterprise. This Capability Assessment is first carried out in Phase A, and updated in Phase E.

The following contents are typical within a Capability Assessment deliverable:

Business Capability Assessment, including:
- Capabilities of the business
- Baseline state assessment of the performance level of each capability
- Future state aspiration for the performance level of each capability
- Baseline state assessment of how each capability is realized
- Future state aspiration for how each capability should be realized
- Assessment of likely impacts to the business organization resulting from the successful deployment of the Target Architecture
IT Capability Assessment, including:
- Baseline and target maturity level of change process
- Baseline and target maturity level of operational processes
- Baseline capability and capacity assessment
- Assessment of likely impacts to the IT organization resulting from the successful deployment of the Target Architecture
Architecture Maturity Assessment, including:
- Architecture Governance processes, organization, roles, and responsibilities
- Architecture skills assessment
- Breadth, depth, and quality of landscape definition within the Architecture Repository
- Breadth, depth, and quality of standards definition within the Architecture Repository
- Breadth, depth, and quality of reference model definition within the Architecture Repository
- Assessment of re-use potential
Business Transformation Readiness Assessment, including:
- Readiness factors
- Vision for each readiness factor
- Current and target readiness ratings
- Readiness risks

Architecture Definition Document

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (Business, Data, Application, and Technology) and also examines all relevant states of the architecture (Baseline, Transition, and Target).

It is first created in Phase A, where it is populated with artifacts created to support the Architecture Vision. It is updated in Phase B, with Business Architecture-related material, and subsequently updated with Information Systems Architecture material in Phase C, and then with Technology Architecture material in Phase D. Where the scope of change to implement the Target Architecture requires an incremental approach, the Architecture Definition Document will be updated to include one or more Transition Architectures in Phase E.

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

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

Typical contents of an Architecture Definition Document include:

Scope
Goals, objectives, and constraints
Architecture Principles
Baseline Architecture
Architecture models (for each state to be modeled):
- Business Architecture models
- Data Architecture models
- Application Architecture models
- Technology Architecture models
Rationale and justification for architectural approach
Mapping to Architecture Repository:
- Mapping to Architecture Landscape
- Mapping to reference models
- Mapping to standards
- Re-use assessment
Gap analysis
Impact assessment
Transition Architecture (see Transition Architecture)

The following sections look at each of the architectures in more detail.

Business Architecture

The Business Architecture is developed in Phase B. The topics that should be addressed in the Architecture Definition Document related to Business Architecture are as follows:

Baseline Business Architecture, if appropriate – this is a description of the existing Business Architecture
Target Business Architecture, 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 and functions – relate business functions to organizational units in the form of a matrix report
Views corresponding to the selected viewpoints addressing key stakeholder concerns

Information Systems Architectures

The Information Systems Architectures are developed in Phase C. The topics that should be addressed in the Architecture Definition Document related to the Information Systems Architectures are as follows:

Baseline Data Architecture, if appropriate
Target Data Architecture, including:
- Business data model
- Logical data model
- Data management process models
- Data Entity/Business Function matrix
Data Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns
Baseline Application Architecture, if appropriate
Target Application Architecture
Application Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns

Technology Architecture

The Technology Architecture is developed as part of Phase D. The topics that should be addressed in the Architecture Definition Document related to Technology Architecture are as follows:

Baseline Technology Architecture, if appropriate
Target Technology Architecture, 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

Architecture Requirements Specification

The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed architecture definition. As mentioned earlier in this chapter, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective to provide the quantitative view.

Typical contents of an Architecture Requirements Specification include:

Success measures
Architecture requirements
Business service contracts
Application service contracts
Implementation guidelines
Implementation specifications
Implementation standards
Interoperability requirements
IT service management requirements
Constraints
Assumptions

Business Architecture Requirements

Business Architecture requirements populating the Architecture Requirements Specification in Phase B include:

Gap analysis results
Technical requirements

An initial set of technical requirements should be generated as the output of Phase B (Business Architecture). These are the drivers for the architecture work that follows, and should identify, categorize, and prioritize the implications for work in the remaining architecture domains.
Updated business requirements

The Business Scenarios technique can be used to discover and document business requirements.

Information Systems Architecture Requirements

Information Systems Architecture requirements populating the Architecture Requirements Specification in Phase C include:

Gap analysis results
Data interoperability requirements
Application interoperability requirements
Areas where the Business Architecture may need to change in order to comply with changes in the Data and/or Application Architecture
Constraints on the Technology Architecture about to be designed
Updated business requirements, if appropriate
Updated data requirements, if appropriate
Updated application requirements, if appropriate

Technology Architecture Requirements

Technology Architecture requirements populating the Architecture Requirements Specification in Phase D include:

Gap analysis results
Updated technology requirements

Interoperability Requirements

The determination of interoperability is present throughout the ADM cycle. A set of guidelines is provided in the ADM Techniques document for defining and establishing interoperability requirements.

Architecture Roadmap

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

Typical contents of an Architecture Roadmap are as follows:

Work package portfolio:
- Work package description (name, description, objectives, deliverables)
- Functional requirements
- Dependencies
- Relationship to opportunity
- Relationship to Architecture Definition Document and Architecture Requirements Specification
- Business value
Implementation Factor catalog, including:
- Risks
- Issues
- Assumptions
- Dependencies
- Actions
- Impact
Consolidated Gaps, Solutions, and Dependencies matrix, including:
- Architecture domain
- Gaps
- Potential solutions
- Dependencies
Transition Architectures, if any
Implementation recommendations:
- Criteria/measures of effectiveness of projects
- Risks and issues
- SBBs

Architecture Building Blocks

Architecture Building Blocks (ABBs) are architecture documentation and models from the enterprise’s Architecture Repository classified according to the Architecture Continuum. They are defined or selected as a result of application of the ADM (mainly in Phases A, B, C, and D). The characteristics of ABBs are as follows:

They capture architecture requirements; e.g., business, data, application, and technology requirements
They direct and guide the development and procurement of SBBs

The content of ABB specifications include the following as a minimum:

Fundamental functionality and attributes: semantics, unambiguous, including security capability and manageability
Interfaces: chosen set, supplied (Application Programming Interfaces (APIs), data formats, protocols, hardware interfaces, standards)
Interoperability and relationship with other building blocks
Dependent building blocks with required functionality and named user interfaces

Each ABB should include a statement of any architecture documentation and models from the enterprise’s Architecture Repository that can be re-used in the architecture development. The specification of building blocks using the ADM is an evolutionary and iterative process.

Solution Building Blocks

Solution Building Blocks (SBBs) relate to the Solutions Continuum. They are implementation choices of the architectures identified in the enterprise’s Architecture Continuum and may be either procured or developed. SBBs appear in Phase E of the ADM where product-specific building blocks are considered for the first time. SBBs define what products and components will implement the functionality, thereby defining the implementation. They fulfill business requirements and are product or vendor-aware. The content of an SBB specification includes the following as a minimum:

Specific functionality and attributes
Interfaces; the implemented set
Required SBBs used with required functionality and names of the interfaces used
Mapping from the SBBs to the IT topology and operational policies
Specifications of attributes shared such as security, manageability, localizability, scalability
Performance, configurability
Design drivers and constraints, including the physical architecture
Relationships between the SBBs and ABBs

Implementation and Migration Plan

The Implementation and Migration Plan is developed in Phases E and F, and provides a schedule of the projects for implementation of the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. The Implementation and Migration Strategy identifying the approach to change is a key element of the Implementation and Migration Plan.

Typical contents are as follows:

Implementation and Migration Strategy:
- Strategic implementation direction
- Implementation sequencing approach
Project and portfolio breakdown of implementation:
- Allocation of work packages to project and portfolio
- Capabilities delivered by projects
- Milestones and timing
- Work breakdown structure
- May include impact on existing portfolio, program, and projects

It may contain:

Project charters:
- Included work packages
- Business value
- Risk, issues, assumptions, dependencies
- Resource requirements and costs
- Benefits of migration, determined (including mapping to business requirements)
- Estimated costs of migration options

Transition Architecture

Where the scope of change to implement the Target Architecture requires an incremental approach, one or more Transition Architectures are defined within the Architecture Definition Document output from Phase E. A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe interim architectures necessary for the effective realization of the Target Architecture. These provide an ability to identify clear interim points of reference along the roadmap to realizing the Target Architecture.

The following contents are typical within a Transition Architecture:

Transition Architecture:
- Definition of transition states
- Business Architecture for each transition state
- Data Architecture for each transition state
- Application Architecture for each transition state
- Technology Architecture for each transition state

Implementation Governance Model

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

The Implementation Governance Model produced as an output of Phase F ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance (for Phase G).

Typical contents of an Implementation Governance Model are:

Governance processes
Governance organization structure
Governance roles and responsibilities
Governance checkpoints and success/failure criteria

Architecture Contracts

Architecture Contracts may occur at various stages of the ADM; for example, in Phase G: Implementation Governance. Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective architecture. By implementing a governed approach to the management of contracts, the following will be ensured:

A system of continuous monitoring to check the integrity, changes, decision-making, and audits of all architecture-related activities within the organization
Adherence to the principles, standards, and requirements of the existing or developing architectures
Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body

Typical contents of an Architecture Design and Development Contract are:

Introduction and background
The nature of the agreement
Scope of the architecture
Architecture and strategic principles and requirements
Conformance requirements
Architecture development and management process and roles
Target Architecture measures
Defined phases of deliverables
Prioritized joint work plan
Time window(s)
Architecture delivery and business metrics

Typical contents of a Business Users’ Architecture Contract are:

Introduction and background
The nature of the agreement
Scope
Strategic requirements
Conformance requirements
Architecture adopters
Time window
Architecture business metrics
Service architecture (includes SLA)

Change Request

Requests for Architecture Change are considered in Phase H: Architecture Change Management. During the implementation of an architecture, as more facts become known, it is possible that the original architecture definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions. Additionally, external factors – such as market factors, changes in business strategy, and new technology opportunities – may open up opportunities to extend and refine the architecture.

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

Typical contents of a Change Request are:

Description of the proposed change
Rationale for the proposed change
Impact assessment of the proposed change, including:
- Reference to specific requirements
- Stakeholder priority of the requirements to date
- Phases to be revisited
- Phase to lead on requirements prioritization
- Results of phase investigations and revised priorities
- Recommendations on management of requirements
Repository reference number

Compliance Assessment

Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation lessons are fed back into the architecture process. Periodic compliance reviews of implementation projects in Phase G provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives.

Typical contents of a Compliance Assessment are:

Overview of project progress and status
Overview of project architecture/design
Completed architecture checklists:
- Hardware and operating system checklists
- Software services and middleware checklists
- Applications checklists
- Information management checklists
- Security checklists
- System management checklists
- System engineering checklists
- Methods and tools checklists

Requirements Impact Assessment

Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.

It documents an assessment of the changes and the recommendations for change to the architecture. The typical contents are as follows:

Reference to specific requirements
Stakeholder priority of the requirements to date
Phases to be revisited
Phase to lead on requirements prioritization
Results of phase investigations and revised priorities
Recommendations on management of requirements
Repository reference number

These are often produced as a response to a Change Request.