3. Core Concepts
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:
- 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 applications to be deployed, their interactions, and their relationships to the core business processes of the organization
- The Technology Architecture describes the digital architecture and the logical software and hardware infrastructure capabilities and standards that are required to support the deployment of business, data, and applications services. This includes digital services, Internet of Things (IoT), social media infrastructure, cloud services, IT infrastructure, middleware, networks, communications, processing, standards, etc.
There are many other domains that could be defined by combining appropriate views of the Business, Data, Application, and Technology domains. For example:
- Information Architecture
- Risk and Security Architectures
- Digital Architecture
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 .
Phases within the ADM are as follows:
- The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of the TOGAF framework and definition of Architecture Principles
- Phase A: Architecture Vision describes the initial phase of an architecture development cycle
It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
- Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision
- Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision
- Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision
- 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 how to move from the Baseline to the Target Architectures by finalizing a detailed 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 operates the process of managing architecture requirements throughout the ADM
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:
- Mandate that the phases must be performed in any specific sequence
- Mandate a "waterfall" method
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.
|
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:
- A deliverable is a work product that is contractually specified and in turn formally reviewed, approved,
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, application interaction matrix, and a value chain diagram. An architectural deliverable may contain one or more artifacts and artifacts will form the content of the Architecture Repository. An artifact may or may not be considered a deliverable based on the contractual specification.
- A building block represents a potentially re-usable component 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 Figure 3-2 .
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 .
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:
- Why — why is the architecture needed?
- What — what functionality and other requirements need to be met by the architecture?
- How — how do we structure the functionality?
- With what — with what assets shall we implement this structure?
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:
- Enterprise Principles provide a basis for decision-making throughout an enterprise, and inform how the
organization sets about fulfilling its mission
Such principles are commonly found as a means of harmonizing decision-making across an organization. In particular, they are a key element in a successful Architecture Governance strategy (see TOGAF Standard — EA Capability and Governance).
Within the broad domain of Enterprise Principles, it is common to have subsidiary principles within a business or organizational unit; for example, principles specific to IT, HR, domestic operations, or overseas operations. These principles provide a basis for decision-making within the subsidiary domain and will inform architecture development within the domain. Care must be taken to ensure that the principles used to inform architecture development align to the organizational context of the Architecture Capability.
- Architecture Principles are a set of principles that relate to architecture work
They reflect a level of consensus across the enterprise and embody the spirit and thinking of existing Enterprise Principles. Architecture Principles govern the architecture process, affecting the development, maintenance, and use of the Enterprise 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:
- In the Architecture Vision (Phase A), the nature and security considerations of the information and service exchanges are first revealed within the business scenarios
- In the Business Architecture (Phase B), the information and service exchanges are further defined in business terms
- In the Data Architecture (Phase C), the content of the information exchanges is detailed using the corporate data and/or information exchange model
- In the Application Architecture (Phase C), the way that the various applications are to share the information and services is specified
- In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are specified
- In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-The-Shelf (COTS) packages) are selected
- In Migration Planning (Phase F), the interoperability is logically implemented
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:
- Operational or Business Interoperability defines how different parts of the enterprise work together at the business level
- Information Interoperability defines how information is to be shared
- Technical Interoperability defines how technical resources are to be shared or at least connect to one another
From an IT perspective, it is also useful to consider interoperability in a similar vein to Enterprise Application Integration (EAI); specifically:
- Presentation Integration/Interoperability is where a common look-and-feel approach through a common portal-like solution guides the user to the underlying functionality of the set of systems
- Information Integration/Interoperability is where the corporate information is seamlessly shared between
the various corporate applications to achieve, for example, a common set of client information
Normally this is based upon a commonly accepted corporate ontology and shared services for the structure, quality, access, and security/privacy for the information.
- Application Integration/Interoperability is where the corporate functionality is integrated and shareable
so that the applications are not duplicated (e.g., one change of address service/component; not one for every application) and are
seamlessly linked together through functionality such as workflow
This impacts the business and infrastructure applications and is very closely linked to corporate business process unification/interoperability.
- Technical Integration/Interoperability includes common methods and shared services for the communication, storage, processing, and access to data primarily in the application platform and communications infrastructure domains
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 .
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 .
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 is the architectural representation of assets deployed within the operating enterprise at a particular point in time — the landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
- The Standards Library 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 Repository provides a record of governance activity across the enterprise
- The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
- The Solutions Landscape presents an architectural representation of the SBBs supporting the Architecture Landscape which have been planned or deployed by the enterprise
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:
- A categorization framework to be used to structure the Architecture Descriptions, the work products used to express an architecture, and the collection of models that describe the architecture; this is referred to as the Content Framework
- An understanding of the types of entities within the enterprise and the relationships between them that need to be captured, stored, and analyzed in order to create the Architecture Description; this Enterprise Metamodel depicts this information in the form of a formal model
- The specific artifacts to be developed (see 3.6 Deliverables, Artifacts, and Building Blocks)
The Content Framework chosen is likely to be influenced by:
- The Architecture Framework selected as the basis for the Enterprise Architecture Capability
- The chosen software tool used to support the Enterprise Architecture Capability
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:
- Provide a detailed model of architectural work products
- Drive consistency in the outputs created when following the ADM
- Provide a comprehensive checklist of architecture output that could be created
- Reduce the risk of gaps within the final architecture deliverable set
- Help an enterprise mandate standard architecture concepts, terms, and deliverables
At the highest level, the TOGAF Content Framework (see Figure 3-6) is structured in line with the phases of the ADM.
- Architecture Principles, Vision, Motivation, and Requirements models are intended to capture the
surrounding context of formal architecture models, including general Architecture Principles, strategic context that forms input
for architecture modeling, and requirements generated from the architecture
The relevant aspects of the business context that have given rise to the Request for Architecture work are typically investigated, refined, validated, and recorded in the Preliminary and Architecture Vision phases.
- Business Architecture captures architecture models of the business, looking specifically at factors that motivate the enterprise, its structure, and its capabilities
- Information Systems Architecture models capture architecture models of IT systems, looking at applications and data in line with the TOGAF ADM phases
- Technology Architecture models capture technology assets that are used to implement and realize information system solutions
- Architecture Realization/Transformation models capture change roadmaps showing transition between architecture states and binding statements that are used to steer and govern an implementation of the architecture
- Architecture Change Management models capture value realization management events, internal and external, that impact the Enterprise Architecture and the generation of requirements for action
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:
- It gives architects a starter set of the types of thing to investigate and to cover in their models
- It provides a form of completeness-check for any architecture modeling language, or architecture metamodel, that
is proposed for use in an enterprise
Namely, how completely does it handle the types of entity in the Enterprise Metamodel, and manage required facts about them such as their attributes and relationships?
- It can help ensure:
- Consistency
- Completeness
- Traceability
Note that the TOGAF Standard does not aim to constrain an enterprise's:
- Selection of artifacts
- Modeling notation
The TOGAF Standard may use a variety of modeling languages, such as the ArchiMate® modeling language, Business Process Modeling NotationTM (BPMNTM), Unified Modeling LanguageTM (UML®), entity relationship diagramming, flowcharting, or any other notation that can express some TOGAF ideas.
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"):
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 .
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 .
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:
- Financial Management
- Performance Management
- Service Management
- Risk and Opportunity Management (see B.34 Risk Management)
- Resource Management
- Communications and Stakeholder Management (see 4.36 Communications and Stakeholder Management)
- Quality Management
- Supplier Management (see B.40 Supplier Management)
- Configuration Management (see B.7 Configuration Management)
- 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 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:
- Increased transparency of accountability, and informed delegation of authority
- Proactive risk and opportunity 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 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:
- 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 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:
- TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures
- TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture
Some of these have been developed collaboratively between The Open Group and other bodies. Examples include:
- TOGAF® and SABSA® Integration
- Archi Banking Group: Combining the BIAN Reference Model, ArchiMate® Modeling Notation, and the TOGAF® Framework
- Exploring Synergies between TOGAF® and Frameworx
- TOGAF® 9 and DoDAF 2.0
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.
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:
- TOGAF® Series Guide: Applying the ADM Using Agile Sprints
- TOGAF® Series Guide: Enabling Enterprise Agility
- The Open Agile ArchitectureTM Standard
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:
- Initial level of risk: risk categorization prior to determining and implementing mitigating actions
- Residual level of risk: risk categorization after implementation of mitigating actions (if any)
The process for risk management consists of the following activities:
- Risk classification
- Risk identification
- Initial risk assessment
- Risk mitigation and residual risk assessment
- Risk monitoring
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).
TOGAF is a registered trademark of The Open Group