Architecture Development Method Flashcards
Phase H: Architecture Change Management
Ensures that the architecture responds to the needs of the enterprise
The final step in the development of the four architecture domains
Create Architecture Definition Document
The version numbers used by the TOGAF standard as a convention to denote a high-level outline of an architecture
Version 0.1
The recommended information areas managed by a governance repository.
- Reference Data. Used for guidance and instruction during project implementation
- Process Status. Record of all information regarding the state of any governance processes
- Audit Information. A record of all completed governance process actions
The ADM supports the concept of iteration at three levels.
- Cycling around the ADM. The ADM is presented in a circular manner indicating that the completion of one phase of architecture work directly feeds into subsequent phases of architecture work
- Iterating between phases. The TOGAF standard describes the concept of iterating across phases (e.g., returning to Business Architecture on completion of Technology Architecture)
- Cycling around a single phase. The ADM supports repeated execution of the activities within a single ADM phase as a technique for elaborating architectural content.
Architecture Development Method Activities by Phase
- Preliminary Phase
- Requirements Management
- Phase A: Architecture Vision
- Phase B: Business Architecture
- Phase C: Information Systems Architectures (Application & Data)
- Phase D: Technology Architecture
- Phase E: Opportunities & Solutions
- Phase F: Migration Planning
- Phase G: Implementation Governance
- Phase H: Architecture Change Management
Preliminary Phase
- Prepare the organization for successful TOGAF architecture projects.
- Undertake the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, selection of tools, and the definition of Architecture Principles.
Requirements Management
Every stage of a TOGAF project is based on and validates business requirements. Requirements are identified, stored, and fed into and out of the relevant ADM phases, which dispose of, address, and prioritize requirements.
Phase A: Architecture Vision
- Set the scope, constraints, and expectations for a TOGAF project.
- Create the Architecture Vision.
- Identify stakeholders.
- Validate the business context and create the Statement of Architecture Work.
- Obtain approvals.
Phase B: Business Architecture, Phase C: Information Systems Architectures (Application & Data), Phase D: Technology Architecture
Develop architectures in four domains.
- Business
- Information Systems – Application
- Information Systems – Data
- Technology
In each case, develop the Baseline and Target Architecture and analyze gaps.
Phase E: Opportunities & Solutions
- Perform initial implementation planning and the identification of delivery vehicles for the building blocks identified in the previous phases.
- Determine whether an incremental approach is required, and if so identify Transition Architectures.
Phase F: Migration Planning
Develop a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
Phase G: Implementation Governance
- Provide architectural oversight for the implementation.
- Prepare and issue Architecture Contracts.
- Ensure that the implementation project conforms to the architecture.
Phase H: Architecture Change Management
Provide continual monitoring and a change management process to ensure that the architecture responds to the needs of the enterprise and maximizes the value of the architecture to the business.
Phase A: Architecture Vision Deliverable
Architecture Vision
- Business Architecture
- Data Architecture
- Application Architecture
- Technology Architecture
Phase B: Business Architecture Deliverable
Architecture Definition Document
- Business Architecture
Phase C: Information Systems Architecture Deliverable
Architecture Definition Document
- Data Architecture
- Application Architecture
Phase D: Technology Architecture Deliverable
Architecture Definition Document
- Technology Architecture
Version 0.1
Indicates that a high-level outline of the architecture is in place.
Version 1.0
Indicates a formally reviewed, detailed architecture.
The practical implementation of the Enterprise Continuum
Take the form of an Architecture Repository
Architecture Repository
Includes reference architectures, models, and patterns that have been accepted for use within the enterprise, and actual architectural work done previously within the enterprise.
The application of the ADM is supported by
An extended set of resources – guidelines, templates, checklists, and other detailed materials
Main reasons to constrain (or restrict) the scope of the architectural activity to be undertaken
- 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
Dimensions for Limiting the Scope of the Architecture Activity
- Breadth. What is the full extent of the enterprise, and what part of that extent should the architecting effort deal with?
- Depth. To what level of detail should the architecting effort go? How much architecture is “enough”? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)?
- 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? If not, how many Transition Architectures are to be defined, and what are their time periods?
- Architecture domains. A complete 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.
The scope of architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed.
