Business Architecture in TOGAF (capabilities, value streams etc.)

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 15/10/2017 22:23

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.

 

TOGF includes more terms, concepts and artefacts for business architecture than any other domain.

And its artefacts presume knowledge of structured business analysis.

The Open Group has separately published a draft or preliminary standard for Business Architecture (called O-BA here).

As is common, different standard authors tend to use their own vocabularies to express the same concepts.

 

This paper discusses where and how the capability and value stream concepts appear in TOGAF.

It points to a few issues that bedevil documenting a business architecture model (inside or outside of TOGAF).

E.g. the morphing of capabilities into organisation units when it comes to the assignment of goals, managers and resources.

Contents

Business architecture in O-BA and TOGAF. 1

Using TOGAF standard artefact types to describe a business structure. 2

Mapping the TOGAF standard to core O-BA concepts. 4

Capabilities. 5

Value streams. 7

Competencies. 9

Conclusions and remarks. 11

Appendix: O-BA core concepts. 11

 

Business architecture in O-BA and TOGAF

EA is about extending, optimising, integrating and standardising business roles and processes that create and use business data.

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

The preliminary O-BA standard speaks of a taking a holistic view comprising three domains:

 

Strategy

Where O-BA speaks of the business intent, vision and priorities, TOGAF says: "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."

 

Business structure

Where O-BA speaks of the capability map, the organisation structure and value streams, TOGAF speaks of functional decomposition, organisation decomposition and business scenarios. It says: "A knowledge of the business architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.)."

 

Operational context

Where O-BA speaks of business outcome, enabling means, resource, input, implication, TOGAF speaks of goals, objectives, requirements, service contracts, logical and physical system components, prioritisation, transition planning, implementation and governance of system change.

 

This focus in this paper is on the business structure domain.

 

TOGAF includes more guidance for business structure modelling that any other architecture domain.

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

And more artefacts for business architecture than for any other architecture domain.

It suggests it users consider the following techniques.

 

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

 

Business process modelling (cf. value stream modelling)

"Process Flow diagrams show sequential flow of control between activities and may utilize swim lane techniques to represent ownership and realization of process steps."

Structured analysis (cf. capability modelling and more)

This is the basis of the business architecture artefacts in the TOGAF standard.

 

This focus in this paper is on structured analysis.

Using TOGAF standard artefact types to describe a business structure

There seems to a world-wide failure to teach the basics of structured analysis on which TOGAF's business architecture is based.

It takes 30 to 45 minutes in a training course to explain and illustrate structured analysis, only core ideas can be outlined here.

 

Structured analysis defines at least one logical business function structure, independent of the organisation/management structure.

This function structure relates functions by composition and decomposition in a hierarchical “tree”.

Any function (at any level you choose) can be related in a matrix or diagram artefact to other architectural entities.

 

Functions <are related to>

Other architectural entities

TOGAF artefact

Functions <provide>

Services (the external view of a function)

Business service/function catalogue

Functions <are composed of>

Functions/activities (the internal view of a function)

Functional decomposition

Functions <serve>

Functions/external Roles (with information/material flows)

Node connectivity diagram

Functions <trigger>

Functions (in sequential processes)

Process flow diagram

Functions <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix

Functions <create and use>

Data entities

Data entity/function matrix

Functions <are served by>

Applications

Application/function matrix

 

“The level and rigor of decomposition needed varies from enterprise to enterprise” TOGAF

Business function/capability decomposition is usually taken down to a 3rd or 4th level; it is difficult but not impossible to maintain more detail than that.

Business process modelling is often done only for particular processes of interest, and may be done at a lower (5th or 6th) level of decomposition.

The two (structure and behaviour) models can in theory be brought into perfect correspondence, joined at the atomic activity level.

In practice they rarely are, but you must be able to map every activity in a process model to a bottom-level function in the functional decomposition, else the latter is incomplete.

 

How to form a function?

A function is a cohesive group or cluster of lower level or elementary functions.

The cohesion criteria for clustering functions are typically:

·         sharing the same or related goals

·         producing the same or related products/services

·         performing the same or related activities.

 

The common practice is to define one primary function hierarchy – down to 3 or 4 levels.

You can build other logical hierarchies – especially where different executives set different goals for an enterprise.

Structured analysis of this kind stretches back to the 1980s if not before.

One enterprise has nine hierarchies – a “forest” of function tree structures – which correspond to different executive-level perspectives.

 

You can build a free-standing function by selecting functions (from any given hierarchy) with reference to a different goal.

You can cluster functions on any criterion – say data created or experience required (see the discussion of “competencies” below).

 

When and where to document the features of a function?

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

In a simple case, one function relates to one organisation unit (as in a “functional organisation”), so you might say they 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 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.)

Mapping the TOGAF standard to core O-BA concepts

At first sight, the Business Capability / Value Stream distinction in O-BA part 1 is exactly the same as the Business Function / Process distinction in the framework.

But the “Capability” concept seems ambiguous in O-BA, and part 2 seems to contradict part 1.

 

O-BA term

O-BA definition

Mappable to this term in the TOGAF standard

Business Capability

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

A capability is a fundamental and unique contribution to the business mission, independent of any kind of organization.

In some communities it is called a business function.”

A business Function as in a Functional decomposition.

See discussion below.

Organisation

A social unit of people that is structured and managed to meet a need or to pursue collective goals.

An Organisation unit as in an Organisation decomposition.

Value Stream

“A sequence of activities an enterprise undertakes to deliver on a customer request. 

More broadly, the sequence of activities required to design, produce, and deliver a good or service to a customer, and it includes the dual flows of information and material.”

A Scenario or Process.

Scenarios usually are modelled at a high level.

Processes can be modelled at any level of granularity.

Business Service

“The valued attribute of a capability as perceived by the stakeholder.”

A definition that differs significantly from other standards.

Business Structure

“A set of business capabilities and their inter-relationships that contribute to accomplishing a higher-level goal.”

This is presented as composite of a capability map, organisation structure and value streams.

The TOGAF standard includes a Node Connectivity Diagram which can be used to show relationships between capabilities or organisation units.

Competence

“An organizational mechanism composed of related capabilities, commitments, knowledge, and skills that enable an organization to accomplish its strategic intent and objectives.

Business competencies embrace and communicate the holistic view.

Competence descriptions express the strategic need comparable with the concepts of key mechanism, core competence, and critical success factors.

Competence descriptions also define the required quality levels of competence maturity and capabilities.

It resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts.

Customer experience is a nice example.

The difference between competence and capability is the way in which capabilities are performed.

Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.”

This could well be a Function. Yes, really!

See discussion below.

Capabilities

Many sources (including O-BA, NAF and VDML) define capability loosely.

For example, VDML defines capability

·         as yielding a desired value, and accessible via a prescribed interface, which could be a single service or process

·         as a building block shown in a “capability map”.

And goes on to say: “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

Which is surprising to those aware of structured analysis principles and TOGAF business architecture artifacts.

 

Structured analysis can be seen in the preliminary O-BA standard, but not clearly.

O-BA part 1 presents the Capability / Value Stream distinction the same as the Function / Process distinction in the TOGAF standard.

Just like functions, capabilities are modelled in a top-down decomposition structure, independent of the organisation structure.

Just like processes, value streams relate capabilities by sequential dependencies.

 

Curiously, although a capability corresponds to a function in TOGAF, it is more than that in O-BA.

“It is composed of people, process, technology, management, and information and informed by business strategy how that best contributes to the ambition of the organization”.

That sounds like an organisation unit rather than a capability – a concrete system realisation rather than an abstract system description.

 

Moreover, part 2 defines the attributes of a capability as though it were a single value stream or process.

“Capabilities are described with the following aspects: name, description, purpose, input, techniques, and outcome.

Each Business Architecture capability is elaborated and described with the following aspects:

1.      Name – A stateless expression of a capacity an organization or individual possesses.

2.      Description – The transformation process the capability accomplishes.

3.      Purpose – The value the capability provides for receiving stakeholders.

4.      Input – The specific input that is transformed by the capability.” 

 

This definition is questionable.

1.      capacity” - that typically means a throughput rate, “ability” might be better.

2.      process” - that is an odd word here – suggests a value stream rather than a capability.

3.      value” - if that is the value of a material/information flow, that surely that is the same as a “Business Service” in O-BA?

4.      specific input” – does that mean one input instance, as in a process performance? Or one input type, implying a single process capability?

 

Ways of modelling capabilities

O-BA defines at least one logical capability map, independent of the organisation/management structure.

This map relates capabilities by composition and decomposition in a hierarchical “tree” structure.

O-BA includes two other views of capabilities, which are named in the right hand column of the table below.

 

Capabilities <are related  to>

Other architectural entities

TOGAF artefact

O-BA ways of modelling

Capabilities <provide>

Services (the external view of a capability)

Business service/function catalogue

 

Capabilities <are composed of>

Capabilities/activities (the internal view of a capability)

Functional decomposition

Capability map/hierarchy

Capabilities <serve>

Capabilities/external Roles (with information/material flows)

Node connectivity diagram

Dependency network diagram

Capabilities <trigger>

Capabilities (in sequential processes)

Process flow diagram

Value stream

Capabilities <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix

 

Capabilities <create and use>

Data entities

Data entity/function matrix

 

Capabilities <are served by>

Applications

Application/function matrix

 

 

If the O-BA standard is to be aligned with TOGAF, then attention should be given to the “structured analysis” concepts that underpin TOGAF’s content framework.

For example, consider the following notes and questions arising.

 

How to form a capability?

A capability is a cohesive group or cluster of lower level or elementary capabilities.

The criteria for clustering capabilities are typically:

·         sharing the same or related goals

·         producing the same or related products/services

·         performing the same or related activities.

 

The common practice is to define one primary capability map – down to 3 or 4 levels.

Does O-BA say you can draw different maps – especially where different executives set different goals for an enterprise?

 

When and where to document the features of a capability?

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

In defining the concept of “capability”, authors often include concepts associated with their implementation.

In a simple case, one capability relates to one organisation unit (as in a “functional organisation”), so you might say they 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 capabilities and organisation units.

O-BA expects enterprise architects to relate purposes or goals to a capability.

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

Instead, you could take a service-oriented view (as in TOGAF) and relate goals to business services.

Then presume those goals are inherited by capabilities and organisation units that provide the services.

 

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

Value streams

Capabilities can be related by various kinds of relationship.

Bottom-level capabilities – discrete activities – can be related in strictly sequential procedural flows – each activity triggering the next.

Sometimes, high-level capabilities can also be related that way.

However, high-level capabilities may comprise many discrete activities performed in parallel.

They can be related by relationships that represent a flow of materials of information from an activity in one capability to an activity in another

Or by more abstract dependency relationships - which abstract from the sequential dependencies and flows at lower levels.

 

Value streams as behavioral models

The value stream concept is usually defined along these lines:

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

·         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 value stream implies a step-by-step process.

It usually involves more than one participant (function, organisation unit, role or building block), which may be shown in swim lanes.

Value stream analysis involves measuring process steps, and optimising the process in the light of those measurements.

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

 

Value networks as structural models

The preliminary O-BA standard includes a footnote suggest it may in future include value networks.

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

The building blocks can be capabilities, business functions, organisation units or roles.

The relationships are typically information and material flows – consumed and produced via services.

The normal and natural presumption is that each flow provides a value to its receiver.

 

It is sometimes possible to carve an end-to-end flow between building blocks out of a network structure.

Sometimes, such an end-to-end flow is drawn and discussed as a value stream - even though the building blocks work in parallel rather than sequentially.

There are sequences – but at a lower level - between discrete activities performed within the parallel-working building blocks.

 

Aside: value chain diagrams as high-level structural models with a hint of behavioral flow

The value chain concept is usually expressed in a very high level model:

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

 

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

It shows a first level functional decomposition – and adds to it a hint of an end-to-end value stream.

TOGAF’s “more formal Functional Decomposition diagram” represents a logical organization structure built over the top of bottom-level “elementary” business activities.

The framework models value streams separately – in scenarios or processes.

Competencies

You can build a free-standing capability by selecting capabilities from a given capability map with reference to a different or new goal.

You may cluster capabilities on any criterion you choose – say data created or experience required.

Clustering by data is a way to identify where capabilities can be supported by the same application or application family

However, the result of clustering capabilities on any chosen criteria is not necessarily well described as a capability.

 

O-BA defines a competence by clustering of capabilities in a given hierarchy that are related in some way.

OK, so how does O-BA differentiate a competence from a capability?

 

 “It [competence] resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts.”

This doesn’t differentiate a competence from a capability.

Every capability is more than the sum of its parts; every capability depends on interactions between its elements.

 

“Customer experience is a nice example.”

This doesn’t clearly differentiate a competence from a capability.

Presumably the competence is delivering a good (rather than bad) customer experience.

Directors might declare this to be a measurable goal and required capability of their business.

E.g. Training providers usually measure customer experience by collecting information flows from them, on comment forms.

 

“The difference between competence and capability is the way in which capabilities are performed.”

This sounds like how services/products are delivered rather than what.

The how is definable in role definitions that declare what activities are done, and how.

Role definitions can include activities like showing good manners, smiling and chatting to customers.

Again, success may be measured by collecting customer feedback and/or winning repeat business.

 

“Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.”

Every non-elementary capability combines lower level capabilities.

Every human capability and role may be defined in terms of experience required.

That leaves us with “culture” as a factor that distinguishes a competence from a capability.

If so, then like every other aspect of business operations, it ought to be definable and measurable.

Else, it cannot be agreed whether it exists in a baseline capability or is realised in a new capability.

 

The very length of the O-BA “competence” definition suggests it is not easy to distinguish a competence from a capability.

Perhaps the distinction is more subjective than objective. Or can it be drawn in a simpler way?

 

Are competencies about the qualities of capabilities? (just an idea)

Many define a capability as an ability.

That is a loose concept; it could embrace any of what is done or delivered, how it is done or delivered, or knowledge, skills and resources needed.

Perhaps a capability is about what is delivered? definable in terms of material/information flow contents?

Perhaps a competency is about how well it is delivered? definable in terms of qualities such as speed, low defect rate, and high customer satisfaction?

 

Hmm… every capability should be measurable in terms of such competencies.

And grouping capabilities by any particular “ability” is not necessarily helpful.

E.g. you could cluster capabilities that require human actors with the ability to, say, speak Spanish.

That would group capabilities under heading that seems more a competence than a capability - or is it a skill?

And if a goal of the business is to do more business in Spain, then it might it be capability as well?

 

Aside on people and business change

Some business architects speak of taking a people-first or people-centric view of a business.

In defining a new or transformed enterprise, enterprise architects always start from the concerns of sponsors and stakeholders.

However, they usually leave thinking about the human actors (needed to play the roles) to others.

A natural sequence is to define goals/services, value streams and capabilities, roles and organisation units, and only then, the human actors.

The required human abilities should be defined in role definitions before assigning, hiring or recruiting the human actors.

Where roles are changed, enterprise architects usually work in parallel with business managers, HR and some kind of “business change” team.

Conclusions and remarks

The preliminary O-BA standard speaks of a holistic view comprising three domains:

·         Strategy (intent, vision, priorities)

·         Business structure (capability map, organisation structure and value streams)

·         Operational context (business outcome, enabling means, resource, input, implication).

 

This paper focuses on the business structure domain.

It discusses where the capability and value stream concepts appear in TOGAF.

It points to a few issues that bedevil documenting a business architecture model (inside or outside of TOGAF).

E.g. the morphing of capabilities into organisation units when it comes to the assignment of goals, managers and resources.

And the impossibility of relating goals to everything they could be related to.

 

The O-BA material on the business structure domain could probably be rewritten with reference to TOGAF business architecture terms and artefacts.

If people tell you the business structure concepts in O-BA are different - then make them prove it by example!

Perhaps the operational context domain material could be rewritten to the same end?

 

You may want to read also “The TOGAF standard mapped to Capabilities in 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.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

Appendix: O-BA core concepts

Note that the definitions in the two parts of the preliminary standard are not exactly the same.

 

2.1 Approach

A flow (as in work flow) of steps or phases that show how the goal accomplishment will be addressed in order to produce a defined deliverable and/or result.

2.2 Business

Anything that is related to organizing for exchange of products and services by business, governmental, or institutional organizations.

2.3 Business Architecture

The formalized description of how an organization uses its essential competencies for realizing its strategic intent and objectives.

2.4 Business Capability

A particular ability or capacity that a business may possess or exchange to achieve a specific purpose. Note: A capability is a fundamental and unique contribution to the business mission, independent of any kind of organization. In some communities it is called a business function.

2.5 Business Service

The valued attribute of a capability as perceived by the stakeholder.

2.6 Business Structure

A set of business capabilities and their inter-relationships that contribute to accomplishing a higher-level goal.

2.7 Common Language

A set of definitions of concepts that are essential to the Business Architecture practice. Note: In order to facilitate integration of the common language with the way of modeling and way of working, it is preferably controlled to a certain extent. Control in this standard is conducted through clearly stating to which concepts certain terms refer. The essential concepts can be found in Appendix E. By adhering to these concepts the practice enables consistent description of a holistic view, integrated analysis of operational implications, and review of validity of the structure and operations against the assumed business strategy.

2.8 Competence

An organizational mechanism composed of related capabilities, commitments, knowledge, and skills that enable an organization to accomplish its strategic intent and objectives. Business competencies embrace and communicate the holistic view. Competence descriptions express the strategic need comparable with the concepts of key mechanism, core competence, and critical success factors. Competence descriptions also define the required quality levels of competence maturity and capabilities. It resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts. Customer experience is a nice example. The difference between competence and capability is the way in which capabilities are performed. Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.

2.9 Discipline

The framework, method, and approaches that constitute a complete integrated set for practicing in the field of a profession.

2.10 Framework

A set of linked ways of thinking or insights that serve as the guiding principles for the structuring of a method and associated approaches.

2.11 Holistic View

The complete set of descriptions of the business strategy, the business structure, and the implications of the strategy and structure for operations. Note: The business strategy includes an external vision, the strategic intent, and the strategic priorities. It provides insights reckoning with the horizontal and vertical dependencies between the strategic, structural, and operational level as well as between business domains.

2.12 Organization

A social unit of people that is structured and managed to meet a need or to pursue collective goals. Note: Organizations are open systems – they affect and are affected by their environment.

2.13 Resource

A human, financial, physical, or knowledge factor that provides an organization the means to perform its business processes.

2.14 Structure

The aggregate of elements of an entity in their relationships to each other.

2.15 Value Stream

A sequence of activities an enterprise undertakes to deliver on a customer request. More broadly, the sequence of activities required to design, produce, and deliver a good or service to a customer, and it includes the dual flows of information and material.

2.16 View

A representation of a whole system from the perspective of a related set of concerns.

2.17 Viewpoint

A pattern or template from which to construct individual views. A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view.