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 Saturday, 01 December 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 shorter and older one on Mapping TOGAF to the Nato Architecture Framework (NAF).

Contents

Preface: introducing the business architect role. 1

More on enterprise architecture in general 5

More on hierarchical decomposition. 6

More on corresponding and clashing hierarchies. 8

More on capabilities in general 9

More on functions and capabilities in TOGAF. 10

Conclusions wrt business capability maps and value stream diagrams. 12

Impact on TOGAF terms, definitions and meta model 13

 

Preface: introducing the business architect role

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

Operations view

Business functions/capabilities, information subjects and flows

IT architecture

Systems view

Application components and information exchanges

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

 

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.

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 3rd or 4th 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 capabilities in general

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

The trouble is:

·         The something could be of many different kinds

·         Whatever it is, the capability is in 1-to-1 correspondence with it

·         To disambiguate one must refer to the something directly.

 

For example, a business capability could be the ability to:

·         perform a business process

·         perform the activities grouped into a business function or role

·         perform the services required of an organization unit

·         achieve a goal, objective or purpose.

 

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

Then proceed by defining resources with the required capability.

Those resources may 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.)

 

Some speak of a capability as though it is the resources that have the ability.

“A capability is composed of some resources interacting in repeatable value streams to meet some given purpose(s).”

But that is to equate a capability with system.

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

 

In short, the “capability” concept is a chameleon.

And the resources that make the capability deployable are of various kinds.

 

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

This flexibility makes the term appealing and convenient in discussion with business people.

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

Different kinds of capability may be related to different, or all, entities in an EA meta model.

 

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

A concrete capability is defined in terms of people, processes, data and technologies.

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

By contrast an abstract capability is defined independent of people, processes, data and technologies.

It usually if not always corresponds to a logical business function in a functional decomposition hierarchy.

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

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

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.