Get Started. It's Free
or sign up with your email address
Rocket clouds
Togaf ADM by Mind Map: Togaf ADM

1. G. Implementation governance

1.1. Objectives

1.1.1. Conformance of implementation (projects) to Target architectures

1.1.2. Arch governance for solution

1.1.3. Implenetation driven arch change rquests

1.2. Approach

1.2.1. Implementation program to deliver transition architectures

1.2.2. Phased deployment schedule as per business priority in Roadmap

1.2.3. Follow standards for Corp>IT>Arch governance

1.2.4. Use existing program-project mgmt.

1.2.5. Use Operations framework for deployed solution

1.3. Steps

1.3.1. Confirm scope/priority with Dev

1.3.1.1. Gaps between EA and solutioons framework

1.3.1.2. Specific SBBs to fill gaps- Solution architects

1.3.2. Deployment resource and skills

1.3.3. Guide solutions devp

1.3.3.1. Project recommendation and scope

1.3.3.2. Impact analysis/Project

1.3.3.2.1. Scope of

1.3.3.2.2. Strategic requirement from EA perspective

1.3.3.3. Arch contract

1.3.3.4. Update solution repository

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

1.3.3.6. Definition of business and IT ops requiremnts

1.3.3.7. Gaps between solution architecture and Operations

1.3.3.8. Implementation plan

1.3.4. EA Compliance reviews

1.3.5. Implement Business and IT Ops

1.3.5.1. Business service delivery

1.3.5.2. IT Service delivery - App deployment

1.3.5.3. Skills dev & training

1.3.5.4. Communications

1.3.5.5. New baseline architectures in Architecture repository

1.3.5.6. Impacted repositories - Ops config mgmt. stores

1.3.6. Post implementation review

1.3.7. Monitor risks and mitigation actions

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

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

2. Prelim

2.1. Objectives

2.1.1. Dtermine required EA capability

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

2.1.1.2. EA scope- where is change needed

2.1.1.3. Existing frameworks/methods relevant to Arch capability

2.1.1.4. EA maturity (current and target)

2.1.2. Set up EA capability

2.1.2.1. EA organization model

2.1.2.2. EA Goverannce framework

2.1.2.3. Define EA principles

2.1.2.3.1. Pricnicple catalog

2.1.2.4. Implement EA tool

2.2. Approach

2.2.1. Enterprise scope

2.2.2. Drivers and context

2.2.2.1. Commercial models for EA

2.2.2.2. Stakeholders issues and concerns

2.2.2.3. Business drivers, goals and imperatives

2.2.2.4. Current processes for change and ops

2.2.2.4.1. Arch description

2.2.2.4.2. Project mgmt /project portfolio methods

2.2.2.4.3. Systems mgmt methods/ sytems design and dev

2.2.2.4.4. App portfolio/Informtion portfolio/tech portfolio methods

2.2.2.5. Baseline architecture landscape

2.2.2.6. Current skills and capabilities

2.2.3. EA requirements

2.2.3.1. Business reqs

2.2.3.2. Strategic

2.2.3.3. Organization

2.2.3.4. Cultural

2.2.3.5. financial

2.2.4. EA principles

2.2.5. EA and Other mgmt framewroks

2.2.5.1. Business capability mgmt

2.2.5.2. Project/portfolio mgmt

2.2.5.3. Ops mgmt

2.2.5.4. Solution devp

2.2.6. EA maturity

2.3. steps

2.3.1. identify/ agree scope

2.3.1.1. Governance /support framewrk

2.3.1.1.1. EA team and organization

3. A Architecture vision

3.1. Objectives

3.1.1. vision (of capability needed)

3.1.2. EA SOW/ program

3.2. Approach

3.2.1. Initial Validation

3.2.1.1. Scope

3.2.1.2. Constraints

3.2.1.3. Principles

3.2.2. EA vision

3.2.2.1. Stakeholders: concerns, interest, work products

3.2.2.1.1. Stakeholder map

3.2.2.2. Vision elements -goals, objective linakge

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

3.2.2.3.1. Scenarios

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

3.2.2.4.1. Solution concept map

3.2.2.5. EA work plan, resources, budget, risks

3.3. Steps

3.3.1. Arch Project

3.3.1.1. stakeholder & Requirements

3.3.1.1.1. Confirm goals

4. B. Business architecture

4.1. Objectives

4.1.1. Target BA/ Operating model

4.1.2. Candidate roadmap components, sbb, abb?

4.2. Approach

4.2.1. (arch vision) to specific requirement

4.2.2. Base line BA

4.2.2.1. Previous Architecture definitions

4.2.2.2. Bottom up analyssi

4.2.3. Business modeling

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

4.2.3.2. Existing Business models in repository

4.2.3.2.1. Rosettanet- Semi conductor mfg- Supply chain ebusiness processes

4.2.3.2.2. STEP- Aerospace and construction- Product design and supply chain processes

4.2.3.2.3. REA ontology- accounting and e-commerce

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

4.3. Steps

4.3.1. reference models, views, tools

4.3.1.1. Views

4.3.1.1.1. Modelling process

4.3.1.2. Baseline BAD

4.3.1.2.1. Target BAD

5. C. Information systems

5.1. Data

5.1.1. Objectives

5.1.1.1. Target Data architecture

5.1.1.2. Candidate data components in Architecture roadmap

5.1.2. Approach

5.1.2.1. Key data considerations

5.1.2.1.1. Data mgmt

5.1.2.1.2. data migraton

5.1.2.1.3. Data governance

5.1.2.2. Architecture (Data) repository

5.1.2.2.1. ARTS data model for Retail

5.1.2.2.2. Energistics data model for Petro technical

5.1.2.2.3. TM Forum data model for Telecom

5.1.3. Data modeling process

5.1.3.1. data related models from Business and app domains

5.1.3.1.1. Data requrements - catalog of iventory

5.2. Applications

5.2.1. Objectives

5.2.1.1. Target App archtiecture

5.2.1.2. Candidate App components in roadmap

5.2.2. Approach

5.2.2.1. Repository

5.2.2.1.1. Industry specific reference

5.2.2.1.2. Org specific (app) building blocks

5.2.3. Process

5.2.3.1. Requirements

5.2.3.1.1. List of apps (compoenns)

6. D. technology architecture

6.1. Objectives

6.1.1. Target Technology architecture

6.1.2. Candidate technology components for roadmap

6.2. Approach

6.2.1. Repository

6.2.1.1. Existing IT services?

6.2.1.2. Foundation refeerence - Togaf TRM

6.2.1.3. Industry specific refrence technology models

6.2.1.4. Common Systems reference - III-RM

6.3. Process

6.3.1. Set up

6.3.1.1. Principles

6.3.1.2. Reference models

6.3.1.3. Viewpoints and views

6.3.1.4. Tools and techniques

6.3.1.5. BAD

6.3.1.5.1. TAD

7. E. Opportunity/solutions

7.1. Objectives

7.1.1. Initial Architecture roadmap

7.1.2. Transition architectures (for incremental value)

7.2. Approach

7.2.1. Gaps to Work packages

7.2.2. Architecture Roadmap

7.2.3. Transition architectures

7.2.4. Initial implementation/migration plan

7.3. Steps

7.3.1. Change factors

7.3.1.1. Implementation factor and deduction matrix

7.3.2. Implementation constraints

7.3.3. Consolidated gaps

7.3.3.1. Gaps, solutions and dependency matrix

7.3.4. Consolidated requirements

7.3.5. Interoperability requirements

7.3.5.1. New BB to intermediate btw conflicting BBs

7.3.5.2. Change to spec of one of existing BB )

7.3.6. Validate dependencies

7.3.7. Business readiness and mitigate risks

7.3.8. Implementation/migration strategy

7.3.9. Work packages

7.3.10. Transition archtiectures

7.3.10.1. Architecture definition increment table

7.3.11. Roadmap and initial migration plan

8. F, Migration planning

8.1. Objectives

8.1.1. Finalize roadmap and migration plan

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

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

8.2. Steps

8.2.1. Integration with other mgmt frameworks

8.2.1.1. Buisness planning

8.2.1.2. EA - initial migration plan

8.2.1.3. Portfolio/project mgmt

8.2.1.4. Ops mgmt

8.2.2. Business value for each work package

8.2.2.1. Performance criteria/ Measures for effectiveness

8.2.2.2. ROI criteria

8.2.2.3. Strategic fit/ assign Value

8.2.2.4. Critical factors for success

8.2.3. Projects

8.2.3.1. Identify projects/

8.2.3.1.1. Risks to projects

8.2.3.1.2. Busines value of projects

8.2.3.2. Project resourcing, Costing, Timelinrd

8.2.3.3. Project cost-benfefit and priority

8.2.3.4. Review residual risks

8.2.4. Finalzie Dev cycle

8.2.4.1. Confirm roadmap

8.2.4.1.1. Transition architecture state evolution table

8.2.4.1.2. Transitin architecture increment table

8.2.4.2. Confirm migraion plan

8.2.4.3. Complete ADM cycle

8.2.4.4. Finalied ADD, ARS

8.2.4.5. Lessons learned

9. H. Architecture change mgmt

9.1. Objectives

9.1.1. Architecture lifecycle is maintained

9.1.2. Architecture governance framework is executed

9.1.3. EA capability meets requirements

9.2. Approach

9.2.1. Monitor

9.2.1.1. Governance request

9.2.1.2. Business envi

9.2.1.2.1. Business growth and decline

9.2.1.2.2. Usage and capacity

9.2.1.2.3. Other drivers for CRs

9.2.1.3. Tech env (Dynamic EA)

9.2.1.3.1. Tech advances

9.2.1.3.2. Tech withdrawals

9.2.1.3.3. Asset mgmt. cost rerductions

9.2.1.3.4. Standards based initiatives

9.2.1.4. Perofmrance mgmt. and reporting

9.2.2. Drivers for change (CRs)

9.2.2.1. Strategic- Top down

9.2.2.2. Bottom-up changees

9.2.2.3. Recent project experience- Lessons learned

9.2.3. Determine

9.2.3.1. Types of change

9.2.3.1.1. Simplification change

9.2.3.1.2. Incrmental change

9.2.3.1.3. Rearchitecting change

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

9.2.3.3. Maintain: Update of EA

9.2.3.4. Redesign: New ADM cycle

9.2.3.5. Architecture compliance report

9.3. Steps

9.3.1. Value realization

9.3.2. Monitoring tools

9.3.3. Manage EA risks and IT strategy recommendations

9.3.4. Change analyssi

9.3.4.1. Existing EA Performance

9.3.4.2. Assess CRs

9.3.4.3. Gaps in EA performance

9.3.5. Change Reqs to meet performance targets

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

9.3.7. Activate to implement change

10. Architecture requirements mgmg

10.1. Objectives

10.1.1. RM process

10.1.2. Manage architecture reqs

10.1.3. Available for use

10.2. Approach

10.2.1. Requirement repository

10.2.2. Reuirement development

10.2.2.1. Architecture req spec

10.2.2.2. Mapping deliverables to reqs

10.2.3. Business scenarios