TOGAF - Must be adapted to satisfy organization specific requirements. Not treat the establishmen...

Get Started. It's Free
or sign up with your email address
Rocket clouds
TOGAF - Must be adapted to satisfy organization specific requirements. Not treat the establishment as a one-off project. Process model, best practices and assets to aid production, use and maintenance of EA by Mind Map: TOGAF - Must be adapted to satisfy organization specific requirements. Not treat the establishment as a one-off project. Process model, best practices and assets to aid production, use and maintenance of EA

1. Part VII (Architecture Capability Framework) - describes processes, skills and roles to establish and operate an architecture function within an enterprise

1.1. Establishing an Architecture Capability. Before implement - use ADM

1.2. Architecture Board. Not approves strategic business plans. Not allocates resources for a projects. Not preparing A review report Accepts and singoff A Compliance review. Enforces a compliance

1.3. Architecture Compliance

1.3.1. Architecture Compliance Review - to review a project against established A criteria and business objectives. To identify errors. To communicate technical readiness of the project. NOT to identify business transformation risks for an A project

1.3.1.1. After it - tailor the checklist to address business requirements

1.4. Architecture Contracts

1.5. Architecture Governance - manages enterprise and other a. Ensures the compliance of individual projects to the enterprise a. A practice by which enterprise a are controlled at an enterprise-wide level

1.5.1. Architecture Governance Framework (Image - Conceptual Structure)

1.6. Architecture Maturity Models

1.7. Architecture Skills Framework

2. Part VI (TOGAF Reference Models)

2.1. Technical Reference Model - includes a set of graphical models and a corresponding taxonomy. Is a example and should be tailored to the needs of an organization. Is a fundamental a upon which more specific a can be based

2.2. Integrated Information Infrastructure Reference Model - example of Application A ref. model

3. Part V (Enterprise Continuum and Tools)

3.1. Enterprise Continuum - describes classification methods for A and solution artifacts within enterprise; view of the A repository; used to structure reusable A and solution assets; aids communication and understanding between architects

3.1.1. Enterprise Continuum

3.1.1.1. Provides methods for classifying a artifacts as they evolve from generic a to Org Specific A

3.1.2. Architecture Continuum

3.1.2.1. Foundation A - most generic artifact. Contains bb and their corresponding standards

3.1.2.2. Common system A

3.1.2.3. Industry A - encourages levels of interoperability within the industry

3.1.2.4. Organization-Specific A

3.1.3. Solutions Continuum - As the A evolves, its assets progress toward Organization Specific A. Represents impl of a A Continuum

4. Part IV (Architecture Content Framework) - step by step approach to develop EA

4.1. Architecture repository - used to store different classes of a output created in ADM

4.1.1. Architecture metamodel

4.1.2. Architecture capability - to promote effective architectural activity within the enterprise. Defines processes that support governance of A repository

4.1.3. Architecture landscape - shows which bb are currently in use

4.1.3.1. Strategic Architecture - provides view of the entire enterprise

4.1.3.2. Segment A

4.1.3.3. Capability A

4.1.4. Standard Information Base - holds specifications to which architecture must conform

4.1.5. Reference library - holds best practice or template materials that can be used to construct a. Guidelines and templates used to crate new a

4.1.6. Governance Log

4.1.6.1. Decision Log

4.1.6.2. Compliance Assessments - to govern a throughout its impl process

4.1.6.3. Capability Assessments

4.1.6.4. Calendar

4.1.6.5. Project Portfolio

4.1.6.6. Performance Measurement

5. Part III (ADM Guidelines and techniques) - to support tasks within the ADM. Techniques:

5.1. Stakeholder Management

5.2. Architecture Patterns - a way to put bb togather

5.3. Business Scenarios - recommended to help identify and understand requirements. Define them and articulate the Arch Vision created in phase A

5.3.1. Gap Analysis - to identify potential missing or overlapping functions. Highlights services that are yet to be developed. NOT identifies potential vendors for bb. Validates target a on forgotten elements

5.4. Migration Planning Techniques

5.5. Interoperability Requirements

5.6. Business Transformation Readiness Assessment - determine if organization is ready to accept change

5.6.1. Communication plan - to ensure that a info is communicated to the right stakeholders at the right time

5.7. Risk Management

5.7.1. Risk is pervasive in all enterprise a activity

5.7.2. Initial risk assessment - categorization before determining and impl mitigating actions

5.7.3. Residual risk assessment - after initial

5.8. Capability-Based Planning - a business planning technique that focuses on business outcomes

6. Part II (Architecture Development Method) - should be adapted to suit specific needs of the enterprise. AMD - process for developing org specific eterprise a

6.1. Numbering Scheme - 0.1, .... To permit adaptation as required

6.2. Artifact

6.3. Building block - Should be reused in other a projects. NOT equivalent to software component objects or web services. Reusable bb - legacy system/process that will be reused. Becomes more impl specific in phase E. Its spec should be loosely coupled to its impl

6.3.1. Architecture BB - defines functionality

6.3.2. Solution BB - defines implementation of functionality

6.4. Phases

6.4.1. Architecture Requirements Specification - quantitative view of the solution to measure the implementation

6.5. Deliverable - contractual outputs from the project

6.5.1. Change request - if the original A Definition is not suitable

6.6. A viewpoint - represents concern of stakeholder. Used as a template to create view

6.7. View - describes concerns of stakeholder. Always has viewpoint. Before creating - refer to existing lib of viewpoints to identify one for reuse

6.8. Architecture Definition Document - description to communicate the intent of the architect. To act as a deliverable container for artifacts created during a project

6.9. Request for a work - initiated by sponsoring org. to the a org. to trigger the start of an ADM cycle

7. Part I (Introduction. TOGAF approach for EA)

8. Enterprise Architecture - An architecture that crosses multiple systems and multiple functional groups within the enterprise Fundamental organization of a system embodied in its components, their relations to each other and the principles guiding its design and evolution. To optimize an enterprise into an envirnment that is responsive to business needs

8.1. Enterprise - any collection of org that has a common set of goals

8.2. misc

8.2.1. Boundaryless Information Flow - getting info to the right people in the right time in secure manner. Enabled via Integrated Information Infrastructure Model

8.3. Domains

8.3.1. Application

8.3.2. Business

8.3.3. Data

8.3.4. Technology - describes logical software and hardware capabilities

8.4. Cases

8.4.1. How to adapt ADM if way of doing a is not well recognized? - Create A Vision an then a detailed Buss A

8.4.2. From A to D in ADM a artifacts evolve from generic to org specific a

8.4.3. In B,C,D: first select ref model, viewpoints and tools

8.4.4. In B, C, D: last step create A Definition Doc

8.4.5. If bus principles dictate packaged solution - then completition of Bus A should follow the Inf Sys A