Home The TOGAF® Standard
Search
Word Search | Search Index


Advanced Search
Provide feedback on this page
TOGAF® Fundamental Content
Extended Guidance
General How-To
Establishing an EA Team
Domains
Agile Methods
Business Architecture
Data/Information Architecture
Sustainability
Security Architecture
Reference Models & Method

3. Core Concepts

Chapter Contents: 3.1 What is the TOGAF Standard? | 3.2 What is Architecture in the Context of the TOGAF Standard? | 3.3 What Kind of Architecture Does the TOGAF Standard Deal With? | 3.4 Architecture Development Method | 3.5 Enterprise Architecture Services | 3.6 Deliverables, Artifacts, and Building Blocks | 3.7 Architecture Abstraction | 3.8 Architecture Principles | 3.9 Interoperability | 3.10 Enterprise Continuum | 3.11 Architecture Repository | 3.12 TOGAF Content Framework and Enterprise Metamodel | 3.13 Establishing and Maintaining an Enterprise Architecture Capability | 3.14 Establishing the Architecture Capability as an Operational Entity | 3.15 Using the TOGAF Standard with Other Frameworks | 3.16 Using the TOGAF Framework with Different Architecture Styles | 3.17 Architecture Views and Viewpoints | 3.18 Enterprise Agility | 3.19 Risk Management

For the purposes of the TOGAF Standard, the core concepts provided in this chapter apply.

3.1 What is the TOGAF Standard?

The TOGAF Standard is an architecture framework. It 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. See 2.2 The TOGAF Standard .

3.2 What is Architecture in the Context of the TOGAF Standard?

ISO/IEC/IEEE 42010:2011 defines "architecture" as:

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

The TOGAF Standard embraces but does not strictly adhere to ISO/IEC/IEEE 42010:2011 terminology. In addition to the ISO/IEC/IEEE 42010:2011 definition of "architecture", the TOGAF Standard defines a second meaning depending upon the context:

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

The TOGAF Standard considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology drawn from relevant standards, and commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 4. Definitions and the TOGAF Standard — Architecture Content.

3.3 What Kind of Architecture Does the TOGAF Standard Deal With?

There are four architecture domains that are commonly accepted as subsets of an overall Enterprise Architecture, all of which the TOGAF Standard is designed to support:

There are many other domains that could be defined by combining appropriate views of the Business, Data, Application, and Technology domains. For example:

The TOGAF framework enables the creation of these multi-dimensional views and categorizes them to create specific domains that enable an enterprise to consider the wider scope of their enterprise and capabilities.

3.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. This is illustrated in Figure 3-1 .

Figure 3-1: Architecture Development Cycle

Phases within the ADM are as follows:

The description of the phases of the ADM in the TOGAF Standard — Architecture Development Method focuses on recommendations on what may be done to define and deploy an Enterprise Architecture.

Guidance on how to do what is specified can be found in the TOGAF Series Guides (see 2.2 The TOGAF Standard). A full list of referenced TOGAF Series Guides is included in A. Referenced Documents .

The TOGAF framework recommends that the ADM be adapted to meet the needs of the enterprise and to support different architecture styles (see 3.16 Using the TOGAF Framework with Different Architecture Styles).

In particular, the ADM does not:

The TOGAF Standard describes how the ADM can be used iteratively to develop a comprehensive Enterprise Architecture landscape. Rather than viewing the ADM graphic as a process model, it is helpful to view it as a reference model defining what has to be done in order to deliver solutions in an architected way and identifying interacting components across the enterprise and the relationships between them.

3.5 Enterprise Architecture Services

Activities described in the ADM are often provided through a service delivery model. The services are organized and presented in service categories. These services address specific needs independent of an organization's specific operation model. Any given service described utilizes the appropriate activities in the ADM to address a given need.

Table 3-1 summarizes the proposed service categories and provides some context. The first four categories are customer-centric and the others are more internally centered on architects. Each service category is briefly described in the following subsections.

Table 3-1: Service Categories and Descriptors

 

Descriptor

Categories

Typical Customer

Typical Provider

Deliverable(s)

Desired Result

Customer-centric

Enterprise Support Services

C-level management

Enterprise analysts using Enterprise Architecture as a tool

Answers to questions

Assessment reports

Recommendations

Better enterprise decisions

Lower risk

Design Support Services

Program-level decision-makers

Enterprise Architect builder/modeler

MVAs (including standards and compliance criteria, roadmaps) for programs

Compliance guidance

Compliance reports

Better design decisions

Successful programs and projects

Development Support Services

Project-level decision-makers

Enterprise Architect builder/modeler

MVAs (including standards and compliance criteria) for projects/products

Compliance guidance

Compliance reports

Better product decisions

Successful products

Requirements Elicitation and Understanding Services

Product managers

Enterprise Architect with requirements understanding specialty

Stakeholder concerns

Requirements

Assessments (value, ability, etc.)

Solid outside-in view of requirements and value for solutions balanced among stakeholders

Internal-centric

Architecture Planning Services

Architecture team leaders

Experienced Enterprise Architect

Architecture project plans

Resourced architecture team

Enterprise Architecture Practice Development Support Services

Architecture organization decision-makers

Enterprise Architecture practice experts

Enterprise Architecture Capability assessments

Enterprise Architecture Capability improvement recommendations

Highly skilled and organized Enterprise Architecture practice organization (internal or external)

3.5.1 Enterprise Support Services

This service category contains candidate services that enable informed enterprise decisions in support of organization change. These services could be provided independent of any individual project. These services focus on answering questions and providing enterprise analysis in support of strategic decisions.

3.5.2 Design Support Services

This service category contains candidate services that enable informed design decisions in support of organization change. These services would typically be provided after a project has been funded, whether large or small, waterfall or agile. These services include the development of Minimum Viable Architectures (MVAs) and associated analysis to support the design decisions.

3.5.3 Development Support Services

This service category contains candidate services that enable informed development decisions in support of organization change. These services would typically be provided during the development phase of a project, whether large or small, waterfall or agile. These services focus on answering questions and providing enterprise analysis in support of development decisions.

3.5.4 Requirements Elicitation and Understanding Services

This service category contains candidate services that enable requirements understanding. Taking a step beyond requirements management, these services help get closer to real need that will deliver greater business value.

3.5.5 Architecture Planning Services

This service category contains candidate services that enable well-planned and executed architecture projects in support of organization change. These services would typically be provided at the beginning of a "project" whether large or small, waterfall or agile.

3.5.6 Enterprise Architecture Practice Development Support Services

This service category contains candidate services that enable the development and management of an Enterprise Architecture practice. These services are focused on improving Enterprise Architecture Capability.

3.6 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 the TOGAF Standard — Architecture Content) 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:

The relationships between deliverables, artifacts, and building blocks are shown in Figure 3-2 .

Figure 3-2: 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 Figure 3-3 .

Figure 3-3: Example — Architecture Definition Document

The concepts of Deliverables, Artifacts, and Building Blocks are described in more detail in the TOGAF Standard — Architecture Content.

The TOGAF Standard — ADM Techniques describes the Architecture Development Method and includes summary lists of Deliverables and Artifacts that may be created in each phase. The TOGAF Standard — Architecture Content contains detailed descriptions of these.

3.7 Architecture Abstraction

An architectural technique for dividing a problem area into smaller problem areas that are easier to model and therefore easier to solve.

Abstraction levels are layered in nature, moving from high-level models to more detailed models.

Architecture effort can be divided into four distinct abstraction levels that cross the Business, Data, Application, and Technology domains to answer fundamental questions about an architecture:

Note that why, what, and how have no connection to their use in the Zachman® Enterprise Architecture Framework.

3.7.1 Contextual Abstraction Level

This abstraction level is focused on understanding the environment in which an enterprise operates and the context in which architecture work is planned and executed. It answers why an enterprise undertakes architecture work, what is the scope of work, and the motivation in terms of goals, drivers, and objectives.

3.7.2 Conceptual Abstraction Level

This abstraction level is centered on decomposing the requirements to understand the problem, and what is needed to address the problem, without unduly focusing on how the architecture will be realized. It answers what is necessary to realize the requirements and is usually modeled using service models (business service, application service, technology service) that represent desired behavior.

Note this abstraction level can also be referred to as either service abstraction or behavior abstraction.

3.7.3 Logical Abstraction Level

This abstraction level is focused on identifying the kinds of business, data, application, and technology components needed to achieve the services identified in the conceptual level. It is about identifying how an architecture can be organized and structured, in an implementation-independent fashion. There will potentially be several ways to group services into logical components, based on principles and other grouping criteria, providing different logical solution alternatives.

3.7.4 Physical Abstraction Level

This abstraction level manages the allocation and implementation of physical components to meet the identified logical components. It is about determining with what physical components the logical-level components can be realized. There will potentially be many ways to use physical components to realize logical components, based on principles and other grouping criteria, providing different physical solution alternatives.

3.8 Architecture Principles

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

Depending on the organization, principles may be established within different domains and at different levels. Two key domains inform the development and utilization of architecture:

Within an enterprise the hierarchy of principles starts with the Enterprise Principles. The subsidiary segment principles must exist within the bounds of these Enterprise Principles which are overarching. Consequently, at each hierarchical level the set of principles will be informed by and elaborate on the principles inherited from the level above and cannot overstep their boundaries.

Architecture Principles may restate other enterprise guidance in terms and form that effectively guide architecture development.

Architecture Principles define the underlying general rules and guidelines for the use and deployment of all resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise and form the basis for making future architecture decisions.

Each Architecture Principle should be clearly related back to the business objectives and key architecture drivers.

Architecture Principles are further explained in the TOGAF Standard — ADM Techniques.

3.9 Interoperability

A definition of interoperability is "the ability to share information and services". Defining the degree to which the information and services are or are not to be shared is a very useful architectural requirement, especially in a complex organization and/or extended enterprise.

The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows:

There are many ways to define interoperability and the aim is to define one that is consistently applied within the enterprise and extended enterprise. It is best that both the enterprise and the extended enterprise use the same definitions.

Many organizations find it useful to categorize interoperability as follows:

From an IT perspective, it is also useful to consider interoperability in a similar vein to Enterprise Application Integration (EAI); specifically:

Interoperability and Interoperability Requirements are addressed in detail in the TOGAF Standard — ADM Techniques.

3.10 Enterprise Continuum

The TOGAF Standard 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 categorization for assets held in the Enterprise Repositories that provides methods for classifying assets, including 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 is described in detail in the TOGAF Standard — Architecture Content.

An overview of the structure and context for the Enterprise Continuum is shown in Figure 3-4 .

Figure 3-4: Enterprise Continuum

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

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 Figure 3-5 .

Figure 3-5: TOGAF Architecture Repository Structure

The major components within an Architecture Repository are as follows:

The TOGAF Architecture Repository is described in the TOGAF Standard — Architecture Content.

3.12 TOGAF Content Framework and Enterprise Metamodel

3.12.1 Overview

The TOGAF ADM provides lifecycle management to create and manage architectures within an enterprise. At each phase within the ADM, a discussion of inputs, outputs, and steps describes a number of architectural work products.

An essential task when establishing the enterprise-specific Enterprise Architecture Capability in the Preliminary Phase of the ADM is to define:

The Content Framework chosen is likely to be influenced by:

3.12.2 Content Framework

The Content Framework defines a categorization framework to be used to describe the building blocks and artifacts reflecting decisions taken in creating the overall architecture deliverables.

The Architecture Repository, which is explained in 3.11 Architecture Repository , is structured to store the artifacts and work products identified in the Content Framework. The Content Framework is one element of the Enterprise-Specific Architecture Framework.

There are many alternative Content Frameworks (e.g., the TOGAF Content Framework, the Zachman Framework, DoDAF, NAF, etc.). Selecting a Content Framework is essential even though the choice of Content Framework is less important. The final Content Framework is usually adapted to fit specific organization needs.

The TOGAF Content Framework is intended to:

At the highest level, the TOGAF Content Framework (see Figure 3-6) is structured in line with the phases of the ADM.

Figure 3-6: Content Framework by ADM Phase

The TOGAF Content Framework is described in detail in the TOGAF Standard — Architecture Content.

3.12.3 Enterprise Metamodel

The TOGAF Standard encourages development of an Enterprise Metamodel, which defines the types of entity to appear in the models that describe the enterprise, together with the relationships between these entities.

For example, one type in an Enterprise Metamodel might be Role. Then the enterprise's Business Architecture models might include such instances of Role as Teller, Pilot, Manager, Volunteer, Customer, or Firefighter. Of course it would be an unusual enterprise that had all of these roles.

An Enterprise Metamodel provides value in several ways:

Note that the TOGAF Standard does not aim to constrain an enterprise's:

The types of entity within an enterprise and the relationships between them are specific to the individual enterprise. Developing a high-quality metamodel is an important aspect of establishing the Enterprise Architecture Capability.

3.12.4 Developing the Enterprise Metamodel

The Enterprise Metamodel is an important part of the Organization-Specific Architecture Framework, as highlighted here. Figure 3-7 shows how the Enterprise Continuum (see 3.10 Enterprise Continuum) provides a way to consider resources on a scale ranging from the most general ("Foundation") to most specific ("Organization-Specific"):

Figure 3-7: Applying the Enterprise Continuum

To support development of the enterprise's metamodel, the TOGAF Library includes a Foundation-level Core Enterprise Metamodel, detailed in the TOGAF Standard — Architecture Content. It shows types of entity, and relationships between them, that are likely to be required in modeling most enterprises and provides a context for the artifacts suggested in the ADM.

The Foundation Enterprise Metamodel is illustrated in Figure 3-8 .

Figure 3-8: The TOGAF Core Enterprise Metamodel

3.13 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 Figure 3-9 .

Figure 3-9: TOGAF Architecture Capability Overview

3.14 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:

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 the TOGAF Standard 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:

Further detail on establishing an Enterprise Architecture Capability is given in the TOGAF Standard — EA Capability and Governance.

3.15 Using the TOGAF Standard with Other Frameworks

Two of the key elements of any Enterprise Architecture framework are:

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 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 framework 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 or best practices, such as ITIL®, CMMI®, COBIT®, PRINCE2, PMBOK, and MSP®. It may also include adopting reference materials from the TOGAF Library, such as the IT4ITTM Reference Architecture. Guidelines for adapting the TOGAF ADM in such a way are given in the TOGAF Standard — ADM Techniques.

As a generic framework and method for Enterprise Architecture, the TOGAF Standard provides the capability and the collaborative environment to integrate with other frameworks. Organizations are able to fully utilize vertical business domains, horizontal technology areas (such as security or manageability), or application areas (such as e-Commerce) to produce a competitive Enterprise Architecture framework which maximizes their business opportunities.

3.16 Using the TOGAF Framework with Different Architecture Styles

The TOGAF framework is designed to be flexible and is used with various architectural styles.

Architectural styles differ in terms of focus, form, techniques, materials, subject, and time period. The TOGAF Standard is a generic framework intended to be used in a wide variety of environments. It is a flexible and extensible framework that can be readily adapted to a number of architectural styles.

An organization's Architecture Landscape can be expected to contain architecture work that is developed in many architectural styles. The TOGAF Standard ensures that the needs of each stakeholder are appropriately addressed in the context of other stakeholders and the Baseline Architecture.

When using the TOGAF Standard to support a specific architectural style the practitioner must take into account the combination of distinctive features in which architecture is performed or expressed. As a first step, the distinctive features of a style must be identified.

The second step is determining how these distinctive features will be addressed. Addressing a distinctive style should not call for significant changes to the TOGAF framework; instead it should adjust the models, viewpoints, and tools used by the practitioner.

In Phase B, Phase C, and Phase D the practitioner is expected to select the relevant architecture resources, including models, viewpoints, and tools, to properly describe the architecture domain and demonstrate that stakeholder concerns are addressed (see the TOGAF Standard — ADM Techniques). Depending upon the distinctive features, different architectural styles will add new elements that must be described, highlight existing elements, adjust the notation used to describe the architecture, and focus the architect on some stakeholders or stakeholder concerns.

Addressing the distinctive features will usually include extensions to the Architecture Content Metamodel and the use of specific notation or modeling techniques and the identification of viewpoints. Dominance of a particular architectural style can direct the practitioner to revisit the Preliminary Phase to make changes to the Architecture Capability or to address a distinctive feature in the expected scope of a single ADM cycle.

Style-specific reference models and maturity models are commonly used tools that support a practitioner.

During the lifetime of the TOGAF framework many architectural styles have been developed to address key problems facing practitioners and to demonstrate how the TOGAF framework can be made more relevant within defined contexts.

Some of these have been developed by The Open Group Forums and Work Groups working in specific areas and have been published in Guides, White Papers, and Standards. Examples include:

Some of these have been developed collaboratively between The Open Group and other bodies. Examples include:

The TOGAF Library (see www.opengroup.org/togaf-library) is a structured library of resources that support the TOGAF Standard.

3.17 Architecture Views and Viewpoints

The ability to create specific "views" of parts of a complex architecture is fundamental in being able to communicate with and allay concerns of stakeholders or groups of stakeholders. To gain full understanding and support from stakeholders it is necessary to present information in a form that each stakeholder will relate to and understand.

The role of architecture views is shown in Figure 3-10 , adapted from more formal definitions contained in ISO/IEC/IEEE 42010:2011 and ISO/IEC/IEEE 15288:2015.

Figure 3-10: Basic Architectural Concepts

3.18 Enterprise Agility

Enterprise agility is a commonly used term, but the exact definition differs among practitioners. Regardless of how the term is defined, it is important because it enables an enterprise to better react to change by being more customer and product-centric, more efficient, and better able to ensure regulatory compliance.

The term "agile" is frequently associated with agile software development processes associated with the Manifesto for Agile Software Development.

While these "agile" principles and techniques can be applied to adapt the TOGAF framework, enterprise agility is a broader context than agile software development. Therefore, additional techniques are employed in adapting the TOGAF framework to an agile enterprise.

Enterprise Architecture provides a framework for change, linked to both strategic direction and business value. It provides a sufficient view of the organization to manage complexity, support continuous change, and manage the risk of unanticipated consequences.

The TOGAF framework has embraced the call to respond to the needs of the enterprise in a timely manner, through the concepts of "partitions" and "levels". Partitions define how the work is broken down into multiple architecture initiatives. Levels define how the overall architecture can be developed at different levels of granularity and detail.

In addition, the TOGAF ADM supports a number of concepts that are characterized as iteration.

More detailed descriptions of how to adapt the TOGAF ADM to support enterprise agility can be found in:

3.19 Risk Management

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.

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.

It is also important to note that the Enterprise Architect may identify the risks and mitigate certain ones, but it is within the governance framework that risks have to be first accepted and then managed.

There are two levels of risk that should be considered, namely:

The process for risk management consists of the following activities:

A qualitative approach to risk management is described in the TOGAF Standard — ADM Techniques.

Risk concepts are included in the Enterprise Security Architecture described in the TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture.

A more rigorous quantitative approach is described in the Open FAIRTM Body of Knowledge which comprises two standards from The Open Group: Open Risk Taxonomy (O-RT) and Open Risk Analysis (O-RA).

return to top of page
Copyright © 1999-2022 The Open Group, All Rights Reserved.
TOGAF is a registered trademark of The Open Group
<<< Previous Home Next >>>