TOGAF Phases. Initiated by Request For A Work

Get Started. It's Free
or sign up with your email address
TOGAF Phases. Initiated by Request For A Work by Mind Map: TOGAF Phases. Initiated by Request For A Work

1. Preliminary Phase - To define the A principles, framework and methodologies to be used. Here occurs initial assessment of business transformation readiness. Selecting impl. tools. Not identify stakeholders. Establish Org Model for EA

1.1. Architecture Principles - Not detailed policies that prescribe behavior and requirements. Provides a foundation for making A and planning decisions, framing policies, procedures, standards and supporting resolutions of contradictory situations To guide decision making/ assets use within the enterprise. Recommended to use in developing A Vision

1.1.1. Qualities Understandable Robust Complete Consistent Stable

1.1.2. Components Name Statement Rationale - highlights the business benefits for adhering to the principle Implications - highlights requirements for carrying out the principle, ouputs

1.2. Business Imperatives - drives the requirements and performance metrics when scoping the enterprise A work, but not technical elegance

2. Phase A. Architecture Vision - high level description of the baseline and target A, high level view on target A. Goals: To secure formal approval to proceed. To articulate architecture vision.

2.1. Initiated by Request for A Work

2.2. A Vision document - a tool for selling the benefits of the proposed capability to stakeholders. Describes how new capability will address stakeholder concerns

2.3. Here first validated business principles, b goals and strategic drivers

2.4. Buss principles are most prominent here

2.5. Statement of Architecture Work - defines the scope and approach that will be used to complete an architecture development cycle

2.6. Business Scenarious - recommended to help identify and understand requirements. Define them and articulate the A Vision created in phase A

3. Phase B. Business Architecture. To demonstrate how stakeholder concerns are addressed in the Buss A. Provides prerequisite knowledge for undertaking work in the other a domains. Not to defining the strategic business plan.

3.1. Select reference models,viewpoints,and tools

3.2. Develop Baseline Business Architecture Description

3.2.1. If no 1/few architecture assets exists - use Bottom Up approach

3.3. Develop Target Business Architecture Description

3.4. Perform gap analysis

3.5. Define candidate roadmap components

3.6. Resolve impacts across the Architecture Landscape

3.7. Conduct formal stakeholder review

3.8. Finalizethe Business Architecture

3.9. Create Architecture Definition Document

4. Phase C. Information System Architecture. Most relevant model to use - III Ref Model. Not Objective: definig data entities that are normalized to minimize update anomalies

4.1. Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision

4.2. Identify candidate Architecture Roadmap

4.3. Develop Data A and Application A in either sequence

5. Phase D. Technology Architecture - to define tech components into a set of tech platforms

6. Phase E. Opportunities and solutions - Directly concerned with the planning for the implementation of the target a. Purpose - to define initial implementation plan

6.1. Implementation and Migration Plan - incorporated actions arising from Bus Trans Readin Assessment techbique

6.2. Architecture Contract - establishes connection between A organization and implementation organization. Agreement between dev partners and sponsors on the A deliverables

6.3. A Roadmap - to show change from baseline to target a

6.4. BB become impl specific

7. Phase F. Migration Planning - used to finalize a set of transition architecture that will support implementation

7.1. Implementation and Migration Plan coordinates with other framework

8. Pahse G. Implementation Governance - focuses on the governance and management of A contracts that cover the overall implementation and deployment process. Ensures that impl project conform to the defined A. Establishes connection between A org and impl org. Provides a oversight of the implementation

9. Requirements Management - Responsible for managing the flow of requirements. It's On-going activity, that visited throughout project. Store r and manages their flow into relevant ADM phases

9.1. Phase H. Architecture Change Management - Not includes: Business Scenarios. Ensures that A achieves its target

9.1.1. Simplification change. Example - multiple systems consolidated into 1. To reduce investments

9.1.2. Incremental change is driven by requirement to derive aditionsl value from the existing investment

9.1.3. Re-architecting change - to increase investment in order to create new value to exploitation