ADM Baseline Deliverables (A) Flashcards
Architecture Contract
Output: None
Input: None
Purpose
The joint agreements between development partners and sponsors including the deliverables, quality, and fitness-for-purpose of an architecture.
-
Successful implementation of these agreements will be delivered through effective Architecture Governance (see Part VI, Chapter 44). By implementing a governed approach to the management of contracts, the following will be ensured:
■ A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
■ Adherence to the principles, standards, and requirements of the existing or developing architectures
■ Identification of risks in all aspects of the development and implementation of the
architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that
the organization can continue its business within a resilient environment
■ A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
■ A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body
Architecture Roadmap
Output: B,C, D, E, F
Input: B, C, D, E, F
Purpose
Lists individual work packages that will realize the Target Architecture and arranges them on a timeline to show progression from the Baseline Architecture to the Target Architecture.
-
The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM.
Organizational Model for Enterprise Architecture
Output: Pre
Input: Pre, A, B, C, D, E, F, G, H, RM
Purpose
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.
Content
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
Tailored Architecture Framework
Output: Pre, A
Input: P, A, B, C, D, E, F, G, H, R
Purpose
Before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary. 1. Organizationally and 2. Specific Architecture Project.
-
Firstly, it is necessary to tailor the TOGAF model 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.
Second, the specific architecture project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.
— Tailored architecture method
— Tailored architecture content (deliverables and artifacts)
— Architecture Principles
— Configured and deployed tools
Architecture Repository
Output: Pre
Input: All
Purpose
The Architecture Repository is a storage 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.
Request for Architecture Work
Output: Pre, F, H
Input: A, G
Purpose
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.
Statement of Architecture Work
Output: A, B, C, D, E, F, G,H
Input: B, C, D, E, F, G, H, RM
Purpose
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.
Content
■ 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 Principles
Output: Pre, A, B, C, D
Input: ALL
Purpos
General rules and guidelines, intended to be enduring and seldom amended, that inform and support the way an organization fulfils 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 to actions and results.
Architecture Vision
Output: A, E
Input: B, C, D, E, F, G, H, RM
Purpose
It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.
-
The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. Early agreement on the outcome enables the architects to 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.
— Problem description
— Objective of the Statement of Architecture Work
— Summary views
— Mapped requirements
— Reference to Draft Architecture Definition Document
Architecture Definition Document
Output: B, C, D, E, F
Input: C, D, E, F, G, H
Purpose
Is a deliverable container for the core architectural artifacts created during a project and for important related information. Provides a qualitative view of the solution and aims to communicate the intent of the architects
-
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).
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.
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
