Get Started. It's Free
or sign up with your email address
TOGAF 9.1 by Mind Map: TOGAF 9.1

1. Part 1: Introduction

1.1. Definitions

1.1.1. TOGAF

1.1.1.1. Definition

1.1.1.1.1. TOGAF is an architecture framework.

1.1.1.1.2. TOGAF is an architecture framework that provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture.

1.1.1.1.3. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

1.1.1.2. Benefits of Adoption to TOGAF

1.1.1.2.1. A more efficient

1.1.1.2.2. Better return on existing investment

1.1.1.2.3. Reduced Risk for Future Investment

1.1.1.3. Who would benefit from using TOGAF?

1.1.1.3.1. Any organization undertaking, or planning to undertake, the development and implementation of an enterprise architecture for the support of business transformation

1.1.1.3.2. Organizations seeking Boundaryless Information Flow can use TOGAF to define and implement the structures and processes to enable access to integrated information within and between enterprises.

1.1.1.4. What Kind of Architecture Does TOGAF Deal With

1.1.1.4.1. Business

1.1.1.4.2. Data

1.1.1.4.3. Application

1.1.1.4.4. Technology (IT)

1.1.2. Enterprise

1.1.2.1. “any collection of organizations that has a common set of goals”

1.1.3. Architecture

1.1.3.1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation

1.1.3.2. It defines the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

1.2. Why do we need Enterprise Architecture?

1.2.1. 1. Lower costs – development, maintenance, support

1.2.2. 2. Reduced complexity

1.2.3. 3. Reduced risk

1.2.4. 4. Simpler to add new systems

1.2.5. 5. Faster purchase and implementation

1.3. What is an Architecture Framework?

1.3.1. Def 1

1.3.1.1. A common vocabulary

1.3.1.2. A set of tools or building blocks

1.3.1.3. A set of recommended standards

1.3.1.4. A method for designing a target state of the enterprise

1.3.2. Def 2

1.3.2.1. An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures

1.3.2.2. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together

1.3.2.3. It should contain a set of tools and provide a common vocabulary

1.3.2.4. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

1.4. Core Concepts

1.4.1. Establishing the Architecture Capability as an Operational Entity, an enterprise architecture practice should establish capabilities in the following areas

1.4.1.1. Financial Management

1.4.1.2. Performance Management

1.4.1.3. Service Management

1.4.1.4. Risk Management

1.4.1.5. Resource Management

1.4.1.6. Communications and Stakeholder Management

1.4.1.7. Quality Management

1.4.1.8. Configuration Management

1.4.1.9. Supplier Management

1.4.1.10. Environment Management

2. Part 3: ADM Guidelines and Techniques

2.1. 1. Applying Iteration to the ADM

2.1.1. Iteration Cycles

2.1.1.1. Architecture Capability Iteration

2.1.1.1.1. Iterations support the creation and evolution of the required Architecture Capability.

2.1.1.1.2. This includes the initial mobilization of the architecture activity for a given purpose or architecture engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.

2.1.1.2. Architecture Development Iteration

2.1.1.2.1. iterations allow the creation of architecture content by cycling through, or integrating, Business, Information Systems, and Technology Architecture phases.

2.1.1.2.2. These iterations ensure that the architecture is considered as a whole. In this type of iteration stakeholder reviews are typically broader.

2.1.1.2.3. As the iterations converge on a target, extensions into the Opportunities and Solutions and Migration Planning phases ensure that the architecture's implementability is considered as the architecture is finalized.

2.1.1.3. Transition Planning Iteration

2.1.1.3.1. iterations support the creation of formal change roadmaps for a defined architecture.

2.1.1.4. Architecture Governance Iteration

2.1.1.4.1. iterations support governance of change activity progressing towards a defined Target Architecture.

2.1.2. Classes of Architecture Engagement

2.1.2.1. Identification of Required Change

2.1.2.1.1. Outside the context of any change initiative, architecture can be used as a technique to provide visibility of the IT capability in order to support strategic decision-making and alignment of execution.

2.1.2.2. Definition of Change

2.1.2.3. Implementation of Change

2.1.3. Approaches to Architecture Development

2.1.3.1. Baseline First

2.1.3.1.1. In this style, an assessment of the baseline landscape is used to identify problem areas and improvement opportunities.

2.1.3.1.2. This process is most suitable when the baseline is complex, not clearly understood, or agreed upon.

2.1.3.1.3. This approach is common where organizational units have had a high degree of autonomy.

2.1.3.2. Target First

2.1.3.2.1. In this style, the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity.

2.1.3.2.2. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to effectively transition to the target model.

2.2. 2. Applying the ADM at different Enterprise Levels

2.2.1. Strategic Architectures (executive level)

2.2.2. Segment Architectures (program or portfolio level)

2.2.3. Capability Architectures

2.3. 3. Security Architecture and the ADM

2.3.1. How to adapt the ADM for security

2.3.1.1. Preliminary Phase

2.3.1.1.1. Scope the enterprise organizations impacted by the security architecture

2.3.1.1.2. Define and document applicable regulatory and security policy requirements

2.3.1.1.3. Define the required security capability as part of Architecture Capability

2.3.1.1.4. Implement security architecture tools

2.3.1.2. Phase A

2.3.1.2.1. Obtain management support for security measures

2.3.1.2.2. Define necessary security-related management sign-off milestones of this architecture development cycle

2.3.1.2.3. Determine and document applicable disaster recovery or business continuity plans/requirements

2.3.1.2.4. Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

2.3.1.2.5. Determine and document the criticality of the system: safety-critical/mission-critical/non-critical

2.3.1.3. Phase B

2.3.1.3.1. Determine who are the legitimate actors who will interact with the product/service/process

2.3.1.3.2. Assess and baseline current security-specific business processes (enhancement of existing objective)

2.3.1.3.3. Determine whom/how much it is acceptable to inconvenience in utilizing security measures

2.3.1.3.4. Identify and document interconnecting systems beyond project control

2.3.1.3.5. Determine the assets at risk if something goes wrong - "What are we trying to protect?"

2.3.1.3.6. Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

2.3.1.3.7. Identify and document the ownership of assets

2.3.1.3.8. Determine and document appropriate security forensic processes

2.3.1.3.9. Identify the criticality of the availability and correct operation of the overall service

2.3.1.3.10. Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

2.3.1.3.11. Reassess and confirm Architecture Vision decisions

2.3.1.3.12. Assess alignment or conflict of identified security policies with business goals

2.3.1.3.13. Determine "what can go wrong?"

2.3.1.4. Phase C

2.3.1.4.1. Assess and baseline current security-specific architecture elements (enhancement of existing objective)

2.3.1.4.2. Identify safe default actions and failure states

2.3.1.4.3. Identify and evaluate applicable recognized guidelines and standards

2.3.1.4.4. Revisit assumptions regarding interconnecting systems beyond project control

2.3.1.4.5. Determine and document the sensitivity or classification level of information stored/created/used

2.3.1.4.6. Identify and document custody of assets

2.3.1.4.7. Identify the criticality of the availability and correct operation of each function

2.3.1.4.8. Determine the relationship of the system under design with existing business disaster/continuity plans

2.3.1.4.9. Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

2.3.1.4.10. Identify lifespan of information used as defined by business needs and regulatory requirements

2.3.1.4.11. Determine approaches to address identified risks:

2.3.1.4.12. Identify actions/events that warrant logging for later review or triggering forensic processes

2.3.1.4.13. Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

2.3.1.4.14. Identify potential/likely avenues of attack

2.3.1.4.15. Determine "what can go wrong?"

2.3.1.5. Phase D

2.3.1.5.1. Assess and baseline current security-specific technologies (enhancement of existing objective)

2.3.1.5.2. Revisit assumptions regarding interconnecting systems beyond project control

2.3.1.5.3. Identify and evaluate applicable recognized guidelines and standards

2.3.1.5.4. Identify methods to regulate consumption of resources

2.3.1.5.5. Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis

2.3.1.5.6. Identify the trust (clearance) level of:

2.3.1.5.7. Identify minimal privileges required for any entity to achieve a technical or business objective

2.3.1.5.8. Identify mitigating security measures, where justified by risk assessment

2.3.1.5.9. Determine "what can go wrong?"

2.3.1.6. Phase E

2.3.1.6.1. Identify existing security services available for re-use

2.3.1.6.2. Engineer mitigation measures addressing identified risks

2.3.1.6.3. Evaluate tested and re-usable security software and security system resources

2.3.1.6.4. Identify new code/resources/assets that are appropriate for re-use

2.3.1.6.5. Populate the Architecture Repository with new security building blocks.

2.3.1.6.6. Determine "what can go wrong?"

2.3.1.7. Phase F

2.3.1.7.1. Assess the impact of new security measures upon other new components or existing leveraged systems

2.3.1.7.2. Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

2.3.1.7.3. Identify correct secure installation parameters, initial conditions, and configurations

2.3.1.7.4. Implement disaster recovery and business continuity plans or modifications

2.3.1.7.5. Determine "what can go wrong?"

2.3.1.8. Phase G

2.3.1.8.1. Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

2.3.1.8.2. Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

2.3.1.8.3. Implement necessary training to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; ensure awareness training of all users and non-privileged operators of the system and/or its components

2.3.1.8.4. Determine "what has gone wrong?"

2.3.1.9. Phase H

2.3.1.9.1. Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

2.3.1.9.2. Determine "what has gone wrong?"

2.3.2. Accepted areas of concern for the security architect

2.3.2.1. Authentication

2.3.2.2. Authorization

2.3.2.3. Audit

2.3.2.4. Assurance

2.3.2.5. Availability

2.3.2.6. Asset Protection

2.3.2.7. Administration

2.3.2.8. Risk Management

2.3.3. Typical security architecture artifacts

2.3.3.1. Business rules regarding handling of data/information assets

2.3.3.2. Written and published security policy

2.3.3.3. Codified data/information asset ownership and custody

2.3.3.4. Risk analysis documentation

2.3.3.5. Data classification policy documentation

2.4. 4. Using TOGAF to Define & Govern SOAs

2.4.1. A style of architecture that looks at all the functions of the system as services.

2.4.2. Services

2.4.2.1. Services: Self-contained Can call other services Is a black box to consumers of the service

2.4.2.2. Examples of Services:

2.4.2.2.1. Authentication service

2.4.2.2.2. Email service

2.4.2.2.3. Data Access Layer

2.4.2.2.4. Report generation service

2.4.3. Using TOGAF for SOA

2.4.3.1. Additional artifacts around services Content metamodel extensions

2.5. 5. Architecture Principles

2.5.1. Principle Components

2.5.1.1. Name

2.5.1.1.1. Should both represent the essence of the rule as well as be easy to remember.

2.5.1.1.2. Specific technology platforms should not be mentioned in the name or statement of a principle.

2.5.1.1.3. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff).

2.5.1.2. Statement

2.5.1.2.1. Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous.

2.5.1.3. Rationale

2.5.1.3.1. Should highlight the business benefits of adhering to the principle, using business terminology.

2.5.1.3.2. Point to the similarity of information and technology principles to the principles governing business operations.

2.5.1.3.3. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

2.5.1.3.4. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation.

2.5.1.4. Implications

2.5.1.4.1. Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

2.5.2. Qualities

2.5.2.1. Understandable

2.5.2.1.1. The underlying tenets can be quickly grasped and understood by individuals throughout the organization.

2.5.2.1.2. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.

2.5.2.2. Complete

2.5.2.2.1. Every potentially important principle governing the management of information and technology for the organization is defined.

2.5.2.2.2. The principles cover every situation perceived.

2.5.2.3. Consistent

2.5.2.3.1. Strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations.

2.5.2.3.2. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another.

2.5.2.3.3. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.

2.5.2.4. Stable

2.5.2.4.1. Principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.

2.5.3. Two key domains inform the development and utilization of architecture:

2.5.3.1. Enterprise

2.5.3.2. Architecture

2.5.4. Example Set of Architecture Principles (BDAT)

2.5.4.1. Business Principles

2.5.4.1.1. Primacy of Principles

2.5.4.1.2. Maximize Benefit to the Enterprise

2.5.4.1.3. Information Management is Everybody's Business

2.5.4.1.4. Business Continuity

2.5.4.1.5. Common Use Applications

2.5.4.1.6. Service Orientation

2.5.4.1.7. Compliance with Law

2.5.4.1.8. IT Responsibility

2.5.4.1.9. Protection of Intellectual Property

2.5.4.2. Data Principles

2.5.4.2.1. Data is an Asset

2.5.4.2.2. Data is Shared

2.5.4.2.3. Data is Accessible

2.5.4.2.4. Data Security

2.5.4.2.5. Data Trustee

2.5.4.2.6. Common Vocabulary and Data Definitions

2.5.4.3. Application Principles

2.5.4.3.1. Technology Independence

2.5.4.3.2. Ease-of-Use

2.5.4.4. Technology Principles

2.5.4.4.1. Requirements-Based Change

2.5.4.4.2. Responsive Change Management

2.5.4.4.3. Control Technical Diversity

2.5.4.4.4. Interoperability

2.6. 6. Architecture Stakeholder Management

2.6.1. Stakeholder

2.6.1.1. Def.

2.6.1.1.1. An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.

2.6.1.2. examples

2.6.1.2.1. Architect (You)

2.6.1.2.2. Accounting/Finance

2.6.1.2.3. The Customer

2.6.1.2.4. User of the Solution

2.6.1.2.5. Business Unit

2.6.1.2.6. Partners/Implementers

2.6.1.2.7. External Suppliers

2.6.1.2.8. (IT/HR/QA/Security/Customer Service) Group

2.6.1.3. Sample Stakeholder Analysis

2.6.2. Technique

2.6.2.1. Identifying who they are in Phase A to identify key players, versus minor players

2.6.2.2. Classifying their positions

2.6.2.3. Determine stakeholder management approach

2.6.2.4. Tailor engagement deliverables

2.6.3. Approach to Stakeholder Management

2.6.3.1. View

2.6.3.1.1. The representation of a related set of concerns.

2.6.3.1.2. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture.

2.6.3.1.3. A view does not have to be visual or graphical in nature.

2.6.3.2. Viewpoint

2.6.3.2.1. A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template).

2.6.3.2.2. A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.

2.6.3.2.3. examples

2.6.3.3. Concern

2.6.3.3.1. "Concerns" are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system.

2.6.3.3.2. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability. The terms "concern" and "requirement" are not synonymous.

2.6.3.3.3. Concerns are the root of the process of decomposition into requirements. Concerns are represented in the architecture by these requirements. Requirements should be SMART (e.g., specific metrics).

2.7. 7. Architecture Patterns

2.7.1. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in other

2.7.2. In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem.

2.7.3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

2.8. 8. Business Scenarios

2.8.1. Introduction

2.8.1.1. Principally used in the

2.8.1.1.1. Architecture Vision

2.8.1.1.2. Business Architecture,

2.8.1.1.3. and in other architecture domains as well,

2.8.1.2. A business scenario describes:

2.8.1.2.1. A business process, application, or set of applications that can be enabled by the architecture

2.8.1.2.2. The business and technology environment

2.8.1.2.3. The people and computing components (called "actors") who execute the scenario

2.8.1.2.4. The desired outcome of proper execution

2.8.1.3. A good Business Scenario

2.8.1.3.1. is representative of a significant business need or problem, and enables vendors to understand the value to the customer organization of a developed solution.

2.8.1.3.2. is "SMART":

2.8.2. Benefits of Business Scenarios

2.8.2.1. A business scenario is essentially a complete description of a business problem, both in business and in architectural terms,

2.8.2.2. Without such a complete description to serve as context:

2.8.2.2.1. There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work.

2.8.2.2.2. The business value of solving the problem is unclear.

2.8.2.2.3. The relevance of potential solutions is unclear.

2.8.2.3. in communication with vendors.

2.8.3. Creating the Business Scenario

2.8.3.1. Overall Process

2.8.3.1.1. Identifying, documenting, and ranking the problem driving the scenario

2.8.3.1.2. Identifying the business and technical environment of the scenario and documenting it in scenario models

2.8.3.1.3. Identifying and documenting desired objectives (the results of handling the problems successfully); get "SMART"

2.8.3.1.4. Identifying the human actors (participants) and their place in the business model

2.8.3.1.5. Identifying computer actors (computing elements) and their place in the technology model

2.8.3.1.6. Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation

2.8.3.1.7. Checking for "fitness-for-purpose" and refining only if necessary

2.8.3.2. Phases

2.8.3.2.1. Gathering

2.8.3.2.2. Analyzing

2.8.3.2.3. Reviewing

2.8.4. Contents of a Business Scenario

2.8.4.1. The documentation of a business scenario should contain all the important details about the scenario. It should capture, and sequence, the critical steps and interactions between actors that address the situation.

2.8.4.2. It should also declare all the relevant information about all actors, specifically: the different responsibilities of the actors; the key pre-conditions that have to be met prior to proper system functionality; and the technical requirements for the service to be of acceptable quality.

2.8.5. Contributions to the Business Scenario

2.8.6. Business Scenarios and the TOGAF ADM

2.8.6.1. Business scenarios figure most prominently in the initial phase of the Architecture Development Method (ADM), Architecture Vision, when they are used to define relevant business requirements, and to build consensus with business management and other stakeholders.

2.8.7. Developing Business Scenarios

2.8.8. Business Scenario Documentation

2.8.9. Guidelines on Goals and Objectives

2.9. 9. Gap Analysis

2.9.1. Business domain gaps:

2.9.1.1. People gaps (e.g., cross-training requirements)

2.9.1.2. Process gaps (e.g., process inefficiencies)

2.9.1.3. Tools gaps (e.g., duplicate or missing tool functionality)

2.9.1.4. Information gaps

2.9.1.5. Measurement gaps

2.9.1.6. Financial gaps

2.9.1.7. Facilities gaps (buildings, office space, etc.)

2.9.2. Data domain gaps:

2.9.2.1. Data not of sufficient currency

2.9.2.2. Data not located where it is needed

2.9.2.3. Not the data that is needed

2.9.2.4. Data not available when needed

2.9.2.5. Data not created

2.9.2.6. Data not consumed

2.9.2.7. Data relationship gaps

2.9.3. Applications impacted, eliminated, or created

2.9.4. Technologies impacted, eliminated, or created

2.10. 10. Migration Planning Techniques

2.10.1. Matries

2.10.1.1. 1. Implementation Factor Assessment & Deduction Matrix

2.10.1.1.1. Used to document factors impacting the architecture Implementation and Migration Plan.

2.10.1.1.2. The matrix should include a list of the factors to be considered, their descriptions, and the deductions that indicate the actions or constraints that have to be taken into consideration when formulating the plans.

2.10.1.1.3. Factors typically include:

2.10.1.2. 2. Consolidated Gaps, Solutions, & Dependencies Matrix

2.10.1.2.1. The technique of creating a Consolidated Gaps, Solutions, and Dependencies matrix allows the architect to group the gaps identified in the domain architecture gap analysis results and assess potential solutions and dependencies to one or more gaps.

2.10.1.2.2. This matrix can be used as a planning tool when creating work packages. The identified dependencies will drive the creation of projects and migration planning in Phases E and F.

2.10.2. Tables

2.10.2.1. 3. Architecture Definition Increments Table

2.10.2.1.1. The technique of creating an Architecture Definition Increments table allows the architect to plan a series of Transition Architectures outlining the status of the enterprise architecture at specified times.

2.10.2.2. 4. Transition Architecture State Evolution Table

2.10.2.2.1. The technique of creating the Transition Architecture State Evolution table allows the architect to show the proposed state of the architectures at various levels using the Technical Reference Model (TRM).

2.10.2.2.2. A table should be drawn, listing the services from the TRM used in the enterprise, the Transition Architectures, and proposed transformations.

2.10.2.2.3. All Solution Building Blocks (SBBs) should be described with respect to their delivery and impact on these services. They should also be marked to show the progression of the enterprise architecture. In the example, where target capability has been reached, this is shown as "new" or "retain"; where capability is transitioned to a new solution, this is marked as "transition"; and where a capability is to be replaced, this is marked as "replace

2.10.3. 5. Business Value Assessment Technique

2.10.3.1. A technique to assess business value is to draw up a matrix based on a value index dimension and a risk index dimension.

2.10.3.2. The value index should include criteria such as

2.10.3.2.1. compliance to principles,

2.10.3.2.2. financial contribution,

2.10.3.2.3. strategic alignment,

2.10.3.2.4. and competitive position.

2.10.3.3. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure.

2.10.3.4. Each criterion should be assigned an individual weight.

2.10.3.5. The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.

2.11. 11. Interoperability Requirements

2.11.1. Definitions

2.11.1.1. interoperability

2.11.1.1.1. the ability to share information and services

2.11.2. Categories

2.11.2.1. Operational or Business Interoperability

2.11.2.1.1. defines how business processes are to be shared.

2.11.2.2. Information Interoperability defines

2.11.2.2.1. defines how information is to be shared.

2.11.2.3. Technical Interoperability

2.11.2.3.1. defines how technical services are to be shared

2.11.3. Enterprise Operating Model

2.11.4. Refining Interoperability

2.11.4.1. Implementing interoperability requires the creation, management, acceptance, and enforcement of realistic standards that are SMART

2.11.5. Determining Interoperability Requirements

2.11.6. Reconciling Interoperability Requirements with Potential Solutions

2.11.7. Summary

2.11.7.1. Defining interoperability in a clear unambiguous manner at several levels (business/service, information, and technical) is a useful architecture planning tool.

2.11.7.2. The notions of interoperability will become ever more important in the Service Oriented Architecture (SOA) environment where services will be shared internally and externally in ever more inter-dependent extended enterprises.

2.12. 12. Business Transformation Readiness Assessment

2.12.1. Introduction

2.12.1.1. Initial Business Transformation readiness assessment is carried out in Phase A of the TOGAF ADM

2.12.1.2. Understanding the readiness of the organization to accept change, identifying the issues, and then dealing with them in the Implementation and Migration Plans is key to successful architecture transformation in Phases E and F.

2.12.1.3. This will be a joint effort between corporate (especially human resources) staff, lines of business, and IT planners.

2.12.2. Recommended Activities

2.12.2.1. Determine the readiness factors that will impact the organization

2.12.2.2. Present the readiness factors using maturity models

2.12.2.3. Assess the readiness factors, including determination of readiness factor ratings

2.12.2.4. Assess the risks for each readiness factor and identify improvement actions to mitigate the risk

2.12.2.5. Work these actions into Phase E and F Implementation and Migration Plan

2.12.3. Business Transformation Enablement Program (BTEP)

2.12.3.1. The Canadian Government (BTEP) provides guidance on how to identify the business transformation-related issues.

2.12.4. Determine Readiness Factors

2.12.4.1. Vision

2.12.4.1.1. is the ability to clearly define and communicate what is to be achieved. This is where management is able to clearly define the objectives,

2.12.4.2. Desire, Willingness, and Resolve

2.12.4.2.1. is the presence of a desire to achieve the results, willingness to accept the impact of doing the work, and the resolve to follow through and complete the endeavor.

2.12.4.3. Need

2.12.4.3.1. in that there is a compelling need to execute the endeavor. There are clear statements regarding what the organization will not be able to do if the project does not proceed, and equally clear statements of what the project will enable the organization to do.

2.12.4.4. Business Case

2.12.4.4.1. exists that creates a strong focus for the project, identifying benefits that must be achieved and thereby creating an imperative to succeed.

2.12.4.5. Funding

2.12.4.5.1. in the form of a clear source of fiscal resources, exists that meets the endeavor's potential expenditures.

2.12.4.6. Sponsorship and Leadership

2.12.4.6.1. exists and is broadly shared, but not so broad as to diffuse accountability.

2.12.4.7. Governance

2.12.4.7.1. is the ability to engage the involvement and support of all parties with an interest in or responsibility to the endeavor with the objective of ensuring that the corporate interests are served and the objectives achieved.

2.12.4.8. Accountability

2.12.4.8.1. is the assignment of specific and appropriate responsibility, recognition of measurable expectations by all concerned parties, and alignment of decision-making with areas of responsibility and with where the impact of the decisions will be felt

2.12.4.9. Workable Approach and Execution Model

2.12.4.9.1. is an approach that makes sense relative to the task, with a supporting environment, modeled after a proven approach.

2.12.4.10. IT Capacity to Execute

2.12.4.10.1. is the ability to perform all the IT tasks required by the project, including the skills, tools, processes, and management capability.

2.12.4.11. Enterprise Capacity to Execute

2.12.4.11.1. is the ability of the enterprise to perform all the tasks required by the endeavor, in areas outside of IT, including the ability to make decisions within the tight time constraints typical to project environments based upon the recent successful execution of a similar endeavor of at least half the size and complexity

2.12.4.12. Enterprise Ability to Implement and Operate

2.12.4.12.1. the transformation elements and their related business processes, absorb the changes arising from implementation, and ongoing ability to operate in the new environment.

2.12.5. Present Readiness Factors

2.12.5.1. Once the factors are determined, it is necessary to present them in such a way that the assessment is clear and the maximum value is derived from the participants.

2.12.5.2. One such presentation is through the use of maturity models that enable participants to:

2.12.5.2.1. Assess their current (Baseline Architecture) maturity level

2.12.5.2.2. Determine the target maturity level that would have to be achieved to realize the Target Architecture

2.12.5.2.3. Determine an intermediate target that would be achievable in a lesser timeframe

2.12.5.3. example

2.12.5.3.1. example

2.12.6. Assess Readiness Factors

2.12.6.1. Readiness Factor Vision

2.12.6.2. Readiness Factor Rating

2.12.6.3. Readiness Factor Risks & Actions

2.12.7. Readiness and Migration Planning

2.12.7.1. The assessment exercise will provide a realistic assessment of the organization and will be a key input into the strategic migration planning that will be initiated in Phase E and completed in Phase F.

2.12.7.2. It is important to note whether the business transformation actions will be on the vision's critical path and, if so, determine how they will impact implementation.

2.12.8. Marketing the Implementation Plan

2.13. 13. Risk Management

2.13.1. Intro

2.13.1.1. Risk is pervasive in any enterprise architecture activity and present in all phases within the ADM.

2.13.1.2. There will always be risk with any architecture/business transformation effort. It is important to identify, classify, and mitigate these risks before starting so that they can be tracked throughout the transformation effort.

2.13.1.3. Mitigation is an ongoing effort and often the risk triggers may be outside the scope of the transformation planners (e.g., merger, acquisition) so planners must monitor the transformation context constantly.

2.13.1.4. Risk Levels

2.13.1.4.1. Initial Level of Risk

2.13.1.4.2. Residual Level of Risk

2.13.2. Risk Classification

2.13.2.1. Risk is pervasive in any enterprise architecture activity and is present in all phases within the Architecture Development Method (ADM). From a management perspective, it is useful to classify the risks so that the mitigation of the risks can be executed as expeditiously as possible.

2.13.2.2. Risks are normally classified as

2.13.2.2.1. time (schedule),

2.13.2.2.2. cost (budget),

2.13.2.2.3. Scope

2.13.2.2.4. but they could also include

2.13.3. Risk Identification

2.13.3.1. The maturity and transformation readiness assessments

2.13.3.1.1. will generate a great many risks. Identify the risks and then determine the strategy to address them throughout the transformation.

2.13.3.2. Capability Maturity Models (CMMs)

2.13.3.2.1. is suitable for specific factors associated with architecture delivery to first identify baseline and target states and then identify the actions required to move to the target state. The implications of not achieving the target state can result in the discovery of risks. Refer to Chapter 30 for specific details.

2.13.3.3. Risk documentation

2.13.3.3.1. is completed in the context of a Risk Management Plan, for which templates exist in standard project management methodologies (e.g., Project Management Book of Knowledge and PRINCE2) as well as with the var ious government methodologies.

2.13.4. Initial Risk Assessment

2.13.4.1. Effect

2.13.4.1.1. Catastrophic

2.13.4.1.2. Critical

2.13.4.1.3. Marginal

2.13.4.1.4. Negligible

2.13.4.2. Frequency

2.13.4.2.1. Frequent:

2.13.4.2.2. Likely:

2.13.4.2.3. Occasional:

2.13.4.2.4. Seldom:

2.13.4.2.5. Unlikely:

2.13.4.3. Combined

2.13.4.3.1. Extremely High Risk (E):

2.13.4.3.2. High Risk (H):

2.13.4.3.3. Moderate Risk (M):

2.13.4.3.4. Low Risk (L):

2.13.5. Risk Mitigation and Residual Risk Assessment

2.13.5.1. Risk mitigation refers to the identification, planning, and conduct of actions that will reduce the risk to an acceptable level.

2.13.5.2. The mitigation effort could be a simple monitoring and/or acceptance of the risk to a full-blown contingency plan calling for complete redundancy in a Business Continuity Plan (with all of the associated scope, cost, and time implications).

2.13.6. Conduct Residual Risk Assessment

2.13.6.1. Once the initial risk is mitigated, then the risk that remains is called the ‘‘residual risk’’. The key consideration is that the mitigating effort actually reduces the corporate impact and does not just move the risk to another similarly high quadrant.

2.13.7. Risk Monitoring and Governance (Phase G)

2.13.7.1. The residual risks have to be approved by the IT governance framework and potentially in corporate governance where business acceptance of the residual risks is required.

2.13.7.2. Once the residual risks have been accepted, then the execution of the mitigating actions has to be carefully monitored to ensure that the enterpr ise is dealing with residual rather than initial risk.

2.13.7.3. The risk identification and mitigation assessment worksheets are maintained as governance artifacts and are kept up-to-date in Phase G (Implementation Governance) where risk monitoring is conducted.

2.13.8. Initial Risk Assessment

2.13.8.1. Effect

2.13.8.1.1. Catastrophic infers critical financial loss that could result in bankruptcy of the organization.

2.13.8.1.2. Critical infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the IT investment.

2.13.8.1.3. Marginal infers a minor financial loss in a line of business and a reduced return on investment on the IT investment.

2.13.8.1.4. Negligible infers a minimal impact on a line of business' ability to deliver services and/or products.

2.13.8.2. Frequency

2.13.8.2.1. Frequent: Likely to occur very often and/or continuously.

2.13.8.2.2. Likely: Occurs several times over the course of a transformation cycle.

2.13.8.2.3. Occasional: Occurs sporadically.

2.13.8.2.4. Seldom: Remotely possible and would probably occur not more than once in the course of a transformation cycle.

2.13.8.2.5. Unlikely: Will probably not occur during the course of a transformation cycle.

2.13.8.3. Combines (Effect+Frequency)

2.13.8.3.1. Extremely High Risk (E):

2.13.8.3.2. High Risk (H):

2.13.8.3.3. Moderate Risk (M):

2.13.8.3.4. Low Risk (L):

2.14. 14. Capability-Based Planning

2.14.1. Overview

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

2.14.1.2. Capability-based planning focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise.

2.14.1.3. It also copes well with the friction of co-ordinating projects across corporate functional domains that together enable the enterprise to achieve that capability

2.14.1.4. Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond is required and the same resources are involved in multiple capabilities.

2.14.2. Capability-Based Planning Paradigm

2.14.3. Concept of Capability-Based Planning

2.14.3.1. From an enterprise architecture and IT perspective, capability-based planning is a powerful mechanism to ensure that the strategic business plan drives the enterprise from a top-down approach. It is also adaptable with capability engineering to leverage emerging bottom-up innovations.

2.14.3.2. Capability Dimensions

2.14.3.3. Capability Increments

2.14.4. Capabilities in an Enterprise Architecture Context

2.14.5. Summary

2.14.6. Old

2.14.6.1. Intro

2.14.6.1.1. It focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise.

2.14.6.1.2. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability.

2.14.6.2. Concept of Capability-Based Planning

2.14.6.2.1. Explanation

2.14.6.2.2. Capability Dimensions

2.14.6.2.3. Capability Increments

2.14.7. Links

3. Part 5: Enterprise Continuum and Tools

3.1. Architecture Continuum

3.1.1. Foundation Architecture

3.1.2. Common Systems Architecture

3.1.3. Industry Architecture

3.1.4. Organization-Specific Architecture

3.2. Architecture Repository

3.2.1. Architecture

3.2.1.1. Metamodel

3.2.1.2. Capability

3.2.1.3. Landscape

3.2.1.3.1. Strategic Architectures

3.2.1.3.2. Segment Architectures

3.2.1.3.3. Capability Architectures

3.2.2. SIB

3.2.3. Reference Library

3.2.4. Governance Log

3.3. Solutions Continuum

3.3.1. Foundation Solutions

3.3.2. Common Systems Solutions

3.3.3. Industry Solutions

3.3.4. Organization-Specific Solutions

3.4. Architecture Partitioning

3.4.1. Reasons

3.4.1.1. Two units within the same organization have conflicting architectures

3.4.1.2. Different teams need to work on different elements of the same architecture at the same time

3.4.1.3. Having a modular architecture supports the concept of re-usable building blocks

3.4.2. Architectural Landscape:

3.4.2.1. Strategic architecture (enterprise)

3.4.2.1.1. less detailed, more stable, handled at the top level

3.4.2.2. Segment architecture (group)

3.4.2.2.1. a bit more detail, cross project, handled by the relevant business unit(s)

3.4.2.3. Capability architecture (project or portfolio)

3.4.2.3.1. most detail, project focused, handled by an individual team

3.4.3. Integration Risks:

3.4.3.1. If one project team has an “8” architecture maturity, and another has a “3”

3.4.3.2. Disjointed, fragmented architecture that cannot be integrated to form one overall architecture

3.4.4. What is needed:

3.4.4.1. Architecture standards across the organization

3.4.4.2. Enforced by proper architecture governance

3.4.4.3. Standard catalog of building blocks for project teams to choose from

3.4.5. Explanation

3.4.5.1. Architecture Partitioning is the practice of dividing up an enterprise architecture in a logical manner between two or more groups

3.4.5.2. There is no “one size fits all” way to partition an architecture, It’s highly customized to each organization structure and scenario

3.4.5.3. The enterprise continuum is a catalog of building blocks organized from highly-generic to organization-specific

3.4.5.4. Keeping metadata on each building block helps classify it for the purposes of partitioning:

3.4.5.5. Subject matter (breadth), time, maturity/volatility, depth

3.4.5.6. Architectures can be partitioned based on this criteria.

4. Part 2: ADM

4.1. Intro

4.1.1. Overview

4.1.1.1. The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners.

4.1.1.2. It describes a method for developing and managing the lifecycle of an Enterprise Architecture, and forms the core of the TOGAF standard.

4.1.2. Architecture Development Cycle

4.1.2.1. A Preliminary Phase (only done once)

4.1.2.2. Eight phases (A-H) arranged in a cycle

4.1.2.3. All phases have inputs, steps and outputs

4.1.2.4. Outputs (deliverables) are in the form of documents, that get saved to the repository

4.1.2.5. ADM designed to be generic, to fit most enterprises, but can be modified or extended to meet a specific need

4.1.3. Scoping the Architecture

4.1.3.1. There are many reasons to constrain the scope of the architectural activity

4.1.3.1.1. The organizational authority of the team producing the architecture

4.1.3.1.2. The objectives and stakeholder concerns to be addressed within the architecture

4.1.3.1.3. The availability of people, finance, and other resources

4.1.3.2. Four dimensions are typically used in order to define and limit the scope

4.1.3.2.1. Breadth

4.1.3.2.2. Depth

4.1.3.2.3. Time Period

4.1.3.2.4. Architecture Domains

4.2. Architecture Development Cycle

4.2.1. The ADM is iterative, over the whole process, between phases and within phases

4.2.2. For each iteration of the ADM, a fresh decision must be taken as to

4.2.2.1. The breadth of coverage of the enterprise to be defined

4.2.2.2. The level of detail to be defined

4.2.2.3. The extent of the time period aimed at, including the number and extent of any intermediate time periods

4.2.2.4. The architectural assets to be leveraged, including:

4.2.2.4.1. Assets created in previous iterations of the ADM cycle within the enterprise

4.2.2.4.2. Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)

4.2.3. These decisions should be based on a

4.2.3.1. Practical assessment of resource and competence availability,

4.2.3.2. The value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work.

4.2.4. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

4.3. Phases

4.3.1. Preliminary Phase

4.3.1.1. Objectives

4.3.1.1.1. Determine the Architecture Capability desired by the organization

4.3.1.1.2. Establish the Architecture Capability

4.3.1.2. Approach

4.3.1.2.1. Defining

4.3.1.2.2. Evaluating the enterprise architecture maturity

4.3.1.2.3. Identifying key drivers and elements

4.3.1.3. Steps

4.3.1.3.1. Scope the enterprise organizations impacted

4.3.1.3.2. Confirm governance and support frameworks

4.3.1.3.3. Define and establish enterprise architecture team and organization

4.3.1.3.4. Identify and establish architecture principles

4.3.1.3.5. Tailor TOGAF and, if any, other selected architecture frameworks

4.3.1.3.6. Implement architecture tools

4.3.1.4. Output

4.3.1.4.1. Request for Architecture

4.3.2. Phase A: Architecture Vision

4.3.2.1. Objectives

4.3.2.1.1. Obtain approval for a Statement of Architecture Work

4.3.2.1.2. Develop a high-level aspirational vision of the capabilities and business value to be delivered

4.3.2.2. Approach

4.3.2.2.1. Request for Architecture Work ➤ what is in and out of scope

4.3.2.2.2. Creating the Architecture Vision

4.3.2.2.3. Business Scenarios

4.3.2.3. Steps

4.3.2.3.1. Identify

4.3.2.3.2. Develop

4.3.2.3.3. Define

4.3.2.3.4. Confirm

4.3.2.3.5. Establish the architecture project

4.3.2.3.6. Evaluate business capabilities

4.3.2.3.7. Assess readiness for business transformation

4.3.2.4. Output

4.3.2.4.1. Matrices

4.3.2.4.2. Diagrams

4.3.2.4.3. Framework to be used

4.3.3. Phase B: Business Architecture

4.3.3.1. Summary

4.3.3.1.1. B in BDAT

4.3.3.1.2. Develop the baseline and target business architecture

4.3.3.1.3. Identify gaps between baseline and target

4.3.3.2. Inputs

4.3.3.2.1. Non-Architectural Inputs

4.3.3.2.2. Architectural Inputs

4.3.3.3. Steps

4.3.3.3.1. 1. Select reference models, viewpoints, and tools

4.3.3.3.2. 2. Develop Baseline & Target Architecture Description

4.3.3.3.3. 4. Perform gap analysis

4.3.3.3.4. 5. Define candidate roadmap components

4.3.3.3.5. 6. Resolve impacts across the Architecture Landscape

4.3.3.3.6. 7. Conduct formal stakeholder review

4.3.3.3.7. 8. Finalize the Architecture

4.3.3.3.8. 9. Create Architecture Definition Document

4.3.3.4. Approach

4.3.3.4.1. Business architecture is the foundation on which the other domains architecture are built on

4.3.3.4.2. Develop the baseline description (bottom-up)

4.3.3.4.3. Build Business models i.e.

4.3.3.4.4. Finding models from other sources, like industry groups and standards

4.3.3.5. Output

4.3.3.5.1. Keywords

4.3.3.5.2. Catalogs

4.3.3.5.3. Matrices

4.3.3.5.4. Diagrams

4.3.4. Phase C: Information Systems Architecture

4.3.4.1. Objectives

4.3.4.1.1. 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

4.3.4.1.2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

4.3.4.2. Steps

4.3.4.2.1. 1. Select reference models, viewpoints, and tools

4.3.4.2.2. 2. Develop Baseline & Target Architecture Description

4.3.4.2.3. 4. Perform gap analysis

4.3.4.2.4. 5. Define candidate roadmap components

4.3.4.2.5. 6. Resolve impacts across the Architecture Landscape

4.3.4.2.6. 7. Conduct formal stakeholder review

4.3.4.2.7. 8. Finalize the Architecture

4.3.4.2.8. 9. Create Architecture Definition Document

4.3.4.3. Approach

4.3.4.3.1. Phase C involves some combination of Data and Application Architecture, in either order. Advocates exist for both sequences.

4.3.4.3.2. Detailed descriptions for Phase C are given separately for each architecture domain

4.3.4.4. Information Systems Architecture

4.3.4.4.1. Approach

4.3.4.4.2. Objectives

4.3.4.5. Data Architecture

4.3.4.5.1. Approach

4.3.4.5.2. Objectives

4.3.4.5.3. Artifacts

4.3.4.6. Application Architecture

4.3.4.6.1. Objectives

4.3.4.6.2. Approach

4.3.4.7. Outputs

4.3.4.7.1. Keywords: “application”, “interface”, “software"

4.3.4.7.2. Catalogs

4.3.4.7.3. Matrices

4.3.4.7.4. Diagrams

4.3.5. Phase D: Technology Architecture

4.3.5.1. Objectives

4.3.5.1.1. 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

4.3.5.1.2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

4.3.5.2. Steps

4.3.5.2.1. 1. Select reference models, viewpoints, and tools

4.3.5.2.2. 2. Develop Baseline & Target Architecture Description

4.3.5.2.3. 4. Perform gap analysis

4.3.5.2.4. 5. Define candidate roadmap components

4.3.5.2.5. 6. Resolve impacts across the Architecture Landscape

4.3.5.2.6. 7. Conduct formal stakeholder review

4.3.5.2.7. 8. Finalize the Architecture

4.3.5.2.8. 9. Create Architecture Definition Document

4.3.5.3. Approach

4.3.5.3.1. Architecture Repository

4.3.5.3.2. Emerging Technologies

4.3.5.4. Outputs

4.3.5.4.1. 1. Catalogs: Technology Standards catalog, Technology Portfolio catalog

4.3.5.4.2. 2. Matrices: Application/Technology matrix

4.3.5.4.3. 3. Diagrams: Environments and Locations diagram, Platform Decomposition diagram, Processing diagram, Networked Computing/Hardware diagram, Communications Engineering diagram

4.3.5.4.4. Keywords

4.3.6. Phase E: Opportunities and Solutions

4.3.6.1. Intro

4.3.6.1.1. Phase E: Opportunities and Solutions describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases

4.3.6.1.2. Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages within the enterprise's portfolios.

4.3.6.1.3. This is an effort to build a best-fit roadmap that is based upon

4.3.6.1.4. The key is to focus on the final target while realizing incremental business value.

4.3.6.2. Objectives

4.3.6.2.1. Architecture Roadmap

4.3.6.2.2. Incremental approach

4.3.6.3. Approach

4.3.6.3.1. Figure out how to deliver the target architecture

4.3.6.3.2. Architecture Roadmap & Work Packages

4.3.6.3.3. Transition Architectures

4.3.6.3.4. Implementation and Migration Plan

4.3.6.4. Steps

4.3.6.4.1. Determine & Confirm key corporate change attributes

4.3.6.4.2. Determine business constraints for implementation

4.3.6.4.3. Review and consolidate gap analysis results from Phases B, C and D

4.3.6.4.4. Identify and group major work packages

4.3.6.4.5. Confirm readiness and risk for business transformation

4.3.6.4.6. Review consolidated requirements across related business functions

4.3.6.4.7. Consolidate and reconcile interoperability requirements

4.3.6.4.8. Identify Transition Architectures

4.3.6.4.9. Formulate Implementation and Migration Strategy

4.3.6.4.10. Create Architecture Roadmap & Implementation and Migration Plan

4.3.6.4.11. Refine and validate dependencies

4.3.6.5. Outputs

4.3.6.5.1. Diagrams: Product context diagram, benefits diagram

4.3.7. Phase F: Migration Planning

4.3.7.1. Intro

4.3.7.1.1. Include assessing the dependencies, costs, and benefits of the various migration projects.

4.3.7.1.2. Phase F confirms the Transition Architectures defined in Phase E with the relevant stakeholders and finalizes them.

4.3.7.1.3. Provides a schedule of the projects that will realize the Target Architecture.

4.3.7.1.4. A series of Transition Architectures should be planned that take into account the priorities.

4.3.7.1.5. Detailed resource estimates should be created for the work to be completed and the business value identified for all deliverables.

4.3.7.1.6. When this is completed the Implementation and Migration Plan can be finalized.

4.3.7.1.7. Migration planning should be conducted by the enterprise architecture team.

4.3.7.1.8. The approach should be confirmed and coordinated with the corporate management frameworks involved.

4.3.7.1.9. The Business Planning, Portfolio Management, and Operations Management groups should all be involved in the development of the major deliverables.

4.3.7.1.10. Once the deliverables have been completed, the architecture development cycle should be completed.

4.3.7.2. Objectives

4.3.7.2.1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan

4.3.7.2.2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio

4.3.7.3. Approach

4.3.7.3.1. The focus of Phase F is the creation of an Implementation and Migration Plan in co-operation with the portfolio and project managers.

4.3.7.3.2. Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Request for Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are integrated with the enterprise’s other change activity

4.3.7.3.3. Activities include assessing the dependencies, costs, and benefits of the various migration projects within the context of the enterprise’s other activity.

4.3.7.4. Outputs

4.3.7.4.1. Implementation and Migration Plan, version 1.0

4.3.7.4.2. Re-useable Architecture Building Blocks (ABBs)

4.3.7.4.3. Finalized

4.3.7.4.4. Requests for Architecture Work for next ADM cycle (if any)

4.3.7.4.5. Implementation of governance model

4.3.7.4.6. Change requests for architecture capability from lessons learned

4.3.7.5. Steps

4.3.7.5.1. 1. Confirm management framework interactions for Implementation and Migration Plan

4.3.7.5.2. 2. Assign a business value to each work package

4.3.7.5.3. 3. Estimate resource requirements, project timings, and availability/delivery vehicle

4.3.7.5.4. 4. Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation

4.3.7.5.5. 5. Confirm Architecture Roadmap and update Architecture Definition Document

4.3.7.5.6. Complete

4.3.8. Phase H: Architecture Change Management

4.3.8.1. Objectives

4.3.8.1.1. Monitoring Changes

4.3.8.1.2. Ensure Architecture

4.3.8.2. Approach

4.3.8.2.1. The enterprise change management process determines how changes are managed

4.3.8.2.2. Drivers for change – not always strategic in this phase, but reacting to “reality”

4.3.8.2.3. How to determine what is simple maintenance vs redoing the ADM cycle

4.3.8.3. Steps

4.3.8.3.1. Establish value realization process

4.3.8.3.2. Deploy monitoring tools

4.3.8.3.3. Provide analysis for architecture change management

4.3.8.3.4. Develop change requirements to meet performance targets

4.3.8.3.5. Manage risks

4.3.8.3.6. Manage governance process

4.3.8.3.7. Activate the process to implement change

4.3.8.4. Outputs

4.3.8.4.1. Architecture updates (for maintenance changes)

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

4.3.8.4.3. New Request for Architecture Work

4.3.8.4.4. Statement of Architecture Work (see Part IV, 32.2.20 Statement of Architecture Work), updated if necessary

4.3.8.4.5. Architecture Contract updated if necessary

4.3.8.4.6. Compliance Assessments, updated if necessary

4.3.9. Requirements Management

4.3.9.1. Summary

4.3.9.1.1. Center of the hub

4.3.9.1.2. Operates continuously during the ADM process

4.3.9.1.3. Requirements change all the time, regardless what phase you’re currently in

4.3.9.1.4. RM involves assessing impact of these changes

4.3.9.2. Objectives

4.3.9.2.1. Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases

4.3.9.2.2. Manage architecture requirements identified during any execution of the ADM cycle or a phase

4.3.9.2.3. Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

4.3.9.3. Approach

4.3.9.3.1. Center of the hub – continuously drives the ADM cycle

4.3.9.3.2. Each phase of the ADM, the architect should identify which requirements are relevant for that phase

4.3.9.3.3. No specific tool is recommended within TOGAF for managing requirements

4.3.9.4. Steps

4.3.9.4.1. Identify

4.3.9.4.2. Assess

4.3.9.4.3. Implement

4.3.9.4.4. 8. Update the requirements repository

4.3.9.4.5. 2. Baseline requirements

4.3.9.4.6. 3. Monitor baseline requirements

5. Part 4: Architecture Content Framework

5.1. Intro.

5.1.1. This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables

5.1.2. Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc.

5.1.3. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented

5.2. Content Metamodel

5.2.1. 1. Overview

5.2.1.1. The content metamodel provides formal structure for these terms to ensure consistency within the ADM and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.

5.2.2. 2. Content Metamodel Vision and Concepts

5.2.2.1. 1. Core Content Metamodel Concepts

5.2.2.1.1. Core and extension content

5.2.2.1.2. Core Metamodel Entities

5.2.2.1.3. Catalog, matrix, and diagram concept

5.2.2.2. 2. Overview of the Content Metamodel

5.2.2.2.1. Architecture Principles, Vision, and Requirements artifacts

5.2.2.2.2. Business Architecture artifacts

5.2.2.2.3. Technology Architecture artifacts

5.2.2.2.4. Information Systems Architecture artifacts

5.2.2.2.5. Architecture Realization artifacts

5.2.3. 3. Content Metamodel in Detail

5.2.3.1. Core Content Metamodel

5.2.3.2. Core Architecture Artifacts

5.2.3.3. Full Content Metamodel

5.2.4. 4. Content Metamodel Extensions

5.2.4.1. Governance Extensions

5.2.4.1.1. Purpose

5.2.4.1.2. Used in situations:

5.2.4.2. Services Extensions

5.2.4.2.1. Purpose

5.2.4.2.2. Used in situations:

5.2.4.3. Process Modeling Extensions

5.2.4.3.1. Purpose

5.2.4.3.2. Used in situations:

5.2.4.4. Data Extensions

5.2.4.4.1. Purpose

5.2.4.4.2. Used in situations:

5.2.4.5. Infrastructure Consolidation Extensions

5.2.4.5.1. Purpose

5.2.4.5.2. Used in situations:

5.2.4.6. Motivation Extensions

5.2.4.6.1. Purpose

5.2.4.6.2. Used in situations:

5.2.5. 5. Content Metamodel Entities

5.2.6. 6. Content Metamodel Attributes

5.2.7. 7. Metamodel Relationships

5.3. Architectural Artifacts

5.3.1. Classifications

5.3.1.1. Catalogs

5.3.1.1.1. Catalogs are lists of building blocks of a specific type, or of related types, that are used for governance or reference purposes (for example, an organization chart, showing locations and actors).

5.3.1.1.2. As with building blocks, catalogs carry metadata according to the metamodel, which supports query and analysis.

5.3.1.2. Matrices

5.3.1.2.1. Matrices are grids that show relationships between two or more model entities. Matrices are used to represent relationships that are list-based rather than graphical in their usage (for example, a CRUD matrix showing which applications Create, Read, Update, and Delete a particular type of data is difficult to represent visually).

5.3.1.3. Diagrams

5.3.1.3.1. Diagrams are renderings of architectural content in a graphical format to allow stakeholders to retrieve the required information. Diagrams can also be used as a technique for graphically populating architecture content or for checking the completeness of information that has been collected. TOGAF defines a set of architecture diagrams to be created (e.g., organization chart). Each of these diagrams may be created several times for an architecture with different style or content coverage to suit stakeholder concerns.

5.3.2. Artifacts

5.3.2.1. Preliminary Phase

5.3.2.1.1. catalog

5.3.2.1.2. P ➢P

5.3.2.2. Phase A, Architecture Vision

5.3.2.2.1. matrix

5.3.2.2.2. diagram

5.3.2.2.3. "Stakeholders" think of "Value" about the "solution"

5.3.2.3. Phase B, Business Architecture

5.3.2.3.1. catalog

5.3.2.3.2. matrix

5.3.2.3.3. diagram

5.3.2.4. Phase C, Data Architecture

5.3.2.4.1. catalog

5.3.2.4.2. matrix

5.3.2.4.3. diagram

5.3.2.5. Phase C, Application Architecture

5.3.2.5.1. catalog

5.3.2.5.2. matrix

5.3.2.5.3. diagram

5.3.2.6. Phase D, Technology Architecture

5.3.2.6.1. catalog

5.3.2.6.2. matrix

5.3.2.6.3. diagram

5.3.2.7. Phase E. Opportunities & Solutions

5.3.2.7.1. Project Context diagram

5.3.2.7.2. Benefits diagram

5.3.2.8. Requirements Management

5.3.2.8.1. Requirements catalog

5.3.2.9. Others

5.3.2.9.1. http://player.slideplayer.info/27/9134417/#

5.3.2.9.2. Core Architecture Artifacts

5.4. Architecture Deliverables

5.4.1. 1. Architecture Building Blocks

5.4.1.1. characteristics:

5.4.1.1.1. Capture architecture requirements (BDAT)

5.4.1.1.2. Direct and guide the development of SBBs

5.4.1.2. contain the following, at a minimum

5.4.1.2.1. Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability

5.4.1.2.2. Interfaces: chosen set, supplied

5.4.1.2.3. Interoperability and relationship with other building blocks

5.4.1.2.4. Dependent building blocks with required functionality and named user interfaces

5.4.1.2.5. Map to business/organizational entities and policies

5.4.2. 2. Architecture Contract

5.4.2.1. Architecture Design and Development

5.4.2.1.1. Introduction and background

5.4.2.1.2. The nature of the agreement

5.4.2.1.3. Scope of the architecture

5.4.2.1.4. Architecture and strategic principles and requirements

5.4.2.1.5. Conformance requirements

5.4.2.1.6. Architecture development and management process and roles

5.4.2.1.7. Target Architecture measures

5.4.2.1.8. Defined phases of deliverables

5.4.2.1.9. Prioritized joint workplan

5.4.2.1.10. Time window(s)

5.4.2.1.11. Architecture delivery and business metrics

5.4.2.2. Business Users' Architecture Contract

5.4.2.2.1. Introduction and background

5.4.2.2.2. The nature of the agreement

5.4.2.2.3. Scope

5.4.2.2.4. Strategic requirements

5.4.2.2.5. Conformance requirements

5.4.2.2.6. Architecture adopters

5.4.2.2.7. Time window

5.4.2.2.8. Architecture business metrics

5.4.2.2.9. Service architecture (includes Service Level Agreement (SLA))

5.4.3. 3. Architecture Definition Document

5.4.3.1. is a companion to the Architecture Requirements Specification, with a complementary objective:

5.4.3.1.1. The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.

5.4.3.1.2. The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

5.4.3.2. Def.

5.4.3.2.1. The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information.

5.4.3.2.2. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).

5.4.4. 4. Architecture Principles

5.4.5. 5. Architecture Repository

5.4.6. 6. Architecture Requirements Specification

5.4.6.1. provides

5.4.6.1.1. a qualitative view of the solution and aims to communicate the intent of the architect.

5.4.6.1.2. a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

5.4.7. 7. Architecture Roadmap

5.4.7.1. Work package portfolio:

5.4.7.2. Implementation Factor Assessment and Deduction matrix, including:

5.4.7.2.1. Risks, Issues, Assumptions, Dependencies, Actions, Inputs

5.4.7.3. Consolidated Gaps, Solutions, and Dependencies matrix, including:

5.4.7.3.1. Architecture domain, Gap, Potential solutions, Dependencies

5.4.7.4. Any Transition Architectures

5.4.7.5. Implementation recommendations:

5.4.7.5.1. Criteria measures of effectiveness of projects, Risks and issues, Solution Building Blocks (SBBs)

5.4.8. 8. Architecture Vision

5.4.8.1. The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.

5.4.8.2. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome.

5.4.8.3. Early agreement on the outcome enables the architects to focus on the detail necessary to validate feasibility.

5.4.8.4. Providing an Architecture Vision also supports stakeholder communication by providing a summary version of the full Architecture Definition.

5.4.9. 9. Business Principles, Business Goals, and Business Drivers

5.4.10. 10. Capability Assessment

5.4.10.1. Explanation

5.4.10.1.1. Capability assessments are tracked, and updated occasionally to ensure progress made from baseline to target capabilities.

5.4.10.1.2. First created in Phase A, and updated in Phase E.

5.4.10.1.3. An honest assessment of the capability of an enterprise across many different disciplines.

5.4.10.1.4. Being honest about your ability to execute a business plan successfully will help with designing backup plans, and indicate where potential structural problems are that need to be addressed.

5.4.10.2. IT Capability Assessment

5.4.10.2.1. Baseline and target maturity level of

5.4.10.2.2. Baseline capability and capacity assessment

5.4.10.2.3. Assessment of the likely impacts to the IT organization resulting from the successful deployment of the Target Architecture

5.4.10.3. Architecture Maturity Assessment

5.4.10.3.1. Architecture governance processes, organization, roles, and responsibilities

5.4.10.3.2. Breadth, depth, and quality of

5.4.10.3.3. Architecture skills assessment

5.4.10.3.4. Assessment of re-use potential

5.4.10.4. Business Capability Assessment

5.4.10.4.1. Capabilities of the business

5.4.10.4.2. Baseline state assessment of performance

5.4.10.4.3. Future state aspiration of performance

5.4.10.4.4. Baseline state assessment of how each capability is realized

5.4.10.4.5. Future state aspiration of how each capability is realized

5.4.10.4.6. Assessment of likely impacts to the business if the Target Architecture is realized

5.4.11. 11. Communications Plan

5.4.11.1. Identification of stakeholders and grouping by communication requirements

5.4.11.2. Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and Critical Success Factors (CSFs)

5.4.11.3. Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.

5.4.11.4. Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location

5.4.12. 12. Compliance Assessment

5.4.12.1. Overview of project progress and status

5.4.12.2. Overview of project architecture/design

5.4.12.3. Completed architecture checklists:

5.4.12.3.1. Hardware and operating system,

5.4.12.3.2. Software services and middleware

5.4.12.3.3. Applications, Information management,

5.4.12.3.4. Security

5.4.12.3.5. System management

5.4.12.3.6. System engineering

5.4.12.3.7. Methods and tools

5.4.13. 13. Implementation and Migration Plan

5.4.13.1. Implementation and Migration Strategy

5.4.13.2. Project and portfolio breakdown of implementation:

5.4.13.2.1. Allocation of work packages to project and portfolio,

5.4.13.2.2. Capabilities delivered by projects,

5.4.13.2.3. Milestones and timing

5.4.13.2.4. Work breakdown structure

5.4.13.2.5. May include impact on existing portfolio,

5.4.13.2.6. program, and projects

5.4.14. 14. Implementation Governance Model

5.4.14.1. Governance processes

5.4.14.2. Governance organization structure

5.4.14.3. Governance roles and responsibilities

5.4.14.4. Governance checkpoints and success/failure criteria

5.4.15. 15. Organizational Model for Enterprise Architecture

5.4.15.1. Scope of organizations impacted

5.4.15.2. Maturity assessment, gaps, and resolution approach

5.4.15.3. Roles and responsibilities for architecture team(s)

5.4.15.4. Constraints on architecture work

5.4.15.5. Budget requirements

5.4.15.6. Governance and support strategy

5.4.16. 16. Request for Architecture Work

5.4.16.1. Organization sponsors

5.4.16.2. Organization's mission statement

5.4.16.3. This is the request sent from the sponsoring organization (business sponsor) to the architecture group to request that architecture work be done.It is a high-level new project request.

5.4.16.4. Business goals (and changes)

5.4.16.5. Strategic plans of the business

5.4.16.6. Time limits

5.4.16.7. Changes in the business environment

5.4.17. 17. Change Request

5.4.18. 18. Requirements Impact Assessment

5.4.18.1. Reference to specific requirements

5.4.18.2. Stakeholder priority of the requirements to date

5.4.18.3. Phases to be revisited

5.4.18.4. Phase to lead on requirements prioritization

5.4.18.5. Results of phase investigations and revised priorities

5.4.18.6. Recommendations on management of requirements

5.4.18.7. Repository reference number

5.4.19. 19. Solution Building Blocks

5.4.19.1. Characteristics

5.4.19.1.1. Define what products and components will implement the functionality

5.4.19.1.2. Define the implementation

5.4.19.1.3. Fulfil business requirements

5.4.19.1.4. Are product or vendor-aware

5.4.19.2. Contents

5.4.19.2.1. Specific functionality and attributes

5.4.19.2.2. Interfaces; the implemented set

5.4.19.2.3. Required SBBs used with required functionality and names of the interfaces used

5.4.19.2.4. Mapping from the SBBs to the IT topology and operational policies

5.4.19.2.5. Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability

5.4.19.2.6. Performance, configurability

5.4.19.2.7. Design drivers and constraints, including the physical architecture

5.4.19.2.8. Relationships between SBBs and ABBs

5.4.20. 20. Statement of Architecture Work

5.4.20.1. Title

5.4.20.2. Architecture project request and background

5.4.20.3. Architecture project description and scope

5.4.20.4. Overview of Architecture Vision

5.4.20.5. Specific change of scope procedures

5.4.20.6. Roles, responsibilities, and deliverables

5.4.20.7. Acceptance criteria and procedures

5.4.20.8. Architecture project plan and schedule

5.4.20.9. Approvals

5.4.21. 21. Tailored Architecture Framework

5.4.21.1. Tailored architecture method

5.4.21.2. Tailored architecture content (deliverables and artifacts)

5.4.21.3. Configured and deployed tools

5.4.21.4. Interfaces with governance models and other frameworks

5.4.21.4.1. Corporate Business Planning

5.4.21.4.2. Enterprise Architecture

5.4.21.4.3. Portfolio, Program, Project Management

5.4.21.4.4. System Development/Engineering

5.4.21.4.5. Operations (Services)

5.5. Building Blocks

5.5.1. Characteristics

5.5.1.1. is a package of functionality defined to meet the business needs across an organization.

5.5.1.2. has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

5.5.1.3. has a defined boundary and is generally recognizable as "a thing" by domain experts.

5.5.1.4. A building block may interoperate with other, inter-dependent, building blocks

5.5.2. A good building block has the following characteristics:

5.5.2.1. It considers implementation and usage, and evolves to exploit technology and standards.

5.5.2.2. It may be assembled from other building blocks.

5.5.2.3. It may be a subassembly of other building blocks.

5.5.2.4. Ideally a building block is re-usable and replaceable, and well specified

5.5.3. Architecture Building Blocks

5.5.3.1. Characteristics

5.5.3.1.1. Capture architecture requirements; e.g., business, data, application, and technology requirements

5.5.3.1.2. Direct and guide the development of SBBs

5.5.4. Solution Building Blocks

5.5.4.1. Characteristics

5.5.4.1.1. Define what products and components will implement the functionality

5.5.4.1.2. Define the implementation

5.5.4.1.3. Fulfil business requirements

5.5.4.1.4. Are product or vendor-aware

5.5.4.2. The first occurence of Solution building blocks happen in Phase E

5.5.5. Building Block Specification Process in the ADM

5.5.5.1. The process of building block definition takes place gradually as the ADM is followed, mainly in Phases A, B, C, and D.

5.5.5.2. The major work in these steps consists of identifying the ABBs required to meet the business goals and objectives.

5.5.5.3. The selected set of ABBs is then refined in an iterative process to arrive at a set of SBBs which can either be bought off-the-shelf or custom developed.

5.5.5.4. It is an iterative process because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of products may affect the choice and the content of building blocks.

6. Part 7: Architecture Capability Framework

6.1. Overview

6.1.1. In order to successfully operate an architecture function within an enterprise, it is necessary to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability.

6.1.2. Part VII: Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

6.2. Establishing an Architecture Capability

6.2.1. Can be supported by the TOGAF Architecture Development Method (ADM).

6.2.2. Require the design of the four domain architectures

6.3. Architecture Board

6.3.1. Responsibilities

6.3.1.1. Common Goals

6.3.1.1.1. Providing the basis for all decision-making with regard to the architectures

6.3.1.1.2. Consistency between sub-architectures

6.3.1.1.3. Establishing targets for re-use of components

6.3.1.1.4. Flexibility of enterprise architecture:

6.3.1.1.5. Enforcement of Architecture Compliance

6.3.1.1.6. Improving the maturity level of architecture discipline within the organization

6.3.1.1.7. Ensuring that the discipline of architecture-based development is adopted

6.3.1.1.8. Supporting a visible escalation capability for out-of-bounds decisions

6.3.1.2. Operational

6.3.1.2.1. All aspects of monitoring and control of the Architecture Contract

6.3.1.2.2. Meeting on a regular basis

6.3.1.2.3. Ensuring the effective and consistent management and implementation of the architectures

6.3.1.2.4. Resolving ambiguities, issues, or conflicts that have been escalated

6.3.1.2.5. Providing advice, guidance, and information

6.3.1.2.6. Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives

6.3.1.2.7. Considering policy (schedule, Service Level Agreements (SLAs), etc.) changes where similar dispensations are requested and granted; e.g., new form of service requirement

6.3.1.2.8. Ensuring that all information relevant to the implementation of the Architecture Contract is published under controlled conditions and made available to authorized parties

6.3.1.2.9. Validation of reported service levels, cost savings, etc.

6.3.1.3. Governance

6.3.1.3.1. The production of usable governance material and activities

6.3.1.3.2. Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication

6.3.1.3.3. Providing a fundamental control mechanism for ensuring the effective implementation of the architecture

6.3.1.3.4. Establishing and maintaining the link between the implementation of the architecture, the architectural strategy and objectives embodied in the enterprise architecture, and the strategic objectives of the business

6.3.1.3.5. Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates

6.3.2. Role

6.3.2.1. A key element in a successful architecture governance strategy (see 50. Architecture Governance) is a cross-organization Architecture Board to oversee the implementation of the strategy

6.3.2.2. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.

6.3.2.3. levels

6.3.2.3.1. Local (domain experts, line responsibility)

6.3.2.3.2. Global (organization-wide responsibility)

6.3.3. Setting Up the Architecture Board

6.3.3.1. Triggers

6.3.3.1.1. New CIO

6.3.3.1.2. Merger or acquisition

6.3.3.1.3. Consideration of a move to newer forms of computing

6.3.3.1.4. Recognition that IT is poorly aligned to business

6.3.3.1.5. Desire to achieve competitive advantage via technology

6.3.3.1.6. Creation of an enterprise architecture program

6.3.3.1.7. Significant business change or rapid growth

6.3.3.1.8. Requirement for complex, cross-functional solutions

6.3.3.2. Sponsorship

6.3.3.2.1. In many companies, the executive sponsor of the initial architecture effort is the CIO

6.3.3.2.2. it is the executive-level group responsible for the review and maintenance of the strategic architecture and all of its sub-architectures.

6.3.3.2.3. The Architecture Board is the sponsor of the architecture within the enterprise, but the Architecture Board itself needs an executive sponsor from the highest level of the corporation. This commitment must span the planning process and continue into the maintenance phase of the architecture project.

6.3.3.2.4. In many companies that fail in an architecture planning effort, there is a notable lack of executive participation and encouragement for the project.

6.3.3.3. Size of the Board

6.3.3.3.1. Architecture Board is four or five (and no more than ten) permanent members.

6.3.3.3.2. Membership Rotation

6.3.3.3.3. Board Structure

6.3.3.3.4. Operation of the Architecture Board

6.4. Architecture Compliance

6.4.1. Terminology

6.4.1.1. Irrelevant

6.4.1.1.1. The implementation has no features in common with the architecture implementation (so the question of conformance does not arise)

6.4.1.2. Consistent

6.4.1.2.1. Implementation has some features in common with the architecture implementation, A-I (50-50)

6.4.1.3. Compliant

6.4.1.3.1. Some of the features are not implemented, but all are in accordance with the specifications) I within A

6.4.1.4. Conformanance

6.4.1.4.1. Conformant

6.4.1.4.2. Fully Conformant

6.4.1.4.3. Non-conformant

6.4.2. Architecture Compliance Reviews

6.4.2.1. Purpose

6.4.2.1.1. Quality Assurance

6.4.2.1.2. Politically-oriented motivations

6.4.2.2. Timing

6.4.2.2.1. Specific checkpoints

6.4.2.3. Governance and Personnel Scenario

6.4.2.3.1. For smaller-scale projects,

6.4.2.3.2. In larger-scale projects,

6.4.2.4. Architecture Compliance Review Process

6.4.2.4.1. Architecture Board

6.4.2.4.2. Project Leader/Board

6.4.2.4.3. Architecture Review/Co-ordinator

6.4.2.4.4. Lead Enterprise Architect

6.4.2.4.5. Architect

6.4.2.4.6. Customer

6.4.2.4.7. Business Domain Expert

6.4.2.4.8. Project Principals

6.5. Architecture Contracts

6.5.1. Architecture Contracts are the joint agreements between development partners and sponsors on the:

6.5.1.1. Deliverables

6.5.1.2. Quality

6.5.1.3. Fitness-for-purpose of an architecture

6.5.2. Successful implementation of these agreements will be delivered through effective architecture governance

6.6. Architecture Governance

6.6.1. Hierarchy of Governance:

6.6.1.1. Corporate Governance (Executive Team & Board of Directors)

6.6.1.2. Technology Governance

6.6.1.2.1. Technology governance controls how an organization utilizes technology in the research, development, and production of its goods and services. Although it may include IT governance activities, it often has broader scope.

6.6.1.2.2. Technology governance is a key capability, requirement, and resource for most organizations because of the pervasiveness of technology across the organizational spectrum.

6.6.1.3. IT Governance

6.6.1.3.1. IT governance provides the framework and structure that links IT resources and information to enterprise goals and strategies.

6.6.1.3.2. Furthermore, IT governance institutionalizes best practices for planning, acquiring, implementing, and monitoring IT performance, to ensure that the enterprise's IT assets support its business objectives.

6.6.1.4. Architecture Governance

6.6.1.4.1. System of controls over all architecture components and activities

6.6.1.4.2. System to ensure compliance with internal and external standards and legal obligations

6.6.1.4.3. Processes to support effective management of the above two

6.6.1.4.4. Practices that ensure accountability

6.6.2. Characteristics of Governance

6.6.2.1. Discipline

6.6.2.1.1. – adhere to authority, policies and procedures

6.6.2.2. Transparency

6.6.2.2.1. – all actions available for inspection

6.6.2.3. Independence

6.6.2.3.1. – minimize conflicts of interest

6.6.2.4. Accountability

6.6.2.4.1. – authorized and accountable for their actions

6.6.2.5. Responsibility

6.6.2.5.1. – required to act responsibly

6.6.2.6. Fairness

6.6.2.6.1. – not allowed to create an unfair advantage

6.6.3. Architecture Governance Framework

6.6.3.1. Processes

6.6.3.1.1. Policy Management and Take-On

6.6.3.1.2. Compliance

6.6.3.1.3. Dispensation

6.6.3.1.4. Monitoring and Reporting

6.6.3.1.5. Business Control

6.6.3.1.6. Environment Management

6.6.3.2. Architecture Governance Organization

6.7. Architecture Maturity Models

6.7.1. Capability Maturity Models (CMMs)

6.7.1.1. They describe the practices that any organization must perform in order to improve its processes.

6.7.1.2. They provide a yardstick against which to periodically measure improvement.

6.7.1.3. They constitute a proven framework within which to manage the improvement efforts

6.7.1.4. They organize the various practices into levels, each level representing an increased ability to control and manage the development environment.

6.8. Architecture Skills Framework

6.8.1. Provide a view of the competency levels required for specific roles

6.8.1.1. The roles within a work area

6.8.1.2. The skills required by each role

6.8.1.3. The depth of knowledge required to fulfil the role successfully

6.8.2. Goals

6.8.2.1. Certification of Enterprise Architects

6.8.2.1.1. To formally recognize the skill of its practicing architects,

6.8.2.1.2. To ensure the alignment of necessary staff skills and experience with the architecture tasks that the enterprise wishes to be performed

6.8.2.2. Specific Benefits

6.8.2.2.1. Reduced time, cost, and risk in training, hiring, and managing architecture professionals, both internal and external

6.8.2.2.2. Reduced time and cost to set up an internal architecture practice

6.8.2.2.3. Reduced time and cost to implement an architecture practice helps reduce the time, cost, and risk of overall solution development

6.8.3. Enterprise Architecture Role and Skill Categories

6.8.3.1. Overview

6.8.3.1.1. This section describes the role of an enterprise architect, the fundamental skills required, and some possible disciplines in which an enterprise architect might specialize.

6.8.3.2. TOGAF Roles

6.8.3.2.1. A typical architecture team undertaking the development of an enterprise architecture as described in TOGAF would comprise the following roles:

6.8.3.2.2. Architecture Board Members

6.8.3.2.3. Architecture Sponsor

6.8.3.2.4. Architecture Manager

6.8.3.2.5. Architects for

6.8.3.3. Categories of Skills

6.8.3.3.1. The TOGAF team skill set will need to include the following main categories of skills:

6.8.3.3.2. Generic Skills

6.8.3.3.3. Business Skills & Methods:

6.8.3.3.4. Enterprise Architecture Skills

6.8.3.3.5. Program or Project Management Skills

6.8.3.3.6. IT General Knowledge Skills

6.8.3.3.7. Technical IT Skills

6.8.3.3.8. Legal Environment

6.8.3.4. Proficiency Levels

6.8.4. Enterprise Architecture Role and Skill Categories

7. Part 6 TOGAF Reference Models

7.1. Foundation Architecture: TRM

7.1.1. Intro

7.1.1.1. The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built.

7.1.1.2. It's considered for use in this phase C. It focuses on the application-level components and services necessary to provide an integrated information infrastructure.

7.1.2. TRM

7.1.2.1. TRM in Detail

7.1.2.1.1. Distinct entities

7.1.2.1.2. Distinct interfaces

7.1.2.1.3. Qualities

7.1.2.2. Provide a visual model, and core terminology for generic platform services

7.1.2.3. Provides a database of standards that can be used to define the particular services and other components of an organization-specific architecture that is derived from the TOGAF Foundation Architecture

7.1.3. SIB

7.2. Integrated Information Infrastructure Reference Model) III-RM

7.2.1. Boundaryless Information Flow

8. Others

8.1. Resources

8.1.1. ADM Steps Reference

8.1.2. Architectural Artifacts

8.1.3. TOGAF 9 certification preparation advices & exam tips

8.1.4. Togaf Modeling

8.2. Exams

8.2.1. Level 1

8.2.1.1. Exam 1

8.2.1.2. Questions and Answers

8.2.2. Level 2

8.3. What's new in 9.2

8.3.1. Move to Modular

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

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

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

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

8.3.2. Why

8.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

8.3.3. ADM Vision and Business Phases

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

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

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

8.3.4. Content Metamodel

8.3.4.1. The TOGAF content metamodel has been expanded.

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

8.3.4.3. Location is now a global entity.

8.3.5. Summary

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