Functions and capabilities in business architecture and TOGAF^®

Integrating capabilities and value streams into a wider conceptual framework for business architecture

Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated Tuesday, 09 July 2019

Architects should use whatever words work for their stakeholders in communication with them.

But it is difficult to make sense of an architecture standard that uses common architectural terms with several meanings.

Every profession has its own domain-specific language, and terms commonly used by architects should be disambiguated.

Before reading this paper, read “The truth about functions and capabilities”.

And perhaps also Mapping TOGAF to the Nato Architecture Framework (NAF).

This paper goes to say more about meaning of function and capability in business architecture generally, and TOGAF in particular.

It also discusses the concepts called process and value stream, service and component

It discusses impacts on TOGAF’s terms, definitions and meta model.

After this reading this paper, you may want to read Business Architecture Roles - a survey of what business architecture means.

It distils from what is said in several job advertisements and several industry standards.

Contents

Preface: introducing the business architecture. 1

More on enterprise architecture in general 1

Preface: introducing the business architecture

You don’t have to document everything about a business that can be documented.

You document what you need to understand, then choose what to communicate - simplifying as need be.

However, imagine you were asked to analyse everything a business does in its regular operations.

And you begin by listing all the atomic activities that are regularly performed by the actors in the business.

(Where atomic means the shortest activities that you consider worth identifying and naming.)

The table below maps the definition of business architecture in TOGAF 9.2 to some core business architecture entities.

Then defines each business architecture entity in terms of how it groups a selection of business activities.

Business architecture as defined in TOGAF 9.2	Architecture entities	Definable in terms of activities thus
“Business operations	Roles and Processes	A role is the group of activities that one actor can be asked to perform; it may span several processes. A process is a sequence of activities that lead to a result of value; it may span several organisation units.
“factors that motivate the enterprise	Goals	A goal is a motivation for one or more activities
“how the enterprise is organizationally structured	Organization units	An organisation unit has a manager who is held accountable for the performance of a selection of activities.
“and what functional capabilities the enterprise has”	Business functions and Capabilities	A business function groups activities that are cohesive in some way(s) to be discussed below. A capability is the ability to perform a group of activities that are cohesive in some way(s) to be discussed below.

It is not enough to define each concept on its own and/or name an example.

One has to differentiate it from related concepts, and define its relationships to them.

So, this paper discusses how the concepts above relate to each other.

Note that each concept can be recursively composed and decomposed, which complicates how they relate to each other.

In BOST, relating business to IT

A business is, in reality, a complex network of actors and activities.

Architects and managers impose one or more hierarchical structures on that network to help them understand and/or manage it.

In EA, business architecture has long been centered on using a function hierarchy to impose a logical structure over an organization’s behavior or capabilities.

But note the terminology torture in these business architecture reference models:

· PCF for a commercial business - the function hierarchy is called a process hierarchy.

· BIAN for a bank- the function hierarchy is called a service landscape.

· ProAct for a retailer - the function hierarchy, from the top down, features capability area, service function and basic service function.

The approach used to create ProAct is generalised in the Business Transformation Framework (BOST) endorsed by CISCO and Informatica.

BOST is a relatively simple, traditional, EA framework that adds a “business view” over the top of the domains of enterprise architecture.

	BOST	Features
Business architecture	Business view	Enterprise market, products, relationships and resources
Business architecture	Operations view	Business functions/capabilities, information subjects and flows
IT architecture	Systems view	Application components and information exchanges
IT architecture	Technology view	Technology components and devices

BOST users describe the views using hierarchical structures.

They then map elements in one view to elements in another view (e.g. map applications to business functions).

The business operations architecture is based on a function hierarchy that provides “a structured definition of all essential operations capabilities.”

“Functions are:

· independent of organization [the management structure];

· independent of where work is performed [locations] or who [roles] performs it; and

· independent of how the work is performed [process flow sequences].”

Some draw several function hierarchies; the resulting set of trees is called a "function forest".

This may be done where different business managers are focused on different goals, have different value propositions.

But it is normal (as in BOST) to treat one function hierarchy as the primary structure for enterprise architecture purposes.

Note: there is some terminology torture here.

BOST uses function and capability interchangeably, it uses service where TOGAF says component or building block, and its systems are business applications.

In BizBOK

BiZBOK is a collection of guidance on business architecture. Its founders say:

“Business architecture serves as a bridge between strategy and execution.

• Framing and communicating impacts of strategic business objectives

• Aligning strategies and plans across business units

• Realizing business model aspirations

• Enabling strategic business transformation”

Other stated uses include:

• “Framing business requirements

• Scoping IT investments

• Defining target state IT architectures

• Integrating companies during a merger or acquisition.”

BizBOK defines business architecture as:

“holistic, multi-dimensional business views of capabilities, end-to-end value delivery, information, and organizational structure,

as well as the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”

Note that:

· capabilities = functions in other sources.

· end-to-end value delivery = the flow of business processes from suppliers to customers.

· information = data created and used by activities in the processes.

This table maps BizBOK’s terms and concepts to those in SFIA (above) and in TOGAF (below).

In BizBOK terms	In SFIA terms	In TOGAF terms
holistic, multi-dimensional business views of		cross-organisational, multi-dimensional views of
capabilities (see notes on hierarchies below)	current and required capabilities	business functions (see notes on hierarchies below)
end-to-end value delivery	processes	business scenarios and processes,
information	data, information	business data/information
organizational structure	people and organisations	organizational decomposition

BizBOK defines an enterprise “on a page" as a high-level business capability map that is independent of the organisation structure and process flows.

It suggests you layer heat maps on that map to show areas of concern or change.

You can map each key capability to the organisation units needed to realise that capability (in a capability/organisation matrix).

TOGAF defines an enterprise "on a page" as a high-level business function hierarchy that is independent of the organisation structure and process flows.

It suggests you layer heat maps on that hierarchy to show areas of concern or change.

And map each key function to the organisation units needed to realise that function (in a function/organisation matrix).

Descriptions of business capability modelling (like this one) read very like descriptions of functional decomposition.

The referenced description is good in many ways, but misleading on a few points made in the footnotes on hierarchical structures below.

In TOGAF 8 and 9

In the course of one cycle of TOGAF, architects define a target business architecture and plan how to get there.

The wider objectives are those of EA in general - to ensure (taking a cross-organisational view) that business processes and roles help a business meet its goals.

TOGAF recommends some business architecture effort before embarking on any change initiative.

It says that on starting an “architecture project”...

"... little or no Business Architecture work may have been done to date.

In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to

the key business objectives [goals] and processes that the architecture is to support.

This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A."

TOGAF version 9.2 describes business architecture as capturing architectural models of:

“business operations [processes], factors that motivate the enterprise [drivers],

how the enterprise is organizationally structured, and what functional capabilities the enterprise has.”

This table lists maps this definition to some core business architecture entities, and to other terminologies.

TOGAF 9.2’s definition of business architecture	Some core entities	In SFIA’s definition	In BizBOK’s definition
“Business operations	Processes	processes	end-to-end value delivery
“factors that motivate the enterprise”	Drivers and Goals	business strategy, goals and drivers	strategies
“how the enterprise is organizationally structured”	Organization units and Actors (physical active structures)	people and organisations	organizational structure
“what functional capabilities the enterprise has”	Business functions and Roles (logical active structures)	current and required capabilities	capabilities

TOGAF mostly presumes architects already know architecture definition techniques and artifacts

However, it does outline the ones listed below.

Business architecture approach in TOGAF 8 and 9

TOGAF 8 and 9 provided a process and products for business architecture, as listed in this table.

Business architecture process in TOGAF 8.1	Business architecture artifacts in TOGAF 9.1
1. Document the organization structure, relating locations to organizational units.	Organization Decomposition diagram Business Interaction matrix/diagram
2. Document business goals and objectives for each organizational unit.	Driver/Goal/Objective catalog
3. Define business functions... successive decomposition... into sub-functions.	Functional Decomposition diagram
4. Define business services each unit provides to its customers, internal and external.	Goal/Objective/Service diagram Business Service/Function catalog
5. Define business processes, including measures and deliverables.	Process Catalog, Flow diagrams
6. Define business roles, including skills requirements.	Role catalog
7. Define business data [information] model.	Conceptual Data diagram
8. Relate business functions to organizational units in the form of a matrix	Function/Organization ,atrix

Note: Business architecture is not limited to supply chain businesses.

TOGAF defines business functions in terms of the services they are required to provide.

The entry conditions to a service include any trigger or input; the exit conditions include any output or product produced.

It then defines the processes and roles needed to deliver a service.

And defines information created and used in business processes in a business/conceptual data model/diagram.

TOGAF assumes knowledge of the functional decomposition (cf. business capability mapping)

“Functional decomposition diagram [shows] on a page the capabilities of an organization.

By examining the capabilities of an organization, it is possible to quickly develop models of what the organization does

without being dragged into debate on how the organization does it.

... layer heat-maps on top of this diagram to show scope and decisions.

E.g. the capabilities to be implemented in different phases of a change program.”

Business architecture products - in BizBOK and TOGAF 9.2

TOGAF 9.1 authors treated business architecture techniques and artifacts as presumed knowledge.

TOGAF 9.2 was extended to include business architecture terms and artifacts from BizBOK.

So today, TOGAF has two vocabularies for comparable business architecture artifacts and more optional artifacts than anybody wants to use

Some business architecture definition activities	TOGAF artifacts in v9.1	BizBOK-style artifacts added in v9.2
Document the organization structure	Organization Decomposition diagram Business Interaction matrix diagram	Organization map
Document business goals and objectives	Driver/goal/objective catalog	Strategy
Define business services that meet the goals	Goal/Objective/Service diagram
Present a top-level view of activities needed to deliver services and goals	Value chain diagram	Business model canvas or diagram
Sequence activities in processes that deliver products/services of value	Business scenarios or process flows	Value stream map or diagram
Define the abilities or functions needed to complete activities And organise them in a hierarchical structure	Functions Functional decomposition diagram.	Capabilities Business capability map
Map business abilities or functions to the strategy or services	Business Service/Function catalog	Strategy/Capability matrix
Map activities in processes to functions, roles or capabilities	Business scenarios or process flows	Value stream map or diagram
Map business abilities or functions to organizational units	Function/Organisation matrix	Capability/Organization matrix

More on enterprise architecture in general

The dawn of the Information Age in the 1970s stimulated efforts to formalise business system planning.

Enterprise architecture (EA) emerged in the early 1980s out of thinking how to do this across an organization.

Practices (then and now) include drawing cross-organizational business architecture artifacts such as:

· a value chain diagram – which identifies top-level core and support functions of a business (after Porter, 1985)

· a functional decomposition diagram - that is independent of the enterprise’s organization structure

· a value stream diagram - which represents activities in the end to end flow of a business process (after Martin, 1995 if not before)

· a data entity/business function matrix – which shows which data is created and used by which functions (not by organization units).

The table below generalises business architecture entities that appear in EA frameworks (like TOGAF and NAF) and modelling languages (like ArchiMate and UML).

Business architecture entities	General definitions
Aims (why)	motivations for behavior
Goal or Objective	A target to be achieved, a motivation or reason to perform behaviors.
Behaviors (how and when)	things that happen over time and change the state of a system or its environment
Service	A behavior performable by a business component that produces a result of value to its consumer. An external view, a logical contract, that encapsulates whatever process(es) are need to deliver the desired result.
Process	A sequence of activities performed by the actors in a business in the course of delivering a business service. A process may occur within one organization or function, or coordinate activities in several organizations or functions.
Logical structures	groups of behaviors that are assignable to active structures
Function	A logical business component. A node in a business structure that represents both a subdivision and a group of its logical activities and capabilities. It is describable externally by services provided and internally by activities assignable to organization units.
Role	A business function performable by one or more actors with the requisite capabilities. It is describable externally by services provided and internally by activities assignable to an actor.
Active structures (who)	things that perform behaviors
Organization unit	A real business component, capable of realising one or more logical functions. A node in a management structure that subdivides and groups its physical actors, and perhaps resources also. Note: in the special case of a “functional organization”, each organization unit realises one business function.
Actor	An entity capable of realising one or more roles; typically assigned to a bottom-level organization unit.
Passive structures (what)	things that are acted on
Physical entity	A concrete entity type that a business creates and/or uses in the course of performing behaviors.
Data entity	A record type that describes the attributes of an entity or event, created and used in the course of performing behaviors.
Location (where)	A place where actors, components or entities are found and work is done.

More on hierarchical decomposition

Motivational decomposition

A business strategy usually includes top-level business aims; some relating to business as usual; others to changing business systems.

Typically, top-level aims are decomposed into sub aims, and so on.

Some teach a fixed aim decomposition structure: say: Goals < Objectives < Purposes, but this is artificial, since the concept is essentially the same.

Some speak of decomposing aims from “what” to “how”, but the distinction is subjective, since one person’s what is another’s how.

Structural decomposition

Moving up a structural hierarchy, the components get larger; moving down, they get smaller.

Big components are decomposed into smaller components, and so on.

Human actors are composed into a hierarchy of organization units, which are also called actors in ArchiMate.

(Software classes are composed into modules, packages, deployable assemblies, applications and system families.)

Behavioral decomposition

Moving up a behavioral hierarchy, the behaviors get longer; moving down, they get shorter.

Long “end-to-end” business processes are decomposed into shorter sub processes, and so on.

Every process, at every level of decomposition, has an aim - at that level of decomposition.

It ends by producing a measurable result of value to a consumer of that result - at that level.

Some teach a fixed process decomposition structure: e.g. Value streams < Processes < Procedures < Activities.

The processes at each level are named differently, and may be represented using different kinds of artifact.

This places artificial constraints on a general concept, and doesn’t always fit reality well.

Even the topmost end-to-end process (say package delivery) might readily be represented in a process flow chart.

Level of decomposition

There is inevitably a "threshold for decomposition".

From the top down, you start by dividing the structure into what appear to be distinct and different functions/capabilities

But eventually reach a level where the same activity or ability is needed in two or more legs of the hierarchy.

You might then do one of three things:

· Duplicate the activity or ability under several nodes - in what is called a redundant hierarchy

· Arbitrarily assign the activity or ability under only one node of the hierarchy

· Assign the activity or ability to an extra leg of the hierarchy called "generic/support functions/capabilities".

The common rule of thumb to stop decomposition at a 3rd or 4th level may prevent you reaching this threshold of decomposition.

Still, it is useful to understand the following cross validation rule.

Every activity in your process flow models should be placeable under at least one bottommost node of your function hierarchy

Even if you never attempt to decompose the hierarchy that far.

Classically, business functions are named using nouns. E.g. Sales, Marking, Delivery, Finance.

Some name the bottommost “elementary business functions” as imperatives. E.g. Identify prospect, Contact prospect, Complete sale.

And then sequence these atomic activities in processes (aka scenarios or value streams).

Keeping a meta model generic

In a specific business system, architectural entities are sometimes in 1-to-1 correspondence.

E.g. 1 Sales organization unit may realise 1 Sales business function and meet 1 Sales goal.

Generally however, architectural entities are associated by many-to-many relationships.

E.g. Several organization units may realise one Sales business function (wholly or partly).

One Sales organization unit may realise several business functions (wholly or partly).

And one Sales organization or function may have several goals: e.g. for turnover, profit and customer satisfaction.

More on corresponding and clashing hierarchies

When the same hierarchy is imposed over different actors, activities or data elements, the structures are said to correspond (the nodes are in 1-to-1 correspondence).

When different hierarchies are imposed over the same or related actors, activities or data elements, the structures are said to clash.

The science of corresponding and clashing hierarchies can be traced back through Michal A Jackson (1975) to earlier sources.

In applications architecture, any two data structures read and written by an application must either correspond or clash.

When they correspond, the structures can be merged into one program structure.

When they clash (Jackson showed) the program is better divided into application components that each process a different data structure.

Business architecture also features corresponding and clashing hierarchies.

Multiple hierarchies

Managers usually impose a hierarchical management or reporting line structure over the employees of a business – an organisation decomposition.

Architects often impose other, more logical, hierarchies on the actors, activities and resources of a business.

Here are four common hierarchical structures.

Motivations: goal/objective decomposition - as in a strategy map, or a balanced score card.

Behaviors: process decomposition – dividing longer processes or value streams into shorter processes.

Physical active structure: organization decomposition – dividing people and resources for management purposes.

Logical active structure: functional decomposition – dividing larger/wider functions or capabilities smaller/narrower functions or capabilities.

Corresponding structures

Managers may choose to base the organization structure on a functional decomposition.

In such a “functional organization”, every unit in the organisation realises a function in the functional decomposition.

Architects may choose to align a functional decomposition with a goal/objective decomposition

Suppose managers define a top-down business goal/objective hierarchy.

Architects can build a function hierarchy from the bottom up, by successively clustering bottom and lower level activities/functions under higher level nodes.

Provided the clustering criterion is a business goal/objective, then this second structure will necessarily correspond to the goal/objective hierarchy.

Although the concepts of capability and function differ, they are naturally organised under hierarchies that correspond to each other.

Why? Because to realise each unique function, you need a unique capability.

The two hierarchies will clash only if you insist on using different cohesion criteria to cluster lower level nodes under a higher level node.

Wherever two hierarchies correspond, you may merge and maintain them in one structure, though this is a hostage to fortune.

Clashing structures

Given two structures are currently in correspondence, one may change without the other.

E.g. an organization’s management structure may be restructured by location, customer type, product type or resource type.

This may be done without significantly changing what the business does, as shown in a functional decomposition.

And that is the major reason for basing business architecture documentation on the latter rather than the former.

Moreover, business architects may impose different, logical hierarchies over the network of business actors and activities

One enterprise architect drew 9 different functional decomposition hierarchies to match the interests of 9 different business directors.

Reuse of elements in different legs of a hierarchy?

Process, function and capability hierarchies abstract from the bottom up by composition or aggregation.

You may find some common or shared elements at the bottom, which may be reused by delegation.

If you decompose a business capability or function hierarchy far enough, you will reach some capabilities or functions that are shared or generic.

But if you follow the convention to decompose to only a 3^rd or 4^th level, you are unlikely to find those common elements.

(By contrast, class hierarchies abstract from the bottom up by generalisation.

You will find common or shared elements at the top, which may be reused by inheritance.)

More on functions and capabilities in TOGAF

Although the concepts of capability and function differ, they are readily organised under hierarchies that correspond 1-to-1.

A functional decomposition diagram naturally corresponds to business capability map, because to realise each unique function, you need a unique capability.

The two hierarchies will clash only if you insist on using different cohesion criteria to build them.

If you decompose a business capability or function hierarchy far enough, you will reach a level where some capabilities or functions are shared or generic.

But if you follow the convention to decompose to only a 3^rd or 4^th level, you are unlikely to find those common elements.

The TOGAF series guide to “business capability” uses the term more specifically than “capability” above.

The concern here is not so much what the guide says about business capabilities.

It is more how to distinguish business capabilities from functions since:

Capabilities in TOGAF

There is confusion in discussions of capability.

TOGAF first defines a capability in abstract terms,

Then describes capability-based planning in terms of concrete systems to be delivered.

An abstract capability (cf. logical business function)

This is defined independent of people, processes, data and technologies.

It corresponds to a logical business function in a functional decomposition hierarchy.

A cycle of TOGAF’s ADM might deliver one new capability/function, but that is rare.

A business capability refers to the ability that a business has to achieve a specific business outcome.

The name of a capability identifies some aims and/or activities a business must perform.

It identifies what a business does to create value for its customers and stakeholders

It does not describe how to achieve it, makes no reference to people, processes, data and technologies.

It abstracts a structural description of a business from its dynamic processes.

Exactly as a functional decomposition abstracts a structural description of a business from its processes.

A business capability does not encapsulate people, process, data or technology.

A person may act in two capabilities, a process may span capabilities, and any data or technology may support or enable two capabilities.

A concrete capability (physical system to be architected and delivered)

This is defined in terms of people, processes, data and technologies.

It is a physical business system to be constructed and delivered.

A cycle of TOGAF’s ADM is expected to deliver such a system, to support or enable one or more abstract capabilities.

In TOGAF capability-based planning is an approach to the planning, engineering, and delivery of capabilities to the enterprise.

OK, but TOGAF is already an approach to the planning, architecting and delivery of business systems to the enterprise.

A request for architecture work is rarely to deliver an abstract capability/function in a top-level map/diagram.

Usually it is to deliver is a change to part(s) of one or more capability/function(s).

It delivers concrete systems, composed of people, processes, data and technologies.

One system may support or enable part of one logical function/capability, or parts of several of them.

Functions in TOGAF

Mostly, TOGAF equates functions to business capabilities.

“The term ‘‘function’’ is used to describe a unit of business capability.”

The term does appear in the standard with other meanings (e.g. process, goal and organization unit).

However, the most definitive references to function clearly:

a) align business functions with capabilities

b) distinguish business functions from organization units.

In its artifact definitions, TOGAF treats functions as capabilities.

“The purpose of the Functional Decomposition diagram is to show on a single page the capabilities of an organization that are relevant to the consideration of an architecture.

By examining the capabilities of an organization from a functional perspective, it is possible to quickly develop models of what the organization does without being dragged into extended debate on how the organization does it.

Once a basic Functional Decomposition diagram has been developed, it becomes possible to layer heat-maps on top of this diagram to show scope and decisions.

For example, the capabilities to be implemented in different phases of a change program.”

In discussion of business architecture, TOGAF suggests mapping functions to organization units.

“Structured Analysis: Identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business.”

And suggests using a matrix because the mapping is many to many.

“relate business functions to organizational units in the form of a matrix report.”

In discussion of information system architecture, TOGAF indicates that higher the function, the wider and more likely cross-organizational it is.

“high-level business functions, such as electronic commerce, supply chain management, etc.”

The existence of these two artifacts tells us organization units and functions are different.

“Application/Organization matrix” and “Application/Function matrix”.

In discussion of its meta model, TOGAF distinguishes organization units from functions.

“Business Architecture artifacts capture architectural models of

· business operation, looking specifically at

· factors that motivate the enterprise,

· how the enterprise is organizationally structured, and also

· what functional capabilities the enterprise has.”

Conclusions wrt business capability maps and value stream diagrams

In discussion of EA, TOGAF distinguishes:

· planning from day-to-day management

· business system planning from wider business planning

· strategic enterprise architecture from more tactical solution/capability architecture

· general concepts (in the meta model chapter) from specific artifact types (in the artifacts chapter).

The TOGAF standard is generic and flexible.

Its diagram artifacts are defined in a logical way that leaves their physical format to the user.

The TOGAF series guides to business capability maps and value stream diagram artifacts are somewhat more specific.

Function is a general concept.

Enterprise architects usually map out what the business does using only one function hierarchy.

But a functional decomposition diagram divides the aims or behavior of an enterprise using whatever criteria you choose.

So many such diagrams (a function forest) could be drawn.

And any logical subdivision of an enterprise’s aims or behavior might be called a function.

By contrast, the TOGAF series guide suggests particular criteria for defining a business capability.

So a business capability map divides the aims or behavior of an enterprise using that guidance.

Nevertheless, inevitably, it will correspond to one of the countless functional decomposition diagrams that could be drawn.

Process is a general concept.

A process is a sequence of activities that leads to a result of value to one or more consumers of that result.

There is no constraint on the length of the process, or who the consumer is.

A value stream diagram is a specific kind of artifact.

It is used to represent what may be called an end-to-end process (say package delivery) in a particular way.

It does not usually show control logic or exception paths in the process.

But even the topmost end-to-end process might (instead or as well) be represented in a process flow chart.

The idea that a value stream differs from a process is misleading.

“a value stream is a process in the sense that it is an end-to-end collection of activities that lead to a result of value to the consumer of that result.

However, value streams are representations that do not sequence all the activities under control logic.” Wikipedia July 1018

Note also:

“Some methodologies reference value streams as delivering value to an internal stakeholder.

While this can hold true within a specified context, the goal of most practitioners is to focus on stakeholders outside of an organization.” Wikipedia July 1018

The principle that the consumer of a value stream’s result is what people call a “customer” is debatable.

It may be read to imply the scope of a business system is fixed at the level of a legal entity.

But generally, the internal/external boundary of a business system is determined in scoping the work to be done.

The “customers” of a smaller business system are “actors” inside a larger business system.

So, as James Martin said in 1995: the “customer” of a value stream might be the ultimate customer or an internal “end user” of the value stream.

Impact on TOGAF terms, definitions and meta model

A generic meta model for TOGAF

TOGAF adds some entities to the traditional EA entities mentioned above.

First, because it abstracts logical (supplier/resource independent) component specifications from physical ones.

Second, because it is “service-oriented”; it defines architecture requirements in terms of services to be peformed by components.

Common EA entity types	TOGAFs physical components	logical components	services
Organization Unit	Organization Unit	Function	Business service
Application	Physical Application Component	Logical Application Component	Application/IS Service
Platform Technology	Physical Technology Component	Logical Technology Component	Technology Service

Currently, the TOGAF definitions, meta model and artifacts do not add up to a coherent whole.

But they can do, and the road to achieve it is clear if it is recognised that TOGAF generally:

· distinguishes required behaviors (services) from active structures (systems and components thereof)

· encapsulates the internal structures and behaviors of a system or component behind the external services it can be required to perform

· abstracts logical active structures (e.g. functions and roles) from physical active structures (e.g. organization units and actors)

ArchiMate’s generic meta model

A generic EA meta model abstracts from more specific meta models.

E.g. ArchiMate features a generic relation that may be expressed this way.

· Services <are accessed via> Interfaces <enable access to> Internal active structure elements

This table shows how the service and internal active structure elements abstract from entities in three architecture domain/layer meta models

Generic meta model entities	Architecture domain/layer	Meta model entities
Service	Business	Business Service
	Application	Application Service
	Technology	Technology Service
Internal active structure	Business	Role, Actor
	Application	Application Component
	Technology	Node, System Software, Device

ArchiMate’s generic meta model is not meant to be a database or repository schema.

Rather, it standardises terms and concepts in a way that makes the standard more coherent and consistent.

TOGAF’s generic meta model

It is easy to abstract a similar-but-different generic meta model from TOGAF’s meta model.

TOGAF features a generic relation that may be expressed this way.

· Services <are assigned to> Logical components <are realized by> Physical components.

This table shows how the service and component super types abstract from more specific entities in TOGAF.

Generic meta model entities			Meta model entities
Service A unit of behavior performable by a system or component thereof, defined as a service requester or consumer sees it, without regard to how the service is performed.			Business Service
			Application/IS Service
			Technology Service
Component A subsystem that can be defined by the service portfolio it provides; a node in a structural view of system behavior.	Business Component	Logical	Function / Business Capability, Role
	Business Component	Physical	Organization Unit, Actor
	Application Component	Logical	Logical Application Component,
	Application Component	Physical	Physical Application Component
	Technology Component	Logical	Logical Technology Component,
	Technology Component	Physical	Physical Technology Component

Again, the idea here is to standardise terms and concepts in a way that makes the standard more coherent and consistent.

Of course, people do use terms like service and component in ways contrary to their meanings above.

The term service is often used to mean an interface, or a component, or a product (rather than a unit of work as seen by an external entity).

And of course, architects should use whatever words work for their stakeholders in communication with them.

But if authors of different TOGAF chapters and guides use core terms like service and component with different meanings, it will be difficult to make sense of the standard.

Every profession has its own domain-specific language, and it is surely better to give these core terms coherent and consistent meanings.

This table shows how the simple generic meta model is specialised in three architecture domains/layers.

Generic meta model	Services	<are assigned to>	Logical components	<are realized by>	Physical components
Business	Business Services	<are assigned to>	Business Functions Roles	<are realized by> <are realized by>	Organization Units Actors
Information Systems	Application/IS Services	<are assigned to>	Logical Application Components	<are realized by>	Physical Application Components
Technology	Platform Services	<are assigned to>	Logical Technology Components	<are realized by>	Physical Technology Components

This table (in my experience) does help people to make sense of TOGAF.

Looking at TOGAF this way helps people to make sense of the meta model and artifacts chapters in a way that is otherwise more difficult.

Keeping a meta model simple

An indirect relation involves three or more entities (as above)

The two entities at either end of the relation may be associated directly: e.g. Business Services <are performed by> Organisation Units

To keep models simple, meta modellers typically omit the direct relationship

Also, they eschew 1-to-1 relations.

They typically compress a 1-to-1 relation (say 1 Business Entity <is recorded by> 1 Data Entity) to a single entity with two aspects.

A few impacts on TOGAF’s definitions and meta model

Discussion of this paper has raised several questions.

Is the business architecture section of the meta model supposed to be a generic or universal business data model?

Enterprise architecture approaches typically involve drawing a business data model.

There are many generic data models for modelling a business, which feature concepts such as:

· Party (Person or Organization), Contract, Product type, Product instance, Activity type, Activity instance, Location (Area or Address).

The business architecture section of an EA meta model is a somewhat different animal.

Why? Let me duck that one.

Is the meta model supposed to include artifact names?

The meta model should feature general concepts.

It should feature process (general concept) rather than value stream (an artifact type used to represent some processes).

It should feature function (general concept) rather than business capability (which is, in practice, used as a specific subtype of function).

Or else, the meaning of business capability should be generalised so it can replace function throughout.

What is the meta model for?

Do people record all meta model entities in an EA repository?

In practice, people find it easier to identify and model structures than behaviors.

In designing a target system, one should start from the requirements for it.

And TOGAF’s template for Architecture Requirements Specification does include business and application/IS services.

But in documenting baseline systems, identifying services requires much more effort than identifying components.

So, I teach the TOGAF meta model as a domain-specific language for EA.

Architects must decide for themselves what they can and will maintain in an EA repository.

What is the impact on definitions in TOGAF version 9.2?

E.g. To deliver something is to hand it over to a receiver.

You may use a capability to deliver results, outputs, products or changes to an object..

But you don't deliver a capability, any more than you deliver an activity, work or task performed.

TOGAF defines business function (definitions chapter) and function (meta model chapter) the same way.

“Business Function: Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.”

“Function: Delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization.”

Both definitions are questionable because:

· you do not deliver capabilities

· a business function is not generally closely aligned to an organization unit.

· the word governed would better be replaced by managed.

Function is performed by Actor?

A Role can be seen as a low level Function performable by one or more Actors

But it is clearer to distinguish higher and lower levels of business architecture composition in which:

· Functions <are realized by> Organization Units (phase B says to use a matrix to document this N-to-N relationship).

· Roles <are realized by> Actors (no point in distinguishing actors from roles unless this relationship holds true).

Remember, generally, relations should be expressed as Subjects <verb phrase> Objects.

Sometimes a constraint can be identified that limits the number of Subjects or Objects in the relation.

But in most cases, the association is many-to-many; some examples follow.

Function delivers Business Capability?

Better to say Functions <need> Business Capabilities.

If a capability is an ability, you don’t hand it over, you use or employ it to deliver something (result, output, product or change to an object).

If (as some imply) a capability is a resource, you don’t hand over the resource, you use or employ it to deliver something.

(Strictly, actors, in realizing roles, deliver things; roles don’t deliver anything.

And organization units, in realizing functionsm deliver things; functions don’t deliver anything.

But OK, we do speak as though logical roles and functions deliver things, and they needs one or more capabilities to do that.)

Note: it is always true that 1 Function <needs> 1 Business Capability.

True, one Function <needs> one or more Capabilities.

And conversely, one Capability <is needed to realise> one or more Functions.

Because both Functions and Capabilities are composable and decomposable.

Each can be as coarse-grained or fine-grained as the aim (goal, objective, or purpose) it is related to

But at any level of decomposition, 1 Function needs the 1 Capability that is uniquely appropriate to that Function.

This explains why a business capability map looks like a functional decomposition diagram.

Function is bounded by Business Service?

Better to say Functions <are bounded by> Business Services.

Certainly, one Function <is bounded by> one or more Business Services (the service portfolio of the Function).

And ideally, the relation is one to many, since one Business Service <is assigned to> one and only one Function.

However, since there can be delegation from one Function to another, one Business Service <may be realized by> several Business Functions.

Function is owned by Organizational Unit?

Better to say Organization Units <are responsible for> Functions.

Or rather, are responsible for performing one or more of the Services assigned to one or more Functions.

Should TOGAF’s generalizations be made more explicit?

Yes! This would help to standardise core terms and concepts, and so make the standard more coherent and consistent.

To begin, these two generic architecture entities:

· Service: a unit of behavior performable by a system or component thereof, defined as a service requester or consumer sees it, without regard to how the service is performed.

· Component: a subsystem that can be defined by the service portfolio it provides; a node in a structural view of a system’s behavior.

are related in this generic meta model.

· Services <are assigned to> Logical components <are realized by> Physical components.

The generic model can be generalised little further and expressed in a more academic way:

· Required behaviors <are assigned to> Logical active structures <are realized by> Physical active structures.

Other generalizations can help to make TOGAF more coherent and consistent.

The table below further generalises terms and concepts commonly used in business architecture definition.

It also positions business capability maps and value stream diagrams in a wider conceptual framework for describing business systems.

	Generalizations	View	Terms and concepts commonly used in business architecture definition
Active Structure	Business component: A logical or physical division of a business; a node in a structural view of business operations. Core divisions focus on developing, marketing, selling and delivering business-specific products and services. Support divisions such as personnel or facilities management, being similar in different businesses, are candidates to be out-sourced.	Logical	Business function: A logical business component. A node in a business structure that represents both a subdivision and a group of its logical activities and capabilities. It is describable externally by services provided and internally by activities assignable to organization units. Business capability: The ability to realise a business function that meets specific criteria (see the series guide). Role: A business function performable by one or more actors with the requisite capabilities. It is describable externally by services provided and internally by activities assignable to an actor.
		Physical	Organization unit: A real business component, capable of realising one or more logical functions. A node in a management structure that subdivides and groups its physical actors, and perhaps resources also. Note: in the special case of a “functional organization”, each organization unit realises one business function. Actor: An entity capable of realising one or more roles; typically assigned to a bottom-level organization unit.
	Business structure decomposition: A technique that successively divides an enterprise into smaller divisions. Architects use this basis for business analysis, heat mapping and classification of other architectural entities.	Logical	Functional decomposition: A logical decomposition of functions, typically stopping at a 3^rd or 4^th level. Business capability map: A functional decomposition-like diagram in which nodes are defined according to specific criteria (see the series guide).
		Physical	Organization decomposition: A structure of organization units and/or reporting lines between managers It may associate roles or actors to organization units. Note: in the special case of a “functional organization”, this corresponds to the functional decomposition.
	Atomic business component: An elementary business component, not further subdivided.	Logical	Atomic business function: A node at the bottom of a logical functional decomposition, or a role realisable by an actor.
		Physical	Actor: An entity capable of realising one or more roles; typically assigned to a bottom-level organization unit.
	Physical to logical mapping: An artifact showing which physical entities realise which logical entities.		Organization/Business function matrix: An artifact that maps organization units to business functions. It may be drawn at whatever level of granularity suits its purpose. Actor/Role matrix: An artifact that maps actors to roles
Behavior	Business behavior: A repeatable activity that (if successful) ends with a result (output/product or change) of value to the requester or consumer of the result.	External	Business service: A behavior performable by a business component that produces a result of value to its consumer. An external view, a logical contract, that encapsulates whatever process(es) are need to deliver the desired result.
		Internal	Business process: A sequence of activities performed by the actors in a business in the course of delivering a business service. A process may occur within one organization or function, or coordinate activities in several organizations or functions.
	Business behavior decomposition: A technique that successively divides longer behaviors into shorter ones. Architects use this both to capture requirements and design business operations.	External	Service decomposition: Showing one service as dependent on subordinate services (which implies component decomposition).
		Internal	Process decomposition: Showing one step/activity in a longer process as a lower-level process of several activities.
	Atomic business behavior: An elementary behavior, not further subdivided.	External	Atomic business service: A service that is wholly performed by an atomic business component.
		Internal	Atomic activity: A process step or activity at the bottom of business process decomposition. (See aside in the paper above.)
			OPOPOT: The one person, one place, one time principle or rule of thumb for where business process decomposition stops.
	Verification technique: A technique to ensure a system description is comprehensive and consistent.		Structured analysis verification: A technique to ensure a business architecture description is comprehensive and consistent. The principle that every atomic activity in a business process can be placed under an atomic business function. In practice, structural decomposition usually stops well short of atomic activities, but some cross-validation can still be useful.
	Process artifact: A way of representing a process, usually in a diagram. Typically, architects focus on what is called the main, straight-thru, happy or sunny day path. It is said however that 80% of the complexity lies in the 20% of exception paths		Value chain diagram: An artifact that presents top-level business functions in a sequence. Typically in the arrow shape drawn by Michael Porter in "Competitive Advantage" 1985.
			Value stream diagram: An artifact representing “an end-to-end collection of activities that create a result for a ‘customer’” Martin (1995). It focuses on the entry/exit conditions and major stages of a process, without detailing control logic governing activities.
			Business scenario diagram: An artifact that shows how a business goal/objective can be met by a process or value stream. It also shows roles played by human and computer actors in each process step. It is an effective way to identify and clarify architecture requirements.
			Process flow diagram: An artifact that shows the control logic of a process, and may include exception paths. It may relate roles to process steps by lines, positioning or swim lanes.
Passive structure			Object: A material structure or data structure that is made, moved or modified; it may be maintained or under development.
	Product: One or more results of a behavior, which can include output objects and changes to objects.		Output: An object sent from a producer to a requester/consumer.
			Change: A change in the quality/value of an object that is maintained or under development (which includes any “added value”).
			Location: A place where actors, components or objects are found and work is done.

Aside: this conceptual framework reflects the general system theory applicable to all discrete event-driven activity systems.