-
2. Core Concepts
For the purposes of TOGAF 9, the core concepts provided in this chapter apply.
2.1 What is TOGAF?
TOGAF is an architecture framework - The Open Group Architecture Framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.
2.2 What is Architecture in the Context of TOGAF?
ISO/IEC 42010:2007 defines "architecture" as:
"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In TOGAF, "architecture" has two meanings depending upon the context:
- A formal description of a system, or a detailed plan of the system at component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
In TOGAF we endeavor to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 - ensuring that our usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard - and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts .
2.3 What Kind of Architecture Does TOGAF Deal With?
There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:
- The Business Architecture defines the business strategy, governance, organization, and key business processes.
- The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources.
- The Application Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
- The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.
2.4 Architecture Development Method
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.
All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.
Phases within the ADM are as follows:
- The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.
- Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
- Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.
- Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
- Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.
- Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.
- Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.
- Phase G: Implementation Governance provides an architectural oversight of the implementation.
- Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
- Requirements Management examines the process of managing architecture requirements throughout the ADM.
2.5 Deliverables, Artifacts, and Building Blocks
Architects executing the 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. The TOGAF Architecture Content Framework (see Part IV, 33. Introduction) provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.
The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:
- A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. 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.
- An artifact is a more granular architectural work product that describes an architecture from a specific viewpoint. Examples include a network diagram, a server specification, a use-case specification, a list of architectural requirements, and a business interaction matrix. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.
- A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be
combined with other building blocks to deliver architectures and solutions.
Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".
- Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.
- Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise.
The relationships between deliverables, artifacts, and building blocks are shown in Relationships between Deliverables, Artifacts, and Building Blocks .
Figure 2-1: Relationships between Deliverables, Artifacts, and Building Blocks For example, an Architecture Definition Document is a deliverable that documents an architecture description. This document will contain a number of complementary artifacts that are views of the building blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target call handling process (a building block). This artifact may also describe other building blocks, such as the actors involved in the process (e.g., a Customer Services Representative). An example of the relationships between deliverables, artifacts, and building blocks is illustrated in Example - Architecture Definition Document .
Figure 2-2: Example - Architecture Definition Document
2.6 Enterprise Continuum
TOGAF includes the concept of the Enterprise Continuum, which sets the broader context for an architect and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual organization. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.
An overview of the structure and context for the Enterprise Continuum is shown in Enterprise Continuum .
Figure 2-3: Enterprise Continuum
2.7 Architecture Repository
Supporting the Enterprise Continuum is the concept of an Architecture Repository which can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels.
By means of the Enterprise Continuum and Architecture Repository, architects are encouraged to leverage all other relevant architectural resources and assets in developing an Organization-Specific Architecture.
In this context, the TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository. The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and their relationships to each other, and the constraints and requirements on a cycle of architecture development.
The structure of the TOGAF Architecture Repository is shown in TOGAF Architecture Repository Structure .
Figure 2-4: TOGAF Architecture Repository Structure The major components within an Architecture Repository are as follows:
- The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
- The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
- The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.
- The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
- The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
- The Governance Log provides a record of governance activity across the enterprise.
2.8 Establishing and Maintaining an Enterprise Architecture Capability
In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. An overview of the TOGAF architecture capability is shown in TOGAF Architecture Capability Overview .
Figure 2-5: TOGAF Architecture Capability Overview
2.9 Establishing the Architecture Capability as an Operational Entity
Barring architecture capabilities set up to purely support change delivery programs, it is increasingly recognized that a successful enterprise architecture practice must sit on a firm operational footing. In effect, an enterprise architecture practice must be run like any other operational unit within a business; i.e., it should be treated like a business. To this end, and over and above the core processes defined within the ADM, an enterprise architecture practice should establish capabilities in the following areas:
- Financial Management (see 3.41 Financial Management)
- Performance Management (see 3.60 Performance Management)
- Service Management (see 3.73 Service Management)
- Risk Management (see A.76 Risk Management)
- Resource Management (see 3.69 Resource Management)
- Communications and Stakeholder Management (see 3.33 Communications and Stakeholder Management)
- Quality Management (see 3.65 Quality Management)
- Supplier Management (see A.83 Supplier Management)
- Configuration Management (see A.15 Configuration Management)
- Environment Management (see 3.40 Environment Management)
Central to the notion of operating an ongoing architecture is the execution of well-defined and effective governance, whereby all architecturally significant activity is controlled and aligned within a single framework.
As governance has become an increasingly visible requirement for organizational management, the inclusion of governance within TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.
The benefits of architecture governance include:
- Increased transparency of accountability, and informed delegation of authority
- Controlled risk management
- Protection of the existing asset base through maximizing re-use of existing architectural components
- Proactive control, monitoring, and management mechanisms
- Process, concept, and component re-use across all organizational business units
- Value creation through monitoring, measuring, evaluation, and feedback
- Increased visibility supporting internal processes and external parties' requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
- Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise - studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
- Integrates with existing processes and methodologies and complements functionality by adding control capabilities
Further detail on establishing an enterprise architecture capability is given in Part VII, 45. Introduction .
2.10 Using TOGAF with Other Frameworks
Two of the key elements of any enterprise architecture framework are:
- A definition of the deliverables that the architecting activity should produce
- A description of the method by which this should be done
With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).
Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.
As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.
In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP. Guidelines for adapting the TOGAF ADM in such a way are given in Part II, 5.3 Adapting the ADM .
As a generic framework and method for enterprise architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains, specific horizontal technology areas (such as security or manageability), or specific application areas (such as e-Commerce).
2.11 TOGAF Document Categorization Model
A TOGAF document categorization model exists to structure the release management of the TOGAF specification. It is not intended to serve as an implementation guide for practitioners.
Within the model, the content of the TOGAF document is categorized according to the following four categories:
- TOGAF Core consists of the fundamental concepts that form the essence of TOGAF.
- TOGAF Mandated consists of the normative parts of the TOGAF specification. These elements of TOGAF are central to its usage and without them the framework would not be recognizably TOGAF. Strong consideration must be given to these elements when applying TOGAF.
- TOGAF Recommended consists of a pool of resources that are specifically referenced in TOGAF as ways in which the TOGAF Core and Mandated processes can be accomplished (e.g., the SEI Architecture Trade-Off Analysis Method or business scenarios).
- TOGAF Supporting consists of additional resources that are not referenced in the other three TOGAF categories itself but provide valuable assistance.
The following table maps the content of this document to the four categories.
Section
Category
Comments
Preface
TOGAF Mandated
1
Introduction
1.1
Structure of the TOGAF Document
TOGAF Core
1.2
Executive Overview
TOGAF Core
2
Core Concepts
TOGAF Core
3
Definitions
TOGAF Mandated
4
Release Notes
TOGAF Supporting
Part II: Architecture Development Method
5
Introduction
5.1
ADM Overview
5.1.1
The ADM, Enterprise Continuum, and Architecture Repository
TOGAF Mandated
5.1.2
The ADM and the Foundation Architecture
TOGAF Recommended
5.1.3
ADM and Supporting Guidelines & Techniques
TOGAF Supporting
5.2
Architecture Development Cycle
5.2.1
Key Points
TOGAF Core
5.2.2
Basic Structure
TOGAF Core
5.3
Adapting the ADM
TOGAF Mandated
5.4
Architecture Governance
TOGAF Recommended
5.5
Scoping the Architecture
TOGAF Core
Concepts of scoping are Core; specific ways are Recommended.
5.5.1
Enterprise Scope/Focus
TOGAF Recommended
5.5.2
Architecture Domains
TOGAF Core
5.5.3
Vertical Scope/Level of Detail
TOGAF Recommended
5.5.4
Time Period
TOGAF Recommended
5.6
Architecture Integration
TOGAF Recommended
5.7
Summary
TOGAF Supporting
6
Preliminary Phase
6.1
Objectives
TOGAF Mandated
6.2
Approach
TOGAF Recommended
6.3
Inputs
TOGAF Mandated
6.4
Steps
TOGAF Mandated
6.5
Outputs
TOGAF Mandated
7
Phase A: Architecture Vision
7.1
Objectives
TOGAF Mandated
7.2
Approach
TOGAF Recommended
7.3
Inputs
TOGAF Mandated
7.4
Steps
TOGAF Mandated
7.5
Outputs
TOGAF Mandated
8
Phase B: Business Architecture
8.1
Objectives
TOGAF Mandated
8.2
Approach
TOGAF Recommended
8.3
Inputs
TOGAF Mandated
8.4
Steps
TOGAF Mandated
8.5
Outputs
TOGAF Mandated
9
Phase C: Information Systems Architectures
9.1
Objectives
TOGAF Mandated
9.2
Approach
TOGAF Recommended
9.3
Inputs
TOGAF Mandated
9.4
Steps
TOGAF Mandated
9.5
Outputs
TOGAF Mandated
10
Phase C: Data Architecture
10.1
Objectives
TOGAF Mandated
10.2
Approach
TOGAF Recommended
10.3
Inputs
TOGAF Mandated
10.4
Steps
TOGAF Mandated
10.5
Outputs
TOGAF Mandated
11
Phase C: Application Architecture
11.1
Objectives
TOGAF Mandated
11.2
Approach
TOGAF Recommended
11.3
Inputs
TOGAF Mandated
11.4
Steps
TOGAF Mandated
11.5
Outputs
TOGAF Mandated
12
Phase D: Technology Architecture
12.1
Objectives
TOGAF Mandated
12.2
Approach
TOGAF Recommended
12.3
Inputs
TOGAF Mandated
12.4
Steps
TOGAF Mandated
12.5
Outputs
TOGAF Mandated
13
Phase E: Opportunities & Solutions
13.1
Objectives
TOGAF Mandated
13.2
Approach
TOGAF Recommended
13.3
Inputs
TOGAF Mandated
13.4
Steps
TOGAF Mandated
13.5
Outputs
TOGAF Mandated
14
Phase F: Migration Planning
14.1
Objectives
TOGAF Mandated
14.2
Approach
TOGAF Recommended
14.3
Inputs
TOGAF Mandated
14.4
Steps
TOGAF Mandated
14.5
Outputs
TOGAF Mandated
15
Phase G: Implementation Governance
15.1
Objectives
TOGAF Mandated
15.2
Approach
TOGAF Recommended
15.3
Inputs
TOGAF Mandated
15.4
Steps
TOGAF Mandated
15.5
Outputs
TOGAF Mandated
16
Phase H: Architecture Change Management
16.1
Objectives
TOGAF Mandated
16.2
Approach
TOGAF Recommended
16.3
Inputs
TOGAF Mandated
16.4
Steps
TOGAF Mandated
16.5
Outputs
TOGAF Mandated
17
ADM Architecture Requirements Management
17.1
Objectives
TOGAF Mandated
17.2
Approach
TOGAF Recommended
17.3
Inputs
TOGAF Mandated
17.4
Steps
TOGAF Mandated
17.5
Outputs
TOGAF Mandated
18
Introduction
TOGAF Supporting
19
Applying Iteration to the ADM
TOGAF Core
Concept of iteration is Core; iteration cycles are Recommended.
20
Applying the ADM at Different Enterprise Levels
TOGAF Recommended
21
Security Architecture and the ADM
TOGAF Recommended
22
Using TOGAF to Define & Govern SOAs
TOGAF Supporting
23
Architecture Principles
TOGAF Supporting
23.1
Introduction
23.2
Characteristics of Architecture Principles
TOGAF Recommended
23.3
Components of Architecture Principles
TOGAF Recommended
23.4
Developing Architecture Principles
TOGAF Recommended
23.5
Applying Architecture Principles
TOGAF Recommended
23.6
Example Set of Architecture Principles
TOGAF Recommended
24
Stakeholder Management
24.1
Introduction
TOGAF Mandated
24.2
Approach to Stakeholder Management
TOGAF Mandated
24.3
Steps in the Stakeholder Management Process
TOGAF Recommended
24.4
Template Stakeholder Map
TOGAF Recommended
25
Architecture Patterns
TOGAF Supporting
26
Business Scenarios
TOGAF Recommended
27
Gap Analysis
TOGAF Recommended
28
Migration Planning Techniques
TOGAF Recommended
29
Interoperability Requirements
TOGAF Recommended
30
Business Transformation Readiness
AssessmentTOGAF Recommended
31
Risk Management
TOGAF Recommended
32
Capability-Based Planning
TOGAF Recommended
33
Introduction
TOGAF Recommended
34
Content Metamodel
TOGAF Recommended
35
Architectural Artifacts
TOGAF Recommended
For the views, the content example is Supporting.
36
Architecture Deliverables
TOGAF Mandated
37
Building Blocks
37.1
Overview
TOGAF Core
37.2
Introduction
TOGAF Core
37.3
Building Blocks and the ADM
TOGAF Recommended
37.4
Building Block Example
TOGAF Recommended
38
Introduction
TOGAF Supporting
39
Enterprise Continuum
TOGAF Mandated
40
Architecture Partitioning
TOGAF Supporting
41
Architecture Repository
TOGAF Supporting
42
Tools for Architecture Development
TOGAF Recommended
Current contents are Supporting.
42.1
Overview
TOGAF Supporting
42.2
Issues in Tool Standardization
TOGAF Supporting
42.3
Evaluation Criteria and Guidelines
TOGAF Supporting
43
Foundation Architecture: Technical
Reference Model43.1
Concepts
TOGAF Mandated
43.2
High-Level Breakdown
TOGAF Recommended
43.3
TRM in Detail
TOGAF Recommended
43.4
Application Platform - Taxonomy
TOGAF Recommended
43.5
Detailed Platform Taxonomy
TOGAF Recommended
44
Integrated Information Infrastructure
Reference ModelTOGAF Recommended
45
Introduction
TOGAF Supporting
46
Establishing an Architecture Capability
TOGAF Recommended
47
Architecture Board
TOGAF Recommended
48
Architecture Compliance
TOGAF Recommended
49
Architecture Contracts
TOGAF Recommended
50
Architecture Governance
TOGAF Recommended
51
Architecture Maturity Models
TOGAF Supporting
52
Architecture Skills Framework
TOGAF Supporting
A
Glossary of Supplementary Definitions
TOGAF Supporting
B
Abbreviations
TOGAF Supporting