Architecture Development Method (ADM) Flashcards
ADM Overview
- Architecture development is a continuous**, **cyclical process**, and in executing the ADM **repeatedly over time**, the architect gradually adds more and more content to the organization’s Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise’s own Architecture Repository with r_elevant re-usable building blocks_ taken **from the “left”, more generic side of the Enterprise Continuum.
- In fact, the first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce.
- The ADM is iterative**, over the whole process, **between phases, and within phases.
Version Numbering in ADM
A version numbering convention is used within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions.
Version 0.1** indicates that a **high-level outline of the architecture is in place.
Version 1.0** indicates a **formally reviewed, detailed architecture.
Adapting the ADM
- One reason for adapting the ADM is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise.
- Another reason for adapting the ADM is if the TOGAF framework is to be integrated with another enterprise framework.
- The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation
- The enterprise is a small-to-medium enterprise**, and wishes to use a “cut-down” method more attuned to the **reduced level of resources and system complexity typical of such an environment
- The enterprise is very large and complex, comprising many separate but interlinked “enterprises” within an overall collaborative business framework, and the architecture method needs to be adapted to recognize this
Different approaches to planning and integration ADM;
- Top-down planning and development — designing the whole interconnected metaenterprise as a single entity (an exercise that typically stretches the limits of practicality)
- Development of a “generic” or “reference” architecture, typical of the enterprises within the organization, but not representing any specific enterprise, which individual enterprises are then expected to adapt in order to produce an architecture “instance” suited to the particular enterprise concerned
- Replication** — developing a specific architecture for one enterprise, implementing it as a proof-of-concept, and then taking that as a “**reference architecture” to be cloned in other enterprise
Architecture Governance
The major information areas managed by a governance repository should contain the following types of information:
Reference Data (collateral from the organization’s own repositories/Enterprise Continuum, including external data; e.g., COBIT, the IT4IT Reference Architecture). The reference data includes a description of the governance procedures themselves.
Process Status: all information regarding the state of any governance processes will be managed
Audit Information: this will record all completed governance process actions and will be used to support.
Scoping the Architecture
There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:
- The organizational authority of the team producing the architecture
- The objectives and stakeholder concerns to be addressed within the architecture
- The availability of people, finance, and other resources
Scoping the Architecture
Four dimensions** are typically **used in order to define and limit the scope of an architecture:
- Breadth: what is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?
- Depth: to what level of detail should the architecting effort go?
- Time Period: what is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed Architecture Description?
- Architecture Domains:acomplete Enterprise Architecture description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise
Scoping the Architecture
Breadth:
For large complex enterprises, federated architectures — independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework — are typical.
Depth:
It is important that a consistent and equal level of depth be completed in each architecture domain (business, data, application, technology) included in the architecture effort. If pertinent detail is omitted, the architecture may not be useful. If unnecessary detail is included, the architecture effort may exceed the time and resources available, and/or the resultant architecture may be confusing or cluttered
Scoping the Architecture
Time Period:
An enterprise is represented by several different architecture instances (for example, strategic, segment, capability**), each representing the enterprise at _a particular point in tim_e. One architecture instance will represent the current enterprise state (the “as-is”, or **baseline**). Another architecture instance, perhaps defined only partially, will represent the ultimate **target end-state (the “vision”**). In-between, **intermediate or “Transition Architecture” instances may be defined, each comprising its own set of Target Architecture Descriptions.
Architecture Domains:
A complete Enterprise Architecture should address all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains.
Preliminary Phase
Preliminary Phase describes the preparation and initiation activities** required to meet the business directive for a new Enterprise Architecture, including the **definition of an Organization-Specific Architecture framework** and **the definition of principles.
This Preliminary Phase is about defining “where, what, why, who, and how we do architecture”
The Preliminary Phase may be revisited, from the Architecture Vision phase, in order to ensure that the organization’s Architecture Capability is suitable to address a specific architecture problem.
Objectives:
- Determine the Architecture Capability desired by the organization:
- Establish the Architecture Capability
Architectural Inputs : Organizational Model for Enterprise Architecture
Preliminary Phase
Steps:
- Scope the Enterprise Organizations Impacted
- Confirm Governance and Support Frameworks
- Define and Establish Enterprise Architecture Team and Organization
- Determine existing enterprise and business capability
- Enterprise Architecture/business change maturity assessment
- Determine existing enterprise and business capability
- Identify and Establish Architecture Principles
- Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)
- Develop a Strategy and Implementation Plan for Tools and Techniques
Preliminary Phase
Outputs:
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Initial Architecture Repository
- Restatement of, or reference to, business principles, business goals, and business drivers
- Request for Architecture Work (optional)
- Architecture Governance Framework
Preliminary Phase
The main frameworks suggested to be co-ordinated with the TOGAF framework are:
- Business Capability Management that determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures
- Project/Portfolio Management Methods that determine how a company manages its change initiatives
- Operations Management Methods that describe how a company runs its day-to-day operations, including IT
- Solution Development Methods that formalize the way that business systems are delivered in accordance with the structures developed in the IT architecture
Preliminary Phase
Capability Maturity Models are useful ways of assessing the ability of an enterprise to exercise different capabilities.
Several good models exist, including NASCIO**, and the **US Department of Commerce Architecture Capability Maturity Model, US Federal Enterprise Architecture Maturity Model.
Phase A: Architecture Vision
Phase A: Architecture Vision describes the initial phase of the Architecture Development Method (ADM)**. It includes information about **defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
Objectives:
- Develop a high-level aspirational vision of the capabilities and business value to be delivered
- Obtain approval for a Statement of Architecture Work
Inputs:
- Request for Architecture Work
- Business principles, business goals, and business drivers
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Populated Architecture Repository
Phase A: Architecture Vision
Steps:
- Establish the architecture project
- Identify stakeholders, concerns, and business requirements
- stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns
- Communications Plan
- Confirm and elaborate business goals, business drivers, and constraints
- Evaluate capabilities
- Capability Assessment
- Assess readiness for business transformation
- Business Transformation Readiness Assessment can be used to evaluate and quantify the organization’s readiness to undergo a change
Phase A: Architecture Vision
Steps:
- Establish the architecture project
- Identify stakeholders, concerns, and business requirements
- stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns
- Communications Plan
- Confirm and elaborate business goals, business drivers, and constraints
- Evaluate capabilities
- Capability Assessment
- Assess readiness for business transformation
- Business Transformation Readiness Assessment can be used to evaluate and quantify the organization’s readiness to undergo a change
Phase A: Architecture Vision
Steps:
- Define scope
- Confirm and elaborate Architecture Principles, including business principles
- Develop Architecture Vision
- Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements.
- Define the Target Architecture value propositions and KPIs
- Identify the business transformation risks and mitigation activities
- risk management framework
- There are two levels of risk that should be considered, namely:
- Initial Level of Risk: risk categorization prior to determining and implementing mitigating actions
- Residual Level of Risk: risk categorization after implementation of mitigating actions (if any)
- Develop Statement of Architecture Work; secure approval
Phase A: Architecture Vision
Outputs:
- Approved Statement of Architecture Work
- Refined statements of business principles, business goals, and business drivers
- Capability Assessment
- Tailored Architecture Framework
- Architecture Principles
- Architecture Vision
- Draft Architecture Definition Document
- Communications Plan
- Additional content populating the Architecture Repository
The outputs may include some or all of the following:
- Matrices: Stakeholder Map matrix
- Diagrams: Business Model diagram — Business Capability Map — Value Stream Map — Value Chain diagram — Solution Concept diagram
Phase B: Business Architecture
Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision
Objectives:
- 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
Phase B: Business Architecture
Inputs:
- Request for Architecture Work
- Business principles, business goals, and business drivers
- Capability Assessment
- Communications Plan
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Approved Statement of Architecture Work
- Architecture Principles
- Enterprise Continuum
- Architecture Repository
- Architecture Vision
- Draft Architecture Definition Document
Phase B: Business Architecture
Steps:
- Select Reference Models, Viewpoints, and Tools
- Determine Overall Modeling Process (Business modeling and strategy assessments, Business scenarios )
- The techniques that 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
- Organization Mapping:arepresentation 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)
- Value Stream Mapping: the 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
- The techniques that can be utilized to progressively decompose a business:
- Determine Overall Modeling Process (Business modeling and strategy assessments, Business scenarios )
Phase B: Business Architecture
- The techniques that can be utilized to progressively decompose a business:
- Structured Analysis: identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business
- Use-case Analysis: the breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability
- Process Modeling: the breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions
Phase B: Business Architecture
Steps:
- Select Reference Models, Viewpoints, and Tools
- Determine Overall Modeling Process (Business modeling and strategy assessments, Business scenarios )
- Identify Required Service Granularity Level, Boundaries, and Contracts
- Identify Required Catalogs of Business Building Blocks
- Identify Required Matrices
- Identify Required Diagrams
Phase B: Business Architecture
Steps:
- Select Reference Models, Viewpoints, and Tools
- Identify Types of Requirement to be Collected
- Relate to the business domain
- Provide requirements input into the Data, Application, and Technology Architectures
- Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements
- Identify Types of Requirement to be Collected
Phase B: Business Architecture
Steps:
- Develop Baseline Business Architecture Description
- Develop Target Business Architecture Description
- Perform Gap Analysis
- Verify the architecture models for internal consistency and accuracy:
- Perform trade-off analysis to resolve conflicts (if any) among the different views
- Validate that the models support the principles, objectives, and constraints
- Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
- Test architecture models for completeness against requirements
- Verify the architecture models for internal consistency and accuracy:
