3 Where is the demand viewpoint?
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:
- Implement this demand-capability within the organisation as a coordination of some other capabilities.
- Outsource this demand-capability via Business-to-Business (B2B) partnership and access it in accordance with a contract between two organisations.
- Acquire this demand-capability as commodity maybe via a tender.
- 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
- Capability The organisation has to be able to do something (because of the mission) with a particular level of performance (because of the vision).
- 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.
- 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.
- Process For better estimation of the expected performance, processes (actually, BPM) offer an explicit coordination of ”smaller” capabilities.
To avoid confusion when talking about capabilities, please, be explicit about what viewpoint(s) you are using. Also, please, define related terminology up-front.