The science of functions and capabilities

Resolving the confusion in EA/BA standards

https://lnkd.in/gBugTAX

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 14/07/2019 10:26

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

                                                                                                                                          

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

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

However, there is a science about what can be documented.

And many in the EA, BA and TOGAF communities seem unaware of it.  

Contents

Concepts used in the documentation of business activity systems. 1

On “function”. 1

Functions mapped to other things. 1

On “capability”. 1

Function hierarchies mapped to capability maps. 1

Functions/capabilities mapped to other things. 1

An aside on value streams as end-to-end processes. 1

In conclusion, some things to remember 1

 

Concepts used in the documentation of business activity systems

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

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

 

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

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

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


EA regards the enterprise as a system of systems, in which actors (in roles) perform activities (in processes) to meet aims or goals.

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

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

 

Business architecture as defined in TOGAF 9.2

Architecture entities

Definable in terms of activities thus

“Business operations

Roles and

Processes

A role is the group of activities that one actor can be asked to perform; it may span several processes.

A process is a sequence of activities that lead to a result of value; it may span several organisation units.

“factors that motivate the enterprise

Goals

A goal is a motivation for one or more activities

“how the enterprise is organizationally structured

Organization units

An organisation unit has a manager who is held accountable for the performance of a selection of activities.

“and what functional capabilities the enterprise has”

Business functions

and Capabilities

A business function groups activities that are cohesive in some way(s) to be discussed below.

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

 

You can find corresponding concepts in many sources.

In general system theory, actors perform activities.

In UML, objects perform methods that realise operations (defined in interfaces, which encapsulate classes of objects).

In ArchiMate, components perform processes that deliver services (accessed via interfaces, which encapsulate components).

What external entities see as services are completed by the performance of processes that consume inputs and deliver outputs and/or system state changes.

 

To form a domain-specific vocabulary, it is not enough to define each concept in a sentence and/or name some examples.

One has to differentiate the concepts and define their relationships to each other – as discussed below.

Beware that how they relate to each other is complicated by the fact that each concept can be hierarchically composed and decomposed.

On “function”

The term function is used with different meanings in different contexts.

Often, to name the function of a thing is to name a goal of that thing.

In the UML standard, a function is a process (an algorithm).

In the ArchiMate standard, an application function appears to be a logical application component.

The discussion below is of business functions – as in structured analysis and TOGAF.

 

Function as opposed to goal, organisation unit and process

Managers (typically) define business goals and organisation structures.

A goal is a motivation or target, ideally measurable and timebound.

An organisation unit is a managed group of actors and activities - a physical business component.

A function is grouping of the activities required to achieve one or more goals. 

A function is a logical business component – a group of activities required of one or more organisation units.

 

Business architects (typically) define business processes and functions.

A process arranges activities sequentially, ending in the production of result(s) or desired effect(s) that contribute to goal(s).

A function is a group of activities that are cohesive in some other way - to be discussed below.

 

A function hierarchy

A function hierarchy imposes a hierarchical structure over bottom-level functions.

Ideally, it is supposed to be a normalised structure.

Meaning no atomic activity appears under more than one bottom-level function in the hierarchy.

 

Why do EAs/BAs draw a logical function 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.

 

Breadth and depth of a function hierarchy

The breadth of the hierarchy is as wide (even an entire business) or as narrow as you choose it to be.

There are some numeric rules of thumb for the depth.   

Suppose each node is decomposed into 7 subordinate nodes (“the Miller number”).

 

Level of decomposition

Number of nodes

1

7

2

49

3

343

4

2,401

5

16,087

6

117,649

7

823,543

 

 

 

 

 

 


The numbers explain why few try to maintain a function hierarchy more than 3 or 4 levels deep.

In a large business, the atomic activities might be found at the 6th, 7th or 8th level of decomposition.

You’d need to work in a remarkably stable regular business to maintain a hierarchy that deep.

 

Bottom up construction of a function hierarchy

There is a process for composing a business function hierarchy systematically. 

 

1)     Define an organisation structure (whole or part) down to bottom level units

2)     List the regular activities performed in each unit

3)     Deduplicate that list of activities

4)     Cluster the activities into groups using a cohesion criterion of your choice

5)     Cluster the groups into higher groups, and so on until you reach the top

 

You may cluster activities in any way you choose. E.g.

·       activities that meet the same aims or contribute to the same measures to be reported

·       activities that require the same abilities or skills

·       other…

 

Successively grouping activities implies also successively grouping the cohesion factor (be it aims or abilities).

And therein lies a paradox that arises in modelling system elements in hierarchical structures.

Basing one hierarchical structure on another makes documenting both unnecessary, or at least questionable.

 

Corresponding and clashing structures

Any two hierarchies can either correspond (1 to 1 at every level), or clash to a greater or lesser degree.

Suppose you align the business function hierarchy with the business goal/objective hierarchy.

Then to document both introduces a redundancy into your architecture definition.

Documenting both hierarchies only becomes of interest when the structures are different.

 

The function forest, and the primary tree

You might juggle two or more cohesion criteria to compose one hierarchy.

However, clustering activities or functions using different criteria can lead to different function hierarchies.

You can build several function hierarchies (a function forest) each addressing a particular stakeholder viewpoint.

I recall a speaker (at a BCS EA SG meeting) saying they had 9 function hierarchies - each representing the viewpoint of a different director-level reporting requirement.

 

The EA tradition is to settle on one function hierarchy as a basis for other analyses.

The team uses that function hierarchy as their primary way of presenting the scope of the business they address.

And for mapping functions to data created and used.

This function hierarchy is probably the one that most senior business leaders most buy into.

It might correspond to a business goal/objective hierarchy, but it does not have to.

 

Reused and cross-cutting functions

You may define atomic activities or wider functions that are reused in different legs of the function hierarchy.

You may define a function that cuts across others in any given function hierarchy.

E.g. “disaster recovery” and “money laundering prevention” might be examples.

 

And capability?

Replace “activity” by “ability”, and it might be postulated that almost all said of “function” could equally be said of “capability”.

E.g.

·       A function/capability is grouping of the activities/abilities required to achieve one or more goals. 

·       A function/capability is a logical business component – a group of activities/abilities required of one or more organisation units.

·       A function/capability is a group of activities/abilities that are cohesive in some way.

But we’ll come back to that.

Functions mapped to other things

 

Functions mapped to organisation units

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

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

 

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

They correspond in what some call a *functional organisation*.

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

 

Functions mapped to processes and services

A process arranges activities (performed by actors) to terminate in the production of an end result or desired effect.

A process is a process is a process, be it called a value stream, business scenario, use case, epic, a user story, a procedure or algorithm.    

However, different conventions have evolved for documenting processes at different levels of composition and degrees of precision.

 

Coarse-grained functions can be hierarchically decomposed into smaller (more fine-grained) functions.

Long-running processes can be hierarchically decomposed into shorter processes.

Since both functions and processes can be recursively composed and decomposed:

·       one higher-level function may "contain" several lower level processes

·       one higher-level process (aka value stream) may span several lower-level functions (that is, orchestrate particular activities with them).

 

Service-orientation means defining systems and components in terms of their services they offer.

Here, a service is a process that is named and defined as seen by a customer or other consumer, without reference to its internal activities,

E.g. “Replace wheel”, or “Attend training course” defined in terms of its entry conditions and exit conditions (including desired effects).

Since both functions and services can be recursively composed and decomposed:

·       one high-level function may offer or provide several fine-grained services

·       one coarse-grained service may require several (fine-grained services from) low-level functions

 

Processes and functions mapped to roles

One process can sequence activities that several roles are responsible for.

Conversely, one role can aggregate activities that occur in several processes.

In special cases, a role and a process are in 1 to 1 correspondence.

This occurs when you employ actors to perform 1 and only 1 process.

 

One business function groups activities that several roles are responsible for.

Conversely, one role can aggregate activities that are grouped under several functions.

In special cases, a role and a function are in 1 to 1 correspondence.

This occurs when you build your function hierarchy with roles as functions.

(Which ideally implies no two roles are assigned to the same activity.)        .

On “capability”

Replace “activity” by “ability”, and it might be postulated that almost all said of “function” could equally be said of “capability”.

E.g.

·       A function/capability is grouping of the activities/abilities required to achieve one or more goals. 

·       A function/capability is a logical business component – a group of activities/abilities required of one or more organisation units.

·       A function/capability is a group of activities/abilities that are cohesive in some way.

So, let us explore how people define capability.

 

Dictionaries (surveyed in writing this) typically define a capability as “the ability to do something or to achieve something”.

In other words, the ability to perform one or more activities and/or meet one or more aims.

A business system may be observed in operation as a set of actors performing some activities to meet some aims.

An ordinary business needs the ability to perform activities such as “sales”, “disaster recovery” or (much more fine-grained) “wheel replacement”.

The armed forces need the ability to do such things as “win a battle”, or “rescue friendly forces from enemy territory”.

 

So, which of the following statements do you think make sense?

1.     A capability is an ability of a business (or other entity).

2.     A capability can be used by a business to perform an activity.

3.     A capability can be used by a business to achieve an aim.

4.     A capability can be developed.

5.     A capability can be exchanged.

6.     A capability can be delivered.

7.     A capability can act, can perform an activity

8.     A capability is abstract – defined without reference to people, data or technology.

9.     A capability is concrete – composed of human and technological resources.

10.  An example could be “Manned interplanetary travel”.

 

These interpretations can be found in definitions of capability, yet don’t add up to a consistent and coherent vocabulary.

·       1, 2, 3 and 4 are compatible with most definitions.

·       5 and 6 (BIZBOK and TOGAF) read as incompatible with 1, since what businesses exchange and deliver are the products of using capabilities rather than the abilities themselves.

·       7 is incompatible with 1 and most if not all EA/BA meta models.

·       8 and 9 are contrary meanings: MoDAF favours 8, DoDAF appears to favour 9 and TOGAF confuses the two.

·       However, 10 is compatible with both 8 and 9, since a capability can be an aspiration.

 

Generalising from a dozen definitions of capability

The black text in the table below is copied from this list published in DoDAF .

The blue text – added here - shows most definitions interpret capability as "an ability", and then apply it to activities and/or aims.

 

Source referred to in DoDAF

Definition of capability

JCIDS

The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.

Generalisable as

An ability to achieve an aim by performing a set of activities.

DoDAF/CADM

An ability to achieve an objective.

Generalisable as

An ability to achieve an aim.

DDDS Counter (333/1)(A) (JC3IEDM)           

The potential ability to do work, perform a function or mission, achieve an objective, or provide a service.

Generalisable as

An ability to perform activities, achieve an aim, or provide a service.

MODAF

Capabilities in the MODAF sense are specifically not about equipment but are a high-level specification of the enterprise’s ability.

A capability is a classification of some ability – and can be specified regardless of whether the enterprise is currently able to achieve it.

For example, one could define a capability “Manned Interplanetary Travel” … which may be planned or aspired to.

Capabilities in MODAF are not time-dependent – once defined they are persistent.

Generalisable as

An ability to perform activities that is persistent and abstractly defined.

NAF

The ability of one or more resources to deliver a specified type of effect or a specified course of action. (GEN TERM)

Generalisable as

An ability of actors to an achieve an aim or perform a process.

NAF

A high-level specification of the enterprise's ability. (MM)

Generalisable as

An ability that is abstractly defined.

JCS 1-02                                                       

The ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.)

Generalisable as

An ability to perform a process, with or without an aim.

Webster's

1. The quality of being capable; ability.  2. A talent or ability that has potential for development or use.  

3. The capacity to be used, treated, or developed for a specific purpose.

Generalisable as

An ability to be used, treated or developed to achieve an aim.

Merriam-Webster's Eleventh Collegiate Dictionary

A feature or factor capable of development

Generalisable as

An ability capable of development

Joint Publication 1-02, Dictionary of Military and Associated Terms, 12 Apr 2001 - 30 May 2008

The ability to exercise a specified course of action (A capability may or may not be accompanied by an intention)

Generalisable as

An ability to perform a process, with or without an aim.

Dictionary.com

The quality of being capable; capacity; ability: His capability was unquestionable.

The ability to undergo or be affected by a given treatment or action: the capability of glass in resisting heat.

Usually, capabilities. qualities, abilities, features, etc., that can be used or developed; potential: Though dilapidated, the house has great capabilities.

Generalisable as

An ability to perform or be affected by activities, which can be used or developed.

Wiktionary

The power or ability to generate an outcome

Generalisable as

An ability to achieve an aim.

www.staffordshireprepared.gov.uk/glossary/

Originally a military term which includes the aspects of personnel, equipment, training, planning and operational doctrine.

Now used to mean a demonstrable capacity or ability to respond to and recover from a particular threat or hazard."

Generalisable as

An ability to respond to and recover from a particular threat or hazard.

 

A dozen definitions of “capability” referred to in DoDAF are listed and analysed in the table above.

Note that two of them limit the concept of capability by relating it to a "course of action" which is to say, a process or service.

A course of action is defined here as: “any sequence of activities that an individual or unit may follow.”

By contrast, when used by the military, the term capability can mean a concrete set of resources.

 

Here is an attempt to form a consensus definition of capability - by generalisation from the definitions in DoDAF.

·       A capability is an ability (of actors) to perform activities, achieve an aim, or provide a service.

·       It is an ability that is abstractly defined, whether for development or use.   

 

More questionable definitions

To speak as TOGAF does of delivering a capability is odd.

Surely what businesses deliver are the products or results of using a capability, not the ability itself?

 

In “A Business-Oriented Foundation for Service Orientation”, 2006, Ulrich Homann defined capability thus.

“A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”

Definitions above suggest a business may indeed possess a capability – in the sense of the ability to achieve some aim.

But to speak of exchanging a capability is odd.

Surely what businesses exchange are the products or results of using a capability, not the ability itself?

 

The Business Architecture Guild’s BIZBOK glossary defines capability as Homann did.                                                                                                                                          

But the words “particular” and specific” are redundant in the glossary entry for capability.

Since the glossary separately defines a “capability instance” as a “specific realization”.                                                                                                                                          

 

In DoDAF, an aim is called “a desired effect” meaning “the result, outcome, or consequence of an action”.

It defines “capability” as “the ability to achieve a desired effect under specified standards and conditions through combinations of ways and means to perform a set of activities.”

But the singular associations (1 capability to 1 ability to 1 desired effect) are needless constraints.

If capabilities/abilities are composable and decomposable, then desired effects and activities must also be composable and decomposable.

Better, NATO’s Architecture Framework defines “capability” as “the abilities required for conducting operations in order to reach desired effects”.

Note here that 1 capability relates to several abilities and several desired effects.

 

Abstract capabilities as functions

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

To begin with, a capability can be named abstractly as activities to be performed or aims to be met.

E.g. MoDAF speaks of an abstract capability as akin to a goal such as “Manned Interplanetary Travel”.

And TOGAF defines an abstract capability independently of people, processes, data and technologies – much as a business function might be defined.

 

Concrete capabilities as systems or managed entities

DoDAF speaks of a capability as something that "occupies space and time".

A concrete capability is a physical business system in operation, using a set of resources.

It embraces everything required to perform required activities – knowledge, skills, energy, materials and other resources.

The resources may include people, machines, computers, databases, networks, and procedures that actors must follow.

Might they even include people trained to find whatever resources they need to achieve ad hoc aims?

 

Some speak of a capability as though it acts – as though it is the actors or resources that have the ability to act.

I read somewhere that: “a capability is composed of some resources interacting in repeatable value streams to meet some given purpose(s).”

But that is to equate a business capability with a business system – a system of actors performing activities to meet aims.

Or possibly a managed entity - an organisation unit or project.

 

Mapping capabilities to aims and other things

EA frameworks typically define a business architecture in terms of actors in roles, activities in processes and aims or goals.

This table shows the capability concept can be attached to those and other entities in the TOGAF business architecture set.

 

Business architecture in TOGAF 9.2

The business needs

“Business operations

The Capability to play each

The Capability to perform each

Role

Process or Service

“factors that motivate the enterprise

The Capability to meet each

Goal

“how the enterprise is organizationally structured and

The Capability to manage each

Organization unit

“what functional capabilities the enterprise has”

The Capability to realise each

Business function

 

So, here is a hypothesis about business architecture:

Everything classified as the name of a capability might alternatively be classified as the name of a role, process, service, goal, organisation unit or business function.

 

Whether the hypothesis is accurate or not, the concept called "capability" is a chameleon.

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

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

But makes it difficult to pin down its meaning and its relationships to other architectural entities.

So, introducing it into a meta model of TOGAF’s business architecture entities is highly problematic.

Function hierarchies mapped to capability maps

This section is about the kind of abstract capability that appears in hierarchical capability maps of the kind you can easily find on the internet.

Other interpretations of the capability concept are not addressed below.

 

What delivers value to consumers? Is it activities or actors? It is both.

The actors must have the required abilities and use them to perform the required activities.

 

Consider, “sales”, “disaster recovery”, “wheel replacement”, “win a battle”, or “rescue friendly forces from enemy territory”.

You might find any of those used as the name of a function or capability.

Whereas functions group the activities required of an organisation, capabilities group the abilities required of an organisation.

 

But surely every unique activity requires a unique ability? So, every function needs a unique capability?

What is the evidence? In common practice:

·       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 purposes and effects.

 

In 10 years of asking, nobody has shown me a capability map that differs in appearance or use from a function hierarchy.

In practical examples, the two diagrams look the same and have the same possible uses.

 

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.

Functions/capabilities mapped to other things

Some if not all function-oriented artefacts in the table below could 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 <participate in>

Processes

Value stream diagram, 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 very challenging to include both 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.

An aside on value streams as end-to-end processes

For decades, EA and BA practices have included drawing cross-organizational business architecture artifacts such as:

·       a functional decomposition diagram – a logical organisation structure

·       a data entity/business function matrix – which shows which data is created and used by which functions

·       a value chain diagram – which identifies the core and support functions of a business at the highest level of definition (after Porter, 1985)

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

 

A process is a process is a process, be it called a value stream, business scenario, use case, epic or user story.         

However, different conventions have evolved for documenting processes at different levels of composition and degrees of precision.

 

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 of value streams in different sources researched for this paper.

 

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 can’t always tell from its name whether a thing is a transient behavior/process or a persistent structure/function.

The first three examples in the table above sound like a function rather than a value stream, since they don’t suggest an end-to-end flow.

 

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

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 result(s) of value to some actor or future process.

The results or required effects of a process can be outputs and/or system state changes.

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

·       Aims: how results are used to meet a purpose or add some value.

·       Roles: actors engaged in the value stream/stage.

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

·       Internal view: internal activities, which may be performed in sequence or in parallel.

 

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

In conclusion, some things to remember

For more on business architecture in general, read https://bit.ly/2DRbCC0.

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

For more on the general system theory that underpins these matters, explore https://bit.ly/2yXGImr.

 

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.