The science of business architecture

What TOGAF, DoDAF, BIZBOK and BABOK don’t tell you

https://lnkd.in/gBugTAX

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 28/08/2019 19:01

ArchiMate®, The Open Group®, and TOGAF®, are trademarks of The Open Group.

                                                                                                                                          

There is some science about what can be documented of a business architecture.

Yet many in the enterprise/business architecture and TOGAF communities seem unaware of it.

 

“Very good analysis thx!” “A very detailed and useful work.”

 

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

And the aim here is not to promote any particular approach or diagram style.

The aim is to explain and relate the core concepts that underpin many business architecture approaches – in consistent and coherent way.

 

“I always enjoy [your material], always coherent and consistent to an overarching conceptual framework.”

 

Generally, business architecture creates a model of a human activity system – be it observed or envisaged.

The reference point here is general system theory, which abstracts concepts and principles from how systems are modelled in different scientific domains.

So, the general business architecture concepts discussed below depend in no way on IT.

They are the basis of the “Service-Oriented Structured Analysis” approach to modelling a business in TOGAF versions 8 and 9.

This paper updates some of the research done in 2008 for the British Computer Society’s professional certificates in enterprise and solution architecture.

And it is a companion to The practice of business architecture on the business architect role and concepts used in a variety of standards and frameworks.

Contents

Some ingredients of business architecture. 1

Hierarchical catalogs of things. 1

Capability hierarchies that correspond to function hierarchies. 1

What else to know about function/capability hierarchies?. 1

Capabilities that correspond to services: a case study. 1

Where else does Capability fit?. 1

Relating things to each other – in matrices or diagrams. 1

“Service-Oriented Structured Analysis”. 1

External views. 1

Some other realisation relationships. 1

Some other assignments of behaviors to structures. 1

On processes and value streams. 1

In conclusion, some things to remember 1

FOOTNOTES. 1

Footnote 1: On “capability” in other business architecture sources. 1

Footnote 2: On the science of hierarchical structures. 1

Footnote 3: Do we model services or flows? Notes for ArchiMate diagram drawers. 1

Footnote 4: On systems in general 1

 

Some ingredients of business architecture

Four millennia have passed since businesses stopped relying on human speech and memory.

Since the dawn of civilization, businesses have depended on recording and sharing business data.

 

A mere four decades have passed since approaches recognisable as the ancestors of EA emerged.

For example, Walker’s Business System Planning, and Martin’s Enterprise Engineering.

These approaches start with strategic analysis of business processes that create and use business data.

They look to make cross-organisational improvements, integrations and innovations.

In 2006, the popular book "EA as Strategy" urged enterprises to define their business operating model in terms of core business processes and information.

 

EA can’t ignore IT, since modern business roles and processes depend on IT to store and transmit business data.

However, mainstream EA remains focused on supporting and enabling business roles and processes.

Business architects model "regular, repeatable or determinate" behaviors, which can be realised and tested in the real world.

They are concerned with the services provided by a business.

And with how those services are delivered by processes that refer to and advance the state of the business.

 

The services are behaviors that deliver results of value to actors with a stake in the business.

E.g. Take out a loan. Complete a tax return. Direct an airplane take off. Conduct a research project.

The role of a business architect can include the identification of service improvements and innovations.

 

The processes are sequences of activities that a business must perform to complete services.
The role of a business architect can include process improvements and innovations.

 

The state of a business is represented in information found in the data structures of messages and memories.

The role of a business architect can include improvements and innovations in data capture and use.

 

This paper focuses on modelling business activities rather than business data.

Remember, you don’t have to model every business activity that could possibly be documented.

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

 

Enterprise and business architects are said to regard the enterprise as “a system of systems”.

In general system theory, a system may be defined as collection of actors performing some activities to achieve some aims.

In business architecture, actors in roles and organisation units perform activities in processes to meet the aims or goals of the business.

This table shows how an architect may approach the description of a business, or of a required business change.

 

A simple approach

A simple illustration

1)     What are the goals of the business?

Attract more customers to the hotel

2)     What services will the business offer/provide to achieve those goals?

Valet parking of a car

3)     What processes must be performed to deliver those services?

Park and retrieve a customer’s car

4)     What roles are needed to perform the activities in the processes? (And how many actors in each role?)

Valet (3)

5)     What organisation structure is needed to manage the actors?

Front desk management

6)     What are the locations where the processes are performed?

Hotel entrance and car parks

 

You can find corresponding concepts in many standards and sources on business architecture.

E.g. The SFIA standard’s definition of the business architect role refers to goals, functions, services, processes, information, roles and organisation.

And this table classifies core concepts in the meta models of business architecture you can find in TOGAF and ArchiMate, adding interfaces.

 

 

Behavioral view of activities

Structural view of activities

Consumer view

Business Services

Business Interfaces

 

Implementation view

Processes

Functions & Roles

Logical Components

Organisation Units & Actors

Physical Components

 

Sources refer also to value streams and capabilities.

As will be explained later:

·       Value streams are end-to-end business processes

·       Capabilities are the abilities of an organisation.

Some treat functions and capabilities as interchangeable concepts.

But it isn’t that simple, as explained below.

 

Watch your language!

To be regarded as a profession, business architecture needs 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 there is terminology torture out there, and that these three vocabularies don't always coincide:

·       how business people speak of business architecture concepts

·       how business architecture concepts are named in a business architecture meta model (of the kind found in TOGAF and DoDAF)

·       how business architecture concepts are named in diagrammatic modelling languages (like BPMN or ArchiMate).

 

So, you cannot assume business people will use terms as you find them in a domain-specific vocabulary for business architecture.

Hierarchical catalogs of things

Structured Analysis involves cataloguing business architecture entities under hierarchical structures.

It dates back to the early 1990s, if not before, and was presumed knowledge in TOGAF version 8.

One approach is tabulated in the section called "Business Architecture process in TOGAF 8 and 9" in The practice of business architecture.

 

Catalogs

Most EA frameworks expect business architects to catalog the ingredients of business architecture, for example:

·       Goals: each being a motivation or target, ideally measurable and timebound, for business activity.

·       Processes: each arranging activities sequentially so as to end in the production of result(s) or desired effect(s) that contribute to goal(s).

·       Organisation units: each being a managed group of actors and activities (it might be called a physical business component).

·       Locations: each being a place, area or address where business activities are carried out.

 

There is no fixed level of granularity; the concepts are applicable to modelling a business or component building block of any size.

So, to understand and manage the complexity of a whole enterprise, architects usually organise the items in a catalog under a hierarchical structure.

This involves using the basic systems analysis and design techniques of hierarchical decomposition and composition.

·       Decomposition: dividing larger/longer things into smaller/shorter things

·       Composition: grouping smaller/shorter things into larger/longer things.

 

Hierarchies

The real world is network of interrelated things – including goals, processes and organisation units .

We impose hierarchical structures on those things to help us understand and manage them.

In a hierarchical structure, every node (apart from the top one) has one parent/owner node.

E.g. each organisation unit has one wider parent/owner organisation unit.

 

EA regards a business, holistically, as a system of systems designed to meet business goals.

The whole is composed of subsystems (aka building blocks) that perform behaviors (perform processes and deliver services to each other).

Further structural decomposition reveals successively smaller subsystems.

 

The whole system may be required to perform several end-to-end processes (aka value streams).

Each activity in a high-level process can in turn be elaborated as a process composed of shorter activities.

Further behavioral decomposition reveals successively shorter behaviors

 

Most EA frameworks feature hierarchical catalogs such as these.

 

Category of system element

Hierarchy of business architecture entities

 

Motivations

Goal/objective hierarchy

a cascade of goals, as in a strategy map or a balanced score card.

Physical active structure

Organization hierarchy

dividing people and resources for management purposes.

Logical active structure

Function and/or capability hierarchy

dividing larger/wider functions or capabilities into smaller/narrower functions or capabilities.

Behaviors

Process hierarchies

elaborating each activity in a long-running process (or value stream) as a shorter process.

 

Beware that how business architecture entities relate to each other is complicated by the fact that each entity can be hierarchically composed and decomposed.

 

Numbers constrain what is practical

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

For the depth, there are some numeric rules of thumb. 

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 in the table explain why few architects can maintain a hierarchy more than 3 or 4 levels deep.

 

Perhaps the only practical way to maintain a deep hierarchy is to make it self-populating.

To distribute the responsibility for adding, modifying and deleting nodes to people around the enterprise.

E.g. An organisation hierarchy can be maintained if every employee maintains the name of their manager in that hierarchy.

And a goal hierarchy can be maintained every manager maintains the list of goals given to each person they manage.

Capability hierarchies that correspond to function hierarchies

Some treat functions and capabilities as interchangeable concepts.

This section compares functional decomposition diagrams with business capability maps.

Other ways of looking at capabilities are explored in later sections.

 

In natural language, the term function is used with various meanings.

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

E.g. the functions of a national government are to maintain order and to provide national security, economic security, public services and economic assistance.

In the UML standard, a function is a process that transforms input into output.

E.g. an algorithm to calculate the area of a circle from its radius.

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

The discussion here is of business functions, which each group some activities of an organisation.

 

In natural language, a capability is the ability to do or achieve something.

The term usually refers to a human ability and activity.

E.g. You might either possess or desire the capability to play chess.

The discussion here is of business capabilities of the kind named in capability maps.

In business architecture: “Capabilities are the abilities of an organisation”.

A business uses such capabilities to deliver what are variously called desired effects, services, courses of action or outcomes

 

The table below compares function and capability hierarchies.

Remember that other ways of looking at capabilities are explored in later sections.

 

A function hierarchy - structures the activities of an organisation

A capability hierarchy - structures the abilities of an organisation

What is a (business) function?

A business function is a logical division or component of a business.

It is a group of business activities that are cohesive in some way.

It may group activities needed to achieve a goal or closely-related goals.

Or group activities that need related abilities or other resources.

 

Examples may include “Sales”, “Procurement”, “Disaster recovery”.

Also “Control of the air space over a territory” and aspirations like “Manned interplanetary travel”.

What is a (business) capability?

A capability is the ability to complete some activity(s) or achieve some aim(s).

It is usually named in terms of those activities or aims.

A business capability is a logical division of the total abilities of a business.

It groups abilities needed to achieve a goal or closely-related goals.

 

Examples may include “Sales”, “Procurement”, “Disaster recovery”.

Also “Control of the air space over a territory” and aspirations like “Manned interplanetary travel”.

When to extend an existing function or create a new function?

When the business identifies it has a new goal, or must offer a new service.

Or perhaps it envisages a new process or project.

Or it identities several of the above.

When to extend an existing capability or create a new capability?

When the business identifies it has a new goal, or must offer a new service.

Or perhaps it envisages a new process or project.

Or it identities several of the above.

What is a function hierarchy?

Functions are abstractions – independent of physical resources.

An organisation structure imposes a hierarchical management structure over the actors of a business.

A functional decomposition imposes a more abstract hierarchical structure over the activities of a business.

It groups atomic activities, and then narrower, lower-level, functions under wider, higher-level, functions.

Ideally, the result is a normalised structure; meaning no atomic activity appears under more than one bottom-level function in the hierarchy.

What is a (hierarchical) capability map?                                                                 

In most modern sources, capabilities are abstractions – independent of physical resources.

An organisation structure imposes a hierarchical management structure over the actors of a business.

A capability map imposes a more abstract hierarchical structure over the abilities of a business.

It groups narrower, lower-level, capabilities under wider, higher-level, capabilities.

Why define a function hierarchy?

To define the scope and logical structure of a business

in a way that is more stable than, and independent of, the organisation/management structure.

To assist in discussion of business scope and change.

To group and classify other EA/BA entities and resources.

Why define a capability map?

To define the scope and logical structure of a business

in a way that is more stable than, and independent of, the organisation/management structure

To assist in discussion of business scope and change.

To group and classify other EA/BA entities and resources.

How is a function hierarchy presented and used?

TOGAF 9.2 says that its Functional Decomposition Diagram:

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

Helps to quickly model [those] 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.”

How is a capability map presented and used?

A capability map can:

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

Help to quickly model those 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.

How to build a function hierarchy?

A hierarchy can be built from the top down (decomposition) or bottom up (composition).

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

Understanding this helps to explain the concept, even if you never do it.

1)     Define the organisation structure of interest down to bottom level units

2)     List the regular activities performed (or to be performed) in each unit

3)     Deduplicate that list of activities

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

5)     Cluster the groups into higher groups, and so on until you reach the top of a hierarchy.

 

You may cluster activities and functions using any cohesion criteria you choose.

E.g. cluster activities and functions that:

·        meet the same aim(s) or contribute to the same measure(s) to be reported

·        need related abilities or skills

·        create and use data in the same “bounded context” or using the same “domain-specific language”.

How to build a capability map?

A capability map can be built from the top down (decomposition) or bottom up (composition).

There is a process for composing a business capability map systematically.

Understanding this helps to explain the concept, even if you never do it.

1)     Define the organisation structure of interest down to bottom level units

2)     List the competencies/abilities that are used/needed in each unit

3)     Deduplicate that list of competencies/abilities

4)     Cluster those that meet the same aim(s) or contribute to the same measure(s) to be reported

5)     Cluster the groups into higher groups, and so on until you reach the top of a hierarchy.

 

Note that the abilities of an existing organisation are sometimes called competencies.

There is a short discussion of capability, competence and capacity later in this paper.

 

How numbers constrain what is practical

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

However, few can maintain a function hierarchy more than 3 or 4 levels deep.

And many limit decomposition to what can be shown on one page.

The high degree of abstraction means you will rarely need to change the function hierarchy when there are changes to processes documented at the level of fine-grained activities.

You’d need to work in a remarkably (impossibly?) stable business to maintain a function hierarchy to 6 or 7 levels.

How numbers constrain what is practical

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

However, few can maintain a capability map more than 3 or 4 levels deep.

And many limit decomposition to what can be shown on one page.

This high degree of abstraction means you will rarely need to change the capability map when there are changes to processes documented at the level of fine-grained activities.

 

 

The concepts are different, yet there is a logical reason why capabilities may correspond to functions.        

To perform particular activities, you must develop the corresponding abilities.

E.g. To play a game of chess, you must develop the ability to play chess.

A function groups some activities of an organisation; a capability groups some abilities of an organisation.

To perform the activities in a function, a business must develop the abilities that add up to a corresponding capability.

E.g. to perform a Procurement function, a business must develop a Procurement capability.

 

This surely explains why functional decomposition diagrams and business capability maps look the same and are used in same ways

You will find this is true in industry standards, in examples on the internet, and probably also in practices you can observe.

 

So, you might conclude the concepts of function and capability are interchangeable in a meta model of business architecture.

But no - it isn’t that simple – as explained in later sections.

 

Aside: the artifact definitions in TOGAF are variously interpretable, and several of them may be used to present a view of functions

In the table below, you might reasonably replace Function by Capability, and use the NAF view in place of the TOGAF artefact.

 

Functions <are related to> other architectural entities

Artifact mentioned in TOGAF

NAF views

Functions <provide> Services (consumer view)

Business Service/Function catalogue

Capability/services mapping

Functions <are composed of> Functions

Functional decomposition diagram

Capability taxonomy

Capability/Operational activities mapping

Functions <serve> Functions or Roles (with info/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

 

What else to know about function/capability hierarchies?

Three things you ought to know, though teachers may not discuss them.

 

Duplicate hierarchies of different elements

Successively grouping cohesive activities or abilities implies also successively grouping the cohesion factor.

And therein lies a challenge that arises in modelling system elements in hierarchical catalogs.

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

 

Suppose you align a business function or capability 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.

                                                                                                                                       

(See the footnote on the science of corresponding and clashing structures.)

 

Parallel hierarchies of the same elements – a function forest and the primary tree

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

Generally, 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.

As is the EA tradition, they settled on one function hierarchy as a basis for other analyses.

That function hierarchy was the one that most senior business leaders accepted as reasonably describing the scope of their business.

 

An EA team often uses a primary function hierarchy as a way to present the scope of the business they address.

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

They can then map functions to other things – such as data created and used.

 

(I have yet to hear the possibility of parallel capability maps being discussed.)

 

Reused and cross-cutting functions

A real-world business is a network of interrelated actors, abilities, abilities and aims.

We impose hierarchical structures on them to help us understand and manage them.

In a hierarchical structure, every node (apart from the top one) has one parent/owner node.

 

But (unless your EA tool prevents it) you can define:

·       parallel function hierarchies – a function forest

·       a function that is reused in different legs of one function hierarchy

·       a function outside of any hierarchy

·       a function that cuts across the functions in your “primary tree”.

 

E.g. Consider functions called “photocopying”, “disaster recovery” and “money laundering prevention”.

                                                   

(I don’t know how far it is agreed the same things can be said of capabilities.)

Capabilities that correspond to services: a case study

Later in this paper, there is an explanation of Service-Oriented Structured Analysis.

To be going with, these are the basic ideas:

 

Structured Analysis means defining business architecture entities (in hierarchical catalogs) and relating them (in matrices or diagrams).

This was presumed knowledge in TOGAF version 8 and 9.

 

Service-orientation means defining structural system elements, abstractly, in terms of services they offer and require.

E.g. TOGAF version 1 defined Infrastructure/Technology Components by the Platform Services they provide, in a Technical Reference Model (TRM).

And today, TOGAF also defines both Application Components and what may be called business components by the services they provide.

 

The “Service-Oriented Structured Analysis” implied by TOGAF 9’s business architecture did not feature Capabilities.

A correspondent was keen to show me where Capability fits.

Below is an edited version of our discussion.

 

A case study

Me: Architects abstract from real-world business operations.

They may abstract a logical Function hierarchy from the Organisation/management structure

They may abstract generic Services from particular Service instances discussed with stakeholders.

 

A retailer like Marks and Spencer provides Business Services to its customers.

Some Service do not leave a data trail: E.g. "Browse the stock", "Use a Fitting room", and “Park your Car for free”.

Other Services create data: E.g. "Purchase a Stock Item", "Return a Stock Item", "Purchase a Grocery Item", "Open an Account"

 

Correspondent: In such a retailer, what are the top three reasons that customers go to the Customer Care desk?

If discussion of this lets you grasp the concept of Capability, it might also give you a simple way to explain it to your students.

 

Me: Returns, faults and general queries?

 

Correspondent: A good answer. Let’s go with faults.

The customer walks up to the Customer Care Desk with a faulty item and wants the item repaired.

The business does not have a Repairs Department or any way of sending items back to the manufacturer and therefore cannot repair items.

However, the business can replace the item so the customer gets a replacement.

At the moment, the faulty goods are disposed of by the business with no compensation.

What are the obvious ways to improve the situation for the business?

 

Me: That depends on costings I have no idea about here, but options could include one or more of the following.

·       Ask the manufacturer to pay for the replacement

·       Contract with the manufacturer for repairs

·       Contract with another business for repairs

·       Establish a Repairs Function

·       Press the customer for evidence that the item was faulty when they bought it, then grudgingly offer some other option above

·       Give the customer their money back, and then perhaps some other option above.

·       Find a more reliable manufacturer.

 

Correspondent: Good, you're heading in the right direction.

Let's go with the fourth, create an in-house Repairs Function. Are we definitely agreed that is a Function?

 

Me: Before speaking of Functions let me apply the simple approach outlined above.

 

A simple business architecture approach

In this case study

1.     What are the goals of the business?

To reduce the cost of faulty items returned without compensation.

2.     What services will the business offer/provide to achieve those goals?

A new Repair Item Service.

3.     What processes must be performed to deliver those services?

A Repair Process to be defined.

4.     What roles are needed to perform the activities in the processes? (And how many actors in each role?)

To be defined.

5.     What organisation structure is needed to manage the actors?

To be defined, but the Customer Care Desk will surely be involved.

6.     What are the locations where the process is performed?

To be defined.

 

If we have a documented a function hierarchy (we don’t have to), then we should consider the impact of adding a new Repair Item Service and Process.

This is such a narrowly-focused business change that the activities in new Repair Process might be grouped under an existing Function

Or else, we might add a new, rather simple, Repairs Function.

This new logical business component will group those activities required to achieve defined Goal and deliver the new Repair Item Service.

Then, if the Repairs Function is to be realised in-house, we’ll likely create an in-house Repairs Organisation Unit.

 

Correspondent: Good. Suppose we go ahead and create the Repairs Function.

 

Me: A Function is only an abstraction; what we find or create in the world are physical resources that can perform the activities in the Function.

We create a Repairs Organisation Unit, responsible for actual repair work, and assign Actors in the Customer Care Desk to perform some administrative activities

 

Correspondent: The customer walks up to the Customer Care Desk and probably has no direct contact with the Repairs Function.

 

Me Yes, because the Repairs Function is only an abstraction, it does not do things.

Customers might well have no direct contact with an in-house Repairs Organisation Unit either.

But they surely will interact with Actors in the Customer Care Desk Organisation Unit, who perform some administrative activities in the Repairs Function.

 

Correspondent: If we outsourced repair work, chose another business to do the repairs for us, would the Function be different?

Would the customer have to know the difference?

 

Me: There is no obvious need for the customer to know the difference.

The customer requests a discrete Repair Item Service regardless of how it is implemented – regardless of the Actors used and Processes followed.

As a business director or shareholder, I'd want the implementation to appear seamless to the customer.

And would hope the implementation of the Repair Item Service can be changed without changing the name or essential nature of the Service.

 

Aside: Note that we may well go on to define a contract for the Repair Item Service.

We should define it declaratively (as an external entity sees it) rather than procedurally (as it is performed).

The contract will include some or all of entry conditions, exit conditions and quantitative measures (like duration).

So, if changing the implementation changes any of those details, then customers may indeed notice changes in some quality of the Business Service.

 

Correspondent: Yes, you're almost there [to positioning Capability].

Beforehand, the customer could only get a replacement. What has changed?

 

Me: Before, customers could request only a Replacement Service; now they can request a Repair Item Service instead.

 

Correspondent: I've never seen anyone use a Service at that level, but I guess it's possible.

                                                                                                                                          

Me: You highlight the issue that few teach the “Service-Oriented Structured Analysis” implied in TOGAF version 8 and 9.

Central to TOGAF is the presumption that every business provides Business Services.

Each is a transient unit of behavior that ends in a result of value to a customer – here, a Repair Item Service.

 

Correspondent: And do you see there is a Capability gap in the case study?

 

Me: For sure, there is what you might call a Capability gap and I might call a Service gap.

The business owner may say we need the Capability to achieve the Goal - to save money lost on faulty items.

That Capability may be defined, in an actionable but still abstract way, as a new Repair Service.

 

Correspondent: Defining Capabilities helps us to bridge another gap, the one between high-level goals and implementation, by focusing on what is actionable.

 

Me: Bridging the goal-implementation gap is the role played by Service definition in TOGAF, as this example illustrates perfectly,

You may prefer to say instead that to achieve the higher-level goal, the business must develop and a Repair Item Capability.

But exactly how do you define the term “Capability”?

 

Correspondent

Me

Capabilities are expressed in general and high-level terms

and typically realized by a combination of organization, people, processes, information, and technology.

The same is true of Services (also Goals, and Functions).

Capabilities are typically aimed at achieving some goal or delivering value by realizing an outcome.

The same is true of Services (also Processes, Functions and Roles).

Capabilities are themselves realized by core elements.

The same is true of Services (also Processes, Functions and Roles).

To denote that a set of core elements together realizes a capability, grouping can be used.

Other approaches also group the elements that realise an abstraction.

Capabilities are often used for capability-based planning, to describe their evolution over time.

Other approaches also group the element versions in each transition state.

 

You’ve defined some qualities and uses of the Capability concept without actually defining it.

However, we surely agree that “Capabilities are the abilities of an organisation”.

 

You’ve also neither distinguished Capability from other business architecture entity types, nor related Capability to them.

Which makes it very difficult to pin down where your concept fits in a meta model that includes Goals, Services and Functions.

 

In discussion of MoDAF, “Manned Interplanetary Travel” has been given as an example of a Capability.

Earlier, you posted other examples of Capabilities that could well be documented as Goals.

And complained examples of Capability on the internet and in TOGAF should be called Functions.

And here, to explain Capability, you have discussed the development of a new Business Service.

 

In your retail example, your Capability corresponds to a Goal and to a Business Service.

Which leaves us with the following question.

Suppose a TOGAF user documents the Goal (to save money lost on faulty items) and the proposed Business Service (Repair Item).

Why should they document a Capability as well? What would that add?

 

(As I write this, I am waiting for the correspondent to answer.)

Where else does Capability fit?

The footnotes list a dozen definitions that all define a Capability as an ability - of a business or other entity.

Most define it as an ability to do something - to perform one or more activities and/or achieve one or more aims.

 

Capability is a chameleon, since a business needs the ability to do anything you care to mention.

E.g. to achieve a Goal, deliver a Service, realise a Function, perform a Process, play a Role, etc.

To do any of these things, a business must develop and use the corresponding Capability.

 

Where does capability fit in TOGAF?

The table shows how the Capability concept might be attached to several business architecture entities in TOGAF.

 

Business architecture in TOGAF 9.2

A business (or its actors) must develop and use the

“Business operations

Capability to perform each

Capability to play each 

Process or Service

Role

“factors that motivate the enterprise

Capability to meet each

Goal

“how the enterprise is organizationally structured and

Capability to manage each

Organization unit

“what functional capabilities the enterprise has”

Capability to realise each

Business function

 

In modern sources (unlike in its original military sense) a Capability is supposed to be defined abstractly.

And so, it is most typically associated with one or more of a Goal, a Service and/or a Function.

You might perhaps see it as an abstract supertype of those, which is documentable as any one of them.

 

Where does capability fit in the art of business architecture?

We may use the word Capability in many discussions.

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

And in practice, the term is used freely by management consultants and enterprise architects.

So, tool vendors are encouraged to include Capability in their meta model of business architecture entities.

This enables their users to model whatever they choose as Capabilities.                                                                                                                                          

 

This flexibility leads me to this hypothesis about business architecture:

Everything classified by one modeller as the name of a capability might - alternatively - be classified by another modeller as the name of something else

It could be the name a goal, a role, a service, a process, a function or an organisation unit – for which the business must develop the corresponding capability.

 

Where does capability fit in the science of business architecture?

Including Capability as an entity in business architecture meta model is problematic.

The flexibility of the term makes it difficult to pin down its meaning and its relationships to other architectural entities.

In meta model terms, perhaps…

An abstract Capability might be modelled as a very abstract supertype of other already abstract entity types, notably Goal, Service and Function.

A concrete Capability will be found in whatever resources are grouped in whatever system or subsystem realises the defined abstraction.

 

How to differentiate ability, capability, competence and capacity?

In natural language, these terms are used well-nigh interchangeably in discussion of human abilities.

E.g. You may either desire or possess the ability, capability, competence or capacity to play chess.

By contrast, in so-called “management science”, authors draw arbitrary distinctions between these words.

And different authors draw different distinctions.

 

 

Capability

Competency

Capacity

Source 1: v 1

the condition of having the capacity to do something

the improved version of capability

.

Source 1: v 2

the ability to develop and flex to meet future needs

the possession of the skills, knowledge and capacity to fulfil current needs

 

Source 2

the higher level of ability that

could be demonstrated under the right conditions

the quality or state of being functionally adequate or

having sufficient knowledge, strength and skill to deliver what is required.”

the ability that exists at present

 

Baseline business services and processes (implemented now) are inputs to EA.

Target business services and processes (to be developed) are outputs from EA.

We label these system elements the same way in the baseline and target states.

 

Curiously, two out of three sources above apply the terms competence and capacity to baseline (already used) abilities.

And apply the term capability to target (to be developed) abilities

Which is to imply abilities identified today as target capabilities, once developed, will be relabelled as baseline competencies and capacities.

 

Source 1: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.695.7600&rep=rep1&type=pdf

Source 2: https://www.businessprocessincubator.com/content/ability-capability-capacity-and-competence/

Relating things to each other – in matrices or diagrams

Structured Analysis involves defining a business architecture by:

·       cataloguing entities (e.g. goals and organisation units) under hierarchical structures

·       mapping the elements in one catalog to elements in another catalog.

 

EA/BA frameworks have long employed Structured Analysis.

E.g. see Business System Planning and BOST in The practice of business architecture.

TOGAF versions 1 to 7 were focused on IT architecture rather than EA or BA.

Eventually, TOGAF version 8 drew on the BA tradition above, and TOGAF now includes a menu of possible catalogs and matrices.

 

Relationships as cells in matrices

Bear in mind that every business architecture entity might be composed and/or decomposed.

So, when drawing a matrix, it is normal practice to map entities at about the same level of decomposition.

E.g. you might assign goals to organisation units in a matrix.

 

 

Goal

Goal

Goal

Organisation unit

x

 

 

Organisation unit

 

x

x

Organisation unit

 

x

 

                             

Relationships as lines on diagrams

Business Architecture frameworks often show diagrams in place of matrices.

E.g. You can name organisations and goals in boxes, and draw lines between them.

Bear in mind that EA is supposed to consider the enterprise as a whole.

Drawing hundreds of lines between boxes creates what some call a “shock and awe” diagram.

 

Cluster analysis      

Suppose you want to identify all the organisations units who contribute to the same goal.

Or all the goals that one organisation unit contributes to meeting.

Suppose you want to identify all the functions that create the same data.

Or all the data created by one function.

 

To do this, you can apply cluster analysis to the rows and columns of a matrix.

A matrix building tool may automate this, using what is call the “north-west corner” method.

 

The numbers constrain what is practical

It is difficult for one or two architects to maintain a matrix with more than, say, 1,000 rows and columns.

This implies the business architecture entities in an enterprise-wide matrix are at a decomposition level no lower than 3 or 4.

 

Suppose (as in TOGAF) you draw a Data Entity / Function matrix at the third level of decomposition.

It is unlikely you will get down to the level of atomic activities in work procedures.

You might get down to the level of smallish aggregates of normalised data entities – each centred on a “kernel” entity.

 

Scores of matrices could be drawn between, say, goal, service, process, role, organisation unit, function and kernel data entity.

Different EA frameworks and methods focus on different relationships.

The next section includes some examples.

“Service-Oriented Structured Analysis”

The aim here is not to promote any specific approach - only to bring more consistency and coherence to the whole.

However, what follows in this section fits what I was taught over the last four decades, and fits TOGAF.

 

Structured Analysis means defining business architecture entities (in hierarchical catalogs) and relating them (in matrices or diagrams).

This was presumed knowledge in TOGAF version 8 and 9.

 

Service-orientation means defining structural system elements, abstractly, in terms of the services they offer and require.

E.g. TOGAF version 1 defined Infrastructure/Technology Components by the Platform Services they provide, in a Technical Reference Model (TRM).

And today, TOGAF also defines both Application Components and what may be called business components by the services they provide.

 

How these two approaches work together in what may be called “Service-Oriented Structured Analysis” has never been made entirely clear in TOGAF.

But what follows is compatible with TOGAF’s Content Framework.

 

Imagine you listed all the atomic activities to be performed in the regular processes of a business.

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

It is possible to define other business architecture entities in terms of those activities.

E.g. The table below maps the definition of business architecture in TOGAF 9.2 to some of its business architecture entities – each defined in terms of activities.

 

Business architecture in TOGAF 9.2

Entities

Definable in terms of activities thus

“Business operations,

Processes

Roles

A process sequences activities that lead to a result of value (spanning one or more organisation units).

A role groups the activities that one actor is responsible for performing (in one or more processes).

“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 is accountable for the performance of a selection of activities.

“and what functional capabilities the enterprise has”

Business functions

A business function groups activities that are cohesive in some way(s).

 

The “Service-Oriented Structured Analysis” presumed in TOGAF can be illuminated with reference to the ArchiMate standard.

This table classifies core concepts in the meta models of business architecture you can find in TOGAF and ArchiMate

 

 

Behavioral view of activities

Structural view of activities

Consumer view

Business Services

Business Interfaces

 

Implementation view

Processes

Functions & Roles

Logical Components

(Process Instances)

Organisation Units & Actors

Physical Components

 

Notes

TOGAF does not feature Business Interfaces, but ArchiMate does.

ArchiMate does not distinguish (which can be either distinct or combined)

·       an abstract Interface - listing potentially accessible Services

·       a concrete Interface – in which Services can be accessed by customers/consumers.

ArchiMate’s questionable classification of Functions (under the behavioural view) leads people to confuse them with Processes.

Architects rarely document a Process Instance - except in an illustrative scenario or test case.

 

This table lists a variety of relationships that could, potentially, be documented.

 

Relationship between entities

May be construed as illustrating the general concept of

Services <may be found in> Interfaces

 

 

Assignment of behaviors to structures

Services <encapsulate> Processes

Encapsulation

Realisation

 

Interfaces <encapsulate> Structural views of activities

Encapsulation

Realisation

 

Functions <realise or provide> Services

Encapsulation

Realisation

Assignment of behaviors to structures

Organisation Units <realise or implement> Functions

 

Realisation

 

Actors <realise or implement> Roles

 

Realisation

 

Roles <perform activities in> Processes

 

 

Assignment of behaviors to structures

Processes <sequence activities assigned to> Functions

 

 

Assignment of behaviors to structures

External views

Service and interfaces are abstractions – external views of system activity – defined as consumers see them.

 

Services <may be found in> Interfaces

Business Services may be listed in a catalog, as TOGAF suggests.

And may be found in Interfaces, as ArchiMate indicates.

 

Services <encapsulate> Processes

A Service encapsulates a behavioral view of activities.

A Service is delivered by initiating at least one Process, and perhaps orchestrating others.

A Process is a sequence of activities that end in a result of value to an actor inside or outside the system of interest.

Processes <realise, complete or deliver the results of> Services.

 

Interfaces <encapsulate> Structural views of activities

Structural views of activities includes Functions, Organisation Units, Roles and Actor.

In one famous business case study (“Morning Star”) every Actor in the organisation defines their own Interface.

That is to say, they define the Services they can be asked to provide to other Actors.

More commonly, the Business Interface for an Organisation Unit may be:

·       abstract, as in a Service Level Agreement document that lists many potentially accessible Services

·       concrete, as in a “portal” that makes Services accessible to customers/consumers.

Some other realisation relationships

The term “realisation” applies to relationship between a more abstract thing and a more concrete thing

Interfaces and Services are external views, which are realised by more concrete internal views.

Functions and Roles are logical components, which are realised by more physical components, Organisation Units and Actors.

 

Functions <realise or provide> Services

One Function may provide several Services.

Ideally, each Service is assigned to one Function, though that Function may require other Services from one or more other Functions.

 

Note, a Function is an abstraction, you cannot contact it to request a Service.

Some would here replace Functions by Organisation Units.

 

Organisation Units <realise or implement> Functions

An Organisation Unit is persistent and physical active structure.

It is a managed group of Actors (who perform activities in one or more Functions and Processes).

An organisation structure imposes a hierarchical management structure over the actors of a business.

 

A functional decomposition imposes a more abstract hierarchical structure over the activities of a business.

A Function is persistent but logical active structure – a logical Organisation Unit.

E.g. “Sales”, “Wheel replacement”, or “Training”.

It is an abstract grouping of activities in one or more Processes.

It is a logical division or component of a business’s operations.

It is a group of business activities that are cohesive in some way, notably:

·       activities needed to achieve a goal or closely-related goals

·       activities that need related abilities or other resources.

 

It may be said that Organisation Units implement or realise Functions.

 

 

Function

Function

Function

Organisation unit

x

 

 

Organisation unit

 

x

x

Organisation unit

 

x

 

                                                                                              

In a special case, organisation units correspond to functions.

They correspond 1-to-1 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.

 

Actors <realise or implement> Roles

An Actor is an individual that plays one or more Roles.

A Role may be played by one or more Actors.

A Role is persistent but logical active structure – a logical Actor.

Architects are taught to model Roles.

They rarely model individual Actors other than a Role-played-by-only-one Actor, like a named Organisation Unit.

Some other assignments of behaviors to structures

The convention in ArchiMate is that behaviors are assigned to structures.

But you can express the relationship in the opposite direction.

 

Roles <define responsibilities for performance of activities in> Processes

A Role (in an Organisation Unit) may be assigned to activities in several Processes.

One Process may require Actors in several Roles (in several Organisation Units).

 

 

Role

Role

Role

Role

Process

x

 

x

 

Process

 

x

x

x

Process

 

x

 

x

 

Each row of this matrix may be drawn as diagram – with the Roles as swim lanes.

In special cases, a Role and a Process are in one-to-one correspondence.

This occurs when actors are employed to perform all the activities in 1 and only 1 process.

 

Again, a Role is an abstraction, it does not actually perform Processes.

However, it is rare here to replace Roles by named Actors – except in an illustrative scenario or test case.

 

Processes <sequence activities assigned to> Functions

A process imposes sequences on the activities required to meet some aim(s).

A functional decomposition imposes a hierarchical composition structure over the same activities.

 

One function may wholly "contain" several processes

One process (or value stream) may span several functions (that is to say, it orchestrates particular activities with those functions).

 

 

Function

Function

Function

Function

Process

x

 

x

 

Process

 

x

x

x

Process

 

x

 

x

 

Each row of this matrix may be drawn as diagram – with the Functions as swim lanes.

Again, a Function is an abstraction, it does not actually perform Processes.

Some would here replace Functions by Organisation Units or Roles.

 

In rare cases, a function is in one-to-one correspondence with a process.

That is, all the activities grouped in the function are the steps of one process.

 

Again, at the very bottom of function (structural) and process (behavioural) decomposition are the same atomic activities.

But remember, functional decomposition usually stops at level 3 or 4.

And (where it is needed) process modelling is more commonly completed at level 6 or 7.

A long-running, high-level, coarse-grained process may be defined only sketchily (e.g. in a value stream diagram).

On processes and value streams

A function and/or capability hierarchy may be useful, but is not the aim of business architecture

The aim is process improvement – by optimising, standardising, integrating and innovating in how regular business operations are carried out.

Process improvement techniques are not covered here.

What is covered is the nature of processes.

 

What is a process?

A series of actions or steps taken in order to achieve a particular end. Google dictionary.

A series of actions that you take in order to achieve a result. https://dictionary.cambridge.org/dictionary/english/process

A series of actions which are carried out in order to achieve a particular result. https://www.collinsdictionary.com/dictionary/english/process

 

In BA a process is a sequence of activities (coarse-grained or fine-grained) that end in a result of value to an actor inside or outside the system of interest.

An abstract process type (as defined by business architects or analysts) is realized in the material world as process instances in a concrete system.

It is performed by concrete actor(s) and produces concrete results of value to some actor(s).

 

A process, at any level may be defined with reference to some or all of the following

·       Entry conditions: inputs and preconditions.

·       Exit conditions: outputs and postconditions or state changes– and their value to some actor(s) and/or future process(es).

·       A procedure that constrains activities to occur in sequences with optional and/or repeated and/or parallel paths.

·       The roles of actors engaged in the process or activities within it.

                                                                                                                                                                                                                                                                                     

Process decomposition

All is recursive.

Every service (fine or coarse-grained) is definable declaratively in a service contract (with entry and exit conditions) that encapsulates the process(es) develops and useed to deliver it.

A set of a services requestable and deliverable as a set is simply a coarser-grained service.

A set of connected processes is simply a coarser-grained (longer) process.

At every level and length, a process may be named after its goal - the results (products or desired effects) of value that it produces.

 

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

A process may be documented as a value stream, business scenario, use case, epic, user story, procedure or algorithm.

(A use case or epic is a process during which actors create and/or retrieve digital data using an application’s interface.)

And when talking to business people, you may call a business service or process anything they like (say a product or value stream).

But giving different names to the same concept at different levels of granularity is problematic.

It implies fixing the level of composition/decomposition at which a model is drawn, and makes a mess of any generic meta model.

 

Numbers?

At the highest level of system definition, there are N top-level "end to-end" processes, which produce a result of value to one or more external actors.

You can define a top-level process in terms of coarse-grained activities, then decompose each activity in a lower-level process definition.

There is no rule for how many levels of process decomposition it takes to reach "atomic activities"; it might be 3, it might be 7.

It seems few maintain a complete top-to-bottom set of business process models.

 

Artifacts?

You can document a process using various kinds of artifact.

You can declare its entry and exit conditions - as in a service contract.

You can define it procedurally - as in a flow chart.

You can define it formally or informally - perhaps as in a value stream diagram or use case description.

It seems few maintain thoroughly formal process definitions above the level that is encoded in software.

.

What is a value stream?

A value stream is a sequence of activities (so, a kind of business process) characterised as in three definitions below.

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

A sequence of activities required to design, produce, and provide a specific good or service, and along with information, material. www.businessdictionary.com/definition/value-stream.html

The series of activities (the how) creating a flow of value (realizing the value [product/service]) that the customer gets. https://www.dragon1.com/terms/value-stream-definition

 'Value' is what the customer gets, like a product or a service of high quality, in a fair period of time at a fair price. https://www.dragon1.com/terms/value-stream-definition

 

In short, a value stream is an end-to-end process, often defined at a high-level of abstraction.

However, the length of that process can vary widely, from months to minutes.

The table below contains examples named in different sources researched for this paper.

 

Example value stream names

Note

Cash management. Inventory management. Environmental liabilities.

These sound like functions - don’t suggest an end-to-end flow.

Hire to retire. Procurement to disposal. Deploy to re-deploy/discard.

These sound like entity life histories - ending in the expiration of a resource.

Prospect to order. Order to cash. Procure to pay.

 

Book airplane seat (to ticket). Book holiday (to confirmation). Claim processing (to refund).

 

Open a bank account. Set up a direct debit to pay bills. Withdraw cash from the account.

The second and third are fine-grained – at a level close to application use cases.

 

Value streams can be mapped to capabilities, as processes can be mapped to roles or functions.

 

 

Capability

Capability

Capability

Capability

Value Stream

x

 

x

 

Value Stream

 

x

x

x

Value Stream

 

x

 

x

 

How a value stream is represented is a matter of choice. 

The entry and exit conditions of a value stream may be declared in a service contract.

The end-to-end flow of activities may be drawn – loosely – in a value stream diagram.

Unlike a flow chart, this diagram only lists the activities within each stage - rather than constrains their sequence under a logical control flow.

That imprecision allows some adaptability and agility when the process is decomposed and realised.

 

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.

 

The stages in a value stream diagram can be mapped to whatever capabilities (or functions) participate in the activities in that stage.

 

Related concepts

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

 

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

·       “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/functional decomposition and process flow or value stream.

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

 

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

In conclusion, some things to remember

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

And the aim here is not to promote any particular business architecture framework, approach or diagram style.

The aim is to explain and relate the core concepts that underpin many approaches – in consistent and coherent way.

 

Business architecture in TOGAF 8 and 9 were based on the concepts of what is here called “Service-Oriented Structured Analysis”.

This table classifies those core concepts.

 

 

Behavioral view of activities

Structural view of activities

Consumer view

Business Services

Business Interfaces

 

Implementation view

Processes

Functions & Roles

Logical Components

(Process Instances)

Organisation Units & Actors

Physical Components

 

Note that the TOGAF meta model does not feature Interfaces or Process Instances.

And ArchiMate classifies Functions under behavior, leading people to confuse Functions with Processes.

 

Inserting “Capability” into TOGAF has undermined understanding of its service-orientation and Structured Analysis artifacts

It has been inserted into the meta model without due regard to the concepts of Function and Service.

The result in the latest TOGAF is an unteachable conglomerate of business architecture approaches that use different vocabularies. 

 

More generally, people interpret EA meta models and repository structures in different ways.

There is naive, confused, confusing and inconsistent EA practice.

 

For more on the business architect role and concepts in a variety of role definitions and frameworks, read The practice of business architecture.

For some more detailed research, read https://bit.ly/2Kpa80F.

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

 

There follow some points to remember.

 

Granularity of system elements

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

·       “The level and rigor of decomposition needed varies from enterprise to enterprise” (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”)

·       In most practical examples, what is modelled in capability map looks no different from a function hierarchy. 

 

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.

·       In most practical examples, value streams are long-running processes.

 

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 (one-to-one)

 

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 its implementation by processes.

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

FOOTNOTES

Footnote 1: On “capability” in other business architecture sources

This section explores in some depth 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.

In business architecture: “Capabilities are the abilities of an organisation.”

 

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

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

The armed forces develop and use the ability to do such things as “control the air space over a territory”, or “rescue friendly forces from enemy territory”.

 

This table lists interpretations of capability that can be found in different EA/BA sources, which are not entirely consistent.

 

Which of the following statements do you think make sense?

Comment

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

 

OK, compatible with most definitions.

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 (BIZBOK says).

Appear incompatible with 1, see NOTE below

.

6 A capability can be delivered (TOGAF says).

7 A capability can act, can perform an activity.

Incompatible with 1 and most EA/BA thinking.

8 A capability is concrete – composed of human and technological resources that can act.

DoDAF seems to favours the concrete interpretation.

MoDAF favours the abstract reading; and TOGAF confuses the two

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

10 An example could be “Manned interplanetary travel”.

OK if a capability is attached to an abstract aim or goal.

 

With respect to 5 and 6 in the table above, what businesses exchange and deliver the products of using capabilities, rather than the abilities themselves

Once a capability (aka ability, capacity, competency) has been developed, it can be used.

Sources:

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

·        Dictionary.com: Usually, capabilities. qualities, abilities, features, etc., that can be used or developed.

 

When capabilities are used, what is delivered, provided or produced are desired effects, types of effect, services, courses of action or outcomes

Sources:

·       DoDAF and JCIDS: The ability to achieve a desired effect

·       DDDS Counter (333/1)(A) (JC3IEDM) : The potential ability to do work, perform a function or mission, achieve an objective, or provide a service.

·       NAF: The ability of one or more resources to deliver a specified type of effect or a specified course of action.

·        Wiktionary: The power or ability to generate an outcome.

 

The sources and definitions in black text in the table below are copied from this list of published in DoDAF .

The blue text – added here - distils the definitions to help us compare them, like with like.

 

Source referred to in DoDAF

Definition of capability

DoDAF and 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.

Distilled here as

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

DoDAF/CADM

An ability to achieve an objective.

Distilled here 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.

Distilled here 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.

Distilled here 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)

Distilled here 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)

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

Distilled here 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.

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

Distilled here as

An ability capable of development

Joint Publication 1-02, Dictionary of Military and Associated Terms

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

Distilled here 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.

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

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

Distilled here as

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

 

The consensus?

In business architecture: “Capabilities are the abilities of an organisation”.

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

Here is an attempt to draw a consensus definition from those in the table above.

A capability is an ability (of actors), which can be used or developed, to perform activities, provide service(s) or achieve aim(s).

 

Note however that the definitions are not entirely consistent.

Two of them limit the concept of capability by relating it to a "course of action" (defined here as: “any sequence of activities that an individual or unit may follow.”

Which is to say a capability corresponds to a process.

And while a capability may be abstract (in MoDAF at least), when used by the military, it can refer to concrete set of human and technological resources.

 

Abstract and concrete capabilities

A capability is an ability to be developed or used.

Consider the ability to ride a bicycle.

Before it is achieved it can be discussed as a goal.

When it is achieved, it can be discussed as an attribute of a complete concrete system (rider + bicycle + road surface).

It is an abstract capability until realised in a concrete system.

 

Capability-based planning may start by defining an abstract capability as a goal.

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

To do whatever is to be done, a business must develop and use the corresponding concrete capability.

DoDAF says a capability "occupies space and time" as though it is a concrete entity.                                                                                                                                          .

Others speak of a capability as though it is a physical entity that has the ability to act as required.

This is to equate a capability with a group of actors (in a project, organisation unit or entire business) and all the resources used.

The required resources may include the 3 Ms: men, materials and machines (inc. computers, databases and networks).

And the knowledge, skills, energy and procedures that human actors need.

And even people trained to find whatever resources they need to achieve ad hoc aims.

In other words -  the whole of the system or subsystem needed to demonstrate use of the capability.

 

In meta model terms, perhaps…

An abstract capability might be modelled as a very abstract supertype of other already abstract entity types, notably goal, service and function.

A concrete capability will be found in whatever resources are grouped in whatever system or subsystem realises the abstraction.

 

On the questionable language used in standard definitions

Some speak as though capabilities are active structures that can act (e.g. deliver something).

But you can’t ask an ability do something; you must ask an active structure that possesses the ability (e.g. to deliver something).

 

Some speak as though capabilities are passive structures that can be acted on (e.g. can be delivered or exchanged).

But given a capability has been developed and used, then what is acted on are the result or products of using that ability.

 

You might think this lexical analysis is pointless nit-picking

But departing from natural language in defining business architecture concepts tends to obscure what they mean and how they relate to each other.

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

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.

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

The words particular and specific are redundant in this glossary entry.

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

But singular associations (like 1 capability to 1 desired effect) are always questionable, and can be 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”.

Here, 1 capability relates to one or more desired effects.

Footnote 2: On the science of hierarchical structures

All is recursive.

Grouping smaller/shorter things into larger/longer things – in a hierarchy - is a primary analysis and design technique.

It is used in most EA reference models and frameworks to help people understand and manage things.

Here are four common hierarchical structures.

 

Motivations

Goal/objective hierarchy

as in a strategy map or a balanced score card.

Physical active structure

Organization hierarchy

dividing people and resources for management purposes.

Logical active structure

Function and/or capability hierarchy

dividing larger/wider functions or capabilities smaller/narrower functions or capabilities.

Behaviors

Process hierarchies

dividing each long-running process or value stream into shorter processes.

 

Corresponding and clashing hierarchies

Any two hierarchies may correspond, or else clash to a greater or lesser degree.

 

Two structures are said to clash when different hierarchies are imposed over the same or related elements.

 

The science of corresponding and clashing hierarchies can be traced back through Michal A. Jackson (1975) to earlier sources.

In software design, any two data structures read and written by a program must either correspond or clash.

When they correspond, the data structures can be merged into one program structure.

When they clash (Jackson showed) the program is better divided into application components that each process a different data structure.

 

Corresponding structures

You may base one hierarchy on another.

·       Managers may create a “functional organization” by defining an organization structure to match a logical function hierarchy.

·       Architects may align a function hierarchy with a goal/objective hierarchy.

·       Although the concepts of capability and function differ, they are naturally organised under hierarchies that correspond to each other.

 

Wherever two hierarchies correspond, you may merge and maintain them in one structure, though this is a hostage to fortune.

 

Clashing structures

Given two structures are in correspondence, you may change one without the other.

E.g. an organization’s management structure may be restructured by location, customer type, product type or resource type.

This may be done without significantly changing what the business does, as shown in a function hierarchy.

And that is the major reason for basing business architecture documentation on the latter rather than the former.

 

Duplication or reuse of elements in different legs of a hierarchy?

You may find some common or shared elements in different legs of a hierarchy, which may be reused by delegation.

If you decompose a business capability or function hierarchy far enough, you will reach some capabilities or functions that are shared or generic.

But if you follow the convention to decompose to only a 3rd or 4th level, you are unlikely to find those common elements.

 

(By contrast, class hierarchies abstract from the bottom up by generalization.

You will find common or shared elements at the top, which may be reused by inheritance.)

Footnote 3: Do we model services or flows? Notes for ArchiMate diagram drawers

There are two ways to model communication between active structural elements (square boxes): 

a) as an arrow showing one or more services are provided by a "server" box to "consumer" box, or 

b) as arrows showing data/info flows between boxes. 

The former is more abstract; the latter is more informative.

It usually seems over the top to do both.

 

The square boxes can be components and/or interfaces; modelling both seems over the top in many published examples.

 

The protocol used to send or receive a data/info flow could be shown as an annotation on it (rather than an interface).

 

In reality, flows are often two-way, yet people often ignore the request in a request-reply exchange, and error replies in other cases.

 

The service and the main flow of interest point in opposite directions when invoking a service to update or post some data.

Footnote 4: On systems in general

Discussion of EA is terminology torture.

“Enterprise Architecting, Enterprise Engineering, and Organization Design all seem to refer to activities with the same possible concerns and outcomes.”  Lapalme (2012)

Lapalme tried to divide EA into three schools that might crudely be called IT, integration and adaptation

But mainstream EA cuts across all three schools.

 

Discussion of systems is also terminology torture.

Lapalme sought to promote the use of “systems thinking” in his second and third schools.

But did not distinguish general system theory from socio-cultural systems thinking. 

General system theory about activity systems – human or other – that can be modelled.

In much socio-cultural systems thinking discussion, it is hard to identify what the “system” is, let alone model it.

Remember, no model, no architecture, just stuff happening in an unknown way.

 

See EA as applied system theory for detailed discussion.

This footnote maps some general system ideas to terms of EA frameworks (like TOGAF and NAF)

And of modelling languages (like ArchiMate and UML).

 

General system ideas

Defined in terms of business activities

Business system ideas

Application system ideas

Aim

A testable target for the outcome(s) of activities.

Business goal

Software requirement

Behavior

A contract defining the request for and result/outcomes of required activities.

Business service

Application service

A behavior (e.g. value stream, use case or epic) that sequences activities.

Process

Application process

Abstract structure

A group of services or activities performable by an organisation/actor/component.

Role

Application interface

Business function

Concrete structure

A deployable managed unit that realises services by performing activities in processes.

Actor

Application component

Organisation

 

Every designed system can be described in terms of structures that perform some behaviors to meet some aims.

And it exists in two forms, in logical specification at design time and in concrete operation at run time.

 

Abstract or concrete?

Persistent structures

 

Transient behaviors

Business organisation

In logical specification

business functions

are specified as acting in

business processes (aka value streams).

In concrete operation

organisation units

realise functions

by performing activities in business processes.

Business people

In logical specification

roles

are responsible for performing

activities (aka tasks or sub processes).

In concrete operation

actors

realise the roles

by performing the activities.

Business applications

In logical specification

applications

are specified as acting in

use cases or user stories.

In concrete operation

deployed software

realises the applications

by directing the use cases or user stories.

 

This table brings these ideas together using terms in TOGAF.

 

 

Required behaviors

Logical active structures

Physical active structures

Business

Business Services

Business Processes

Business Functions

Roles

Organization Units

Actors

Information Systems

Application/IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

This table generalises business architecture entities that appear in EA frameworks (like TOGAF and NAF) and modelling languages (like ArchiMate and UML).

 

Business architecture entities

General definitions

Aims (why)

motivations for behavior

Goal or Objective

A target to be achieved, a motivation or reason to perform behaviors.

Behaviors (how and when)

things that happen over time and change the state of a system or its environment

Service

A behavior performable by a business component that produces a result of value to its consumer.

An external view, a logical contract, that encapsulates whatever process(es) are needed to deliver the desired result.

Process

A sequence of activities performed by the actors in a business in the course of delivering a business service.

A process may occur within one organization or function, or coordinate activities in several organizations or functions.

Logical structures

groups of behaviors that are assignable to active structures

Function

A logical business component.

A node in a business structure that represents a subdivision and group of its logical activities and capabilities.

It is describable externally by services provided and internally by activities assignable to organisation units.

Role

A business function performable by one or more actors with the requisite capabilities.

It is describable externally by services provided and internally by activities assignable to an actor.

Active structures (who)

things that perform behaviors

Organisation unit

A real business component, capable of realising one or more logical functions.

A node in a management structure that subdivides and groups its physical actors, and perhaps resources also.

Note: in the special case of a “functional organization”, each organization unit realises one business function.

Actor

An entity capable of realising one or more roles; typically assigned to a bottom-level organization unit.

Passive structures (what)

things that are acted on

Physical entity

A concrete entity type that a business creates and/or uses in the course of performing behaviors.

Data entity

A record type that describes the attributes of an entity or event, created and used in the course of performing behaviors.

Location (where)

A place where actors, components or entities are found and work is done.

 

Aside on data

The EA/BA concerns about information differ from those in Shannon’s “information theory” for maintaining the integrity of physical data structures.

They relate instead to the capture, use and value of the logical information/meaning that actors create and find in data structures.

Information about business entities and events is stored and exchanged using a domain-specific vocabulary in which every term has a specific meaning.

E.g. Loan amount, Required qualification, Capital gain, Airplane position, speed and direction.

 

Aside on actors

In UML, roles are called actors.

In the ArchiMate standard, both people and organisation units are called actors

The table above separates people (actors) from organisations and roles.

And note the curiosity that whereas every human actor is a unique individual, every software actor is a replicable individual.