Capability as discrete unit of purpose

1 Introduction

Capability is a very important concept for any enterprise. Capability is used to manage the relationships between the enterprise mission and the enterprise successful functioning.

Enterprise mission is a short and catchy statement which describes a reason WHY an enterprise is doing what is it doing. Mission links the goals (nouns) and activities (via verbs or gerunds).There are a few patterns for the mission statement:

• “do this until that is achieved”, e.g. “Eliminate poverty”
• “do this while you are achieving that”, e.g. “Earn money by making cars”
• “do this because of that”, e.g. “Create a better everyday life for the many people”
• “do anything to achieve this”, e.g. “Go there, don't know where, bring that don't know what, but this must make me happy”.

Enterprise successful functioning is a result of the behaviour of a complex socio-technical system (or even a system of systems).

To be able to manage the relationships between the enterprise mission and enterprise successful functioning, it is necessary to make these relationships explicit, reliable (with formally validated quality) and quantitative. Capability is one of the key artefacts to do this.

Unfortunately, the concept ‘capability’ has no commonly-agreed definition. Different people understand it differently ( see http://improving-bpm-systems.blogspot.ch/2015/10/concepts-crisis-in-it-and-sister-domains.html ). This article offers a reconciliation between several interpretations (or projections) of this concept.

There are two major interpretations of the concept ‘capability’:

1. Capability as discrete-unit-of-purpose (do right things)
2. Capability as measure-of-performance (do things right)

Mainly the first interpretation will be discussed below.

Related blogposts - http://improving-bpm-systems.blogspot.ch/search/label/%23%23terminology

2 Capability as discrete unit of purpose

The mission of an enterprise can be decomposed into an approximate hierarchy of discrete-units-of-purpose must describe WHAT an enterprise must be doing to conduct its mission.

An example (see figure below) is a strict hierarchical decomposition of the “rent-a-car” business into capabilities-as-discrete-unit-of-purpose.

Note 1: Potential synonym of “capability-as-discrete-unit-of-purpose” is “capability-as-a-discrete-unit-of-mission”.

Note 2: In theory, the decomposition is strictly hierarchical, i.e. some “complex” capabilities are built from some subordinated “simple” capabilities. Also, it is possible to say “aggregated capabilities” and “detailed capabilities”. For example, aggregated capability “Collaboration” comprises the following detailed ECM capabilities (not exhausted list):

• Sharing files
• Pattern “One writer and many readers”
• Pattern “Few managers, several members (writers) and many visitors (readers)”
• Co-editing
• Invitation of any internal person as a visitor (reader or writer)
• Invitation of any external person as a visitor (reader or writer)
• Notifications (or alert)
• Local copy for off-line work
• etc.

Note 3: In practice, there is no exact hierarchy of discrete-units-of-purpose within an enterprise because some discrete-units-of-purpose can be shared.

Note 4: Some capabilities may be outsourced.

Note 5: If outsourcing and sharing are ignored, all enterprises in the same industry sector (e.g. telecom) have the same capability-as-discrete-unit-of-purpose decomposition. (Such a decomposition also called “industry sector reference model”, e.g. https://en.wikipedia.org/wiki/Business_Process_Framework_(eTOM) ).

A capability may be implemented in one of the following ways:

• Internally as a business function (including people, resources, tools and other functions)
• Externally as a commodity which are available from the market (e.g. banking)
• Externally as partnership with a service provider
• Deliberately missing (because of some reasons, e.g. maturity level)

For example, the capabilities of an IT department can be implemented as the following:

• Governance, Business Analysis, PMO, Application Support – internally
• Infrastructure – externally as the partnership with an IaaS provider
• Development – externally as the partnership with an ecosystem of providers
• Testing – externally as commodity, e.g. testers are available for 11 $ per hour
• Service desk – externally via contract with a company MMM
• Enterprise IT Architecture – deliberately missing

Again, internally implemented capability is a business function. Capability itself is an abstract construction.

3 Building internal implementations of capabilities as business functions

An internal implementation of a capability (actually a business function) may use other functions (all subordinated and some shared) and some tools. How to select tools for an implementation of a particular business function? Obviously, the selection must be explicit and quantitative to be able to verify a choice tool is the best. Also, it is mandatory to avoid unjustified duplications at the scale of an enterprise (or “silo” effect).

Thus, it is necessary to establish relationships between the capability demand (i.e. requirements of a particular business function) and the capability supply (i.e. features of some tools).

A few intermediate layers (see figure below) are necessary to make these relationships explicit and practical.

• Concrete Business Capability – concrete functionality needed for the business, also known as requirements.
• Uniform Business Capability – enterprise-wide agreed functionality, which may be implemented once and reused many times (usually based on good business practices and business patterns).
• Generalised Technical Capability – Industry “de-facto” or “de-jure” standards for functionality of particular class of tools (e.g. DBMS, DMS, web browser).
• Specific Technical Capability – Particular functionality implemented by a particular tool, also known as features.

Example:

• HTML5 specifications for web browsers as defined by W3C (generalised technical capability)
• HTML5 implementations in Chrome, IE, Safari, etc. (specific technical capability)

The use of the mentioned above capabilities is described below. Imagine (see figure below) an implementation of the business function B1 that comprises the business function C3 (which is “smaller” than B1) and the tools T1, T2, T3 and T9.

This implementation of the business function B1 requires (in addition to C3) some concrete business capabilities (as requirements described by the owners of the B1) – B1A, B1B, ... B1Z (see figure below). Their implementations reply on the tools T1, T2, T3 and T9.

All the tools expose some specific technical capabilities. Some of those capabilities implement the concrete business capabilities of the business function B1 (see figure below).

Some of the concrete business capabilities from various functions may be very similar. For example, the delegation of authority is a stable and well-defined business pattern ( see http://improving-bpm-systems.blogspot.ch/2012/07/practical-process-pattern-dam.html ). Also, there are numerous “good business practices” proven by practice and helped many companies to avoid “trial and error” improvements. Thus is it logical to have a set of uniform business capabilities that is actually, enterprise-wide collection of good business practices.

So, one of the concrete business capabilities of the business function B1, e.g. B1A, was agreed to match the uniform business capability BC10 (see figure below).

In the similar manner, some of specific technical capabilities can be similar. For example, the specific technical capability T1B and the specific technical capability T2A are the same generalized technical capability TC30 (see figure below).

Thus the tool T2 can be eliminated because its specific technical capability T2A can be provisioned by the tool T1 with its specific technical capability T1B (see figure below).

4 Example

The business requested some “collaboration” functionality to exchange information among staff members, volunteers, and service providers. The requested concrete business capabilities (primarily aggregated) are the following:

• Multilingual
• Omni-channel
• Various audiences
• “Book shelf” as static documentation (slow changing by designated groups)
• “Tool box” as operational documentation (changing with the speed of operations by groups which are involved in operations)
• “Forum” as interactive knowledge capturing and exchange (ah-hoc changes by communities of practices – speed of Internet discussions)
• “News channels” as real-time information (feeds and streaming)
• Activity monitoring

All of these concrete business capabilities were mapped against the generalised technical capabilities as shown in table below (columns “Capability demand”). Additional columns “Capability supply” show the level of provisioning of those generalised technical capabilities by an in-house ECM tool.

5 Other interpretations of the concept ‘capability’

Performance-related interpretation: capability is a measure of how well a function with achieving a desired result. Such a measure can be qualitative or quantitative. Numerous “heat maps” use this interpretation (see figure below).

The important consideration for performance measurement of capabilities is that a function is considered “self-contained” thus capability of a function depends on capabilities of all other functions and tools used by this function (see figure below).

Capacity-centric interpretation: capability is availability of resources required to achieve a desired result. This is very ERP-oriented interpretation.


Thanks,
AS

#bizarch from the #entarch point of view

This blogpost is a placeholder for my presentation at the IASA e-summit. This presentation contains (in notes) additional URLs to various blog posts.

#bizarch from the #entarch point of view from Alexander SAMARIN

Question 1: How #entarch and #bizarch can help innovations?

There are a few mutually enhancing factors.

1. Less stress, higher performance, higher security, less risk, higher predictability of results, and better operations thus liberating people's business potential.

2. Routine activities will be gradually eliminated thus increasing the time for added-value contributions.

3. Armed with actionable patterns, different staff members will employ similar services to implement similar enterprise capabilities thus increasing the re-usability of these services.

4. Modern technologies will be employing in a coordinated and transparent way to streamline evolution and reduce overlapping and omissions.

5. Disjointed solutions and systems will fuse into a corporate unified business execution platform, which will allow quick experimentation for various business ideas thus enable business innovations.

6. Staff members can concentrate on innovative solutions for the unique challenges of their business and not waste time re-inventing the wheel.

Question 2: What is the difference between business and technical capability?

An extra blogpost cover this issue - see http://improving-bpm-systems.blogspot.ch/2016/05/capability-as-discrete-unit-of-purpose.html

Question 3: How #bizarch and #entarch help to software-defined enterprise?

This will be presented at a BPM conference in Lisbon on 2016-06-23.


Thanks,
AS

Will the right use of #blockchain make the records management obsolete?

It is well know that records management is mandatory and not trivial enterprise-wide capability. Its implementation is a daunting task.

Some documents, database snapshots, copies of external sources, etc. must be carefully classified, secured at the very serious level of confidence, stored for many years and, fortunately, never used for legal matters!

Considering that all information become available digitally, is it possible to simplify the records management with the use of some modern technologies? What can be those technologies?

Let us try to imagine.

The first key technology is the one-way hash function which generates a short and unique set of bits (digital signature) for any digital entity. Thus by making the hash of a document (or hash) available publicly (e.g. published in a popular newspaper), an enterprise can proof that their digital entity (e.g. a document) has not been altered. For example, a contract that was signed by two partiers can't be altered by any of these parties.

The second key technology is the blockchain ( see http://improving-bpm-systems.blogspot.ch/2016/01/entarch-view-on-blockchain.html ). It allows to store some information with the guarantee that no one can alter any piece of information. This guarantee is based on the encryption technique that uses the previously collected information. Typically, hashes are stored in the blockchain.

The third key technology is a distributed storage for digital entities. A digital entity is decomposed into smaller chunks which are encrypted and stored in different and independent storages. Thus no single storage can reproduce a complete digital entity and try to decrypt it.

The fourth key technology is BPM (Business Process Management) which tags and classifies all the digital entities as they are used in various business processes.

Thus, the big picture can be the following:

1. Any  digital entity is stored in a distributed storage with required level of confidentiality.

2. A hash of any important business digital entity is stored in the blockchain with the required level of integrity.

3. The context of any business entity is provided by business process instances in which this entity was used. Corporate's business rules define the importance of the business entities.

4. The storage duration may be illimited (with a small annual fee) or time-bound (can be paid in advance) with the required level of availability.

5. All above can be fully automated and its OPEX cost is constantly diminishing.

It seems that the "mechanical part" of the record management can be fully "absorbed" by a proper combination of the modern technologies (actually, by commodity services built on those technologies).

So, the records management will become a creative profession - finding, mining, enriching and disseminating information which is important for the business.

Thanks,
AS

"Smart contracts" as an #BPM application - golden opportunity or not?

This blogpost was discussed at BPM.COM forum http://bpm.com/bpm-today/in-the-forum/do-you-see-smart-contracts-having-an-impact-on-bpm

Smart-contract is the current way to conduct the digital business. Everything is agreed up-front, just wait for actions, execute a payment. Because that everything is non-breakable by any of parties involved,  independent and mutually untrusted parties may conduct safely the business via smart-contracts.

Smart-contracts are explicit and machine-executable "simple" business processes at the level of the global digital economy. At the same time, smart-contracts covers only a happy path in their processes. The reality is more complex.

At present, BPM perfectly knows all traps and techniques for coordination of work and can successfully handle very complex processes (formal regulations, compliances, etc.). Also BPM is explicit, machine-executable and non-breakable but only at the level of individual enterprises. 

Can BPM delivery smart-contracts and enable enterprises for the global digital economy? Or will smart-contracts eat the current BPM areal be becoming more versatile? 

I think that BPM as a discipline already covers the smart-contract concept. But BPM as tools must adapt. Why?

1. There is not commonly-agreed BPM terminology.
2. There is not commonly-agreed processes and cases execution semantic.
3. There is no commonly-agreed design-time APIs.
4. There is no commonly-agreed run-time APIs.
5. BPM, as a business technology, has not been architected yet.

All of these items are doable if there is the real willingness of BPM-suite tools vendors to collaborate. Or BPM can miss a huge business opportunity.

Thanks,
AS

Related blogpost - http://improving-bpm-systems.blogspot.ch/2016/01/entarch-view-on-blockchain.html

What Services should be offered by an Enterprise Architecture Practice?

All depends, as usual.

1 Core EA practice

Let us consider that core EA practice is as defined in http://improving-bpm-systems.blogspot.ch/2015/12/enterprise-patterns-adagio-entarch.html

Its possible services are the following.

1.1 Architecture Governance Services

These services allow to define, execute, supervise, and review strategies, policies and procedures for

• business 
• applications 
• information 
• infrastructure 
• security

1.2 Architecture Delivery Services

The purpose of these services is to deliver architecture in accordance with its lifecycle and some specific of an enterprise. For example, a target architecture of an enterprise has three major parts:

1. Corporate Unified Business Execution (CUBE) platform see http://improving-bpm-systems.blogspot.ch/search/label/%23platform
2. Platform-based solutions see http://improving-bpm-systems.blogspot.ch/search/label/PEAS
3. Stand-alone applications

Then each of "smaller" services must address each of those parts.

1. Architecture Design Service
   • Platform
   • Platform-based solutions
   • Stand-alone solutions
2. Architecture Support Service
   • Platform
   • Platform-based solutions
   • Stand-alone solutions
3. Architecture Operations Service
   • Platform
   • Platform-based solutions
   • Stand-alone solutions
4. Architecture Evolution Service
   • Platform
   • Platform-based solutions
   • Stand-alone solutions

1.3 Innovations and optimisation services

Possible services:

• Training
• Knowledge dissemination
• Prototyping
• Experimentations
• Technology watch

2 Supporting EA practice to enable other functions

Possible services:

• EA services in the PMO processes
• EA services in procurement processes
• EA services in strategic planning processes

3 Reminder - check that set of service is complete

Know all your artefacts (i.e. those are under your responsibilities or those about which you are consulted ) and build services around these artefacts.

For each of artefact:

• Policy
  • RASCI
  • lifecycle = states+events+procedures
  • security
• Procedures (design, build, support, operations, maintenance) - depending of RASCI
• Catalogue
• Relationships to other artefacts

Thanks,

AS

Enterprise patterns: PSST

Enterprise patterns: Process Set Solidity Test (PSST)

Several domain-specific frameworks and bodies-of-knowledge formalise themselves as a coherent set of related processes/value-streams/functions/services/capabilities. Examples: CoBIT, ITIL, IT4IT, eTOM, SCOR, etc.

A normal question from the #entarch viewpoint to those frameworks & bodies-of-knowledge and any process models as well is the following – how to check that a proposed set of processes/functions/services/capabilities/etc. is solid or complete (i.e. having all the necessary or appropriate parts)?

I found practical the following cross-check mapping:

1. List all the processes from the process-set in focus
2. List all the primary artefacts in the domain of the process-set in focus
3. Make a matrix – processes (rows) vs primary artefacts (columns)
4. Check that all the primary artefacts are involved in this process-set (no empty columns)
5. Check that any process uses at least one of the primary artefacts (no empty rows)

A couple of examples for which I use the IT domain with its primary artefacts: Strategy, Governance, Architecture, Capability, Technology, Programme, Project, Solution, Product and Environment.

Below is a cross-check mapping for my own collection of IT value-streams.


And, below is a cross-check mapping for a set of value-streams (based on their data flow diagram) from of the IT initiatives. As we see there are some “holes”.

If necessary, a deeper analysis can be carried out:

• Processes can be decomposed in to main activities
• Values-streams can be decomposed into their stages
• Artefacts can be presented by phases of their life cycles

Thanks,
AS

Platform-based #digital transformation (example egov)

This blogpost is an example of digital transformation in e-government with the use of platforms (extracted from "e-government reference model #GeGF2014 #egov #entarch #bpm #soa" http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html  ).

In general, the e-government implementation architecture is as in Figure 1. It is a combination of an initial coordination platform (the social collaborative extranet) and an e-gov business execution platform (the coordination and integration backbone and functional services to be “cabled” to it).

Figure 1 Implementation architecture overview

Let us put this architecture in the evolution context. For the long time, e-government implementation architecture was portal-centric and its applications (blue "emabas") were extensions for some internal applications as show in Figure 2.

 

Figure 2 Implementation architecture – portal-centric stage

The proposed e-government implementation architecture is actually, the introductory architecture which introduces necessary flexibility. E-government applications may span several existing applications as shown in Figure 3.

        

Figure 3 Implementation architecture – introductory stage

As existing applications are evolving, they will be replaced by processes and services as well thus creating transitional application architecture as shown in Figure 4.

Figure 4 Implementation architecture – transitional stage

With converting all previously monolith applications into processes and services, the target application architecture will be reach as show in Figure 5. E-government applications will be just connections to a cloud of governmental services.

  

Figure 5 Implementation architecture – target stage

And, moving e-government to the really e-social system, the application architecture will morph into a social cloud interacting with the government service cloud as shown in Figure 6. The latter serves as a platform for social, professional, private, voluntary and other services to be integrated into e-social system.

  

Figure 6 Implementation architecture – e-social system stage

For existing e-government systems the evolution from the introductory architecture upwards does require primarily the systematic use of BPM and SOA. Green-field e-government initiatives may start from the target architecture.

All stages form a sort of ladder for step-by-step evolution as shown in Figure 7.

Figure 7 Implementation architecture – all stages as a ladder

Thanks,
AS