This chapter will help you understand and be able to explain the core concepts of the TOGAF standard.
Key Points Explained
This chapter will help you to answer the following questions:
• What are the ADM phase names and the purpose of each phase?
• What are deliverables, artifacts, and building blocks?
• What is the Enterprise Continuum?
• What is the Architecture Repository?
• How to establish and operate an enterprise architecture capability?
• How to use the TOGAF framework with other frameworks?
(Syllabus Reference: Unit 2, Learning Outcome 1: You should be able to explain the core concept of the ADM and the purpose of each phase at a high level.)
The Architecture Development Method (ADM) forms the core of the TOGAF standard and is a method for deriving organization-specific enterprise architecture. It is the result of contributions from many architecture practitioners.
The 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.
The ADM is described as a number of phases within a process of change illustrated by an ADM cycle graphic (see following). Phases within the ADM are as follows:
The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, and the definition of Architecture 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 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.
Phase F: Migration Planning describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
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.
(Syllabus Reference: Unit 2, Learning Outcome 2: You should be able to explain the core concepts of deliverables, artifacts, and building blocks in the context of the Architecture Content Framework.)
During application of the ADM process, a number of outputs are produced; for example, process flows, architectural requirements, project plans, project compliance assessments, etc. In order to collate and present these major work products in a consistent and structured manner, the TOGAF standard defines a structural model – the TOGAF Architecture Content Framework – in which to place them.
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 an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. 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 and can relate to both architectures and solutions, with Architecture Building Blocks (ABBs) typically describing the required capability in order to shape the Solution Building Blocks (SBBs) which would represent the components to be used to implement the required capability.
The relationships between deliverables, artifacts, and building blocks are shown in Figure 4.
Figure 4: Relationships between Deliverables, Artifacts, and Building Blocks
(Syllabus Reference: Unit 2, Learning Outcome 3: You should be able to explain the core concept of the Enterprise Continuum.)
The TOGAF standard includes the concept of the Enterprise Continuum, shown in Figure 5, 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.
The Enterprise Continuum and the Architecture Repository
The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. [Source: TOGAF 9 Part V: Enterprise Continuum and Tools]
Figure 5: The Enterprise Continuum
(Syllabus Reference: Unit 2, Learning Outcome 4: You should be able to explain the core concept of the 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, the TOGAF standard facilitates understanding and co-operation between stakeholders and practitioners at different levels.
The structure of the TOGAF Architecture Repository is shown in Figure 6.
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)9 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.
Figure 6: TOGAF Architecture Repository Structure
(Syllabus Reference: Unit 2, Learning Outcome 5: You should be able to explain the core concept of establishing and maintaining an Enterprise Architecture Capability.)
TOGAF 9 provides an Architecture Capability Framework that is a set of reference materials and guidelines for establishing an architecture function or capability within an organization. A summary of the contents is shown in Table 6.
An overall structure for an Architecture Capability Framework is shown in Figure 7.
Figure 7: Architecture Capability Framework
(Syllabus Reference: Unit 2, Learning Outcome 6: You should be able to explain the core concept of establishing the Architecture Capability as an operational entity.)
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
• Performance Management
• Service Management
• Risk Management
• Resource Management
• Communications and Stakeholder Management
• Quality Management
• Supplier Management
• Configuration Management
• Environment Management
Central to the notion of operating an ongoing architecture is the execution of well-defined and effective governance – Architecture Governance – whereby all architecturally significant activity is controlled and aligned within a single framework.
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
(Syllabus Reference: Unit 2, Learning Outcome 7: You should be able to explain the core concept of the use of the TOGAF framework 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, together with a description of the method for production.
Many 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.
Because the TOGAF standard 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, the TOGAF standard 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.
As a generic framework and method for enterprise architecture, the TOGAF standard 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).
Key Fact
Why is the TOGAF standard becoming so popular in the industry?
One key reason is that architects can use the TOGAF ADM in conjunction with any of the popular frameworks.
The TOGAF ADM is framework-agnostic, and helps IT architects fill in the framework they might already have in use.
[Source: Bill Estrem, “TOGAF to the Rescue” (www.opengroup.org/downloads)]
This chapter has introduced the core concepts of the TOGAF standard. This has included the following:
• The ADM and the purpose of each phase
• The concepts of deliverables, artifacts, and building blocks, and how they relate to the outputs of the ADM
• The Enterprise Continuum as a concept, and how it is used to classify artifacts
• The Architecture Repository and how it is used to store different classes of architectural output
• How to establish and maintain an enterprise architecture capability, and the guidelines available within the TOGAF standard
• How to operate an architecture capability, including a list of recommended capabilities beyond the ADM
• The use of the TOGAF framework with other frameworks, and how the TOGAF framework may be used on its own or in conjunction with another framework
Q1: Which of the TOGAF Architecture Development phases is the initial phase of an Architecture Development Cycle?
A. Preliminary Phase
B. Phase A
C. Phase B
D. Phase C
E. Phase D
Q2: Which of the TOGAF Architecture Development phases provides oversight of the implementation?
A. Phase D
B. Phase E
C. Phase F
D. Phase G
E. Phase H
Q3. Which of the TOGAF Architecture Development phases includes the creation and approval of the Architecture Vision document?
A. Preliminary Phase
B. Phase A
C. Phase B
D. Phase C
E. Phase D
Q4. Which of the following is not a phase of the ADM?
A. Preliminary
B. Phase C: Requirements Architecture
C. Phase F: Migration Planning
D. Phase D: Technology Architecture
E. Phase G: Implementation Governance
Q5: Which of the following is defined as a work product that describes an aspect of an architecture?
A. An artifact
B. A building block
C. A catalog
D. A deliverable
E. A matrix
Q6: Complete the sentence: The Enterprise Continuum is
A. An architecture framework
B. A database of open industry standards
C. A technical reference model
D. A model for classifying artifacts
E. A method for developing architectures
Q7: Which component of the Architecture Repository provides guidelines, templates, and patterns that can be used to create new architectures?
A. The Architecture Metamodel
B. The Architecture Capability
C. The Architecture Landscape
D. The Reference Library
E. The Governance Log
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part I: Introduction, Chapter 2 (Core Concepts)
_______________________
9 An example SIB can be found on The Open Group website at www.opengroup.org/sib.
