TOGAF Basics ¶

TOGAF, an acronym for The Open Group Architecture Framework, is intended to be a standard way to design and implement architectures for very large computer systems. Today, 80% of Global 50 companies use TOGAF. The TOGAF Standard applies to all Enterprise Architecture practices.
It does not matter whether your architecture will support strategy, portfolio, project, or solution delivery, or whether it is about embarking on a Digital Transformation or legacy simplification

The TOGAF Standard is a framework for Enterprise Architecture. Put simply, it is a standard approach for developing, approving, using, and maintaining Enterprise Architectures. It applies to all Enterprise Architecture practices. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.

What is tactical architecture?

Tactical architecture as “temporary” architecture that gets the business to a reasonable target state given a set of significant constraints that demand the architecture address a relatively immediate need without a significant amount of resources (money, time, workers)

Diagram examples¶

Techniques¶

Contextual: Why
Conceptual: What
Logical: How
Physical: Actual solution

Terms¶

Cross Cutting Concern¶

Security Architecture is a cross-cutting concern pervasive through the whole Enterprise Architecture. It can be described as a coherent collection of views, viewpoints, and artifacts, including security, privacy, and operational risk perspectives, along with related topics like security objectives and security services.

The Security Architecture is more than a dataset; it is based on the Information Security Management (ISM) and Enterprise Risk Management (ERM) processes.

Architecture Board¶

An Architecture Board is responsible for operational items and must be capable of making decisions in situations of possible conflict and be accountable for taking those decisions. It should therefore be a representation of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture. It is important that the members of the Architecture Board cover architecture, business, and program management areas.

ABB's and SBB's¶

For instance, at an early stage, a building block can simply consist of a grouping of functionality such as a customer database and some retrieval tools. Building blocks at this functional level of definition are described in TOGAF as Architecture Building Blocks (ABBs). Later on, real products or specific custom developments replace these simple definitions of functionality, and the building blocks are then described as Solution Building Blocks (SBBs).

A building block's boundary and specification should be loosely coupled to its implementation; i.e., it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.

ABB's¶

Architecture Building Blocks (ABB) are related to the Architecture Continuum and define which functionality will be implemented through the capture of business and technical requirements. An ABB is technology aware and is used to direct and guide the development of Solution Building Blocks (SBB).

The fundamental functionality and attributes of an ABB are semantic and unambiguous. Their interfaces are either chosen or supplied

SBB's¶

Solution Building Blocks (SBBs) relate to the Solutions Continuum. They are implementation choices of the architectures identified in the enterprise’s Architecture Continuum and may be either procured or developed.

SBBs appear in Phase E of the ADM where product-specific building blocks are considered for the first time. SBBs define what products and components will implement the functionality, thereby defining the implementation.

They fulfill business requirements and are product or vendor-aware. The content of an SBB specification includes the following as a minimum:

Specific functionality and attributes.
Interfaces; the implemented set.
Required SBBs used with required functionality and names of the interfaces used.
Mapping from the SBBs to the IT topology and operational policies.
Specifications of attributes shared such as security, manageability, localizability, scalability.
Performance, configurability.
Design drivers and constraints, including the physical architecture.
Relationships between the SBBs and ABBs.

Architecture Principles¶

Shortut

N-SIR: Name, Statement, Implication and Rationale

Remember that Arch principles are added in Vision Phase. It may be that the Architecture Principles are documented using a wiki or as an intranet rather than a text-based document. Even better would be to use a licensed TOGAF tool that captures this output.

Name: Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle.
Statement: Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement is unambiguous.
Rationale: Tellls about benefits (Why)
1. The Rationale should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations.
2. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation.
3. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications: Talks about requriements mostly
1. The Implications should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks.
2. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption.
3. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: “How does this affect me?” It is important not to oversimplify, trivialize, or judge the merit of the impact.
4. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

Architecture Capability¶

Creating architecture for an enterprise requires the organization to have the business capability to support the architecture through structures, roles, responsibilities, skills, and processes.

TOGAF architecture capability builds on the Architecture Repository and Enterprise Continuum by identifying the architecture components providing the capability and their relationships to each other.

The components include:

Skilled Resource Pool
Roles and Responsibilities
Contracts
Projects and Portfolios
Governance of Projects and Portfolios
Business Operations
Governance Bodies

Architecture Repository¶

Relationship between Architecture Repository and Entperprise Continum

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:

Architecture Continuum
Solutions Continuum

Architecture Repository can be used to store different classes of architectural output at different levels of abstraction, created by the ADM.

At a high level, six classes of architectural information are expected to be held within an Architecture Repository:

Architecture Metamodel: It describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content.
Architecture Capability: It defines the parameters, structures, and processes that support governance of the Architecture Repository.
Architecture Landscape: It 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 granularity to suit different architecture objectives.
Standards Information Base: It 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 organizations
Reference Library: It 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.
Governance Log: It provides a record of governance activity across the enterprise.

Enterprise Continum¶

A model for structuring a virtual repository and methods for classifying architecture and solution artifacts.

Architecture Landscape¶

The Architecture Landscape holds architectural views of the state of the enterprise at particular points in time. Due to the sheer volume and the diverse stakeholder needs throughout an entire enterprise, the Architecture Landscape is divided into three levels of granularity

Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

Content MetaModel¶

The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another. For example, when creating an architecture, an architect will identify applications, "data entities" held within applications, and technologies that implement those applications. These applications will in turn support particular groups of business user or actor, and will be used to fulfil "business services".

Content Framework¶

Architects executing the ADM will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, or project compliance assessments.

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

The Content Framework provided supports the use of the TOGAF framework as a stand-alone framework for architecture within an enterprise. However, other Content Frameworks exist (for example, that provided by the ArchiMate Specification) and it is expected that some enterprises will use an external framework in conjunction with the ADM instead. In such cases, the TOGAF Content Framework provides a useful reference and starting point for TOGAF content to be mapped to the metamodels of other frameworks.

Organizational Model for EA¶

The Organizational Model for Enterprise Architecture demonstrates the organization, roles and responsibility within the enterprise.

Implementation Governance Model¶

Once an architecture has been defined, it is necessary to plan how the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.

When is this produced?

The Implementation Governance Model produced as an output of Phase F ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance (for Phase G)

Request for Architecture Work¶

The Request for Architecture Work is sent from sponsoring organizations to the architecture organization to trigger the start of an architecture development cycle

When is request of Architecture work created?

It is produced with the assistance of the architecture organization as an output of the Preliminary Phase. Requests for Architecture Work can also be created as a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning.

Requirements Impact Assessment¶

The Requirements Impact Assessment assesses the current architecture requirements and specifications to identify changes to be made and the implications of those changes.

Statement of Architecture Work¶

The Statement of Architecture Work defines the scope and approach used to complete an architecture project.

Transition Architecture¶

Where the scope of change to implement the Target Architecture requires an incremental approach, one or more Transition Architectures are defined within the Architecture Definition Document output from Phase E.

A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe interim architectures necessary for the effective realization of the Target Architecture.

Communication Plan¶

Tldr

The Communications Plan provides a basis for communicating within a planned and managed process to stakeholders.

Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. Development of a Communications Plan for architecture in Phase A allows for this communication to be carried out within a planned and managed process.

Typical contents of a Communications Plan are:

Identification of stakeholders and grouping by communication requirements
Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and CSFs
Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.

Architecture Roadmap¶

The Architecture Roadmap is a listing of individual increments of change and shows the progression from Baseline Architecture to the Target Architecture.

Architecture Requirement Spec¶

A set of quantitative statements, which outline what actions an implementation project must take to comply with the architecture.

Spec and Defination Document difference

The Architecture Definition Document is a companion to the Architecture Requirements Specification where:

The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of solutions supporting the architecture.
The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.

Architecture Definition Document¶

A deliverable container for the core architectural artifacts created during a project. The Architecture Definition Document is a companion document to the Architecture Requirements Specification.

When it is created and updated?

The Architecture Definition Document spans all architecture domains (Business, Data, Application, and Technology) and also examines all relevant states of the architecture (Baseline, Transition, and Target).

It is first created in Phase A, where it is populated with artifacts created to support the Architecture Vision. It is updated in Phase B, with Business Architecture-related material, and subsequently updated with Information Systems Architecture material in Phase C, and then with Technology Architecture material in Phase D. Where the scope of change to implement the Target Architecture requires an incremental approach, the Architecture Definition Document will be updated to include one or more Transition Architectures in Phase E.

Architecture Content Framework¶

A detailed model of architectural work products, including deliverables, artifacts within deliverables, and the Architecture Building Blocks (ABBs) that deliverables represent

EA Capability Model¶

An Enterprise Architecture Capability is the ability to develop, use, and maintain the architecture of a particular enterprise, and use the architecture to govern change.

The term “capability” is defined differently by different practitioners, most commonly when it is used as part of a formal analysis technique when the definition must be precise and constrained. The term EA Capability is used as a management concept that facilitates planning improvements in the ability to do something that leads to enhanced outcomes enabled by the capability.

While every organization can benefit from an EA Capability, each organization will require a different EA Capability.

Architecture Capability Framework¶

A structured definition of the organisations, skills, roles and responsibilities to establish and operate an Enterprise Architecture

Capability Assessment¶

Before embarking upon a detailed architecture definition, it is valuable to understand the baseline and target capability level of the enterprise. This Capability Assessment is first carried out in Phase A, and updated in Phase E

Stakeholder Management¶

Stakeholder management is an important discipline that successful architects can use to win support from others. It helps them ensure that their projects succeed where others fail. The technique should be used during Phase A to identify the key players in the engagement, and also be updated throughout each phase. The output of this process forms the start of the Communications Plan.

Gap Analysis¶

Done at end of every phase

The Gap Analysis technique is usually the final step within a phase.

The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.

Architecture Tradeoff Method¶

There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements.

It is important to identify alternative Target Architectures and build understanding of different possibilities and identify trade-offs between the alternatives. Creating an architecture normally requires trade-offs among competing forces.

Presenting different alternatives and trade-offs to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final Target Architecture. Below Figure illustrates the architecture trade-off method.

Value Stream¶

A value stream is depicted as an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. In modeling terms, those value-adding activities are known as value stream stages, each of which creates and adds incremental stakeholder value from one stage to the next.

Value in a value stream, is achieved through a series of sequential and/or parallel actions, known as value stream stages, that incrementally create and add stakeholder value from one stage to the next.

Business Capability Model¶

A business capability model represents the currently active, stable set of business capabilities (along with all of their defining characteristics) that cover the business, enterprise, or organizational unit in question.

The first task of business capability modeling is to capture and document all of the business capabilities that represent the full scope of what the business segment under consideration does today (irrespective of how well it does it) or what it desires to be able to do in the future. The second task is to organize that information in a logical manner.

GAP Analysis¶

The Gap Analysis technique is usually the final step within a phase. The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.

Architecture Scope¶

Note

Four dimensions are typically used in order to define and limit the scope of an architecture:

Breadth - what is the full extent of the enterprise (i.e., Enterprise Focus)
Depth - To what level of detail should the architecting effort go (i.e., Level of detail)
Time Period - what is the time period that needs to be articulated for the Architecture Vision
Architecture Domains: a complete Enterprise Architecture description should contain all four architecture domains (Business, Data, Application, Technology).