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:
Phase B: Business Architecture
Steps:
- Define Candidate Roadmap Components
- initial** Business Architecture Roadmap will be used as raw material to support more **detailed** definition of a consolidated, cross-discipline **roadmap within the Opportunities & Solutions phase.
- Resolve Impacts Across the Architecture Landscape
- Does this Business Architecture create an impact on any pre-existing architectures?
- Have recent changes been made that impact on the Business Architecture?
- Are there any opportunities to leverage work from this Business Architecture in other areas of the organization?
- Does this Business Architecture impact other projects (including those planned as well as those currently in progress)?
- Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?
Phase B: Business Architecture
Steps:
- Conduct Formal Stakeholder Review
- Finalize the Business Architecture
- Create the Architecture Definition Document
Outputs:
- Refined and updated versions of the Architecture Vision phase deliverables
- Statement of Architecture Work
- Validated business principles, business goals, and business drivers
- Architecture Principles
-
Draft Architecture Definition Documen
- Baseline Business Architecture, Version 1.0
- Target Business Architecture, Version 1.0
- Views corresponding to the selected viewpoints addressing key stakeholder concerns
- Draft Architecture Requirements Specification
- Business Architecture components of an Architecture Roadmap
Phase B: Business Architecture
The outputs may include some or all of the following:
- Catalogs: — Value Stream catalog — Business Capabilities catalog — Value Stream Stages catalog — Organization/Actor catalog — Driver/Goal/Objective catalog — Role catalog — Business Service/Function catalog — Location catalog — Process/Event/Control/Product catalog — Contract/Measure catalog
- Matrices: — Value Stream/Capability matrix — Strategy/Capability matrix — Capability/Organization matrix — Business Interaction matrix — Actor/Role matrix
- Diagrams: — Business Model diagram — Business Capability Map — Value Stream Map — Organization Map — Business Footprint diagram — Business Service/Information diagram — Functional Decomposition diagram — Product Lifecycle diagram — Goal/Objective/Service diagram — Business Use-Case diagram — Organization Decomposition diagram— Process Flow diagram — Event diagram
Phase B : Business Architecture
Applying Business Capabilities
- business capability map
- business capability maturity heat map (maturity, effectiveness, performance, and the value or cost of each capability to the business)
Applying Value Streams
Applying the Organization Map
Organization map is the key element of Business Architecture because it provides the organizational context for the whole Enterprise Architecture effort. While capability mapping exposes what a business does and value stream mapping exposes how it delivers value to specific stakeholders, the organization map identities the business units or third parties that possess or use those capabilities and which participate in the value streams
Phase B : Business Architecture
Applying Modeling Techniques
- Activity Models (also called Business Process Models)
- Use-Case Models
- Class Models
- The Node Connectivity Diagram (Industry specific - defense)
- The Information Exchange Matrix
Architecture Repository
- Industry reference models relevant to the organization’s industry sector
- The Object Management Group (OMG)
- The TM Forum
- Federal Enterprise Architecture Business Reference Model
- The IT4IT Reference Architecture
Phase C : Information Systems Architecture - Data Architecture
Phase C : Information Systems Architecture describes the Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
Objectives:
- Develop the Target Information Systems Architectures, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and 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 Information Systems (Data and Application) Architectures
Phase C : Information Systems Architecture - Data Architecture
Data Architecture:
Inputs:
- Request for Architecture Work
- Capability Assessment
- Communications Plan
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Data principles
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Business Architecture components of an Architecture Roadmap
Phase C : Information Systems Architecture - Data Architecture
Data Architecture:
Steps:
- Select Reference Models, Viewpoints, and Tools
- Examples of data modeling techniques are:
- Entity-relationship diagram
- Class diagram
- Examples of data modeling techniques are:
- Determine Overall Modeling Process
- Identify Required Catalogs of Data Building Blocks
- During the Business Architecture phase, a Business Service/Information diagram was created showing the key data entities required by the main business services. This is a prerequisite to successful Data Architecture activities.
- Identify Required Matrices
Phase C : Information Systems Architecture - Data Architecture
Data Architecture:
Steps:
- Identify Required Diagrams
- Identify Types of Requirement to be Collected
- Develop Baseline Data Architecture Description
- Develop Target Data Architecture Description
- Perform Gap Analysis
- Define Candidate Roadmap Components
- Resolve Impacts Across the Architecture Landscape
- Conduct Formal Stakeholder Review
- Finalize the Data Architecture
- Create the Architecture Definition Document
Phase C : Information Systems Architecture - Data Architecture
Outputs:
- Statement of Architecture Work
- Validated data principles
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Data Architecture components of an Architecture Roadmap
The outputs may include some or all of the following:
- Catalogs: — Data Entity/Data Component catalog
- Matrices: — Data Entity/Business Function matrix — Application/Data matrix
- Diagrams: — Conceptual Data diagram — Logical Data diagram — Data Dissemination diagram — Data Security diagram — Data Migration diagram — Data Lifecycle diagram
Phase C : Information Systems Architecture - Data Architecture
Data Architecture:
- Data Management
- Data Migration
- Data Governance
- Data governance considerations ensure that the enterprise has the necessary dimensions in place to enable the transformation, as follows:
- Structure: this dimension pertains to whether the enterprise has the necessary organizational structure and the standards bodies to manage data entity aspects of the transformation
- Management System: here enterprises should have the necessary management system and data-related programs to manage the governance aspects of data entities throughout its lifecycle
- People: this dimension addresses what data-related skills and roles the enterprise requires for the transformation If the enterprise lacks such resources and skills, the enterprise should consider either acquiring those critical skills or training existing internal resources to meet the requirements through a well-defined learning program.
- Data governance considerations ensure that the enterprise has the necessary dimensions in place to enable the transformation, as follows:
Phase C: Information Systems Architectures — Application Architecture
Objectives:
- Develop the Target Application Architecture that enables the Business Architecture and 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 Application Architectures
Phase C: Information Systems Architectures — Application Architecture
Inputs
- Request for Architecture Work
- Capability Assessment
- Communications Plan
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Application principles
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Business and Data Architecture components of an Architecture Roadmap
Phase C: Information Systems Architectures — Application Architecture
Application Architecture:
Steps:
- Select Reference Models, Viewpoints, and Tools
- Examples of data modeling techniques are:
- Entity-relationship diagram
- Class diagram
- Examples of data modeling techniques are:
- Determine Overall Modeling Process
- Identify Required Catalogs of Data Building Blocks
- The following catalogs should be considered for development within an Application Architecture:
- Application Portfolio catalog
- Interface catalog
- The following catalogs should be considered for development within an Application Architecture:
- Identify Required Matrices
Phase C: Information Systems Architectures — Application Architecture
Application Architecture:
Steps:
- Identify Required Diagrams
- Identify Types of Requirement to be Collected
- Develop Baseline Data Architecture Description
- Develop Target Data Architecture Description
- Perform Gap Analysis
- Define Candidate Roadmap Components
- Resolve Impacts Across the Architecture Landscape
- Conduct Formal Stakeholder Review
- Finalize the Application Architecture
- Create the Architecture Definition Document
Phase C: Information Systems Architectures — Application Architecture
Outputs:
- Statement of Architecture Work
- Validated application principles & new application principles
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Application Architecture components of an Architecture Roadmap
The outputs may include some or all of the following:
- Catalogs: — Application Portfolio catalog — Interface catalog
- Matrices: — Application/Organization matrix — Role/Application matrix— Application/Function matrix — Application Interaction matrix
- Diagrams: — Application Communication diagram — Application and User Location diagram — Application Use-Case diagram — Enterprise Manageability diagram — Process/Application Realization diagram — Software Engineering diagram — Application Migration diagram — Software Distribution diagram
Phase D: Technology Architecture
Phase D: Technology Architecture describes the development of a Technology Architecture for an architecture project.
Objectives:
- Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, 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 Technology Architectures
Phase D: Technology Architecture
Inputs
- Request for Architecture Work
- Capability Assessment
- Communications Plan
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Technology principles
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Business, Data, and Application Architecture components of an Architecture Roadmap
Phase D: Technology Architecture
Technology Architecture:
Steps:
- Select Reference Models, Viewpoints, and Tools
- Examples of data modeling techniques are:
- Entity-relationship diagram
- Class diagram
- Examples of data modeling techniques are:
- Determine Overall Modeling Process
- Technology Architecture may be impacted will include the following:
- Performance: the granularity of the service will impact on technology service requirements Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
- Maintainability: if service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered
- Location and Latency: services might interact with each other over remote links and interservice communication will have in-built latency Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
- Availability: service invocation is subject to network and/or service failure So high communication availability is an important consideration during service decomposition and defining service granularity
- Technology Architecture may be impacted will include the following:
Phase D: Technology Architecture
Technology Architecture:
Steps:
- Identify Required Catalogs of Technology Building Blocks
- The following catalogs should be considered for development within a Technology Architecture:
- Technology standards
- Technology portfolio
- The following catalogs should be considered for development within a Technology Architecture:
- Identify Required Matrices
- Identify Required Diagrams
- Identify Types of Requirement to be Collected
- Select Services
- Develop Baseline Technology Architecture Description
- Develop Target Technology Architecture Description
- Perform Gap Analysis
- Define Candidate Roadmap Components
- Resolve Impacts Across the Architecture Landscape
- Conduct Formal Stakeholder Review
- Finalize the Technology Architecture
- Create the Architecture Definition Document
Phase D: Technology Architecture
Outputs:
- Statement of Architecture Work
- Validated technology principles & new technology principles
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Technology Architecture components of an Architecture Roadmap
The outputs may include some or all of the following:
- Catalogs: — Technology Standards catalog — Technology Portfolio catalog
- Matrices: — Application/Technology matrix
- Diagrams: — Environments and Locations diagram — Platform Decomposition diagram — Processing diagram — Networked Computing/Hardware diagram — Network and Communications diagram
- Define Candidate Roadmap Components
- Resolve Impacts Across the Architecture Landscape
- Conduct Formal Stakeholder Review
- Finalize the Technology Architecture
- Create the Architecture Definition Document
Phase E: Opportunities & Solutions
Phase E: Opportunities & Solutions describes the process of identifying delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases.
Objectives:
- Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
- Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
- Define the overall solution building blocks to finalize the Target Architecture based on the Architecture Building Blocks (ABBs)
Phase E: Opportunities & Solutions
Inputs:
- Request for Architecture Work
- Capability Assessment
- Communications Plan
- Planning methodologies
- Governance models and frameworks
- Organizational Model for Enterprise Architecture
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Change Requests for existing business programs and projects
- Candidate Architecture Roadmap components from Phases B, C, and D
Phase E: Opportunities & Solutions
Steps:
- Determine/Confirm Key Corporate Change Attributes
- Implementation Factor Assessment
- Deduction matrix
- Determine Business Constraints for Implementation
- Review and Consolidate Gap Analysis Results from Phases B to D
- Review Consolidated Requirements Across Related Business Functions
- work packages
- Consolidate and Reconcile Interoperability Requirements
- Refine and Validate Dependencies
- Confirm Readiness and Risk for Business Transformation
- Formulate Implementation and Migration Strategy
- There are three basic approaches as follows:
- Greenfield: a completely new implementation
- Revolutionary: a radical change (i.e., switch on, switch off)
- Evolutionary: a strategy of convergence, such as parallel running or a phased approach to introduce new capabilities
- The most common implementation methodologies are:
- Quick win (snapshots)
- Achievable targets
- Value chain method
- There are three basic approaches as follows:
Phase E: Opportunities & Solutions
Steps:
- Identify and Group Major Work Packages
- Classify every current system that is under consideration as:
- Mainstream: part of the future information system
- Contain: expected to be replaced or modified in the planning horizon (next three years)
- Replace: to be replaced in the planning horizon
- Classify every current system that is under consideration as:
- Identify Transition Architectures
- Create the Architecture Roadmap & Implementation and Migration Plan
Phase E: Opportunities & Solutions
Outputs:
- Statement of Architecture Work
- Architecture Vision, including definition of types and degrees of interoperability
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Capability Assessments, including: — Business Capability Assessment — IT Capability Assessment
- Architecture Roadmap
- Work package portfolio:
- Work package description (name, description, objectives)
- Functional requirements
- Dependencies
- Relationship to opportunity
- Relationship to Architecture Definition Document and Architecture Requirements Specification
- Relationship to any capability increments
- Business value
- Implementation Factor Assessment and Deduction Matrix — Impact
- Identification of Transition Architectures, if any, including: — Relationship to Architecture Definition Document
- Work package portfolio:
Phase E: Opportunities & Solutions
Outputs:
- Implementation recommendations:
- Criteria measures of effectiveness — Risks and issues — Solution Building Blocks (SBBs)
- Implementation and Migration Plan, Version 0.1, including: —
- Implementation and Migration Strategy The outputs may include some or all of the following:
- Diagrams: — Project Context diagram — Benefits diagram
The following four concepts are key to transitioning from developing to delivering a Target Architecture:
- Architecture Roadmap
- Work Packages
- Transition Architectures
- Implementation and Migration Plan
Phase F: Migration Planning
Phase F: Migration Planning addresses migration planning; that is, how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
Objectives:
- Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
- Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
- Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
Phase F: Migration Planning
Inputs:
- Request for Architecture Work
- Capability Assessment
- Communications Plan
- Organizational Model for Enterprise Architecture
- Governance models and frameworks
- Tailored Architecture Framework
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Draft Architecture Definition Document
- Draft Architecture Requirements Specification
- Change Requests for existing business programs and projects
- Architecture Roadmap, Version 0.1
- Capability Assessment
- Implementation and Migration Plan, Version 0.1
Phase F: Migration Planning
Steps:
- Confirm Management Framework Interactions for the Implementation and Migration Plan
- There are typically four management frameworks that have to work closely together for the Implementation and Migration Plan to succeed:
- Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes
- Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain
- Project/Portfolio Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes
- Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes
- There are typically four management frameworks that have to work closely together for the Implementation and Migration Plan to succeed:
Phase F: Migration Planning
Steps:
- Assign a Business Value to Each Work Package
- Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation
- Return-on-Investment Criteria have to be detailed and signed off by the various executive stakeholders
- Business Value has to be defined as well as techniques, such as the value chain, which are to be used to illustrate the role in achieving tangible business outcomes Business value will be used by portfolio and capability managers to allocate resources and, in cases where there are cutbacks, business value in conjunction with return on investment can be used to determine whether an endeavor proceeds, is delayed, or is canceled.
- Critical Success Factors (CSFs) should be established to define success for a project and/or project increment These will provide managers and implementers with a gauge as to what constitutes a successful implementation.
- Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs Where they are treated discretely, it should be clear as to how these criteria are to be grouped.
- Strategic Fit based upon the overall Enterprise Architecture (all tiers) will be the critical factor for allowing the approval of any new project or initiative and for determining the value of any deliverable
Phase F: Migration Planning
Steps:
- Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
- Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
- Confirm Architecture Roadmap and Update Architecture Definition Document
- Complete the Implementation and Migration Plan
- Complete the Architecture Development Cycle and Document Lessons Learned
Outputs:
- Implementation and Migration Plan, Version 1.0
- Finalized Architecture Definition Document
- Finalized Architecture Requirements Specification
- Finalized Architecture Roadmap
- Re-Usable Architecture Building Blocks
- Requests for Architecture Work for a new iteration of the ADM cycle (if any)
- Implementation Governance Model (if any)
- Change Requests for the Architecture Capability arising from lessons learned
Phase G: Implementation Governance
Phase G: Implementation Governance provides an architectural oversight of the implementation.
Objectives:
- Ensure conformance with the Target Architecture by implementation projects
- Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
Inputs:
- Request for Architecture Work
- Capability Assessment
- Organizational Model for Enterprise Architecture
- Statement of Architectural Work
- Tailored Architecture Framework
- Statement of Architecture Work
- Architecture Vision
- Architecture Repository
- Architecture Definition Document
- Architecture Requirements Specification
- Architecture Roadmap
- Implementation Governance Model
- Architecture Contract (standard)
- Request for Architecture Work) identified during Phases E and F
- Implementation and Migration Plan
Phase G: Implementation Governance
Steps:
- Confirm Scope and Priorities for Deployment with Development Management
- Identify Deployment Resources and Skills
- Guide Development of Solutions Deployment
- Perform Enterprise Architecture Compliance Reviews
- Implement Business and IT Operations
- Perform Post-Implementation Review and Close the Implementation
Outputs:
- Architecture Contract (signed)
- Compliance Assessments
- Change Requests
- Architecture-compliant solutions deployed
- The architecture-compliant implemented system
- Populated Architecture Repository
- Architecture compliance recommendations and dispensations
- Recommendations on service delivery requirements
- Recommendations on performance metrics
- Service-Level Agreements (SLAs)
- Architecture Vision, updated post-implementation
- Architecture Definition Document, updated post-implementation
- Business and IT operating models for the implemented solution
Phase G: Implementation Governance
Phase H: Architecture Change Management looks at establishing procedures for managing change to the new architecture.
Objectives:
- Ensure that the architecture lifecycle is maintained
- Ensure that the Architecture Governance Framework is executed
- Ensure that the Enterprise Architecture Capability meets current requirements
Inputs:
Change Request — Technology changes: — New technology reports— Asset management cost reduction initiatives— Technology withdrawal reports— Standards initiatives
Change Request — business changes: — Business developments — Business exceptions — Business innovations — Business technology innovations — Strategic change developments
Change Request — from lessons learned
Phase G: Implementation Governance
Steps:
- Establish Value Realization Process
- Deploy Monitoring Tools
- Manage Risks
- Provide Analysis for Architecture Change Management
- Develop Change Requirements to Meet Performance Targets
- Manage Governance Process
- Activate the Process to Implement Change
Outputs:
- Architecture updates (for maintenance changes)
- Changes to architecture framework and principles (for maintenance changes)
- New Request for Architecture Work to move to another cycle (for major changes)
- Statement of Architecture Work , updated if necessary
- Architecture Contract,updated if necessary
- Compliance Assessments, updated if necessary
Phase G: Implementation Governance
The approach is based on classifying required architectural changes into one of three categories:
- Simplification change:asimplification change can normally be handled via change management techniques
- Incremental change: an incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change
- Re-architecting change:are-architecting change requires putting the whole architecture through the architecture development cycle again
To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:
- Registration of all events that may impact the architecture
- Resource allocation and management for architecture tasks
- The process or role responsible for architecture resources has to make assessment of what should be done
- Evaluation of impacts
ADM Architecture Requirements Management
ADM Architecture Requirements Management looks at the process of managing architecture requirements throughout the ADM.
Objectives:
- Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
- Manage architecture requirements identified during any execution of the ADM cycle or a phase
- Ensure that relevant architecture requirements are available for use by each phase as the phase is executed
ADM Architecture Requirements Management
Inputs:
- A populated Architecture Repository
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework
- Statement of Architecture Work
- Architecture Vision
- Architecture requirements, populating an Architecture Requirements Specification
- Requirements Impact Assessment
ADM Architecture Requirements Management
Steps:
- Identify/document requirements — use business scenarios, or an analogous technique
- Requirements Impact Statement
Outputs:
The outputs of the Requirements Management process may include, but are not restricted to:
- Requirements Impact Assessment
- Updated Architecture Requirements Specification
ADM Architecture Requirements Management
Requirements Development
The first high-level requirements are articulated as part of the Architecture Vision, generated by means of the business scenario or analogous technique.
In each relevant phase of the ADM the architect should identify types of requirement that must be met by the architecture, including applicable:
- Functional requirements
- Non-functional requirements
When defining requirements the architect should take into account:
- Assumptions for requirements
- Constraints for requirements
- Domain-specific principles that drive requirements
- Policies affecting requirements
- Standards that requirements must meet
- Organization guidelines for requirements
- Specifications for requirements
