TOGAF 9.2 Foundation

What is an Enterprise?

Any collection of organizations that has a common goal.

What is the purpose of an Enterprise Architecture?

Optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

What are the business benefits of having an Enterprise Architecture?

Lower business operation costs.

More agile organization.

Business capabilities shared across the organization.

Lower change management costs.

More flexible workforce.

Improved business productivity.

Reduced complexity in the business and IT.

Define what is an Architecture Framework?

A functional structure, or a set of structures, that can be used for developing a broad range of different architectures.

Why TOGAF is suitable for an Enterprise Architecture?

Developed through the collaborative efforts of the whole community.

Using the TOGAF standard results in Enterprise Architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and to the perceived future needs of the business.

What is the structure of the TOGAF standard?

Architecture Capability Framework.

Architecture Development Method (ADM).

ADM Guidelines and Techniques.

Architecture Content Framework.

Enterprise Continuum and Tools.

TOGAF Reference Materials.

What is TOGAF standard?

An architecture framework. It provides the methods and tools for assisting in the acceptance, production, use, and maintenance of Enterprise Architectures.

Based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.

What is an Architecture in the context of the TOGAF Standard?

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

What is an Architecture in the context of the ISO/IEC/IEEE 42010:2011 Standard?

The fundamental Concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

What are different types of architecture TOGAF deals with?

Business Architecture.

Data Architecture.

Application Architecture.

Technology Architecture.

What is TOGAF Library?

Is a reference library containing guidelines, templates, patterns, and other forms of reference material to accelerate the creation of new architectures for the enterprise.

Enterprise Continuum.

View of architecture repository.

From most generic architecture on left and Organization specific architecture on the right.

TOGAF Library Sections.

Section 1: Base Documents.

Section 2: Generic Guidance and Techniques.

Section 3: Industry-Specific Guidance and Techniques.

Section 4: Organization-Specific Guidance and Techniques.

Application Architecture

A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.

Architectural Style.

The combination of distinctive features in which architecture is performed or expressed.

Architecture.

1. The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design evolution.

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution overtime.

Architecture Building Block (ABB).

A constituent of the architecture model that describes a single aspect of the overall model. (Requirement)

Architecture Continuum.

A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization.

This Continuum begins with foundational definitions such as reference models, core strategies, and basic building blocks. From there it spans to Industry Architectures and all the way to an organization's specific architecture.

Architecture Development Method (ADM).

A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation and implementation projects. The core of the TOGAF framework.

Architecture Domain.

The architectural area being considered.

There are four architecture domains within the TOGAF standard: Business, Data, Application, and Technology.

Other domains may also be considered (eg, Security).

Architecture Framework.

A conceptual structure used to develop, implement, and sustain an architecture.

Architecture Governance.

The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps.

Architecture Principle.

A qualitative statement of intent that should be met by the architecture.

Architecture View.

A representation of a system from the perspective of a related set of concerns.

(View is sometimes used as a synonym for Architecture View.)

Architecture Viewpoint.

A specification of the conventions for a particular kind of architecture view.

(View point is sometimes used as a synonym for Architecture Viewpoint.)

Architecture Vision.

A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment.

It serves as an aspirational vision and a boundary for detailed architecture development.

Artifact.

An architectural work product that describes an aspect of the architecture.

Baseline.

A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

Building Block.

A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions.

Business Architecture.

A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

Business Capability.

A particular ability that a business may possess or exchange to achieve a specific purpose.

Business Governance.

Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation.

Capability.

An ability that an organization, person, or system possesses.

Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve; or example, marketing, customer contact, or outbound telemarketing.

Concern.

An interest in a system relevant to one or more of its stakeholders.

Course of Action.

Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model.

Data Architecture.

A description of the structure and interaction of the enterprise's major types and sources of data, logical data assets, physical data assets, and data management resources.

Deliverable.

An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.

Note: Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.

Enterprise.

The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.

Foundation Architecture.

Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built.

Gap.

A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.

Governance.

The discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required.

Information.

Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual.

Information Technology (IT)

The lifecycle management of information and related technology used by an organization.

Logical Architecture

An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure; for example, the products from multiple infrastructure software vendors can all be logically grouped as Java application server platforms.

Metadata.

Data about data, of any sort in any media, that describes the characteristics of an entity.

Metamodel.

A model that describes how and with what the architecture will be described in a structured way.

Method.

A defined, repeatable approach to address a particular type of problem.

Modeling.

A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.

Objective.

A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example, "Increase Capacity Utilization by 30% by the end of 2019 to support the planned increase in market share".

Physical.

A description of a real-world entity. Physical elements in an Enterprise Architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.

Reference Model (RM).

A reference model is an abstract framework for understanding significant relationships among the entities of [an] environment, and for the development of consistent standards or specifications supporting that environment.

Repository.

A system that manages all of the data of an enterprise, including data and process models and other enterprise information.

Requirement.

A statement of need that must be met by a particular architecture or work package.

Segment Architecture.

A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.

Service.

1. A repeatable activity; a discrete behavior that a building block may be requested or otherwise triggered to perform.

2. An element of behavior that provides specific functionality in response to requests from actors or other services.

Solution Architecture.

A description of a discrete and focused business operation or activity and how IS/IT supports that operation.

Note: A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

Solution Building Block (SBB).

A candidate solution which conforms to the specification of an Architecture Building Block (ABB).(Implementation)

Solutions Continuum.

A part of the Enterprise Continuum.

A repository of re-usable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum.

Stakeholder.

An individual, team, organization, or class thereof, having an interest in a system.

Strategic Architecture.

A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.

Target Architecture.

The description of a future state of the architecture being developed for an organization.

Note: There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.

Technical Reference Model (TRM).

A structure which allows the components of an information system to be described in a consistent manner.

Technology Architecture.

A description of the structure and interaction of the technology services and technology components.

Transition Architecture.

A formal description of one state of the architecture at an architecturally significant point in time.

Note: One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.

Value Stream.

A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user.

Viewpoint Library.

A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository.

ADM Overview

Preliminary Phase.

A. Architecture Vision

B. Business Architecture.

C. Information Systems Architectures.

D. Technology Architecture.

E. Opportunities and Solutions.

F. Migration Planning.

G. Implementation Governance.

H. Architecture Change Management.

ADM - Preliminary Phase.

Defining "where, what, why, who, and how we do architecture".

Preparation and initiation activities to create an Architecture Capability.

Key activities are:

Understand the business environment.

Ensure high-level management commitment.

Obtain agreement on scope.

Establish Architecture Principles.

Establish governance structure.

Customization of the TOGAF framework.

ADM - Preliminary Phase - Objectives.

# Determine the Architecture Capability desired by the organization:

+ Review the organizational context for conducting Enterprise Architecture.

+ Identify and scope the elements of the enterprise organizations affected by the Architecture Capability.

+ Identify the established frameworks, methods, and processes that intersect with the Architecture Capability.

+ Establish a Capability Maturity target.

# Establish the Architecture Capability:

+ Define and establish the Organizational Model for Enterprise Architecture.

+ Define and establish the detailed process and resources for Architecture Governance.

+ Select and implement tools that support the Architecture Capability.

+ Define the Architecture Principles.

ADM - Preliminary Phase - Approach.

1. Defining the enterprise.

2. Identifying key drivers and elements in the organizational context.

3. Defining the requirements for architecture work.

4. Defining the Architecture Principles that will inform any architecture work.

5. Defining the framework to be used.

6. Defining the relationships between management frameworks.

7. Evaluating the Enterprise Architecture's maturity.

ADM - Requirements Management.

Ensure that every stage of a TOGAF project is based on and validates business requirements.

Requirements are identified, stored, and fed into and out of the relevant ADM phases, which dispose of, address, and prioritize requirements.

ADM - Phase A: Architecture Vision.

Set the scope, constraints, and expectations for a TOGAF project.

Create the Architecture Vision.

Identify stakeholders.

Validate the business context and create the Statement of Architecture Work.

Obtain approvals.

ADM -

Phase B: Business Architecture.

Phase C: Information Systems Architectures.

Phase D: Technology Architecture.

Develop Baseline and Target Architecture and analyze gaps in four domains (BDAT):

1. Business.

2. Application (Information Systems).

3. Data (Information Systems).

4. Technology.

ADM - Phase E: Opportunities and Solutions.

Perform initial implementation planning.

Identify delivery vehicles for the building blocks identified in the previous phases.

Determine whether an incremental approach is required, if so identify Transition Architectures.

ADM - Phase F: Migration Planning.

Develop detailed Implementation and Migration Plan,

that addresses how to move from the Baseline to the Target Architecture.

ADM - Phase G: Implementation Governance.

Provide architectural oversight for the implementation.

Prepare and issue Architecture Contracts.

Ensure implementation project conforms to the architecture.

ADM - Phase H: Architecture Change Management.

Provide continual monitoring and a change management process.

Ensure that the architecture responds to the needs of the enterprise, and maximizes the business value.

Preliminary Phase Steps.

1. Scope the enterprise organizations impacted.

2. Confirm governance and support frameworks.

3. Define and establish Enterprise Architecture team and organization.

4. Identify and establish Architecture Principles.

5. Tailor the TOGAF framework and, if any, other selected architecture frameworks.

6. Develop a strategy and implementation plan for tools and techniques.

Phase A: Architecture Vision Steps.

1. Establish the architecture project.

2. Identify stakeholders, concerns, and business

requirements.

3. Confirm and elaborate business goals, business drivers and constraints.

4. Evaluate capabilities.

5. Assess readiness for business transformation.

6. Define scope.

7. Confirm and elaborate Architecture Principles, including business principles.

8. Develop Architecture Vision.

9. Define the Target Architecture value propositions and KPIs.

10. Identify the business transformation risks and mitigation activities.

11. Develop Statement of Architecture Work; secure approval.

Phase B: Business Architecture.

Phase C: Information Systems Architectures.

Phase D: Technology Architectures.

Steps.

1. Select reference models, viewpoints, and tools.

2. Develop Baseline Architecture Description.

3. Develop Target Architecture Description.

4. Perform gap analysis.

5. Define candidate roadmap components.

6. Resolve impacts across the Architecture Landscape.

7. Conduct formal stakeholder review.

8. Finalize the Architecture.

9. Create Architecture Definition Document.

Phase E: Opportunities and Solutions Steps.

1. Determine/confirm key corporate change attributes.

2. Determine business constraints for implementation.

3. Review and consolidate gap analysis results from Phases B to D.

4. Review consolidated requirements across related business functions.

5. Consolidate and reconcile interoperability requirements.

6. Refine and validate dependencies.

7. Confirm readiness and risk for business transformation.

8. Formulate Implementation and Migration Strategy.

9. Identify and group major work packages.

10. Identify Transition Architectures.

11. Create Architecture Roadmap & Implementation and

Migration Plan.

Phase F: Migration Planning Steps.

1. Confirm management framework interactions for

Implementation and Migration Plan.

2. Assign a business value to each work package.

3. Estimate resource requirements, project timings, and

availability/delivery vehicle.

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

5. Confirm Architecture Roadmap and update Architecture Definition Document.

6. Complete the Implementation and Migration Plan.

7. Complete the development cycle and document lessons learned.

Phase G: Implementation Governance Steps.

1. Confirm scope and priorities for deployment with

development management.

2. Identify deployment resources and skills.

3. Guide development of solutions deployment.

4. Perform Enterprise Architecture Compliance reviews.

5. Implement business and IT operations.

6. Perform post-implementation review and close the

implementation.

Phase H: Architecture Change Management.

1. Establish value realization process.

2. Deploy monitoring tools.

3. Manage risks.

4. Provide analysis for architecture change management.

5. Develop change requirements to meet performance targets.

6. Manage governance process.

7. Activate the process to implement change.

Requirements Management Steps.

1. Identify/document requirements.

2. Baseline requirements.

3. Monitor baseline requirements.

4. Identify changed requirement; remove, add, modify, and re-assess priorities.

5. Identify changed requirement and record priorities; identify and resolve conflicts; generate requirements impact statements.

6. Assess impact of changed requirement on current and previous ADM phases.

7. Implement requirements arising from Phase H.

8. Update the Architecture Requirements Repository.

9. Implement change in the current phase.

10. Assess and revise gap analysis for past phases.

ADM Iterations.

1. Architecture Capability Iteration.

2. Architecture Development Iteration.

3. Transition Planning Iteration.

4. Architecture Governance Iteration.

Content Metamodel Overview. (CMO)

1. Architecture Principles, Vision and Requirements

2. Business Architecture.

3. Information Systems Architecture

4. Technology Architecture.

5. Architecture Realization.

CMO - 1. Architecture Principles, Vision and Requirements

1. Preliminary (Architecture Principles).

2. Architecture Vision (Business Strategy, Technology Strategy, Business Principles, Objectives, and Drivers, Architecture Vision, Stakeholders).

3. Architecture Requirements (Requirements, Constraints, Assumptions, Gaps, Locations).

CMO - 2. Business Architecture.

1. Motivation (Drivers, Goals, Objectives, Measures).

2. Organization (Organization | Actor, Role).

3. Behavior (Business Services, Contracts, Service Qualities | Processes, Events, Controls, Products | Functions, Business Capabilities, Course of Action, value Streams).

CMO - 3. Information Systems Architecture.

1. Data (Data Entities, Logical Data Components, Physical Data Components).

2. Application (Information System Services, Logical Application Components, Physical Application Components).

CMO - 4. Technology Architecture.

1. Technology Services.

2. Logical Technology Components.

3. Physical Technology Components.

CMO - 5. Architecture Realization.

1. Opportunities, Solutions, & Migration Planning (Capabilities, Work Packages, Architecture Contracts).

2. Implementation Governance (Standards, Guidelines, Specifications).

Artifacts Associated with the Content Metamodel.

Preliminary (Principles Catalog).

Architecture Vision (Stakeholder Map Matrix, Value Chain Diagram, Solution Concept Diagram).

Requirements Management (Requirements Catalog).

Opportunities and Solutions (Project Context Diagram, Benefits Diagram).

Business Architecture.

Data Architecture.

Application Architecture.

Technology Architecture.

Business Architecture Catalogs.

Organization/Actor Catalog.

Role Catalog.

Business Service/Function Catalog.

Location Catalog.

Process/Event/Control/ Product Catalog.

Value Stream Catalog.

Business Capabilities Catalog.

Value Stream Stages Catalog.

Driver/Goal/Objective Catalog.

Contract/Measure Catalog.

Business Architecture Matrices.

Business Interaction Matrix.

Actor/Role Matrix.

Value Stream/Capability Matrix.

Strategy/Capability Matrix.

Capability/Organization Matrix.

Business Architecture Core Diagrams.

Business Footprint Diagram.

Business Service/Information Diagram.

Functional Decomposition Diagram.

Product Lifecycle Diagram.

Business Model Diagram.

Business Capability Map.

Value Stream Map.

organization Map.

Business Architecture Extension Diagrams.

Goal/Objective/Service Diagram.

Business Use-Case Diagram.

Organization Decomposition Diagram.

Process Flow Diagram.

Event Diagram.

Data Architecture Catalogs.

Data Entity/ Data Component Catalog.

Data Architecture Matrices.

Data Entity/Business Function Matrix.

Application/Data Matrix.

Data Architecture Core Diagrams.

Conceptual Data Diagram.

Logical Data Diagram.

Data Dissemination Diagram.