TOGAF Content Framework (for architecture description)

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site 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.

THIS PAPER IS AGEING: KEY CONCLUSIONS FROM THE ANALYSIS BELOW HAVE BEEN DISTILLED INTO THIS SLIDE SHOW

TOGAF-ArchiMate alignment

TOGAF is the most popular public domain enterprise architecture framework.

Since it is voluminous, multi-authored and not an easy read; the Avancier web site hosts papers to help you understand it.

Beware that most TOGAF authors take it for granted you know architecture description techniques already.

TOGAF is a specific transformation management framework

If you want to understand enterprise architecture in general and specific architecting practices, then go to avancier.website.

Abstract

The TOGAF content framework contains advice on architecture description in the form of deliverables, artefacts and entities.

This paper contains analysis and discussion of the content framework.

Contents

The Architecture Content Framework structure. 1

Building blocks (architectural entities) 1

Artefacts. 2

Deliverables. 4

Meta model 5

Why there is no "right" meta model for all 6

Difficulties with the explicit meta model 6

Difficulties with the implicit meta model (the one in the text) 9

And some oddities. 13

The Architecture Content Framework structure

TOGAF encourages architects to document architectural assets and maintain this documentation.

The architecture content framework defines content (products or documentation) that architects may produce.

It does not mandate any products, but does define potentially useful:

· Deliverables: contents lists for word processor documents, which often contain

• Artefacts: catalogues, tables and diagrams, which describe and relate
• Building blocks: discrete architectural entities like business role, application and technology.

One building block may appear in several artefacts. One artefact may appear in several architecture descriptions.

Building blocks (architectural entities)

Meta model for an architecture repository

A building block is an architectural entity that appears in architecture description.

TOGAF is underpinned by two big ideas:

• Services (the required behaviour of a system) are provided by components (the designed structure of a system).
• Logical components are defined before physical (implementation-specific) components.

These two ideas can be used to classify the architectural entities in the TOGAF meta model.

Direction and planning	Principle, Gap, Constraint, Work Package, Assumption, Requirement, Capability
Avancier’s classification	Requirements and behaviour	Logical structure	Physical structure
Business	Driver, Goal, Objective		Location,
	Service (Service Quality, Measure, Contract)	Function	Organization Unit
	Process (Event, Control, Product)	Role	Actor
Applications	Information System Service	Logical Application Component	Physical Application Component
Data		Data Entity Logical Data Component	Physical Data Component
Technology	Platform Service	Logical Technology Component	Physical Technology Component

Note that TOGAF authors use the term building block in two ways:

· Loosely: any architectural entity mentioned above, any potentially reusable element of architecture description.

· Tightly: an encapsulated component; defined by its interface (the functions or services it offers); replaceable by any other building block with the same interface; including business functions, applications and technologies.

Click here to see a slide show introducing the entities and relationships in TOGAF.

Artefacts

An artefact is a view or model that shows architectural entities in relation to each other. It may take the form of a catalog (list), matrix (table), or diagram

An artefact type (or view point) is a template for an artefact. The table below contains the name TOGAF artefact types, under the phase that produces them.

Preliminar	Phase A: Architecture Vision artefacts		Phase E Opportunities and Solutions Artefacts
Principles Catlaog	Stakeholder Map Matrix Value Chain Diagram Solution Concept Diagram		Project Context Diagram Benefits Diagram
Phase B Business Architecture artefacts	Phase C Data Architecture artefacts	Phase C Application Architecture artefacts	Phase D Technology Architecture artefacts
Organization/Actor Catalog Role Catalog Business Service/Function Catalog Driver/Goal/Objective Catalog Location Catalog Process/Event/Control/Product Catalog Contract/Measure Catalog	Data Entity/Data Component Catalog	Application Portfolio Catalog Interface Catalog	Technology Portfolio Catalog Technical Reference Model Technology Standards Catalog
Business Interaction Matrix Actor/Role Matrix	Data Entity/Business Function Matrix Application/Data Matrix	Application/Organization Matrix Role/Application Matrix Application/Function Matrix Application Interaction Matrix	Application/Technology Matrix
Business Footprint Diagram Business Service/Information Diagram Functional Decomposition Diagram Product Lifecycle Diagram Goal/Objective/Service Diagram Business Use-Case Diagram Organization Decomposition Diagram Process Flow Diagram Event Diagram	Conceptual Data Diagram Logical Data Diagram Data Dissemination Diagram Data Security Diagram (or matrix) Data Migration Diagram Data Lifecycle Diagram Class Hierarchy Diagram	Application Communication Diagram Application and User Location Diagram System Use-Case Diagram Enterprise Manageability Diagram Process/Application Realization Diagram Software Engineering Diagram Application Migration Diagram Software Distribution Diagram	Environments and Locations Diagram Platform Decomposition Diagram Processing Diagram Networked Computing/Hardware Diagram Communications Engineering Diagram

Notice that 90% of the artefacts are produced during phases B, C and D, and may be copied into the Architecture Definition Document deliverable.

There are overlaps between artefacts. You could document the deployment of application software to computers or locations in 6 artefacts (Application and User Location Diagram, Software Distribution Diagram, Application/Technology Matrix, Environments and Locations Diagram, Processing Diagram and Networked Computing/Hardware Diagram).

Deliverables

A deliverable is a document signed off at the end of an ADM phase.

The table below lists deliverables against the phases that produce them.

There is an extended version of this table, including artefacts and techniques, at avancier.co.uk.

Iterations	Phases	Objectives	Notable deliverables
Capability	Preliminary	Determine capability, Establish capability	Organisational model for EA
		Identify/tailor Frameworks	Tailored Architecture Framework
		Define Architecture Principles	Architecture Principles
			Request For Architecture Work
	Architecture Vision	Develop Architecture Vision	Architecture Vision (ADD v0.1)
		Approval of Statement Of Architecture Work	Communication Plan
			Statement Of Architecture Work
			Capability Assessments
Development	Business Architecture	Determine target architecture	Architecture Definition Document
		Identify roadmap components	Road Map Components
			Architecture Requirements Specification
	IS (Data) Architecture	Determine target architecture	Architecture Definition Document
		Identify roadmap components	Road Map Components
			Architecture Requirements Specification
	IS (Apps) Architecture	Determine target architecture	Architecture Definition Document
		Identify roadmap components	Road Map Components
			Architecture Requirements Specification
	Technology Architecture	Determine target architecture	Architecture Definition Document
		Identify roadmap components	Road Map Components
			Architecture Requirements Specification
Planning	Opps & Solutions	Generate Initial Roadmap	Architecture Road Map (Transitions, WPs)
		Identify Transitions	Implemntn & Migration Plan (strategy)
			Architecture Requirements Specification
			Capability Assessments
	Migration Planning	Complete Roadmap & Migration Plan	Implemntn & Migration Plan
		Coordinate Plan with Change Management	Implemntn Governance Model
		Ensure cost & value of work packages understood	Change Requests
Governance	Implemntn Governance	Ensure conformance of Implemntn	Architecture (Development) Contracts
		Govern solution & change requests	Compliance Assessments
			Change Requests
	Arch. Change Management	Maintain architecture lifecycle	Architecture (Operational) Contracts
		Execute governance	Change Requests
		Ensure capability meets requirements	Request For Architecture Work
	Requirements Management	Sustain RM process	Architecture Requirements Specification
		Manage architecture requirements	Requirements Impact Statements
		Ensure architecture requirements available

For each deliverable, TOGAF provides a candidate list of headings, with no further advice.

Architects are expected to store the documentation in a repository - using the enterprise’s knowledge management systems, tools and file stores.

Architects are expected to structure and index the repository for ease of access - using structuring and indexing devices such as the enterprise continuum.

Meta model

The meta model contains about 30 entities and 75 relationships.

The table below shows the entities in the meta model. There are horizontal and vertical relationships.

Direction and planning	Principle, Gap, Constraint, Work Package, Assumption, Requirement, Capability
Avancier’s classification	Requirements and behaviour	Logical structure	Physical structure
Business	Driver, Goal, Objective		Location,
	Service (Service Quality, Measure, Contract)	Function	Organization Unit
	Process (Event, Control, Product)	Role	Actor
Applications	Information System Service	Logical Application Component	Physical Application Component
Data		Data Entity Logical Data Component	Physical Data Component
Technology	Platform Service	Logical Technology Component	Physical Technology Component

Click here to see a slide show introducing the entities and relationships in TOGAF.

Click here to see a deeper analysis of TOGAF explicit and implicit meta models.

The explicit meta model is not entirely consistent with the implicit model in the text.

The TOGAF meta model will always fall short of answering questions you have to answer in practice. It offers some challenging puzzles.

Why there is no "right" meta model for all

Functions, Processes, Roles are different ways to group elementary activities. You will probably not model all three views to the same level of detail.

TOGAF's implicit and explicit meta models are centred on Applications.

Applications are related to Locations, Processes, Roles, Actors, Functions, Data, Technologies, etc.

But which Apps? Logical Apps or Physical Apps? Do you relate to both? or choose one?

And what if the Logical to Physical App is not a one to one relationship?

Strictly speaking, Apps should map to Platform Services which map to Technologies. But most people connect Apps to Technologies directly.

Similarly, Roles should map to IS Services which map to Apps. But most people connect Roles to Apps directly.

So the direct relationships are the ones shown in the TOGAF meta model.

Difficulties with the explicit meta model

Difficulties with the meta model principles

The table below comments on the key relationship concepts related to the core meta model entities.

But first, since TOGAF authors are slack about defining terms and using terms, here is a consistent terminology.

There are human processes, computer processes, and hybrid human-computer processes that may be called workflows or use cases.

What does it mean for a process to be described, implemented, deployed and executed?

· A process is described or defined as a sequence of actions or instructions for a human or computer actor (in ADM phases A to E).

• A process is implemented by defining the actions at an executable level, then publishing and testing the process (in ADM phase G).
• A process is deployed by publishing it where actors can read it and execute it (in ADM phase G).
• A process is executed when a human and/or computer actor follows a published process (in ADM phase G and H).

What does it mean for an application to be implemented and deployed?

· An application is implemented by coding its processes at an executable level, then publishing and testing those processes.

• An application is deployed by publishing it where platform technologies can read and execute its processes.

Meta model principle (p 359)	Comment
Process should normally be used to describe flow A process is a flow of interactions between functions and services and cannot be physically deployed.	All processes are deployed in the sense they are published and given to a human or computer actor to be executed.
All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports; i.e., an application implements a function that has a process, not an application implements a process.	This appears to be gobbledegook.
Function describes units of business capability at all levels of granularity The term ‘‘function’’ is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function.	A value chain is a behavioural model rather than a structural one, so is better described as a process than a function.
Business services support organizational objectives and are defined at a level of granularity consistent with the level of governance needed.	Governance by whom of what?
A business service operates as a boundary for one or more functions.	A business service may be pinned to a physical organisation unit and/or a logical business function.
The granularity of business services is dependent on the focus and emphasis of the business (as reflected by its drivers, goals, and objectives).	Appears to be waffle. A service may be decomposed into finer-grained services.
A service in Service Oriented Architecture (SOA) terminology is a deployable unit of application functionality This is closer to an application service, application component, or technology component, which may implement or support a business service.	OK, then let us call that an IS or application service rather than a business service.
Business services are deployed onto application components. Business services may be realized by business activity that does not relate to IT, or may be supported by IT. Business services that are supported by IT are deployed onto application components.	What does deployed mean? Published? Provided by? See discussion above this table. Some business services are deployed as IS services provided by application components.
Application components can be hierarchically decomposed and may support one or more business services.	Yes
It is possible for a business service to be supported by multiple application components, but this is problematic from a governance standpoint. It is symptomatic of business services that are too coarse-grained, or application components that are too fine-grained.	Highly questionable. Some business services are coarse-grained Some application components are fine-grained.
Application components are deployed onto technology components.	Yes
An application component is implemented by a suite of technology components. For example, an application, such as ‘‘HR System’’ would typically be implemented on several technology components, including hardware, application server software, and application services.	What does implemented mean? Coded and tested? Executed? See discussion above this table.

Difficulties relating logical and physical architecture entities

The phases of ADM and the meta model are clearly about describing logical Architecture Building Blocks (ABBs).

But phase E adds more physical Solution Building Blocks (SBBs).

This raises questions such as

· Do ABB and SBBs have the same attributes?

• Do ABB and SBBs have the same relations?
• How do we map physical SBBs to logical ABBs?

The meta model can be seen as containing logical and physical versions of five entity types.

Logical entities	Physical entities
Function	Organization Unit
Role	Actor
Logical Application Component	Physical Application Component
Logical Data Component	Physical Data Component
Logical Technology Component	Physical Technology Component

The meta model does not contain logical and physical versions of other entity types (e.g. Business Service, Capability, Event).

This makes for uncertainty about some relationships.

E.g. The meta model says we map business service to (logical) business function.

But what about the mapping declared in the text, that is, business service to (physical) organisation unit? Should a unit manager be responsible for the service contract?

Difficulties related to decomposition of entities

A tabular meta model usually has the form: plural entities <relate to> plural entities. Meaning the relationships are N to N.  

Unfortunately, the meta model has the form: singular entity <relates to> singular entity.

This might not matter if the text did not also tend to conflate concepts into 1 to 1 relationships.

E.g. suggests 1 business service should map to 1 application component.

Some of the meta model principles don’t account for recursive decomposition of an entity.

E.g. to suggest 1 business service maps to 1 application component both restricts the meaning of business service, and implies a fixed level of granularity.

Have the authors and editors appreciated how hierarchical decomposition (both of systems into subsystems, and of process flows into sub processes) undermines attempts to draw 1-1 or 1-N relationships between concepts in the different hierarchies?

And do hierarchically decomposed entities (like Service) really have the same attributes at the top and bottom level of decomposition?

A few more notes on the decomposition of entities:

• There are 24 recursive relationships, not shown in the meta model diagram.
• 16 entity types (e.g. Function) are recursively decomposed in a hierarchical structure; which belies some entity definitions
• 9 entity types (e.g. Event) are not decomposable, but surely should be.

The same highly generalised architecture entities (function, service, capability, etc.) are used at every level of system decomposition. So, human activity systems are treated as scaled-up software systems.

Other oddities

The explicit meta model is missing some entities and relationships that appear significant in the text.

• Business Domain, Business Requirement, Technical Requirement, Principle, Standard, Network?
• Data Entity <created or used by) Business Function?
• Organisation Units <are given> Goals?
• Many of the 120 relationships listed are reverse-phrasing relationships, but 4 of those are missing and unaccounted for.

Also

• “Data Entity” is ambiguous, can be either a data store or a data flow.
• “Goal” and “objective” would surely better be merged into one hierarchically decomposed entity type.
• “Capability” and “Work Package” are out on a limb related to nothing but each other, which might be a good thing if means Capability is not a central concept.

Remarks

The completeness and consistency of the published meta model will remain problematic until we can be sure all TOGAF authors

· Do gap analysis and impact analysis before adding a new architectural entity. Consider how Capability now overlaps with Function.

· Do gap analysis and impact analysis before adding a new artefact that relates architectural entities. Consider that TOGAF maps Role to Function; but shouldn’t it map Role to Organisation Unit as well or instead?

· Agree the attributes of the entities they discuss.

Difficulties with the implicit meta model (the one in the text)

The text supports the explicit meta model in some places and seems at odds with it in others.

First, it may help to click here for a slide show on activity modelling that relates business functions, capabilities, processes etc.

Obscure text

I don’t say any of these sentences below is mistaken, but they are not easy to interpret.

They leave students confused about the overlapping concepts of business service, business capability, business function and organisation unit.

7.4.4 A business capability can be thought of as a synonym for a macro-level business function.

8.4.1.2 Business services are specific functions.

8.5 Relate business functions to organizational units in the form of a matrix report

22.4 Business-led SOA considers a business service to be a unit of business capability

22.4 The term ‘‘function’’ is used to describe a unit of business capability at all levels of granularity

22.4 The term ‘‘function’’ encapsulates terms such as value chain, process area, capability, business function, etc.

22.7 A function is a thing that a business does.

22.7 A business service is a thing that a business does.

22.7 Services support functions

22.7 Services are functions

22.7 Services have functions

34.2.1 Business Service supports business capabilities

34.2.1 Function delivers business capabilities

34.2.1 Function describes units of business capability at all levels of granularity

34.2.1 The term ‘‘function’’ encapsulates terms such as value chain, process area, capability, business function, etc.

Below are some more sentences from the text that clarify the relationship between functions and services.

8.4.1.2 Services are distinguished from functions through the explicit definition of a service contract.

22.7 Functions are not necessarily services.

22.7 A business service has a defined, measured interface

22.7 A business service has contracts with consumers of the service.

34.2.1 Any bounded unit of business function should be described as a function.

34.2.1 A business service operates as a boundary for one or more functions.

Here are some sentences that suggest the need to distinguish services at different levels of granularity.

22.4 A business service may be fulfilled by manual processes, or may be fully automated

22.5 Within an SOA.. finer-grained application services, creating new challenges and complexity. [Not half!] .

34.2.1 A service in (SOA) is actually much closer to an application service, which may implement or support a business service.

34.2.1 Application components can be hierarchically decomposed and may support one or more business services.

34.2.1 It is possible for a business service to be supported by multiple application components, but this is problematic.

And some more sentences about systems, processes and capabilities.

1.2 The architecture crosses multiple systems, and multiple functional groups within the enterprise.

6.2.5 The significance of systems is that it [sic] brings together the various domains (also known as People, Processes, and Material/Technology) to deliver a business capability.

34.2.1 A process is a flow of interactions between functions and services and cannot be physically deployed.

34.2.1 All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports.

34.2.1 An application implements a function that has a process, not an application implements a process.

35.9 Business Use-Case diagram provides added richness in describing business capability.

Surely the significance of a system is the value it delivers by production of outputs (products or services)? There is no reason to define that value or those outputs as being a single capability. To align “system” with “capability” further compounds the conflation of concepts into 1-to-1 relationships

It seems the term function is used for Application/component and for process. The term service is used for the interface to both a system and a single process. The term system is often used for application, but not always.

Relationships that seems OK

The text above suggests some relationships in accord with TOGAF 8 and traditional understanding

1 Business function <relates to> N Organisation units

1 Organisation unit <relates to> N Business functions

1 Organisation unit <relates to> N Business services

1 Business service <relates to> 1 Business capability.

1 Business service <relates to> 1 Interface

1 Business service <relates to> N Consumer contracts.

	TOGAF text	Commentary
Page 98	Structured Analysis: Identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business.	Yes. That is what TOGAF 8 implies. We map the (logical) business functions to the (physical) organisation units. Both are hierarchical system decomposition structures.
Page 104	Business services — the services that the enterprise and each enterprise unit provides to its customers, both internally and externally.	Yes. That is what TOGAF 8 says.
Page 244	… a business service to be a unit of business capability supported by a combination of people, process, and technology. A business service may be: n Fulfilled by manual processes, or may be fully automated n Fulfilled within an organization, or outsourced to a partner n Exposed to any combination of employees, customers, partners, and suppliers n Fulfilled at the point of use, at a divisional level, or as a corporate competency center.	Yes. That is compatible with TOGAF 8.
Page 247	Business Service: A business service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A business service is supported by combinations of people, process, and technology.	Yes. That sounds like TOGAF 8.
	Information System Service: An information system service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. Information system services are directly supported by applications and have associations to SOA service interfaces.	Yes. Though not all information systems are software.

Click here for a slide show that makes sense of business functions, capabilities and processes.

Relationships that seem mysterious

The text above suggests some relationships that need skilful interpretation

1 Business service <is a> 1 Business Function

1 Business service <relates to> N Functions.

1 Business service should not need > 1 Application component.

1 Business service <relates to> N Processes.

1 Business function <relates to> N Processes.

1 Function <relates to> 1 Process.

1 Process <relates to> 1 Function.

	TOGAF text	Commentary
Page 98	Use-case Analysis: The breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability.	You start use case analysis with actors and the processes they need to execute. But the term actor (in UML) is what TOGAF calls role. The purpose is to identify the services (use cases) that users (actors/roles) require of a system, and to define the step-by-step process flow within each use case.
	Process Modeling: The breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions.	You use process modelling to break down a process, not a function You use functional decomposition to break down a function You model the end-to-end flow of a process that may cross business functions. The two approaches are orthogonal to each other. They come together at the bottom level of decomposition, where the elementary process steps appear as the elementary functions of the business function hierarchy.
Page 99	Business services are specific functions that have explicit, defined boundaries that are explicitly governed.	Might be OK but contradicted by the next paragraph.
	The functions are split as follows: micro-level functions will have explicit, defined boundaries, but may not be explicitly governed. macro business functions may be explicitly governed, but may not have explicit, defined boundaries.	The “mays” in this leave little of the above definition intact.

And some oddities

Finally, there are some oddities in the process definition that are difficult to explain, for example:

Deliverable	TOGAF says output from...	BUT
Statement of Architecture Work	A, B, C, D	Why not updated by and output from later phases?
Architecture Definition Document	B, C, D	Why not updated by and output from later phases?
Architecture Requirements	B, C, D, E, F, Requirements Management	Why not output from Phase A?
Architecture Building Blocks	F,	Why not output from Phases B, C, D?
Compliance Assessment	G	Why not output from Phase H?
Solution Building Blocks	G	Why not output from Phase E?
Change Request	H	Why not output from Phases B to G?
Requirements Impact Assessment	H, Requirements Management	Why phase H, but not other phases?

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org