Functions and capabilities in business architecture and TOGAF®

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

https://bit.ly/2Kpa80F

Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated Tuesday, 16 October 2018

 

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.

 

This paper discusses the meaning of function and capability, process and value stream, service and component in business architecture generally, and TOGAF in particular.

It explains things about enterprise and business architecture that many seem unaware of.

It explores the function / capability confusion.

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

The paper evolved out of an older one on Mapping TOGAF to the Nato Architecture Framework (NAF).

Contents

Key points. 1

Part 1: things about business architecture many seem unaware of. 3

Part 2: Functions and capabilities in EA (in general) 7

Part 3: Functions and capabilities in TOGAF. 9

Conclusions wrt business capability maps and value stream diagrams. 11

Part 4: impact on TOGAF terms, definitions and meta model 12

 

Key points

The grid below is a generic metamodel of system elements, adapted from the ArchiMate standard v3.

It distinguishes behaviors (which change the state of a system over time) from structures which play a role in a system.

And distinguishes external descriptions of a system from its internal workings.

 

 

Behaviours

Structures

External view

Service: an exposed behaviour, explicitly defined in a service contract.

Interface: a list of services accessible at the same place.

Internal view

Process: a sequence of activities performed by one or more components.

Component:  an entity capable of performing behaviour.

 

What this grid does not do is distinguish logical components from physical components.

TOGAF draws this distinction most clearly with respect to components in the application and technology architecture domains.

The same distinction is discussed below with respect to components in the business architecture domain.

 

Relating capabilities to functions

Business architects used to be taught model a business using “structured analysis” and “functional decomposition” techniques.

We were taught to define a logical business structure in the form of a business function hierarchy.

Each function is a logical business component that (using some cohesion criterion) groups some required activities.

 

In a “functional organisation”, each organisation unit realises one function.

Where that is the case (the relation is 1 to 1) we don't need to model both concepts separately.

Where the relation is N to N, we model logical functions and physical organisation units separately.

The map functions to organisation units, as in a function/organisation matrix.

 

Today, people draw business capability maps that look exactly like functional decomposition hierarchies.

Every business capability in the former can seen as the ability to realise a business function in the latter.

If both are named using nouns (e.g. Sales, Marketing, Delivery, etc.) then the capability hierarchy must look identical to the function hierarchy.

The structures look the same, and are used the same way, for the same purposes.

 

Relating logical components to physical components

Traditionally, business functions can be seen as logical (abstract) business components.

And organisation units are seen as physical (real world, managed) business components.

 

Today, discussions of capability-based planning are inconsistent as to whether capabilities are logical or physical.

Some define a capability as a concept that is defined logically, without reference to people, processes and technologies.

Others define a capability as composed of the physical assets and resources (people, processes and technologies) needed to realise a business function.

And some (as in an Open Group guide) define a capability both ways.

 

If the logical capability to physical capability relation is 1 to 1, then we don't need to model both concepts separately.

Presumably, if the relation is N to N, then we do need model map logical capabilities and physical capabilities separately. 

So far, I have seen no recognition of this, or explanation of mapping one to the other.

 

Service-orientation

Services are seen (in TOGAF for example) as requirements, since they are what customers require of a business system.

Services are discretely requestable operations, or units of behavior.

 

Unfortunately, methodologies often confuse dynamics with statics, behaviors with structures.

ArchiMate classifies functions (here called logical structure elements) as behaviors.

BIAN has its own vocabulary in which business function = service domain = capability.

And business service = business service operation.

 

As a result, people confuse behaviors with logical structures.

People confuse services (business service operations in BIAN) with components (service domains in BIAN).

 

Level of decomposition

A function or capability hierarchy may be built from the bottom up or the top down.

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).

Part 1: things about business architecture many seem unaware of

The origins of business architecture

Business planning addresses changes that have been envisioned to one or more of an enterprises’

·         constitution: mergers, acquisitions and divestments

·         market: industry domain/sector/segment, customers and suppliers

·         products: products and services, sales and service channels

·         relationships: partners, in-sourcing and out-sourcing of operations

·         resources: people, machines, locations/buildings and other physical asset types.

 

Business system planning addresses the structures and behaviors of regular business operations.

A business system is composed of some actors interacting to perform some repeatable activities to meet some given aims.

Business system planning is given direction by business planning, and also informs it.

 

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 business architecture practices above stand independent of information technology (IT).

The TOGAF standard was created in the middle of the 1990s as an IT Architecture framework only.

Years passed before TOGAF was widened into an EA framework for business system planning.

At this time (version 8, 2003) TOGAF inherited from 20 years of business architecture practices.

It treated cross-organizational business architecture techniques and artifacts as common knowledge.

This table shows traditional system description concepts that appear in the TOGAF standard at versions 8 and 9.

 

General viewpoint

Business architecture entity

Definable in terms of business activities as

Motivations

Goal (cf. objective, purpose)

An aim for activities

Behaviors

Process (cf. scenario, value stream)

A sequence of activities (from trigger to result)

Logical active structures

Business function and Role

A cohesive grouping of required activities

Physical active structures

Organization unit and Actor

An entity deployable to perform activities

 

TOGAF 9.2 has expanded the concept of business architecture beyond EA to embrace artifacts useful in wider business planning.

So today, EA and BA might be seen as overlapping sets.

Still however, the business architecture artifacts in TOGAF 9.2 are primarily used in business system planning.

Enterprise architecture concepts in general

For a broad introduction to systems thinking, you can read https://bit.ly/2w5XKNK

Here, a business system is composed of some actors interacting to perform some repeatable activities to meet some given aims.

EA is much concerned with how actors, playing roles in regular business processes, interact.

Actors interact by using messages and memory stores to exchange business data (to convey descriptions, directions, decisions and opinions).

This table lists some business architecture concepts that appear in two comparable frameworks.

 

Domain

An IBM view of business systems

CSC’s domains of change (POLDAT)

Business

Problem

 

Process

Process

Organization

Organization

 

Location

Business Entity

 

Data Entity

 

Information

System

Data Store

Data

Application

Application

Technology

 

Technology

 

A model is a representation of something that enables some questions about that thing to be answered.

Consider for example a matrix showing which Organization units perform which Processes.

 

A meta model models a model; it identifes the entity types contained in the model and how they are related.

A meta model is expressible in terms of relations of the kind Subjects <verb phrase> Objects.

For example: EA frameworks typically presume:

·         Actors <play> Roles <in> Organization units <to perform> Processes <that create and use> Data <in the course of meeting> Goals.

 

Are all the relationships above important to you? Perhaps not. Are other relationships important? Perhaps yes.

There is not one universal “right” meta model of business architecture concepts.

Business architecture concepts in TOGAF version 9.2

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

business operations, factors that motivate the enterprise, how the enterprise is organizationally structured, and what functional capabilities the enterprise has.”

 

The table below maps the definition above to core entities in TOGAF’s meta model.

 

Business architecture as defined in TOGAF 9.2

Typical business architecture entities

“Business operations

Processes

“factors that motivate the enterprise”

Drivers and Goals

“how the enterprise is organizationally structured”

Organization units and Actors

“what functional capabilities the enterprise has”

Business functions and Roles

 

TOGAF adds functions (think, abstract organization units) and services (think, abstract processes).

The table below outlines the business architecture approach and artifacts in versions 8 and 9.

 

Business architecture approach in TOGAF 8

Some relevant artifacts in TOGAF 9

1 Define organization structure and locations

Organization Decomposition Diagram

2 Document business goals and objectives for each organization unit

Driver/Goal/Objective Catalog

3 Identify business functions

Functional Decomposition Diagram

4 Define the services each enterprise unit performs, internally and externally

Goal/Objective/Service Diagram

Business Service/Function Catalog

Business Interaction Matrix/Diagram

5 Define business processes, inc. measures and deliverables

Process Catalog, and Flow Diagram

6 Define business roles, inc. skills requirements.

Role Catalog

7 Define business data model

Conceptual Data Diagram

8 Relate business functions to organization units

Function/Organization Matrix

 

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.

 

Note: there is nothing about IT here.

TOGAF 9.2 includes other concepts, notably business capability and value stream.

These are discussed in later – after some discussion of hierarchical structures

Hierarchical composition and decomposition

The scope of a system is a choice made by a system describer.

Systems and system elements (aims, activities and actors) may be recursively composed and/or decomposed.

 

There is no constraint on the size of a system or the length of a process.

The boundary of a system is a decision made by a system describer.

The start and end points of a process are decisions made by a process modeller.

You can describe a large system or a long process at high level of composition only.

Or you can decompose it into subsystems and sub processes, recursively.

 

Hierarchical composition and decomposition

A hierarchy is a tree-like structure in which the top-most node is successively subdivided.

Every node (except the topmost and bottommost) has one higher node and several lower nodes.

In a strict hierarchy, each node appears only once; in a redundant hierarchy, one node may appear in several branches.

 

Given many things to manage, people impose hierarchical structures over them.

You can build a hierarchy from the bottom up by successively composing several nodes under one higher node.

You can build a hierarchy from the top down by successively decomposing one node into several nodes.

 

Structures clash when one set of things is composed, using different criteria, under different hierarchies.

Structures correspond when different sets of things are composed under the same hierarchy.

 

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.

 

Atomic actors and activities

At the base of a business system model are atomic actors and atomic activities.

An atomic activity is performable by an actor (human, computer or machine) without further explanation.

In UML, it is called the “action”; in structured analysis, it called the “elementary process”.

Architectural models/views often stop well short of atomic actors and activities.

But if you decompose different views far enough, you should find the same ones.

 

Business architecture entities may be defined from various perspectives.

One way is to describe how the entity relates to a group of business activities.

This table illustrates how different entities group activities using different criteria.

 

This architecture entity

typically groups sales activities that are cohesive in that they

A sales process

connect sequentially, leading to a result of value to its consumer, a sale.

A sales business function

contribute to a shared sales goal, such as completing 1,000 sales per month.

A sales role

can be performed by employees who share sales-related knowledge and skills.

A sales organization unit

can be performed by a manageable set of sales-related resources.

A sales application

create and use a cohesive set of sales data, relating customers to products.

 

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.

Part 2: Functions and capabilities in EA (in general)

The table below lists four business architecture entities that may be recursively decomposed into entities of the same type.

 

Architectural entity

Decomposition structure

Aim

Goal/Objective cascade - as in a strategy map or balanced score card

Organization init

Organization decomposition - as in an ordinary management structure

Process

Process decomposition - into shorter processes

Business function

Functional decomposition - into smaller/narrower functions

 

The last is the main interest here.

Functional decomposition in general

Functional decomposition imposes a logical structure over an organization’s behavior - its activities.

Function hierarchies have been used for decades, and are used today.

 

For example click here for a slide show on BOST.

BOST is a “business transformation framework” endorsed by CISCO and Informatica.

It is based on describing business systems using composition hierarchies.

It says a function hierarchy provides “a structured definition of all essential operations capabilities.”

“Functions are:

·         independent of organization [the management structure];

·         independent of where work is performed or who performs it; and

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

 

The slide show contains examples of function/capability, data, application and technology hierarchies

It also exemplifies mapping elements in one hierarchy to elements in another hierarchy.

 

In short, enterprise architects define a business using functional hierarchy that is relatively stable

Typically, they stop decomposing functions at a 3rd or 4th level.

Then, they map data entities, applications (and perhaps other architectural entities) to the functions.

 

Structures that correspond

Structures correspond when different sets of things are composed under the same hierarchy.

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

In such a “functional organization”, every organization unit corresponds to one function (at a given level of decomposition).

Still, the concepts are different, and one structure may change independently of the other.

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

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

 

E.g. Architects may choose to base a functional decomposition on a goal decomposition

So that every function corresponds to one goal (at a given level of decomposition).

Still, the concepts are different, and there is no rule that they must be related 1 to 1.

 

Structures that clash

Structures clash when one set of things is composed, using different criteria, under different hierarchies.

Given only 10 nodes there are 10 different (homeomorphic irreducible) hierarchies.

As the number of nodes increases, there is an exponential explosion in the number of possible hierarchies.

 

Obviously, it is possible to compose low level activities into different function hierarchies.

Countless functional decomposition hierarchies may be drawn; 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 to treat one functional decomposition hierarchy as the primary structure for enterprise architecture purposes.

Capability-based planning in general

Wikipedia (11/4/2018) defines a capability as “the ability to perform or achieve certain actions or outcomes.”

Dictionaries define a capability more simply as “the ability to do something or to achieve something”.

By definition, a capability is in 1-to-1 correspondence with something to be done or achieved.

 

Capability-based planning must start by defining the something that is to be done or achieved.

So, a business capability could be the ability to:

·         perform a business process (at a chosen level of decomposition)

·         perform the activities grouped into a business function or role (at a chosen level of decomposition)

·         perform the services required of an organization unit (at a chosen level of decomposition) or

·         achieve a goal, objective or purpose (at a chosen level of decomposition).

 

Capability-based planning must proceed by defining resources that a capability needs.

The resources that collectively enable the capability are of various kinds.

They include some or all of people, machines, computers, databases, networks, and procedures that actors must follow.

(They might even include people trained to find whatever resources they need to achieve some ad hoc aim.)

And note that two capabilities may need or share the same resources.

 

There is widespread confusion in discussion of capability-based planning between.

 

An abstract capability

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

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

 

A concrete capability

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

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

E.g. one source says a capability is composed of some resources interacting in repeatable value streams to meet some given purpose(s).

Just as a business system is composed of some actors interacting to perform some repeatable activities to meet some given aims.

 

It turns out that the “capability” concept is a chameleon.

The term is used freely by management consultants and enterprise architects.

The flexibility of the term makes it appealing and convenient in discussion with business people.

On the other hand, this flexibility makes it difficult to pin down its meaning, and place the concept in a meta model.

 

Conclusion: different capabilities may be related to different, or all, entities in an EA meta model.

And the more you strip a capability of the physical resources it needs, the closer it gets to a logical process or function.

Functions v capabilities in general

There are two ways to explain why a business capability hierarchy corresponds to (looks like) a functional decomposition hierarchy.

 

First: at any level of decomposition, a function needs a capability (to realise that function).

So, the hierarchy of capabilities must look like the hierarchy of functions.

 

Second: any hierarchy imposed over an enterprise’s aims or behaviors might be called a functional decomposition.

So countless functional decomposition hierarchies may be drawn, and that set of trees is called the "function forest".

A capability hierarchy must correspond to one tree in that function forest - and look indistinguishable from it.

 

Suppose business capability maps are formed by clustering nodes in a tree using particular cohesion criteria.

Then while every business capability map corresponds to a functional decomposition, the reverse is not true.

But in EA, as long as the purposes of a functional decomposition diagram and a business capability map are the same, they will have the same structure.

Part 3: Functions and capabilities in TOGAF

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:

·         Examples of business capability maps are indistinguishable from functional decomposition hierarchies.

·         Guidance on business capability maps repeats guidance on functional decomposition diagrams.

·         The term business capability is used where the term business function is used to the same effect.

Capabilities in TOGAF

There is confusion in discussions of capability.

TOGAF first defines a capability in abstract terms (like a function in a functional decomposition).

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.

Part 4: 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

Physical

Organization Unit, Actor

Application Component

Logical

Logical Application Component,

Physical

Physical Application Component

Technology Component

Logical

Logical 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 3rd or 4th 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.