1
Q
ADM Overview
A
- 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.
2
Q
Version Numbering in ADM
A
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.
3
Q
Adapting the ADM
A
- 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
4
Q
Different approaches to planning and integration ADM;
A
- 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
5
Q
Architecture Governance
A
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.
6
Q
Scoping the Architecture
A
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
7
Q
Scoping the Architecture
A
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
8
Q
Scoping the Architecture
A
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
9
Q
Scoping the Architecture
A
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.
10
Q
Preliminary Phase
A
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
11
Q
Preliminary Phase
A
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
12
Q
Preliminary Phase
A
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
13
Q
Preliminary Phase
A
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
14
Q
Preliminary Phase
A
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.
15
Q
Phase A: Architecture Vision
A
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
16
Q
Phase A: Architecture Vision
A
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
17
Q
Phase A: Architecture Vision
A
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
18
Q
Phase A: Architecture Vision
A
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
19
Q
Phase A: Architecture Vision
A
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
20
Q
Phase B: Business Architecture
A
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
21
Q
Phase B: Business Architecture
A
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
22
Q
Phase B: Business Architecture
A
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 )
23
Q
Phase B: Business Architecture
A
- 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
24
Q
Phase B: Business Architecture
A
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
25
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
26
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_**
27
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)?
28
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**
29
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
30
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 va**lue 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
31
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
32
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
33
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
34
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
* 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
35
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
36
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
37
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.
38
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
39
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
40
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
* 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
* Identify Required Matrices
41
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
42
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
43
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
44
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
45
Phase D: Technology Architecture
**_Technology Architecture:_**
**_Steps:_**
* Select Reference Models, Viewpoints, and Tools
* Examples of data modeling techniques are:
* Entity-relationship diagram
* Class diagram
* 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
46
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
* 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
47
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
48
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 ov**erall solution building blocks to finalize the Target Architecture** based on the Architecture Building Blocks (ABBs)
49
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**
50
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
51
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
* Identify Transition Architectures
* Create the Architecture Roadmap & Implementation and Migration Plan
52
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
53
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
54
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
55
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
56
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
57
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
58
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
59
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
60
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
61
Phase G: Implementation Governance
Phase H: Architecture Change Management looks at establishing procedures for managing change to the new architecture.
**_Objectives:_**
* E**nsure 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**
62
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
63
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:
1. Registration of all events that may impact the architecture
2. Resource allocation and management for architecture tasks
3. The process or role responsible for architecture resources has to make assessment of what should be done
4. Evaluation of impacts
64
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
65
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
66
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
67
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
TOGAF-2022
flashcards
Decks in class (4)
# Cards
