This chapter will help you understand the key deliverables of the ADM cycle and their purpose.
Key Points Explained
This chapter will help you to answer the following questions:
• What is the role of architecture deliverables across the ADM cycle?
• What is the purpose of key deliverables?
(Syllabus Reference: Unit 11, Learning Outcome 1: You should be able to briefly explain the role of architecture deliverables across the ADM cycle.)
The TOGAF standard defines a set of suggested deliverables that will be consumed and produced across the TOGAF ADM cycle The deliverable set provided is intended to provide 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.
The TOGAF standard identifies deliverables that are produced as outputs from executing the ADM cycle and potentially consumed as inputs at other points in the ADM. Other deliverables may be produced elsewhere and consumed by the ADM.
As deliverables are typically the contractual or formal work products of an architecture project, it is likely that these deliverables will be constrained or altered by any overarching project or process management for the enterprise (such as CMMI, PRINCE2, PMBOK, or MSP).
[Source: TOGAF 9 Part IV: Architecture Content Framework]
(Syllabus Reference: Unit 11, Learning Outcome 2: For each of the deliverables in this section, you should be able to briefly explain the purpose of the deliverable.)
This section describes the purpose of deliverables consumed and produced across the TOGAF ADM cycle.
ABBs are architecture documentation and models from the enterprise’s Architecture Repository. See Chapter 11.
Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are produced in Phase G: Architecture Governance. Successful implementation of these agreements will be delivered through effective Architecture Governance.
By implementing a governed approach to the management of contracts, the following will be ensured:
• A system of continuous monitoring to check integrity, changes, decisionmaking, and audit of all architecture-related activities within the organization
• Adherence to the principles, standards, and requirements of the existing or developing architectures
• Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
• A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
• A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body
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.
A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.
Architecture Definition Document versus Architecture Requirements Specification
The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:
The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.
The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.
This set of documentation is an initial output of the Preliminary Phase. Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.
In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through actions to results.
See Section 8.3.
The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties.
See Sections 3.5 and 6.8.
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 a contract for more detailed Architecture Definition.
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.
The Architecture Vision is created in Phase A and provides a high-level summary of the changes to the enterprise that will follow from 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 (see Section 8.4) are a recommended technique that can be used as part of developing an Architecture Vision document.
Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. These will have usually been defined elsewhere in the enterprise prior to the architecture activity. Many factors that lie outside the consideration of architecture discipline may have significant implications for the way that architecture is developed.
Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. This assessment is first carried out in Phase A and updated in Phase E.
This Capability Assessment can be examined on several levels:
• What is the capability level of the enterprise as a whole? Where does the enterprise wish to increase or optimize capability? What are the architectural focus areas that will support the desired development of the enterprise?
• What is the capability or maturity level of the IT function within the enterprise? What are the likely implications of conducting the architecture project in terms of design governance, operational governance, skills, and organization structure? What is an appropriate style, level of formality, and amount of detail for the architecture project to fit with the culture and capability of the IT organization?
• What is the capability and maturity of the architecture function within the enterprise? What architectural assets are currently in existence? Are they maintained and accurate? What standards and reference models need to be considered? Are there likely to be opportunities to create re-usable assets during the architecture project?
• Where capability gaps exist, to what extent is the business ready to transform in order to reach the target capability? What are the risks to transformation, cultural barriers, and other considerations to be addressed beyond the basic capability gap?
Requests for Architecture Change are considered in Phase H.
During 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 request a dispensation or to kick-start a further cycle of architecture work.
Enterprise architectures contain large volumes of complex and interdependent information. Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan in Phase A for the architecture allows for this communication to be carried out within a planned and managed process.
Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Periodic compliance reviews of implementation projects 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.
See Section 9.7.
The Implementation and Migration Plan provides a schedule of the projects for implementation of 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.
Development of the Implementation and Migration Plan
The outline Implementation and Migration Plan is created in Phase E and then finalized in Phase F.
Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.
The Implementation Governance Model produced as an output of Phase F ensures that a project transitioning into implementation moves smoothly into appropriate Architecture Governance.
An important deliverable of 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.
This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an Architecture Development Cycle. Requests for Architecture Work can be created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning. In general, all the information in this document should be at a high level.
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.
Implementation-specific building blocks from the enterprise’s Architecture Repository.
See Chapter 11.
The Statement of Architecture Work is created as a deliverable from Phase A and defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services.
Selecting and tailoring a framework is the practical starting point for an architecture project.
The TOGAF standard provides an industry standard framework for architecture that may be used in a wide variety of organizations. However, before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary.
Firstly, it is necessary to tailor the TOGAF model for integration into the enterprise. This tailoring will include integration with project and process 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 fit the framework to the specific architecture project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.
Architecture deliverables are the contractual or formal work products of an architecture project. The definitions provided by the TOGAF standard are a baseline and thus a starting point for tailoring.
Q1: Which of the following best describes the role of architecture deliverables?
A. They are defined so as to avoid tailoring the TOGAF framework.
B. They are defined as a starting point for tailoring the TOGAF framework.
Q2: Which of the following acts as a holding area for all architecture-related projects within the enterprise?
A. Architecture Building Block
B. Architecture Repository
C. Architecture Roadmap
D. Architecture Vision
Q3: Which of the following documents acts as the deliverable container for the Business, Data, Application, and Technology architectural artifacts?
A. Architecture Contract
B. Architecture Definition Document
C. Architecture Requirements Specification
D. Architecture Roadmap
E. Architecture Vision
Q4: Which of the following documents is produced early in the project lifecycle and contains a summary view of the end architecture project?
A. Architecture Contract
B. Architecture Definition Document
C. Architecture Requirements Specification
D. Architecture Roadmap
E. Architecture Vision
Q5: Which of the following documents is produced in Phase A as a response to the Request for Architecture Work?
A. Architecture Contract
B. Architecture Definition Document
C. Requirements Impact Statement
D. Statement of Architecture Work
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part IV: Architecture Content Framework, Chapter 36 (Architecture Deliverables)