TOGAF in 14 pages – on its architecture levels, service-orientation and the rest

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 11/09/2017 13:44

 

Some equate the Open Group Architecture Framework (TOGAF®) to Enterprise Architecture (EA).

Do your customers presume that EA is “doing TOGAF”? This paper may help you educate them.

Contents

EA not = TOGAF. 1

Five levels of architecture (yes five) 2

The history of TOGAF. 5

Service-oriented architecture development 5

TOGAF part 1: Introduction. 6

TOGAF part 2: The Architecture Development Method (ADM) 7

TOGAF part 3: ADM guidelines and techniques. 7

TOGAF part 4: Content framework (documented products) 8

TOGAF part 5: The enterprise continuum and repository. 9

TOGAF part 6: The two reference models. 10

TOGAF part 7: Architecture capability (especially roles in governance) 11

How TOGAF is written. 12

Further reading. 13

Footnote. 13

 

EA not = TOGAF

To begin with, two brief observations on EA.

First, mainstream EA is not = top level business planning.

Rather, EA is about business system planning - at a strategic and cross-organisational level.

Sometimes, business planning and business system planning go hand in hand, but not always.

EA work must be coordinated with business planning, project management and IT services/operations management.

 

Second, an EA is not a portfolio of discrete or silo systems or projects.

Historically, EA started as a reaction to the costs, risk and issues created by silo systems.

“Enterprise-level architecture is required to constrain the [system] design and development activity.” Zachman 1982

EA is about cross-organisational optimisation, integration and standardisation of systems.

 

TOGAF = not = EA, however it is certainly relevant to EA.

The mainstream EA agenda is to address the benefits, costs and risks of IT-related work.

The TOGAF agenda is also to address the benefits, costs and risks of IT-related work.

It continually relates all plans back to executive-level business goals, drivers and strategy.

 

Today, TOGAF is a management framework for what it calls "the architecture project"

That is, an architecture-intensive project to design, plan and govern changes to an enterprise's business system(s).

TOGAF can be used in a way that supports and enables the work of enterprise architects.

But since it is often used as a framework for architecture-intensive solution-level projects, using TOGAF does not make you an enterprise architect.

 

TOGAF provides a framework for architecting at high and low levels, but it does not teach architecting.

E.g. it mentions structured analysis in one sentence; in a training course, we may spend 30 minutes or more on that.

E.g. it defines a data dissemination diagram in a few sentences; we usually spend at least an hour on that, and a process for using it.

Five levels of architecture (yes five)

Running a TOGAF class for an EA team of five, it turned out three of them had previously attended a different, rather soporific, TOGAF course.

We began by discussing and agreeing: TOGAF provides a management framework for “architecture projects” at whatever level you choose to do them.

A study of the TOGAF 9.1 standard shows it divides architecture into five levels, as shown in the table below.

The distinctions drawn between the levels in different chapters are roughly but not exactly consistent.

 

 

Architect Roles as defined in TOGAF chapter 52

---------------

Architecture Landscape as defined in TOGAF chapters 3, 20 and 41

A longer interpretation of the roles at different levels

Enterprise

Architecture

Enterprise architect: works at a landscape and technical reference model level.

Focuses on enterprise-level business functions required.

Often leads a group of Segment Architects/Solution Architects related to a given program.

---------------

A summary formal description of the enterprise.

An executive-level, long-term view.

Enterprise architects work at the cross-organisational and strategic level:

   are concerned to optimise, standardise and integrate business systems,

   maintain a summary description of the enterprise and its system,

   maintain standards, principles, reference models and patterns,

   develop roadmaps for change at a strategic, executive-level,

   govern architects working at lower levels.

Segment

Architecture

Segment architect: works on specific business problems or for a specific organization.

Focuses on enterprise-level business solutions in a given domain.

---------------

A detailed, formal description of an area within an enterprise.

Architecture roadmaps at a program or portfolio level.

Segment architects work for a division or domain of an organization:

   act as enterprise architects for the portfolio of solutions/systems in their business area,

   maintain a description of their division or domain and its systems,

   develop roadmaps for change at a portfolio or program or level,

   govern architects working at lower levels.

Solution

Architecture

Solution architect: works on a system or subsystem.

Focuses on system technology solutions

---------------

A description of a discrete and focused business operation or activity, supported by IS/IT.

Typically applies to a single project or project release.

Solution architects shape a solution and join up the technical specialists who work on it:

   address the problems and requirements of a particular business operation,

   work to deliver a new or changed system using particular information technologies,

   guide projects managers as to the time, cost and risks of project-level work,

   maintain descriptions at the solution outline or high-level design level,

   develop roadmaps for change at a project or release level,

   govern project work (designers, technical specialists, developers, builders and configurers).

Capability

Architecture

A highly detailed description of the architectural approach.

to realize a particular solution or solution aspect.

Architecture roadmaps realizing capability increments.

How the enterprise can support a particular unit of capability.

Allow for individual work packages and projects to be grouped.

Designers and technical specialists complete detailed designs.

Guide those who develop, build, configure and deploy systems.

Capability

Increment

A discrete portion of a capability architecture that delivers specific value.

Work package?

 

TOGAF 7 was an enterprise technology architecture framework, pitched at the highest level of the table above.

From version 7 to 9, TOGAF shifted its emphasis from technology architecture to business architecture, and shifted its focus downwards towards solution architecture.

TOGAF now focuses less on EA level work – portfolios, reference models, business function/capability definition etc.
The process, the ADM, is management framework for "architecture projects" at any level you choose.
Many of the products in the Content Framework fit solution architecture better than enterprise architecture.

 

On architecture at the SA level

The term solution architecture has been used for several decades.

It has long been embedded in the Skills Framework for the Information Age, and it is the level at which the ADM is often applied.

For more on this, read Enterprise and Solution Architecture: the difference?

 

On architecture at the EA level

EA emerged in the 1980s out of business system planning, which is subordinate to business planning.

The purpose of mainstream EA has always been to optimise and improve core business processes.

“An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference).

“Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).

The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.” (TOGAF 9.1, 2009 reference)

 

A solution architect’s vision usually has a relatively short time frame and narrow scope.

Enterprise architects take the broadest possible view, look to standardise, integrate and coordinate business systems across an enterprise.

They respond to the outputs of business planning, align system changes with them, and may influence them.

 

Business Planning

Business mission, vision, drivers, strategies, goals and top-level business plans.

Mergers, acquisitions, divestments, internal organisation restructurings and rationalisations.

Enterprise Architecture 

(Business Systems Planning)

Business

Architecture

Business functions/capabilities, roles, processes/value streams and their interrelationships.

The services they provide to each other and to entities in the business environment.

Information System

Architecture

Applications and their interrelationships

The services applications provide to each other and to business activities.

Data stores and data flows, the data structures they contain and the qualities of that data.

Technology

Architecture

Platform technologies and their interrelationships

The services technologies provide to each other and to business applications.

 

EA is challenging politically as well as technically.

The idea is to take a cross-organisational and strategic perspective of the architecture domains in the table above. 

To do this, architects need not only appropriate knowledge, skills and resources, but also cross-organisational authority.

The history of TOGAF

The Open Group’s vision is: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”

Their mission is: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

They look to realise their vision and mission through the development of IT standards that make information systems portable and interoperable.

 

EA had been discussed for about 20 years before The Open Group Architecture Framework (TOGAF) was published.

Yet to begin with, TOGAF owed little or nothing to that EA history.

 

Version 1 to 7

In 1990s, the US “IT Management Reform Act” demanded that federal government CIOs maintain a “sound and integrated IT architecture repository”.

TOG members developed TOGAF versions 1 to 7 as a framework for IT architecture (sometimes called EITA, rather than EA).

The approach was based on the Technical Reference Model (TRM) discussed below.

 

Version 8

This "Enterprise Edition" borrowed a great deal from the US government’s Federal EA Framework (1999).

FEAF declared its aims as: “common data and business processes”, “information sharing” and “new and improved processes”.

TOGAF 8 extended the service-oriented architecture development approach already used in TOGAF 1 to 7.

"TOGAF Version 8… uses the same underlying method for developing IT architectures that was evolved [in] TOGAF up to and including Version 7.

That method was to define a system or component, an architecture domain or layer, logically, by the services it provides.

Version 8 applies that… method to the other domains of an overall Enterprise Architecture - the Business Architecture, Data Architecture, and Application Architecture, as well” http://www.opengroup.org/architecture/togaf7/index7.htm

 

Version 9

TOGAF versions 1 to 7 were enterprise-wide, but infrastructure technology-oriented.

Versions 8 and 9 became more business-oriented, but also more project-oriented, with side bar references to EA.

TOGAF 9 introduced a content framework and meta model based on a service-oriented approach to system specification.

Service-oriented architecture development

TOGAF has always been thoroughly service-oriented.

It regards an enterprise as a system, as a collection of encapsulated building blocks that interact.

All architecture domains and the building blocks within them are defined by the services they offer.

The table below shows the terms TOGAF uses when abstracting services from building Blocks.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Structures

Building Blocks

Functions & Roles

Application Components

Technology Components


A service is a logical representation of a repeatable activity that has a specified outcome.

A service is first named, then lightly described, and eventually defined in a service contract.

A service contract makes no reference to the internal workings of any building block that provides it (or other building blocks it depends on).

 

The ADM is a method for service-oriented architecture development.

In phases B and C, contracts for Business and IS Services are recorded in the Architecture Requirements Specification. 

In phase C, the III-RM provides a service-oriented design pattern for the applications architecture domain/layer. 

In phase D, the TRM catalogues the foundation Platform Services provided by the technology architecture domain/layer.

These three phases populate the Architecture Continuum and Architecture Repository with Architecture Building Blocks defined by the services they offer.

TOGAF part 1: Introduction

The seven parts of the current standard are introduced below, with observations.

(I am qualified to make observations, having taught TOGAF since version 8, and taught architects before that.)

 

This first part of TOGAF introduces the context for TOGAF, and defines core concepts.

TOGAF also promotes the “business operating model” principle (from “EA as Strategy”, 2006) of standardising and integrating processes across the enterprise.

 “Operating model” for core business processes

High integration

Coordinated

Unified

Low integration

Diversified

Replicated

 

Low standardisation

High standardisation

 

Observations

TOGAF is a general purpose architecture framework – which can be and often is decoupled from EA

It is probably more often used for solution architecture work than for EA.

It does not teach you how to do architecture.

It is a menu of things TOG architecture forum members have done on different projects.

It assumes you know how to do these things (though some TOGAF tutors may explain some of them).

See “Further Reading” for principles used in how TOGAF describes architectures.

TOGAF part 2: The Architecture Development Method (ADM)

The ADM is the core of TOGAF; it is a process for architecture-intensive work to design, plan and govern business systems.

It presents a menu of phases and activities in a rational sequence – outlined below.

You are expected to tailor the ADM process and meld it into your PMO processes.

 

ADM phase

Read it as an architecture project management framework thus

Preliminary

Establish the capability to follow the ADM process from A to H (when a request for work arrives).

Requirements management

Capture and manage requirements (continuous)

A: Architecture vision

Conduct feasibility study, get stakeholder approval for work to be done.

B,C,D: Business, IS and Technology architectures

Logical design of business processes and roles, and supporting data, applications and infrastructure.

E: Opportunities and solutions

Identify and select between suppliers and technologies, and plan transition states

F: Migration planning

Plan projects to develop and deploy new/changed systems.

G: Implementation governance

Govern development and deployment projects.

H: Architecture change management

Govern system changes after deployment.

 

Observations

A cycle of ADM starts with a "request for architecture work" (say, to improve our care-in-the-home business operation).

If stakeholders don’t approve the initial “architecture vision” at the end of phase A, then it is not taken forward.

If they do approve it, then the next step is to study the human activity system in more detail.

And then, how IT can best be used to support and enable that by regularising behaviors, store and transmit information.

 

Architects must tailor TOGAF to the needs of those who request architecture work.

You don’t set out to eat everything on the TOGAF menu in one cycle.

You select items that will help you address a sponsor's particular "request for architecture work".

TOGAF part 3: ADM guidelines and techniques

This part contains techniques used during the ADM, and guidelines for adapting the ADM.

Four guidelines for adapting the ADM

Below are a few observations on the guidelines.

 

Iterative ADM

You can iterate between ADM phases, within each phase, and perform activities iteratively and/or in parallel.

You are not expected to follow the process in a strictly sequential fashion.

You tailor it, in concert with other methods your organisation uses.

 

Fractal ADM levels

Look again at the table at the top of this paper.

TOGAF defines three levels of architecture project, Enterprise, Segment and Capability (aka Solution) Architecture.

Note that in TOGAF 9, a business capability is "high-level function”, and might correspond to the "segment" level in the architecture landscape

But a capability in the architecture landscape is very different; it is a "highly-detailed… solution or solution aspect".

 

Service-oriented ADM

TOGAF has always been thoroughly service-oriented.

The chapter on SOA does not add much of value.

 

Security-oriented ADM

The chapter on security maps security considerations (copied from NIST standards) to ADM phases.

UK architects would more likely map the ISO 27001 standard to ADM phases.

TOGAF is not a security architecture framework.

The aim is only to help you position security considerations in the ADM process.

Ten techniques used during the ADM

Again, TOGAF is a management framework for architects; it does not teach professional architects how to do architecting.

Several of the techniques are management-oriented (e.g. stakeholder management, risk management) rather than architecture-oriented.

TOGAF part 4: Content framework (documented products)

TOGAF does not prescribe how you document arhitectures.

It does contain an extensive menu of products that may be produced by architects during the phases of the ADM.

There is also a meta model indicating how the elements of these products are related.

 

The table below names some core concepts in the content framework.

The columns and rows imply relationships between concepts.

Some relationships are explicit in the TOGAF standard, some are implicit, some are more complex than shown here.

 

 

Deliverable

Architecture requirement specification

Architecture definition document

Architecture roadmap

Enterprise repository

Requirements repository

Architecture repository

Solution repository

Enterprise continuum

Requirements and context

Architecture building blocks

Solution building blocks

Phases and domains

 

Required behaviors

Logical structures

Physical structures

Phase B

Business architecture

 

Business goal/objective

 

Location

Business service

Function

Organisation unit

Process

Role

Actor

Phase C

IS architecture

III reference model

IS (app) service

Logical application component

Physical application component

 

 

Data Entity

Physical data component

Logical data component

Phase D

Technology architecture

Technical reference model

Platform (technology) service

Logical technology component

Physical technology component

 

 

Observations on business architecture

TOGAF catalogues more artifacts for documenting a business architecture than any other architecture domain.

It starts with analysis of required business goals, business services and the business scenarios required to deliver them.

The business architecture approach is based on universal system modelling principles.

 

The universal presumption is that activities can be modelled in:

·         sequences (called processes, scenarios)

·         cohesive clusters (called nodes, functions, roles)

·         collaborations (networks of nodes with flows between them).

 

The flows between nodes may be of energy, materials and/or information.

Flows may be interpreted as of value to senders and/or receivers.

 

TOGAF’s business architecture artifacts might be renamed in the current fashion.

·         Scenarios and processes might be called value streams.

·         Functional decomposition hierarchies might be called capability maps.

·         Node connectivity diagrams might be called value networks.

Renaming them doesn’t change the general principles.

 

Activities can be modelled at several levels of abstraction, and the granularity of the atomic activity is up to you.

TOGAF part 5: The enterprise continuum and repository

The enterprise continuum is a structure for classifying architecture definition products.

The enterprise repository is a data store that contains architecture definition products (and other things).

Enterprise Continuum

Buildings blocks

Enterprise Repository

Requirements

and context

 

Requirements

repository

Architecture

continuum

Foundation

architecture

Common systems

architecture

Industry

architecture

Organisation

architecture

Architecture BBs

Architecture

repository

Solution

continuum

Foundation

solutions

Common systems

solutions

Industry

solutions

Organisation

solutions

Solution BBs

Solutions

repository

Deployed

solutions

 

 

 

Observations

Implicit in TOGAF is a rejection of how the Zachman Framework was used in the 1990s.

You never “do TOGAF”, or attempt to fill the architecture repository for its own sake.

You use TOGAF as checklist for architecture work to be done in response to a sponsor’s request for work.

You populate the repository as a side effect of sponsored work.

It is questionable how many TOGAF users maintain a coherent enterprise repository.

TOGAF part 6: The two reference models

“Enterprise-level architecture is required to constrain the [system] design and development activity.” Zachman

A reference model is a general structure or pattern that helps to constrain or steer system design activity.

 

“EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” Zachman.

“EA regards… the enterprise as one system, or a system of systems” TOGAF 9.1

TOGAF’s two reference models give architects ways treat the entire enterprise as one system.

 

Information Infrastructure Reference Model (III-RM) for cross-organisational integration of application components

In the 1980s, an EA vision was to envision the entire applications portfolio as 1 business application component.

And to build 1 business data model as though for 1 enterprise-wide integrated application.

However, it was recognised that a large enterprise may have to maintain hundreds of substantial business databases.

So, to achieve the vision will require cross-organisational application integration.

 

TOGAF version 8 introduced the III-RM with a view to realising the TOG vision of Boundaryless Information Flow via application integration.

The III-RM is a design pattern for application integration (though only one of many design patterns that may be used for this purpose).

The idea is to give the appearance of 1 application with 1 database.

 

The Technical Reference Model (TRM) for cross-organisational standardisation of technology components

In 1990s, the US “IT Management Reform Act” demanded that federal government CIOs maintain a “sound and integrated IT architecture repository”.

TOG members developed TOGAF versions 1 to 7 as a framework for IT architecture (sometimes called EITA, rather than EA).

They were designed to help IT service managers de-duplicate (rationalise) their enterprise’s infrastructure technology estate.

 

The TRM is used in this rationalisation process.

The idea is to envision the entire platform technology layer as 1 technology component.

To encapsulate that layer behind a 1 logical interface, offering thousands of discrete platform services.

The TRM is a nothing more or less than a definition of that logical interface.

It classifies the platform services provided by platform technologies, and helps people analyse their baseline technology estate

The transformation approach is to bundle the platform services into “cohesive clusters” assignable to discrete logical technology components.

Then choose target physical technology components to realise those logical technology components, more efficiently than before.

 

The TRM chapter defines the interface, not the approach.

The approach was defined in TOGAF 1 to 7, and in Phase D of TOGAF 8.

It has been compressed to brief aside in TOGAF 9.

TOGAF 9 now presents an approach to developing the technology architecture for a single solution.

TOGAF part 7: Architecture capability (especially roles in governance)

This last part is about the roles of architects in an enterprise, especially in governance.

This table highlights core governance activities in TOGAF.

ADM phase

Core governance activities

Preliminary

Establish the architecture board and governance structure

A: Architecture vision

Produce a contract for B to F: The Statement of Architecture Work.

B to F (The architecture project)

G: Implementation governance

Govern development and deployment projects – to development contract

H: Architecture change management

Govern system changes after deployment – to business users contract

 

There is governance of architects by an architecture board.

There is governance by architects of system development/implementation and system change.

 

Observations

The architecture board publish generic principles, standards, road maps etc. to which architects are expected to conform.

Architecture Governance

Architecture Practice

Principles, standards etc.

<publish>                        <used by>

Architecture board  <monitor and guide> Architects

Architecture definitions

<create and use>        <realised by>

Architects  <observe and envisage>  Systems

 

Architects cooperate with management roles performed by others

·         Project managers manage projects to implement systems designed by architects.

·         IT services management (change advisory board) manage work to change live systems.

Architects ensure projects and changes accord with architecture principles, standards and whatever architecture definition has been developed.

How TOGAF is written

It is difficult to get to grips with TOGAF just by reading it.

Or by attending a course presented by a tutor who qualified by passed the TOGAF exams.

Passing the exams is the least of what you need to know.

 

It helps to understand the context for TOGAF and its evolution to date:

·         US legislation that directed CIOs to maintain an IT architecture repository.

·         US federal government guidance on what EA means.

·         The broad methodology history that TOGAF draws from.

·         Various systems analysis and design methods and architecture frameworks.

·         The Open Group, its mission, vision and service-oriented specification principles.

·         The processes by which TOGAF content is developed.

 

Nobody is employed to write TOGAF; you might say it is crowd-sourced.

Any architecture forum member can request a change or draft a contribution.

From that point to publication in TOGAF is a long and democratic process.

 

There is no director or editor you can press to address your special concern.

TOGAF’s scope is determined by what forum members choose to write about.

If you want to contribute, then join the forum.

 

TOGAF tends to lag behind the times; it does not anticipate trends or publish speculative practices.

It contains only what has been approved by enough forum members

As things stand, the refresh cycle takes several years (remember training courses and examinations have to be updated).

 

TOGAF is free to read!

The astonishing thing is not that TOGAF is flawed; it is that it is reasonably coherent and consistent.

Further reading

Enterprise and Solution Architecture: How do they differ?

TOGAF core concepts

Premises of EA in general and TOGAF in particular

 

Footnote

A fuller version of text distilled in the table at the top of the paper.

TOGAF 9.1 Section

3

20.2

20.2

20.2

41.2

 

 

Provides an organizing framework for

Allows for

The development of effective

 

Enterprise or Strategic Architecture

A summary formal description of the enterprise

An executive-level, long-term view

operational and change activity

direction setting an executive level.

 

A long-term summary view of the entire enterprise.

 

Segment Architecture

A detailed, formal description of an area within an enterprise used at the program or portfolio level

operational and change activity

direction setting

architecture roadmaps at a program or portfolio level.

More detailed operating model for an area within an enterprise.

Solution architecture

A description of a discrete and focused business operation or activity

How IS/IT supports that operation. 

Typically applies to a single project or project release.

 

 

 

 

Capability Architecture

A highly detailed description of the architectural approach to realize a particular solution or solution aspect.

change activity

 

architecture roadmaps realizing capability increments.

In a more detailed fashion how the enterprise can support a particular unit of capability.

Provide an overview of current capability, target capability, and capability increments

Allow for individual work packages and projects to be grouped within managed portfolios and programs.

Capability Increment

A discrete portion of a capability architecture that delivers specific value.

 

 

 

 

 

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.