TOGAF 9.2 (I/O, Artifacts, Approach)

TOGAF 9.2Enterprise Architecture

Get Started. It's Free
or sign up with your email address
TOGAF 9.2 (I/O, Artifacts, Approach) by Mind Map: TOGAF 9.2 (I/O, Artifacts, Approach)

1. ADM Input/Output & Steps

1.1. 0 : Preliminary

1.1.1. Inputs

1.1.1.1. External Reference Materials

1.1.1.2. Non-Architectural Inputs

1.1.1.2.1. Request for Architectural Work

1.1.1.2.2. Capability Assessment

1.1.1.2.3. Communications Plan

1.1.1.3. Architectural Inputs

1.1.1.3.1. Everything up until now?

1.1.2. Outputs

1.1.2.1. Organizational Model For EA

1.1.2.2. Tailored Architecture Framework

1.1.2.3. Initial Architecture Repository

1.1.3. Steps

1.1.3.1. Define enterprise

1.1.3.1.1. Find out who benefits

1.1.3.1.2. Appoint sponsor

1.1.3.1.3. Have support from business management

1.1.3.2. Organisational Context

1.1.3.2.1. Architecture budget plan (if not exist)

1.1.3.2.2. Consider existing stakeholders

1.1.3.2.3. Business drivers, goals, principles, strategies

1.1.3.2.4. Examine current management frameworks processes

1.1.3.2.5. Consider the baseline architecture

1.1.3.2.6. Consider the skills and capabilities of the enterprise

1.1.3.2.7. This will help with tailoring the architecture scope (level of strictness, sophistication, cost etc.)

1.1.3.3. Requirements for architecture work

1.1.3.3.1. Helps identify the key decision makers and stakeholders by

1.1.3.3.2. Checking business requirements

1.1.3.3.3. Cultural aspirations

1.1.3.3.4. Organizational intents

1.1.3.3.5. Strategic intent

1.1.3.3.6. Forecast financial requirements

1.1.3.4. Principles

1.1.3.4.1. Define architecture princiles, which often re-state other enterprise guidelines/principles, only in an architecture context

1.1.3.4.2. Principles = long lasting rules and guidelines (Name, Statement, Rationale, Implications)

1.1.3.5. Management Frameworks

1.1.3.5.1. TOGAF cooperates with other framework types like:

1.1.3.5.2. Business Capability Management

1.1.3.5.3. Portefolio\project management methods

1.1.3.5.4. Operations management methods

1.1.3.5.5. Solution development methods

1.2. A: Architecture Vision

1.2.1. Inputs

1.2.1.1. Request for Architecture Work

1.2.1.2. Business: strategy, goals, drivers

1.2.1.3. Architecture principles

1.2.1.4. Enterprise Continuum

1.2.2. Outputs

1.2.2.1. Approved Statement of Architecture Work

1.2.2.2. Refined statement of business goals and drivers

1.2.2.3. Architecture principles (including business principles)

1.2.2.4. Architecture Vision

1.2.3. Steps

1.2.3.1. Establish the architect project by securing support and commitment

1.2.3.2. Identify/refresh business goals and drivers

1.2.3.3. Review Architecture Principles, including Business Principles

1.2.3.4. Define scope of architecture effort

1.2.3.4.1. Breath of the effort

1.2.3.4.2. Level of detail

1.2.3.4.3. Architecture domains to be covered (Business, Data, Application, Technology)

1.2.3.4.4. Time horizon

1.2.3.4.5. Assets to use (e.g. from Enterprise Continuum or other framework/models etc)

1.2.3.5. Define constraints that must be dealt with (time, schedule, resources etc.)

1.2.3.6. Get the key Stakeholders concerns/objectives

1.2.3.7. Make the high level version of the Architecture Vision and Business Requrements

1.2.3.8. Develop Statement of Architecture Work, and secure a formal approval of it

1.3. B C D: Business/Information Systems/Technology Architecture

1.3.1. Inputs

1.3.1.1. Reference materials external to the enterprise

1.3.1.2. Non-Architectural inputs (Request for Architectural Work, Capability Assesment, Communications Plan)

1.3.1.3. Architectural inputs

1.3.1.3.1. Organization model for Enterprise Architecture

1.3.1.3.2. Tailored Architecture Framework

1.3.1.3.3. Application Principles

1.3.1.3.4. Data Principles

1.3.1.3.5. Statement of Architecture Work

1.3.1.3.6. Architecture Vision

1.3.1.3.7. Architecture Repository

1.3.1.3.8. Draft Architecture Definition Document

1.3.1.3.9. Draft Architecture Requirements Specification

1.3.1.3.10. Architecture Roadmap (the Business Architecture parts)

1.3.2. Outputs

1.3.2.1. Catalogs, Matrices, Diagrams:

1.3.2.2. Updated Architecture Vision deliverables (Statement of Architecture Work, Business Principles/Goals/Drivers)

1.3.2.3. The Business Architecture part of the Architecture Roadmap (timeline overview of the releases that gets us to the Target Architecture)

1.3.2.4. Draft of Architecture Requirements (GAP Analysis results, Technical Requirements specs, updated Business Requirements)

1.3.2.5. Draft of Architecture Definition Document (Scope, Goals/objectives/drivers, Baseline Business Architecture, Target Business Architecture, Rationale of approach, mappings to the Architectural Repository, GAP-analysis, impact assesment, transition architecture)

1.3.3. Steps

1.3.3.1. Select Reference Models, Viewpoints and Tools, from the Architecture Repository, to focus on (that are relevant, at the right detail and that gets the info needed)

1.3.3.2. Update (or develop) Baseline Business Architecture Description

1.3.3.3. Develop Target Business/InfoSys/Data Architecture Description (that supports the Vision). Identify relevant building blocks

1.3.3.4. Perform GAP analysis (business domain & data domain, applications impacted, technologies impacted)

1.3.3.5. Define Candidate Roadmap Components

1.3.3.6. Resolve impacts across the Architectural Landscape (what are the impacts on pre-existing architecture or other projects)

1.3.3.7. Conduct formal Stakeholder Review (confirm the plan looks OK)

1.3.3.8. Finalize the Business/InfoSys/Data Architecture (create building blocks, check overall architecture against goals, document and finalize stuff)

1.3.3.9. Create Architecture Definition Document (see Outputs)

1.4. E: Opportuneties and Solutions

1.4.1. Inputs

1.4.1.1. Reference Materials external to the Enterprise

1.4.1.2. Non-Architectural Inputs

1.4.1.2.1. Request for Architectural Work

1.4.1.2.2. Capability Assessment

1.4.1.2.3. Communications Plan

1.4.1.2.4. Planning methodologies

1.4.1.3. Architectural Inputs

1.4.1.3.1. Everything up until now?

1.4.2. Outputs

1.4.2.1. Updated Architecture Vision phase deliverables (Architecture Vision, Statement of Architecture Work)

1.4.2.2. Draft of Architecture Definition Document (Scope, Goals/objectives/drivers, Baseline Business Architecture, Target Business Architecture, Rationale of approach, mappings to the Architectural Repository, GAP-analysis, impact assesment, transition architecture)

1.4.2.3. Draft of Architecture Requirements (Consolidated Gaps, Solution and Dependencies Assessment)

1.4.2.4. Capability Assessment (Business/IT)

1.4.2.5. Archictecture Roadmap (Work package portifolio, Transitional Architectures if any, Implementation recommendations)

1.4.2.6. Implementation and Migration Plan

1.4.2.7. Benefits- and Project Context diagrams

1.4.3. Steps

1.4.3.1. Determine/Confirm Key Corporate Change Attributes (determine culture and skill for change)

1.4.3.2. Determine Business Contraints for Implementation

1.4.3.3. Review and consolidate (group) Gap Analysis results from phase B/C/D

1.4.3.4. Review Consolidated Requirements across related Business Functions (find what functionality can be bundled together to get the most bang of the buck)

1.4.3.5. Consolidate and reconsile Interoperability Requirements (make sure shared stuff is actually shared, not duplicated)

1.4.3.6. Refine and validate dependencies (find what can be delivered together)

1.4.3.7. Confirm Readiness and Risk for Business Transformation (review the Business Readiness Assessment from A)

1.4.3.8. Formulate implementation and Migration Strategy (Choose type: new/radical change/evolve, choose method: quick win, archievable targets, value chain)

1.4.3.9. Identify and group major Work Packages

1.4.3.9.1. Logically group activities into Work Packages

1.4.3.9.2. Decide on packages can be solved by existing solutions or make/buy new ones

1.4.3.9.3. Group Work Packages into Portifolios (containing Projects)

1.4.3.10. Identify Transition Architectures (if neccessary), take the "most value for effort" ones first

1.4.3.11. Create the Architecture Roadmap & Implementation and Migration Plan

1.4.3.11.1. Put the Work Packages (and optionally the Transitional Architecture) into the Architecture Roadmap

1.4.3.11.2. Add the required activities into the Implementation and Migration Plan (the plan matches the roadmap)

1.5. F: Migration Planning

1.5.1. Inputs

1.5.1.1. Reference Materials external to the Enterprise

1.5.1.2. Non-Architectural Inputs

1.5.1.2.1. Request for Architectural Work

1.5.1.2.2. Capability Assessment

1.5.1.2.3. Communications Plan

1.5.1.3. Architectural Inputs

1.5.1.3.1. Everything up until now?

1.5.2. Outputs

1.5.2.1. Implementation and Migration Plan (Strategy, Project and portifolio, project charters)

1.5.2.2. Finalized Architecture Definition Document

1.5.2.3. Finalized Architecture Requirements Specification

1.5.2.4. Finalized Architecture Roadmap

1.5.2.5. Re-Usable Architecture Building Blocls

1.5.2.6. Request for Architecture Work (for new ADM iteration if required)

1.5.2.7. Implementational Gouvernance Model (if any)

1.5.2.8. Change Request for Architecture Capability arising from lessons learned

1.5.3. Steps

1.5.3.1. Confirm Management Framework Interactions for the Implementation and Migration Plan (coordinate the plan with the Management Frameworks that are in use)

1.5.3.2. Assign a Business Value to each Work Package (performance, return-on-investment, business value, critical success factors, measure of effectiveness. strategic fit, risk)

1.5.3.3. Estimate Resource Requirements, Project Timings and Availability/Delivery Vehicle (initial resource, time and cost estimate)

1.5.3.4. Prioritize the Migration Projects by Cost/Benefit Assessment and Risk Validation

1.5.3.5. Confirm Architecture Roadmap and update Architecture Defintion Document (if changed)

1.5.3.6. Generate the Implementation and Migration Plan (gather all projects and activities into plan)

1.5.3.7. Complete the Architecture Development Cycle (and check if need a new ADM cycle) and document the Lessons Learned

1.6. G: Implementation Governance

1.6.1. Inputs

1.6.1.1. Reference Materials external to the Enterprise

1.6.1.2. Non-Architectural Inputs

1.6.1.2.1. Request for Architectural Work

1.6.1.2.2. Capability Assessment

1.6.1.3. Architectural Inputs

1.6.1.3.1. Everything up until now?

1.6.2. Outputs

1.6.2.1. Architecture Contract

1.6.2.2. Compliance Assessents

1.6.2.3. Change Requests

1.6.2.4. Deployed Architecture-compliant solutions (Architecture repository, architecture compliance recommendations and dispensations, SLAs, updated Architcecture Vision etc.)

1.6.3. Steps

1.6.3.1. Confim Scope and Priorities for Deployment with Development Manager

1.6.3.1.1. Create deployment recommendations and prioritize

1.6.3.1.2. Find issues and make recommendations

1.6.3.1.3. Identify building blocks for replacement/updated/etc

1.6.3.1.4. Perform GAP anaysis on difference between EA and solutions

1.6.3.2. Identify Development Resources and Skills

1.6.3.2.1. Educate developers in overall Enterprise Architecture

1.6.3.2.2. Ensure development method enables feedback to the architecture team

1.6.3.3. Guide development of Solutions Deployment

1.6.3.3.1. Formulate project recommendation

1.6.3.3.2. Document Architecture Contract (get it signed)

1.6.3.3.3. Update Enterprise Continuum

1.6.3.3.4. Guide development of operational requirements

1.6.3.3.5. Carry out GAP analysis between operations and solution architecture

1.6.3.3.6. Produce Implementation Plan

1.6.3.4. Perform Enterprise Architecture Compliance Reviews

1.6.3.4.1. Review all building blocks for Implementation and Complience

1.6.3.4.2. Conduct post-development reviews

1.6.3.4.3. Close the development part of deployment projects

1.6.3.5. Implement Business and IT Operations

1.6.3.5.1. Publish new baseline architecture to the Architecture Repository

1.6.3.6. Perform Post-implementation Review and close the implementation

1.6.3.6.1. Perform post-implementation review

1.6.3.6.2. Publish the reviews and close the projects

1.7. H: Architecture Change Management

1.7.1. Inputs

1.7.1.1. Reference Materials external to the Enterprise

1.7.1.2. Non-Architectural Inputs

1.7.1.2.1. Request for Architectural Work

1.7.1.2.2. Capability Assessment

1.7.1.3. Architectural Inputs

1.7.1.3.1. Everything up until now?

1.7.2. Outputs

1.7.2.1. Architecture updates (for maintenance changes)

1.7.2.2. Changes to architecture framework and principles (for maintenance changes)

1.7.2.3. New Request for Architecture Work (for major changes)

1.7.2.4. Update if necessary; Statement of Architecture Work, Architecture Contract, Compliance Assessments

1.7.3. Steps

1.7.3.1. Establish Value Realization Process

1.7.3.1.1. Make a process that influences projects to use the Enterprise Architecture

1.7.3.2. Deploy Monitoring Tools

1.7.3.2.1. Tools that can detect technology changes, business changes, changes in business objectives

1.7.3.2.2. Tools that can monitor enterprise Architecture Capability maturity

1.7.3.2.3. Tools that track the usages and QoS

1.7.3.3. Manage (EA) Risks by providing recommendations for IT-Strategy

1.7.3.4. Provide Analysis for Architecture Change Management

1.7.3.4.1. Analyse performance

1.7.3.4.2. Do EA performance reviews

1.7.3.4.3. Check change requests (and reports) to check that the SLA's are met

1.7.3.4.4. GAP analyse the performance of the EA

1.7.3.4.5. Make sure the change requests follow the EA gouvernance and framework

1.7.3.5. Develop Change Requirements to meet Performance Targets

1.7.3.5.1. Make recommendations on change requirements

1.7.3.6. Manage Gouvernance Process

1.7.3.6.1. Arrange and hold meeting of Architecture Board

1.7.3.7. Activate the process to implement change

1.7.3.7.1. Produce new Request for Architecture Work and Request for Investment

1.7.3.7.2. Make sure all changes are documented in the Architecture Repository

2. ADM Objectives, Approach & Process

2.1. Preliminary

2.1.1. Objectives

2.1.1.1. Dtermine required EA capability

2.1.1.1.1. Org context- Why we do? Key business drivers

2.1.1.1.2. EA scope- where is change needed

2.1.1.1.3. Existing frameworks/methods relevant to Arch capability

2.1.1.1.4. EA maturity (current and target)

2.1.1.2. Set up EA capability

2.1.1.2.1. EA organization model

2.1.1.2.2. EA Goverannce framework

2.1.1.2.3. Define EA principles

2.1.1.2.4. Implement EA tool

2.1.2. Approach

2.1.2.1. Enterprise scope

2.1.2.2. Drivers and context

2.1.2.2.1. Commercial models for EA

2.1.2.2.2. Stakeholders issues and concerns

2.1.2.2.3. Business drivers, goals and imperatives

2.1.2.2.4. Current processes for change and ops

2.1.2.2.5. Baseline architecture landscape

2.1.2.2.6. Current skills and capabilities

2.1.2.3. EA requirements

2.1.2.3.1. Business reqs

2.1.2.3.2. Strategic

2.1.2.3.3. Organization

2.1.2.3.4. Cultural

2.1.2.3.5. financial

2.1.2.4. EA principles

2.1.2.5. EA and Other mgmt framewroks

2.1.2.5.1. Business capability mgmt

2.1.2.5.2. Project/portfolio mgmt

2.1.2.5.3. Ops mgmt

2.1.2.5.4. Solution devp

2.1.2.6. EA maturity

2.1.3. steps

2.1.3.1. identify/ agree scope

2.1.3.1.1. Governance /support framework

2.2. A Architecture vision

2.2.1. Objectives

2.2.1.1. vision (of capability needed)

2.2.1.2. EA SOW/ program

2.2.2. Approach

2.2.2.1. Initial Validation

2.2.2.1.1. Scope

2.2.2.1.2. Constraints

2.2.2.1.3. Principles

2.2.2.2. EA vision

2.2.2.2.1. Stakeholders: concerns, interest, work products

2.2.2.2.2. Vision elements -goals, objective linakge

2.2.2.2.3. Fundamenal (High level)Reuirements : (Goal linkage)

2.2.2.2.4. High level Baseline/target architecture: Solution- the vision ..

2.2.2.2.5. EA work plan, resources, budget, risks

2.2.3. Steps

2.2.3.1. Architecture Project

2.2.3.1.1. stakeholder & Requirements

2.3. B. Business architecture

2.3.1. Objectives

2.3.1.1. Target BA/ Operating model

2.3.1.2. Candidate roadmap components, sbb, abb?

2.3.2. Approach

2.3.2.1. (arch vision) to specific requirement

2.3.2.2. Base line BA

2.3.2.2.1. Previous Architecture definitions

2.3.2.2.2. Bottom up analyssi

2.3.2.3. Business modeling

2.3.2.3.1. Terms, Organization, Functions, Business process, Information

2.3.2.3.2. Existing Business models in repository

2.3.2.3.3. Goal linkage, priority, candidate components (Target BA)

2.3.3. Steps

2.3.3.1. reference models, views, tools

2.3.3.1.1. Views

2.3.3.1.2. Baseline

2.4. C. Information systems

2.4.1. Data

2.4.1.1. Objectives

2.4.1.1.1. Target Data architecture

2.4.1.1.2. Candidate data components in Architecture roadmap

2.4.1.2. Approach

2.4.1.2.1. Key data considerations

2.4.1.2.2. Architecture (Data) repository

2.4.1.3. Data modeling process

2.4.1.3.1. data related models from Business and app domains

2.4.2. Applications

2.4.2.1. Objectives

2.4.2.1.1. Target App archtiecture

2.4.2.1.2. Candidate App components in roadmap

2.4.2.2. Approach

2.4.2.2.1. Repository

2.4.2.3. Process

2.4.2.3.1. Requirements

2.5. D. technology architecture

2.5.1. Objectives

2.5.1.1. Target Technology architecture

2.5.1.2. Candidate technology components for roadmap

2.5.2. Approach

2.5.2.1. Repository

2.5.2.1.1. Existing IT services?

2.5.2.1.2. Foundation refeerence - Togaf TRM

2.5.2.1.3. Industry specific refrence technology models

2.5.2.1.4. Common Systems reference - III-RM

2.5.3. Process

2.5.3.1. Set up

2.5.3.1.1. Principles

2.5.3.1.2. Reference models

2.5.3.1.3. Viewpoints and views

2.5.3.1.4. Tools and techniques

2.5.3.1.5. Biz Architecture Document

2.6. E. Opportunity/solutions

2.6.1. Objectives

2.6.1.1. Initial Architecture roadmap

2.6.1.2. Transition architectures (for incremental value)

2.6.2. Approach

2.6.2.1. Gaps to Work packages

2.6.2.2. Architecture Roadmap

2.6.2.3. Transition architectures

2.6.2.4. Initial implementation/migration plan

2.6.3. Steps

2.6.3.1. Change factors

2.6.3.1.1. Implementation factor and deduction matrix

2.6.3.2. Implementation constraints

2.6.3.3. Consolidated gaps

2.6.3.3.1. Gaps, solutions and dependency matrix

2.6.3.4. Consolidated requirements

2.6.3.5. Interoperability requirements

2.6.3.5.1. New BB to intermediate btw conflicting BBs

2.6.3.5.2. Change to spec of one of existing BB )

2.6.3.6. Validate dependencies

2.6.3.7. Business readiness and mitigate risks

2.6.3.8. Implementation/migration strategy

2.6.3.9. Work packages

2.6.3.10. Transition archtiectures

2.6.3.10.1. Architecture definition increment table

2.6.3.11. Roadmap and initial migration plan

2.7. F, Migration planning

2.7.1. Objectives

2.7.1.1. Finalize roadmap and migration plan

2.7.1.2. migration plan is coordiated with existing change frameworks and portfolio

2.7.1.3. Business value and cost of implementation is agreed/understood by stakeholders

2.7.2. Steps

2.7.2.1. Integration with other mgmt frameworks

2.7.2.1.1. Buisness planning

2.7.2.1.2. EA - initial migration plan

2.7.2.1.3. Portfolio/project mgmt

2.7.2.1.4. Ops mgmt

2.7.2.2. Business value for each work package

2.7.2.2.1. Performance criteria/ Measures for effectiveness

2.7.2.2.2. ROI criteria

2.7.2.2.3. Strategic fit/ assign Value

2.7.2.2.4. Critical factors for success

2.7.2.3. Projects

2.7.2.3.1. Identify projects/

2.7.2.3.2. Project resourcing, Costing, Timelinrd

2.7.2.3.3. Project cost-benfefit and priority

2.7.2.3.4. Review residual risks

2.7.2.4. Finalzie Dev cycle

2.7.2.4.1. Confirm roadmap

2.7.2.4.2. Confirm migraion plan

2.7.2.4.3. Complete ADM cycle

2.7.2.4.4. Finalied ADD, ARS

2.7.2.4.5. Lessons learned

2.8. G. Implementation governance

2.8.1. Objectives

2.8.1.1. Conformance of implementation (projects) to Target architectures

2.8.1.2. Arch governance for solution

2.8.1.3. Implenetation driven arch change rquests

2.8.2. Approach

2.8.2.1. Implementation program to deliver transition architectures

2.8.2.2. Phased deployment schedule as per business priority in Roadmap

2.8.2.3. Follow standards for Corp>IT>Arch governance

2.8.2.4. Use existing program-project mgmt.

2.8.2.5. Use Operations framework for deployed solution

2.8.3. Steps

2.8.3.1. Confirm scope/priority with Dev

2.8.3.1.1. Gaps between EA and solutioons framework

2.8.3.1.2. Specific SBBs to fill gaps- Solution architects

2.8.3.2. Deployment resource and skills

2.8.3.3. Guide solutions devp

2.8.3.3.1. Project recommendation and scope

2.8.3.3.2. Impact analysis/Project

2.8.3.3.3. Arch contract

2.8.3.3.4. Update solution repository

2.8.3.3.5. Business and IT operating models for services (i.e. being implemented)- guidance and requirements

2.8.3.3.6. Definition of business and IT ops requiremnts

2.8.3.3.7. Gaps between solution architecture and Operations

2.8.3.3.8. Implementation plan

2.8.3.4. EA Compliance reviews

2.8.3.5. Implement Business and IT Ops

2.8.3.5.1. Business service delivery

2.8.3.5.2. IT Service delivery - App deployment

2.8.3.5.3. Skills dev & training

2.8.3.5.4. Communications

2.8.3.5.5. New baseline architectures in Architecture repository

2.8.3.5.6. Impacted repositories - Ops config mgmt. stores

2.8.3.6. Post implementation review

2.8.3.7. Monitor risks and mitigation actions

2.8.3.7.1. Risks identification and mitigation assessment worksheets - maintained as governance artefacts

2.8.3.7.2. Identify risks in implementation - may lead to new ADM cycle

2.9. Architecture requirements mgmg

2.9.1. Objectives

2.9.1.1. RM process

2.9.1.2. Manage architecture reqs

2.9.1.3. Available for use

2.9.2. Approach

2.9.2.1. Requirement repository

2.9.2.2. Reuirement development

2.9.2.2.1. Architecture req spec

2.9.2.2.2. Mapping deliverables to reqs

2.9.2.3. Business scenarios

2.10. H. Architecture change mgmt

2.10.1. Objectives

2.10.1.1. Architecture lifecycle is maintained

2.10.1.2. Architecture governance framework is executed

2.10.1.3. EA capability meets requirements

2.10.2. Approach

2.10.2.1. Monitor

2.10.2.1.1. Governance request

2.10.2.1.2. Business envi

2.10.2.1.3. Tech env (Dynamic EA)

2.10.2.1.4. Perofmrance mgmt. and reporting

2.10.2.2. Drivers for change (CRs)

2.10.2.2.1. Strategic- Top down

2.10.2.2.2. Bottom-up changees

2.10.2.2.3. Recent project experience- Lessons learned

2.10.2.3. Determine

2.10.2.3.1. Types of change

2.10.2.3.2. Whether approve RFC or resolve issue within project (w.r.t transition arch)

2.10.2.3.3. Maintain: Update of EA

2.10.2.3.4. Redesign: New ADM cycle

2.10.2.3.5. Architecture compliance report

2.10.3. Steps

2.10.3.1. Value realization

2.10.3.2. Monitoring tools

2.10.3.3. Manage EA risks and IT strategy recommendations

2.10.3.4. Change analyssi

2.10.3.4.1. Existing EA Performance

2.10.3.4.2. Assess CRs

2.10.3.4.3. Gaps in EA performance

2.10.3.5. Change Reqs to meet performance targets

2.10.3.6. Manage governance for change (handling)- change mgmt. process

2.10.3.7. Activate to implement change

3. Artifacts

3.1. 0: Preliminary

3.1.1. Principles Catalog

3.2. A: Architecture Vision

3.2.1. Stakeholder Map Matrix

3.2.2. Value Chain Diagram

3.2.3. Solution Concept Diagram

3.3. B: Business Architecture

3.3.1. Organization/Actor Catalog

3.3.2. Driver/Goal/Objective Catalog

3.3.3. Role Catalog

3.3.4. Business Service/Function Catalog

3.3.5. Location Catalog

3.3.6. Process/Event/Control/Product Catalog

3.3.7. Contract/Measure Catalog

3.3.8. Business Interaction Matrix

3.3.9. Actor/Role Matrix

3.3.10. Business Footprint Diagram

3.3.11. Business Service/Information Diagram

3.3.12. Functional Decomposition Diagram

3.3.13. Product Lifecycle Diagram

3.3.14. Goal/Objective/Service Diagram

3.3.15. Business Use-Case Diagram

3.3.16. Organization Decomposition Diagram

3.3.17. Process Flow Diagram

3.3.18. Event Diagram

3.4. C: Information Systems Architecture

3.4.1. Data

3.4.1.1. Data Entity/Data Component Catalog

3.4.1.2. Data Entity/Business Function Matrix

3.4.1.3. Application/Data Matrix

3.4.1.4. Conceptual Data Diagram

3.4.1.5. Logical Data Diagram

3.4.1.6. Data Dissemination Diagram

3.4.1.7. Data Security Diagram

3.4.1.8. Data Migration Diagram

3.4.1.9. Data Lifecycle Diagram

3.4.2. Application

3.4.2.1. Application Portfolio Catalog

3.4.2.2. Interface Catalog

3.4.2.3. Application/Organization Matrix

3.4.2.4. Role/Application Matrix

3.4.2.5. Application/Function Matrix

3.4.2.6. Application Interaction Matrix

3.4.2.7. Application Communication Diagram

3.4.2.8. Application and User Location Diagram

3.4.2.9. Application Use-Case Diagram

3.4.2.10. Enterprise Manageability Diagram

3.4.2.11. Process/Application Realization Diagram

3.4.2.12. Software Engineering Diagram

3.4.2.13. Application Migration Diagram

3.4.2.14. Software Distribution Diagram

3.5. D: Technology Architecture

3.5.1. Technology Standards Catalog

3.5.2. Technology Portfolio Catalog

3.5.3. Application/Technology Matrix

3.5.4. Environments and Locations Diagram

3.5.5. Platform Decomposition Diagram

3.5.6. Processing Diagram

3.5.7. Networked Computing/Hardware Diagram

3.5.8. Communications Engineering Diagram

3.6. E: Opportunities and Solutions

3.6.1. Project Context Diagram

3.6.2. Benefits Diagram

4. Summary

4.1. Resources

4.1.1. ADM Steps Reference

4.1.2. Architectural Artifacts

4.1.3. TOGAF 9 certification preparation advices & exam tips

4.1.4. Togaf Modeling

4.2. Exams

4.2.1. Level 1

4.2.1.1. Exam 1

4.2.1.2. Questions and Answers

4.2.2. Level 2

4.3. TOGAF 9.2 brief

4.3.1. Move to Modular

4.3.1.1. Instead of the TOGAF Standard being a monolithic 650-page document,

4.3.1.2. the Open Group has moved to start breaking out parts of the standard into other documents.

4.3.1.3. Core specification document reduced to 500-pages. Supported by a set of TOGAF Series Guides.

4.3.1.4. For example, the TRM (technical reference model) is now defined in a series guide and not part of the core specification.

4.3.2. Why

4.3.2.1. Removing some things from the specification that maybe didn't belong there Optional things, examples Breaking the document up is easier to change Removing TRM (Technical Reference Model) and Ill-RM and putting them into their own document

4.3.3. ADM Vision and Business Phases

4.3.3.1. New artifacts added to both Phase A and Phase B of the ADM Cycle.

4.3.3.2. The Architecture Vision phase now contains more definition of the business model and business capability.

4.3.3.3. Recognition that the business goals are part of defining the vision for the project.

4.3.4. Content Metamodel

4.3.4.1. The TOGAF content metamodel has been expanded.

4.3.4.2. There are new entities on the diagram, revised entities, and new relationships between the entities.

4.3.4.3. Location is now a global entity.

4.3.5. Summary

4.3.5.1. fixing errors, minor cleanups, making it easier to make changes in the future

5. EA Operating Model