TOGAF Business Architecture

(Featuring functions, capabilities and value streams)

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 11/12/2017 12:34

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™, are trademarks of The Open Group.

 

This is one of several popular papers on the TOGAF® standard that are posted on the home page at avancier.website.

TOGAF supports both “capability-based planning” and "structured analysis".

This paper attempts to resolve the widespread confusion out there about the similarities and differences.

It shows how capabilities may be documented using existing TOGAF artefacts.

 

Contents

The scope of EA and business architecture. 1

The business structure domain. 2

Principles explicit in TOGAF. 3

A case study to illustrate the function and capability concepts. 4

The concept of capability. 7

Documenting functions and capabilities. 7

Documenting inter-building block relationships. 9

Value streams and end-to-end processes. 9

Stepping from business architecture to applications architecture. 10

Conclusion: things to remember 11

Footnote: When and where to document the goals of a function/capability?. 12

 

The scope of EA and business architecture

TOGAF is a framework used by enterprise architects.

It is therefore about business roles and processes that create and use business data.

It is about standardising, integrating, optimising, innovating those business roles and processes.

It involves talking to business people about those things, and taking a strategic and cross-organisational view of them.

It also addresses the business applications and infrastructure technologies need to do that.

 

Business architecture work is done both above and within above any cycle of TOGAF’s ADM.

The scope of business architecture might be divided into three levels, along the lines in the Open Group’s draft O-BA standard.

 

Business strategy

TOGAF presumes there is usually higher enterprise or strategic business planning, from which business drivers and goals can be obtained.

"in some cases...the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

In other cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives 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

 

Business structure

"A knowledge of the business architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and therefore the first architecture activity that needs to be undertaken.” TOGAF

TOGAF adds this caveat: “if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.)."

Business structure artifacts that may be produced before any ADM cycle include functional decomposition, organisation decomposition and business scenarios.

 

Business operations

TOGAF is a management framework for managing major changes to business operations.

Each ADM cycle defines goals, objectives, requirements, service contracts, logical and physical business system components

And then, prioritisation, transition planning, implementation and governance of system change.

 

TOGAF presumes business strategy is a given, and focuses attention on the business structure and operations levels.

It includes more meta model entities for business architecture than for any other architecture domain.

Some belong more to the business structure level – can be specified above and independently of ADM cycle

Some belong more to the business operations level – are typically specified within and ADM cycle.

 

This table draws a distinction between the two levels, though it is fuzzy in practice, because the scope and level of decomposition varies.

Required behaviors

Logical structures

Physical structures

Business

structure

Goal/objective

Functional decomposition

Capability map

Organisation decomposition

Location

Business

operations

Business service

Process

Role

Actor

Modelling business structure and business operations in TOGAF

TOGAF identifies various techniques that may be used for modelling business architecture and the structure and operations levels.

 

Structured analysis (cf. capability modelling and value stream analysis)

TOGAF presumes knowledge of structured analysis, which people have used for decades.

It can be seen as the basis of TOGAF business architecture artifacts, and is the main topic in this paper.

Structured analysis relates three views of a business.

 

Physical structure view – organisation decomposition

The organisation/management structure, usually a hierarchical structure.

Actors and/or activities may be mapped to the elementary “leaves” of this structure.

There may be duplication of activities.

 

Logical structure view – function and/or capability hierarchy

A hierarchy that decomposes the functions/capabilities a business needs to provide business services and so meet its goals.

There is usually one primary function/capability hierarchy.

Roles and/or activities may be mapped to the elementary “leaves” of a hierarchy.

 

Required behavior view

A service (little discussed in this paper) encapsulates the internal behaviors of a system.

A process is a sequence of activities that leads to the delivery of result (change, product or service) of value.

Higher level, longer running, cross function processes are often called value streams.

 

Business scenario analysis (cf. value stream analysis)

"The ADM has its own method for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements...

This process and may be used iteratively, at different levels of detail in the hierarchical decomposition of the business architecture." TOGAF

 

Business scenarios may be defined at both business structure and operation levels of business architecture.

When used at the lower level, at the start of an ADM cycle, TOGAF says.

“Business models should be logical extensions of the business scenarios from the Architecture Vision,

so that the architecture can be mapped from the high-level business requirements down to the more detailed ones.

A variety of modeling tools and techniques may be employed, if deemed appropriate (bearing in mind the above caution not to go into unnecessary detail).

 

Business process modelling (cf. value stream modelling)

Business processes may be represented informally as business scenarios.

When the logical flow of a value stream needs to be defined, TOGAF presumes process flow diagrams will be drawn.

"Process flow diagrams show sequential flow of control between activities

and may utilize swim lane techniques to represent ownership and realization of process steps." TOGAF

On the level of granularity

The companion paper TOGAF principles and concepts abstracts some principles from TOGAF.

The appearance and reappearance of these principles helps to make TOGAF coherent and consistent.

 

One principle - the freedom to abstract and to refine - means that TOGAF does not prescribe the level you work at.

·         The elements in a system model can be composed and/or decomposed according to the scope of the endeavour, and the level of detail required.

·         “The level and rigor of decomposition needed varies from enterprise to enterprise” and from ADM cycle to ADM cycle.

 

You can compose or decompose any architectural entity as you see fit.

Goals, services, functions and processes can be defined at any level you choose, or at several levels.

E.g. business can meet a goal by performing a process, which is to say there is naturally a 1 to 1 correspondence between the goal and the process.

However, if you relate goals and processes at different levels of decomposition, then they may be related 1-N, or N-1.

 

Note 5: Where do “capabilities” and “value streams” fit?

TOGAF's generic function and process concepts are infinitely composable and decomposable.

So, you can see “capabilities” and “value streams” as corresponding to high-level functions and processes.

True, capabilities cluster abilities whereas functions cluster activities, but their use in a methodology is well nigh identical.

E.g. capability maps are like functional decomposition diagrams in appearance, purpose and practical use.

That is why TOGAF 9.1 does regard capabilities as corresponding to high-level functions.

It could also present value streams as high-level processes, but then, where would that leave TOGAF's business scenario?

 

There are c5,000 words in TOGAF on business modelling.

But they are largely ignored in separately-written TOG guides on business architecture.

And importing terms and concepts from other business architecture standards into TOGAF without care will create new incoherence and inconsistency.

The place of capabilities and value streams in TOGAF is further discussed below.

A case study to illustrate some concepts

To begin with, we have a request for architecture work.

We are given or identify some motivations (drivers, goals, objectives, targets, purposes) for the work to be done.

We might be given a free hand to look for aims, pains and opportunities across an enterprise.

But for the sake of explaining the concepts of function and capability, we’ll consider here two specific business areas.

 

Suppose a request for architecture work outlines some goals for, or concerns about, sales and marketing.

So, we set out to define the sales and marketing functions and the capabilities they require.

 

Services

TOGAF presumes we start by identifying some goals/objectives/purposes for sales and marketing functions.

And then define some services those functions a required to deliver - services of value to other functions and/or external entities.

 

·         The primary meaning of service in TOGAF (from v1 days) is a requestable behavior, as defined in discrete service contract.

·         The recommendation is to define service contracts that encapsulate/hide internal processes.

·         Beware! Business managers use the term service for what might be scoped in a service level agreement, which may list many discrete services.

 

Function-based planning

TOGAF presumes we can draw a function hierarchy for the enterprise that includes the sales and marketing functions.

We can decompose each of them as far we choose to do, but most people stop at the 3rd or 4th level of decomposition.

Each named function is a placeholder for the processes needed to realize that function (regardless of which organization units realize it).

 

TOGAF pitches the function hierarchy as a very high level view, and proposes you draw it for heat mapping and planning purposes.

"Functional Decomposition Diagram

The purpose 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.” TOGAF 9.1

 

A 3 or 4 level structure should be reasonably stable.

From the top down, the traditional advice is to stop there.

From the bottom up you can cluster activities or lower-level functions by any criteria you like.

The cohesion criteria are typically: similar or related purposes, goals, products/services or activities.

 

·         A function hierarchy is a logical structure imposed over business activities; each function is a cluster of lower-level functions or activities.

·         A Porter-style value chain diagram can be read as a first-level functional decomposition, with a hint of end-to-end process.

·         A function decomposition hierarchy is independent of the real organisation structure (though the two can be aligned in a “functional organisation”).

 

(You can grow a "function forest” by drawing several function hierarchies for one business organisation.

If I recall correctly, a UK national enterprise built nine function hierarchies, each related to different executive-level goals.)

 

Capability-based planning

Much of what is said above about function-based planning applies equally to capability based planning.

Because a function typically clusters lower level functions or activities required to meet agreed goals.

Whereas a capability clusters lower level capabilities or abilities a business needs to perform the same activities required to meet the same goals.

See the later sections for more about capabilities.

 

Processes

The sales function does not perform sales processes; because a function is a purely logical construct.

The sales function is a logical structure imposed over some activities in behaviors/processes.

TOGAF presumes we can model end-to-end process flows, which may span several functions.

 

·         Process flows are sequential or behavioral views of the same business activities (clustered underneath functions).

·         Longer (end-to-end) processes often coordinate functions (or more accurately, coordinate specific activities with those functions).

·         Shorter processes tend to be contained within a function - but it depends on the level of functional decomposition.

 

Initially, only processes that cross or coordinate functions may be modeled; later, the processes with a function will be defined.

High-level cross-functional processes (aka scenarios or value streams) may be modeled relatively informally.

These end-to-end processes contain only those process steps that meet the goal of the process

Lower-level, process flow diagrams may be drawn for particular processes of interest, at a 5th or 6th level of decomposition.

 

Every process sequences shorter processes/activities, leading to a result of value somebody or some thing.

And every process can be encapsulated by a service contract (including inputs, outputs, rules and non-functional qualities).

 

Value streams

Much of what is said above about processes applies equally to value streams.

See the later section for more about value streams.

 

Realisation of functions/capabilities and processes/value streams

·         Organisations units realize functions/capabilities - by performing the activities or demonstrating the abilities clustered within them.

·         Organisation units need the capability to realize a function.

 

Sooner or later, the required functions must be mapped to the organization units that have the capabilities to realize them.

If the sales and marketing functions are realized by one organization unit, then it will require both capabilities.

If the sales function is replicated in two organization units, they will both need the sales capability.

If the sales function is partitioned between two organization units, that implies a subdivision of the sales capability also.

 

EA teams are very rarely responsible for organisation design, or hiring, firing and redeploying of individual human actors.

So, when these are needed, they are addressed by a business managers, HR and sometimes a parallel "Business Change" team.

 

Maintaining the integrity of the structured analysis

The integrity of the process view is ensured by ensuring that where one activity appears in two processes, the activities are named the same,

And every activity in a process can be mapped to one node of the function hierarchy.

 

The function hierarchy imposes a logical structure over business activities.

Process models show the sequences of particular behaviors.

In theory, the two views can be brought into perfect correspondence, joined at the atomic activity level.

In practice, they rarely are, but if an activity cannot be mapped to a bottom-level function, then function hierarchy is missing something.

 

Reverse/forward engineering

The general principle is to reverse engineer from physical structure to logical structure and current behavior.

So, when modelling a baseline organisation, you step away from the organisation structure by drawing a functional decomposition diagram.

Then, when modelling a target organisation, you forward engineer from required behavior to logical structure to physical structure.

So, when modelling a target organisation, you start with a functional decomposition diagram to postpone consideration of the organisation structure.

The concept of capability

In a dictionary: a capability is the ability to do something.

Put in general system theory terms: a capability is the ability of a structure to perform a behavior to meet an aim.

In TOGAF terms, you may say: a capability is the ability of a business (or part thereof) to meet goals/objectives.

 

In structured analysis, a function is a collection of processes to deliver services to meet goals/objectives.

And to realise a function, a business must have the associated capability.

In TOGAF terms, you may say capability is the ability to fulfil a function, the ability to perform its activities to meet its goals/objectives).

So, although capability and function are different concepts, they are naturally related in a 1-1 correspondence.

 

The sales capability is the collection of the (cap)abilities our business needs to realize the sales function and so achieve the sales goal.

Put another way, it is the capability to perform the activities within the scope of our current or envisaged sales function.

 

Capability-based planning involves drawing a capability map.

This is a logical structure imposed over the business, based on purposes to be achieved.

The principles for drawing capability map are similar to those for drawing a function hierarchy, discussed below.

 

·         The function and capability concepts are widely confused because they are so naturally and readily aligned 1 to 1.

 

In EA work, capability maps and function hierarchies drawn for much the same purposes.

And they produce artifacts that are well-nigh identical. So how to reconcile the two approaches?

Documenting functions and capabilities

Suppose functions are clustered into a higher level function according to purpose/goal.

Each node in your function hierarchy represents a group of activities clustered by purpose/goal.

Each node in your capability hierarchy represents a group of abilities clustered by purpose/goal.

Now suppose you merge the two hierarchies into one logical structure.

The result would be logical business component hierarchy, each node being describable in terms of both abilities and activities, much like a normal human role definition.

 

 “There does not appear to be a generally accepted specification of additional detail to a capability map model”. VDML

This section show how capabilities may be documented using existing TOGAF artefacts.

 

Capability and function hierarchies are both logical structures in which the building blocks in them are logical business elements.

To realise a function, a business needs the capability to do it, which means there is naturally a 1 to 1 correspondence.

Unsurprisingly, the artifacts used to model the functions and capabilities are very similar.

Some or all of the function-oriented artefacts in the table below could equally be used in capability-oriented modelling.

 

Functions <are related to>

Other architectural entities

Artifact discussed in TOGAF

NAF views

Functions <provide>

Services (the external view of a Function)

Business Service/Function catalogue

Capability/services mapping

Functions <are composed of>

Functions (the internal view of a Function)

Functional decomposition

Capability taxonomy

Capability/Operational activities mapping

Functions <serve>

Functions or Roles (with information/material flows)

Node connectivity diagram

Capability Dependencies

Functions <trigger>

Functions (in sequential processes)

Business scenario; Process flow diagram

Process

Functions <are realised by>

Organisation units

Business Interaction (Organisation/Function) matrix

Capability/organisation deployment mapping

Functions <create and use>

Data entities

Data entity/Function matrix

 

Functions <are served by>

Applications

Application/Function matrix

 

 

And here is an illustration of how the artefact descriptions can exchanged.

Lightly edited from TOGAF 9.1 artifacts

Modifed to fit BA

Function decomposition diagram

The aim is to show (on a single page if possible) the functions of an organization.

By examining the functions, it is possible to quickly model what the organization does without being dragged into debate on how the organization does it.

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

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

Capability map

The aim is to show (on a single page if possible) the capabilities of an organization.

By examining the capabilities, it is possible to quickly model what the organization does without being dragged into debate on how the organization does it.

Once a basic capability map has been developed, it is 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.

Business Interaction (Organisation/Function) matrix

The aim is to depict which organizations realise which business functions.

This helps to highlight value chain dependencies across organizations.

Capability realisation matrix

The aim is to depict which organizations realise which business capabilities.

This helps to highlight value stream dependencies across organizations.

Process flow

The aim is to show sequential flow of control between process steps.

Swim lanes may be used represent ownership and realization of processes and process steps.

Details may include events that trigger a process, or result from its completion, and products generated.

The diagram enables subject matter specialists to describe ‘‘how the job is done’’ for a particular function, or how several functions are coordinated.

Value Stream Diagram

The aim is to show sequential flow of control between processes.

Swim lanes may be used represent ownership and realization of processes.

Details may include events that trigger a value stream, or result from its completion, and products generated.

The diagram enables subject matter specialists to describe ‘‘how the job is done’’ for a particular capability, or how several capabilities are coordinated.

Documenting inter-building block relationships

The building block concept can include capabilities, functions, organisation units and roles.

TOGAF speaks of node connectivity diagrams, which show relationships between building blocks.

There are four main ways that building blocks may be related in such a diagram.

 

Building block A <depends on> building block B

A dependency relationship usually represents an abstraction, hiding several lower-level flows or triggers

 

Building block A <sends a material or information flow to> building block B

A flow relationship represents a flow of materials or information from one building block to another (or from an activity within one building block to an activity within another building block.)

The normal presumption is that a flow provides a value to its receiver building block.

 

Building block A <serves> building block B

A serves relationship may be drawn to show where a building block sends a flow in response to a service invocation.

 

Building block A <triggers> building block B

A triggering relationship can be drawn to relate two building blocks in strictly sequential procedural flow.

Triggers more usually connect bottom-level functions (discrete activities) than higher-level functions.

Value streams as end-to-end processes

The table below contains the names of things that have been called value streams in different sources.

 

Cash management

Inventory management

Environmental liabilities

Hire to retire

Procurement to disposal

Deploy to re-deploy/discard

Prospect to order

Order to cash

Procure to pay

Book airplane seat (journey definition to ticket)

Book holiday (enquiry to booking confirmation)

Claim processing (complaint to refund)

Open a bank account.

Set up a direct debit to pay bills.

Withdraw cash from the account.

 

You cannot tell from a name whether the named thing is a behavior/process or a structure/function.

And some listed in the table above don’t sound like a values stream.

The term value stream is usually defined much as a business process

·         an end-to-end collection of activities that create a result for a ‘customer’ who may be the ultimate customer or an internal ‘end user’ of the value stream” Martin (1995).

·         a sequence of activities an enterprise undertakes to deliver on a customer request.”

 

Every process has a goal and a value; it is a procedure that terminates in a result.

The value of the process lies in the use of that result by one or more users.

 

“Value stream mapping”

"A lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer."

At Toyota, it is known as "material and information flow mapping". https://en.wikipedia.org/wiki/Value_stream_mapping

One convention is to draw value-adding steps are drawn horizontally across the centre of the map, and draw non-value-adding steps in vertical lines at right angles to the value stream.

 

“Value stream analysis”

This (again after Lean I believe)  involves measuring process steps, and optimising the process in the light of those measurements.

This might be done in the course of what TOGAF calls business scenario analysis.

 

Aside on “value chain”

A Porter-style value chain diagram can be read as a first-level functional decomposition, with a hint of end-to-end process.

The value chain concept is usually expressed in a very high, top level, model of an enterprise.

·         a [disaggregation of] a firm into its strategically relevant activities in order to understand the behavior of costs and the existing potential sources of (competitive) differentiation” (Porter, 1985).

·         a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal functional Decomposition diagram developed within Phase B (Business Architecture), the Value Chain diagram focuses on presentational impact. TOGAF

 

Porter’s famous value chain diagram is a compromise between a structural decomposition and process flow.

TOGAF’s “more formal functional decomposition diagram” represents a logical organization structure, with no hint of process flow.

Stepping from business architecture to applications architecture

In ADM phase A and B, or before then, you can draw a capability or function hierarchy down to a 3rd or 4th level.

Then look for aims, pains and opportunities, do some heat mapping, and map hot spots to existing or changed organisation units.

You can also draw some high-level process models (scenarios, value streams) for processes that cross functions and/or organisation units.

 

Moving from ADM phase B to phase C, it is likely that further "structured analysis" is needed.

Because you will probably not have reached the level needed to define the required data entities and required application services.

To do that, somebody will likely have to do some business process modelling at lower (OPOPOT) level.

 

You can draw process models without reference to any earlier capability or function hierarchy.

But TOGAF is keen you maintain a coherent and consistent architecture repository

The traditional cross-validation step is to map each process step to one bottom level building block of the function hierarchy.

 

TOGAF features a data entity/function matrix.

Enterprise architects may tabulate hundreds of data entities against scores or hundreds of functions.

Conclusion: things to remember

Granularity of system elements

·         The elements in a system model can be composed and/or decomposed according to the scope of the endeavour, and the level of detail required.

·         “The level and rigor of decomposition needed varies from enterprise to enterprise” and from ADM cycle to ADM cycle.

Functions (cf. capabilities)

·         A function hierarchy is a logical structure imposed over business activities; each function is a cluster of lower-level functions or activities.

·         A Porter-style value chain diagram can be read as a first-level functional decomposition, with a hint of end-to-end process.

·         A function decomposition hierarchy is independent of the real organisation structure (though they can be aligned in a “functional organisation”).

Processes (cf. value streams)

·         Process flows are sequential or behavioral views of the same business activities (clustered underneath functions).

·         Longer (end-to-end) processes often coordinate functions (or more accurately, coordinate specific activities with those functions).

·         Shorter processes tend to be contained within a function - but it depends on the level of function decomposition.

Realisation of functions/capabilities and processes

·         Organisations units realize functions/capabilities - by performing the activities or demonstrating the abilities clustered within them.

·         Organisation units need the capability to realize a function.

·         The function and capability concepts are widely confused because they are so naturally and readily aligned 1 to 1.

Services

·         The primary meaning of service in TOGAF (from v1 days) is a requestable behavior, as defined in discrete service contract.

·         The recommendation is to define service contracts that encapsulate/hide internal processes.

·         Beware! Business managers use the term service for what might be scoped in a service level agreement, which may list many discrete services.

Footnote: When and where to document the goals of a function/capability?

Functions that begin as abstract architecture elements morph into organisation units with physical resources (much as roles morph into actors).

In a simple case, in a “functional organisation”, one function relates to one organisation unit, so share the same attributes and relationships.

But if the relationship is many-to-many, you have to consider when, where and how to record the attributes and relationships of each.

For example: consider relating goals to functions and to organisation units.

Enterprise architects might relate purposes or goals to a function.

But in the end, directors must assign goals to the managers of the organisation units that fulfil that function using resources (men, materials and machinery).

TOGAF takes a service-oriented view and relates goals to each business service (in a “goal/objective/service diagram”).

It can be presumed those goals are inherited by every function and organisation unit that provides that service.

(However, TOGAF also suggests relating goals to organisation units, presumably because that is important in the real business.)

 

For further discussion of capability as a system, and its position in a meta model, read “The TOGAF standard mapped to NATO’s architecture framework”.

 

 

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences..