Many viewpoints on the concept capability

This blogpost is based on the several recent LI discussions about the concept “capability” (see their URLs at the end of this blogpost).

Those endless discussions only confirm a well-known systemic observation – a complex concept is better understand via its relationships to other concepts. Thus, to define the concept “capability”, it is necessary to define together the several related concepts, such as “function”, “service” and “process”. (Other concepts could be added on demand.)

Another complexity is, again, a well-known systemic observation – different people see the same thing differently. It is called “architecture viewpoint” (like an 3D object may have 3 projections). The many problem with architecture viewpoints is that they must be aligned.

The aim of this article to outline a main (or master) viewpoint which allows to align all other viewpoints. (With special thanks to Michael Poulin for his valuable comments for this article.)

1 Different viewpoints on capability

So far, the several viewpoints on the concept “capability” have been detected.

Demand viewpoint – to achieve our mission and vision we need a system with a particular performance of doing something. Demand-capability is a relative measure of ability of a system (or its element) doing something at a particular level of performance.

This viewpoint is about WHAT and HOW-WELL without any information about WHO, HOW, WHERE, WITH-WHAT-RESOURCES, etc.

Supply viewpoint – we have a system with a particular performance because we made it and deployed some resources. Supply-capability is a proven performance of a system (or its element) doing something.

This viewpoint is about WHAT, HOW-WELL, WHO, HOW, WHERE, etc.

Reference viewpoint – all the systems with a similar purpose (or mission) should be able to do this. Reference-capability is an ability of a system (or its element) doing something.

This viewpoint is about WHAT only. Typically, the reference viewpoint relates to a particular type of business, e.g. banking, rent-a-car, telecom, etc.

2 Let us classify some of the existing approaches

The list below is copied from https://www.dragon1.com/terms/capability-definition to be annotated.

ArchiMate 3.1: A capability represents an ability that an active structure element, such as an organization, person, or system, possesses. AS: It seems that it is the supply viewpoint.

TOGAF 9.1: A capability is an ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing. AS: It seems that it is the supply viewpoint.

BIZBOK 4.1: A capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. AS: It seems that it is the reference viewpoint.

Bas van Gils (Strategy Alliance): CAPABILITY = CAPacity x ABILITY. - ABILITY refers to skills and proficiency in a certain area. It should be noted that ability is a relative term: one actor (human, machine, computer) may have higher levels of proficiency than others. The level of ability can be increased due to (formal) training, and practice. - CAPacity refers to the degree to which actors (human, machine, computer) are available to use their skills to achieve a goal. Capacity can be influenced by freeing up / adding resources to the available pool. More information on the Strategy Alliance Website. AS: It seems that it is the supply viewpoint.

Tom Graves (http://weblog.tetradian.com/2013/12/14/definitions-on-capability/ ) RE “Performance is an attribute of a service – not of a capability as such”. AS: It seems that it is the supply viewpoint.

Mark Paauwe (https://www.dragon1.com/terms/capability-definition ) A capability is a set of tasks that a system is potentially able to perform at a certain performance level, but only with the use of required resources. AS: It seems that it is the supply viewpoint.

Michael Poulin (https://organicbusinessdesign.com/agile-business-capability-part-1/ ) - A business capability is an ability of an entity - person or organisation - to create or deliver certain Real world Effect (outcome) in particular business execution context. If the context changes, yesterdays capability can vanish. A fact that you did something yesterday does not mean (itself) that you can do this tomorrow. A capability exists only if there are all needed resources available for the capability realization. No resources - no capabilities; competencies/knowledge/skills are not enough for having the capability. You lose capability if you outsource it. AS: It seems that it is the supply viewpoint.

Richard Hillier - A business capability is the ability to perform a business activity which is recognized as being required for success and which needs to be specifically managed. AS: It seems that it is the supply viewpoint.

So far, there is no demand viewpoint. Why?

3 Where is the demand viewpoint? 

Any demand viewpoint it is dynamic and organisation specific. In any business, “bigger” (with emergent characteristics) capabilities are assembled from “smaller” (available or not yet) capabilities. Because such emergent characteristics are exhibited as the result of interactions of “smaller” capabilities between themselves and with other capabilities then some coordination of such interactions is mandatory.

Note: It is not a bottom-up approach, but a recursive combination of analysis (finding what "smaller" capabilities are necessary) and synthesis (proving that "smaller" capabilities and some coordination between them achieve "bigger" capability). 

Imagine, an enterprise or solutions architect has to implement a particular demand-capability within an organisation (which is, obviously, a system). There are several choices:

1. Implement this demand-capability within the organisation as a coordination of some other capabilities.
2. Outsource this demand-capability via Business-to-Business (B2B) partnership and access it in accordance with a contract between two organisations.
3. Acquire this demand-capability as commodity maybe via a tender.
4. Ignore this demand-capability by providing some good reasons.

With the option 1 the enterprise architect must chose a set of “smaller” capabilities and a way to coordinate them. The reference viewpoint, if any, may help to find out those “smaller” capabilities. (Of course, some “smaller” capabilities may be not available yet and have to be implemented recursively).

Also, saying that “to implement this capability we will use those two capabilities” is not enough because the way to coordinate those capabilities will affect the performance of this capability. Sure that various estimations of the performance of this future supply-capability may be provided.

Any demand-capability or reference-capability which is implemented by (or within) the organisation is called function. Creating a function implies that several organisational, technical, contractual, resourcing, staffing and other changes must be carried out within the organisation. Function immediately has some performance approximation as supply-capability, i.e. its expected performance is stated. Ideally, the performance of such supply-capability exceeds the requested performance of the related demand-capability. (Sometimes, a gap between them can be huge – remember that we never drive our cars at their maximum speed.)

An illustration of relationships between various concepts is shown below. The left half of this illustration is the reference map of an organisation and the right half of this illustration is the functional map of this organisation. The functional map is smaller then the reference map, because some capabilities were implemented as commodities or via B2B partnership. A formal procedure for moving from “left” to “right” can be produced on demand.

    

Because functions can’t provide a good approximation of its expected performance, organisations uses services – service is an arrangement to access to one or more functions on a contractual basis. (Note: such an access may be within the same organisation as well as between different organisations). Because any service must take into consideration its contract (including SLA) and its expected usage, its performance may be anticipated better than for functions. Creating services also implies some organisational, technical, contractual, resourcing, staffing and other changes.

Nevertheless, neither functions nor services specify explicitly the coordination between “smaller” capabilities thus their estimations of the expected performance is still a guess. So far, only Business Process Management (BPM) allow the organisation to build, run and improve “bigger” capabilities in predictive, transparent and provable manner because process is an explicit, formal, machine-readable and machine-executable coordination. Obviously, one can evaluate (with a high level of confidence) the performance of a “big” supply-capability by knowing the process, its usage and performance of “small” supply-capabilities.

A few notes: Considering that there are many coordination techniques then there are no principal differences between BPM and Adaptive Case Management – see http://improving-bpm-systems.blogspot.bg/2014/03/coordination-techniques-in-bpm.html . BPM is actually a trio: discipline to manage business via processes, software to manage processes themselves (BPM-suite tools) and practice & architecture. Also, orchestration and choreography are variants of coordination.

Some assets and skills are required to operate services and processes. Obviously, assets and skills may be outsourced (or insourced).

Organisational structure depends on the structure of functions (or functional map). (Think about the separation of responsibilities). http://improving-bpm-systems.blogspot.bg/2011/10/enterprise-pattern-structuring-it.html http://improving-bpm-systems.blogspot.bg/2012/01/enterprise-pattern-sito-extended.html

4 Big picture

The overall logic is the following:

1. Capability The organisation has to be able to do something (because of the mission) with a particular level of performance (because of the vision).
2. Function Some of needed (demand-)capabilities must be implemented within the organisation. For example, because it is a core-business capability. By definition, a function is already a supply-capability (as a system element of an organisation as a system) and some assets, skills and coordination have to be provided. 
3. Service Although function is already a supply-capability, the evaluation of its performance is rather approximative. Service allows improving the evaluation of its expected performance by specifying its contractual conditions.
4. Process For better estimation of the expected performance, processes (actually, BPM) offer an explicit coordination of ”smaller” capabilities.

5    Conclusion

To avoid confusion when talking about capabilities, please, be explicit about what viewpoint(s) you are using. Also, please, define related terminology up-front.

Thanks,
AS

Related LI discussion
https://www.linkedin.com/feed/update/urn:li:activity:6378549782734077952

Other discussions:

https://www.linkedin.com/feed/update/urn:li:activity:6362283960789135360/

https://www.linkedin.com/feed/update/urn:li:activity:6359453010652905473/

https://www.linkedin.com/feed/update/urn:li:activity:6361138196524388352/

https://www.linkedin.com/feed/update/urn:li:activity:6362638314935246848/

https://www.linkedin.com/pulse/process-vs-capability-volker-wippermann