TOGAF Business Architecture

(Featuring functions, capabilities and value streams)

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 24/05/2019 14:36

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

 

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

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

This is one of several papers based on analysis done c2009 for the British Computer Society (their professional certificates in enterprise and solution architecture).

Contents

PART ONE (recap) 1

Every function needs the corresponding capability. 1

Value streams as end-to-end processes. 4

PART TWO (more detailed research) 6

The scope of EA and business architecture. 6

Modelling business structure and business operations in TOGAF. 7

Business architecture concepts and techniques. 9

The concept of capability. 14

Documenting functions and capabilities. 15

Documenting inter-building block relationships. 16

Stepping from business architecture to applications architecture. 16

Conclusion: things to remember 17

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

 

 

PART ONE (recap)

Every function needs the corresponding capability

Managers define organisation hierarchies.

Organisation units are managed groups of actors and activities (physical business components).

Functions/capabilities are logically cohesive groups of the activities/abilities required of an organisation (logical business components).

 

A function/capability hierarchy may correspond to or clash with the organisation hierarchy (aka management structure).

They correspond in a *functional organisation*.

They clash where the management structure is divided in other ways, e.g. by location, product type or customer type.

 

Why (since the 1980s) do EAs/BAs draw a logical function/capability hierarchy?

·         To define the activities/abilities of a business in a way that is more stable than and independent of the organisation chart.

·         To assist in discussion of business scope and change.

·         To classify other EA/BA entities - roles, processes and resources.

 

Function? Capability? What is the difference?

Piano playing can be read as the name of a function (an activity) and of a capability (an ability).

What delivers value to consumers? Is it the piano playing or the piano player? It is both.

The piano player must a) have the ability and b) use that ability to perform the activity.

Now replace “piano playing” by “marketing” or “disaster recovery” and “piano player” by “actors”.

Marketing and disaster recovery can be the names of functions and/or capabilities

 

After 10 years of asking, I gave up asking people to show me a capability map that differs in appearance or use from a function hierarchy.

In practice, the two diagrams look the same and all have the same possible uses.

Function hierarchies are used for heat mapping, exactly as capability maps are.

 

Functional Decomposition Diagram (quoted from TOGAF 9.1)

Capability Map

Shows on a single page the organization capabilities relevant to the architecture to be defined and governed.

Helps to quickly model the organization’s capabilities without being dragged into debate on how the organization does it.

Given a basic diagram, it is possible to layer heat-maps on top of it to show scope and decisions.

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

Shows on a single page the organization capabilities relevant to the architecture to be defined and governed.

Helps to quickly model the organization’s capabilities without being dragged into debate on how the organization does it.

Given a basic diagram, it is possible to layer heat-maps on top of it to show scope and decisions.

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

 

Many misunderstand what a business function is - as in "structured analysis" since the 1980s, and presumed knowledge in TOGAF since version 8.

 

Imagine all the different atomic activities of a business were listed (they rarely are).

Other architecture entities can be defined in terms of those activities.

·         An organisation unit has a manager who is held accountable for the performance of some of those atomic activities.

·         A process is a sequence of atomic activities that may span several organisation units, functions or capabilities.

·         A business function is a unique group of atomic activities that are cohesive in some way(s) other than sequence.

·         A capability is the ability to perform a group of atomic activities that are cohesive in some way(s).

 

The ability to perform covers all that is required – knowledge, skills and resources.

 

Functions and capabilities may be recursive composed and decomposed in hierarchical structures.

At each level of definition in a hierarchy, to realise a function requires a corresponding capability (1 to 1).

So, a function hierarchy necessarily corresponds to a capability hierarchy.

 

Functions/capabilities are usually arranged in hierarchies decomposed to 3 or 4 levels.

The hierarchy subdivides the activities/abilities of business into relatively discrete units.

A function is supposed to be cohesive internally and loose-coupled externally.

 

Functions/capabilities can be mapped to behaviors/processes.

Lower level functions (say at a 3rd level) can be mapped to the stages of topmost behaviors (aka value streams).

Functions are rarely decomposed to atomic (say 6th level) activities.

But when they are, those activities may be more formally sequenced in bottommost behaviors (aka procedures).

 

Functions/capabilities can be mapped to organisation units.

A function can be seen as a logical organisation unit, much like a role can be seen as a logical actor.

A function can be seen as an abstract type realised by one or more individual organisation units.

Much like a role can be seen as an abstract type realised by one or more individual human actors.

 

Functions/capabilities can be mapped to applications and other resources they need.

The term function is used with different meanings in the application domain/layer

Sometimes it is a process (as in UML) and sometimes it is a logical application component.

 

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

 

 

It is crazy to include functions and capabilities as distinct entities in a meta model of architecture entities

Because they both have the same relationships to other entities.

 

Beware naming lower level functions/capabilities "services".

In Archimate and TOGAF, service is supposed to be a different concept.

It is a discretely requestable behavior, rather than a node in a structural decomposition.

Value streams as end-to-end processes

The term value stream is not new

It has usually been defined as end-to-end business process.

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

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

 

The table below contains the names used to label 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.

 

The name of a thing doesn’t always reveal whether it is a behavior/process or a structure/function.

Some examples named in the table above don’t sound like a values stream, since they don’t suggest an end-to-end flow.

However, there is no prescription about where a value stream starts or ends, or who its customer is.

 

TOGAF's generic process concept is infinitely composable and decomposable.

So, you can see “value streams” as corresponding to high-level processes or business scenarios.

 

Process Flow Diagram (as in TOGAF 9.1)

Value Stream Diagram

Given a product or service of value to be delivered, this presents the necessary activities/steps in sequence.

It may show for the process and each step

·         Trigger events

·         Outputs, and

·         Controls/rules (pre and post conditions).

It may use swim lanes to represent owners, roles or resources associated with process steps.

It can help subject specialists to describe ‘‘how the job is done’’ for a particular function.

Given a product or service of value to be delivered, this presents the necessary activities/stages in sequence.

It may show for the stream and each  stage

·         Objectives and Roles involved

·         Entry criteria: including trigger events

·         Exit criteria: including products generated.

It may associate owners, roles and capabilities with each value stage.

It can help subject specialists to describe ‘‘how the job is done’’ for a particular capability.

 

Every process has a goal; it is a procedure that terminates in a result of value to some actor or future process.

A whole value stream and each stage within it may be defined in terms of:

·         Aims: achievement , purpose and value added

·         Roles: actors engaged in the value stream/stage

·         External view: encapsulation of the value stream/stage by entry and exit conditions  (as in service contract)

·         Internal view: internal activities (which implies a further level of process decomposition).

 

A process is a process, be called a business scenario, use case or value stream, or encapsulated behind a service contract.

It is possible to use the same template to document any value stream/stage, process or use case.

 

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

PART TWO (more detailed research)

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 and innovations in 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 needed.

 

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

Some kinds of business modelling are done at the higher strategic level.

Some make no reference to business data created or used – leaving nothing for ADM phase C onwards to work on.

And organisation design is very rarely considered the responsibility of an EA team (see below).

 

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 a higher level of enterprise or strategic business planning work, 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's meta model is pitched at a high and general level.

Its busines system description concepts are as generic as generic can be.

They might be documented using ArchiMate, UML, BPMN or any other standard you like.

But they are not particular to any standard, modelling language, method or technique.

 

A business service is a requestable behavior.

A service usually consumes an input flow and produces an output flow or updates system state.

 

A business process is a sequence of steps leading to a result of value to at least one party.

Processes can be very short or very long.

A process may be contained within a function or organisation, or span several functions or organisation units.   

 

A business function is a named group of processes or process steps, as may be clustered under a function name in a functional decomposition hierarchy.

The clustering can by goal or purpose (cf. capability-based planning) or some other criterion. 

Functions are logically bounded by business services needed by other functions or external entities.

 

TOGAF suggests techniques that may be used for modelling business architecture at the structure and operations levels, including:

 

Structured analysis

Business process modelling

Business scenario 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 (lightly 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.

 

On the level of granularity

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

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.

 

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.

There are c5,000 words in TOGAF 9.1 on business modelling, which could do with tidying up.

Importing terms and concepts from other business architecture standards without care may create new incoherence and inconsistency.

For more on capabilities and value streams read on.

Business architecture concepts and techniques

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.

 

Case study:

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

Again, a business service is a requestable behavior.

Services consume input flows and produce output flows and/or update system state.

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

Again, a business function is a named group of processes or process steps, as may be clustered under a function name in a functional decomposition hierarchy.

The clustering can by goal or purpose (cf. capability-based planning) or some other criterion. 

Functions are logically bounded by business services needed by other functions or external entities.

 

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

Again, business process is a sequence of steps leading to a result of value to at least one party.

Processes can be very short or very long.

A process may be contained within a function or organisation, or span several functions or organisation units.   

 

TOGAF presumes process flow diagrams can be drawn to represent the logical flow of a process.

"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

But business process analysis and design has nothing in particular to do with ArchiMate, UML, BPMN or any other standard, modelling language or method.

Processes may be modelled formally or informally in the form of business scenario or value streams.

 

Note that:

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

 

Business scenario analysis (cf. value stream modelling )

EA looks to standardise, integrate, optimise and innovate in business processes and roles that create and use business data.

TOGAF recommends starting from the products and services needed to achieve business goals.

And defining the “architecture vision” by documenting business scenarios that deliver those products and services.

A business scenario outlines a business process and the roles of human and computer actors in it.

 

"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).” TOGAF

 

This table presents a business scenario discussed in TOGAF version 8.

It defines the entry and exit criteria as may be done for any value stream or value stage.

It defines the applications used at each stage, and the capabilities they are assigned to.

Name

Capture order

 

Goal, purpose, value added

As implied  by the name above and exit criteria below

 

Roles

Customer

Sales person

 

Entry criteria

Trigger: Visit customer at scheduled time

Input: Customer details

Preconditions: Sales visit agreed and scheduled

 

Exit criteria

Outputs or products: Signed order

Post conditions: Order captured and recorded

 

Activities

Human activities

Applications

Capabilities

1 Initiate sales process with the customer

 

2 Discuss customer requirements

 

3 Work with customer to create a product configuration

Product Configurator

Sales & Marketing

4 Verify that the desired configuration can be delivered

Inventory

Scheduling

Supply

Delivery

5 Determine price of requested configuration

Pricing

Sales & Marketing

6 Confirm customer desire to purchase

 

7 Place an order

Order entry

Sales & Marketing

8 Capture customer signature

Order entry

Sales & Marketing

Non-functional qualities

Duration: 1 hour

Throughput: 2 per day per salesman

Availability: Working hours

 

 

The value stream is not a process alone, it is the process decomposed into steps (value stages) and the capabilities (or part capabilities) that each value stage requires.

For more detail, read the associated slide show.

 

Value streams

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

See the earlier 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 function name 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.

Here is an illustration of how the artefact descriptions can exchanged.

 

Lightly edited from TOGAF 9.1 artifacts

Modifed to fit Business Architecture terminology

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.

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.

In conclusion, some things to remember

For more detailed research, backing up the above, read https://bit.ly/2Kpa80F.

 

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” (TOGAF 9) and from project to project.

 

Functions (cf. capabilities)

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

·         A Porter-style value chain diagram can be read as a first-level functional decomposition diagram, 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 atomic activities that are grouped into 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 activities and demonstrating abilities.

·         Organisation units need the capability to realize a function.

·         The function and capability concepts are widely confused because every function needs a capability (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..