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

Enterprise patterns: SRAM

This enterprise architecture pattern Security, Risk and Architecture Mixture (SRAM) is just a picture.

Thanks,
AS

Some #entarch concepts derived from the #systemsapproach

In this blogpost I use the systems approach to derive some definitions for Enterprise Architecture (EA) subject field. The basics are in slides 3-12 of http://improving-bpm-systems.blogspot.ch/2016/07/enterprise-architecture-entarch-as.html .

System is a set of interacting discrete parts organised as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes.

Any system-of-interest has an architecture which is a totality of fundamental concepts or properties of a system in its environment embodied in its discrete parts and relationships, and in the principles of its design and evolution. Architecture of a system-of-interest maybe accidental or intended depending on the way of constructing this system. In any case, any serious change in an enterprise-of-interest implies changing in its EA.

Enterprise is an emotive or motivational structure, bounded by a shared vision, shared values and mutual commitments for joint efforts to achieve one or more stated purposes. An enterprise is realized by an organisation which is a legal structure, bounded by rules, roles and responsibilities. Obviously, any modern enterprise together with its organisation is a socio-technical system (in which the interaction between people and technology is a dominant consideration). Also, an enterprise is a self-evolution system.

Thus Enterprise Architecture (EA) is architecture of an enterprise as a socio-technical system. (Although, it is correct, it is a useless definition for many people). The main and unique power of EA is the ability to objectively estimate effect (cost, benefits and risks) of potential internal changes. For example, what could be the effect of changes in a business unit which necessitates some modifications in some enterprise and departmental applications?

A good EA is the primary enabler for any internal transformations of different extent: project, program and strategy. For any transformation, EA is used to define and validate the future version of EA (called target architecture or blueprint). For example, a good EA can evaluate a level of implementability of a proposed strategy.

Usually, EA is described via a set of architecture viewpoints. Those architecture viewpoints define a set of model kinds which establish relationships between various artefacts: vision, mission, objectives, rules, servers, etc. Architecture viewpoints applied to a system-of-interest generates views whcih comprise some models.

Ideally those viewpoints are aligned, but in the reality it is not the case because different viewpoints are created by different people.

Because of the socio-technological nature of enterprises and their high-level of complexity, EA historically considered as two domain architectures:

1. Business architecture is architecture of an enterprise considered as a social system for delivering Value (as products and/or services). Main artefacts in business-centric viewpoints are: mission, vision, products, services, directives, objectives, processes, roles, etc.
2. IT-architecture is architecture of an enterprise considered as an IT-system. Main artefacts in IT-centric viewpoints are: IT tools, processes, and methodologies and associated equipment employed to collect, transform, transport and present information. 

The dependency between those architectures is, in theory, very straightforward. The business architecture defines the IT-architecture. But, in practice, very often, the IT-architecture evolves much slower than the business architecture, thus there is always a gap or misalignment between them.

To avoid this gap, it is necessary:

1. version all the artefacts during their lifecycle;
2. evlove artefacts to become digital, externalised, virtual and components of clouds;
3. model explicitly all relationships between artefacts;
4. make all models machine-executable, and 
5. be able to convert models from one view to models in another view.

Thanks,
AS

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

Concepts crisis in IT and sister domains

1   Introduction

One of the fundamental tendencies in the modern IT and sister domains is the intersection of many, previously, independent methodologies and disciplines. If somebody wants to address holistically (i.e. enterprise-wide) the operations excellence then it is mandatory to deal with business architecture, operation models, BPM, SixSigma, Lean, EPM, ERM, CoBIT, ITSM, SOA, agile, and many others.

Historically, all these methodologies and disciplines were developed in isolation and, some of them are presented differently by various schools and “bodies of knowledge”. Thus, any transversal communication is hampered by the absence of common agreements for the many of used concepts.

In accordance with ISO 1087-1, concept is unit of knowledge created by a unique combination of characteristics. Concepts are mental representations or entities that exist in the brain. Concepts are not necessarily bound to particular languages. Concepts are, however, influenced by the social or technical background which often leads to different categorizations. Concepts in order to be communicated, stored, etc. indeed require a linguistic form.

To understand how concepts related to each other it is necessary to use descriptive (linguistic) statements which serve to differentiate concepts. Ideally, IT and sister domains need a single concept system which is a set of concepts structured according to the relations among them. Then various designations (graphical and verbal) can be defined to represent concepts.

Following international terminological standards, the “intensional definition” approach is used below. It describes the intension of a concept (set of characteristics which makes up the concept) by stating the superordinate or broader concept and the delimiting (indispensable for distinguishing) characteristics. (See the last chapter for some basics of the terminological science).

The following is an example of an intensional definition for the concept 'incandescent lamp': incandescent lamp is electric lamp in which a filament is heated by an electric current in such a way that it emits light.

The following relationships are used for constructing concept systems (see ISO 1087):

• generic relation or genus-species relation
• partitive relation or part-whole relation
• associative relation or pragmatic relation
• sequential relation
• casual relation

2 Additional type of relation

In IT and sister domains, there are many complex concepts. Because of the complexity, different people consider the same concept from different perspectives and for different concerns. Without providing an explicit context (perspectives and concerns), it is not possible to understand adequately different people.

This is a similar situation when the architecture of a system is discussed because different people see this system differently. To avoid potential confusions, the architecture description is built on viewpoints or ways of looking at systems ("a viewpoint frames a concern" – see http://www.iso-architecture.org/ieee-1471/ads/ ). Also, viewpoints are designed for the purpose of communicating and focusing on certain aspects of an architecture.

Each architecture viewpoint is specified by:

• the concerns framed by this viewpoint;
• the stakeholders interested in this viewpoint;
• the model kinds used in this viewpoint;

For more detail about viewpoints, please see http://web.mit.edu/rihh/www/writings/hilliard-TrustVP-r1.pdf and http://web.mit.edu/richh/www/writings/hilliard-TrustVP.pdf

The aim of this article is to demonstrate that some competing definitions for the same concept are just different viewpoints. Usually, one of those viewpoints is the “meta” (the most comprehensive) one and all the other viewpoints are “periphery” (or simplified versions) ones. Using this additional type of relation between concepts (called ‘projection’) will help to build a commonly agreed concept system for the IT and sister domains.

Below there are several examples of using ‘projection’ relation.

3 Concept ‘system’

3.1 Meta viewpoint

A system is a set of interacting or interdependent components (parts or elements) forming a complex/intricate functional whole. [ adopted from https://en.wikipedia.org/wiki/System ]

This viewpoint emphasis “working together” of parts which makes "The whole is more than the sum of its parts".

3.2 Nomenclature viewpoint

System is a collection of interrelated elements. [ see https://www.linkedin.com/grp/post/36781-6057819803043852292 ]

This viewpoint considers primarily individual elements (components or parts) – like seeing the trees not the forest. This viewpoint mentions the structural perspective, i.e. “A system has structure, it contains parts (or components) that are directly or indirectly related to each other”. Moreover, to some extent, this viewpoint ignores the fact that “a system has behaviour and it exhibits processes that fulfil its function or purpose”.

3.3 Artefact-centric viewpoints

Considering that, parts of systems are different artefacts (or types) such as processes, services, etc. then a particular viewpoint may concentrate only on a particular artefact. Examples of these viewpoints are:

• The system-in-scope is a system of processes (see http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ). 
• The system-in-scope is a system of services ... 
• The system-in-scope is a system of business entities (or data structures)...

4 Concept ‘capability’

4.1 Meta viewpoint

Capability is a measure of the ability of a component (or a system) to achieve a particular result.

This viewpoint emphasis the performance (planned, demonstrated and potential) of a component to perform its function (or ability to do something). Compare: 1) Can you play football? Yes, of course! 2) Can you play football at the level of Champions League? Of course not!

Obviously, the top management of an enterprise perfectly knows what their enterprise can do and their main concern is how well their enterprise doing that. Another concern is the following question which was asked by the President of a development bank: “The bank is doubling its funds, shall we double our IT department as well?”

See also http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.html , http://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html and http://improving-bpm-systems.blogspot.ch/2014/08/concept-capability-for-bpm-entarch-and.html

4.2 Functional viewpoint

Capability is the ability to do something [ see http://weblog.tetradian.com/2015/09/27/why-service-function-and-capability/ ]

This viewpoint is not aware about the performance aspect of capability (maybe because it is usually not shared publicly).

4.3 Other viewpoints

• availability of resources to achieve a particular result
• availability of skills to achieve a particular result

5 Concept ‘business process’

5.1 Meta viewpoint

Business process is an explicitly defined coordination for guiding the purposeful enactment of business activity flows.

In other words, a business process is an agreed plan which may include some variants and may be adapted during its execution.

This viewpoint emphasis an intentional, systematic and shared design of future work which is the primary concern of any business process owner. Thus any business process owner must be capable to logically explain WHY his/her business processes as they are. (An explanation "we always do like that" is not acceptable.)

See also http://improving-bpm-systems.blogspot.ch/2014/01/definition-of-bpm-and-related-terms.html

5.2 Observer viewpoint

Business process is a collection of related, structured activities (or tasks) that produce a specific service or product (serve a particular goal) for a particular customer or customers. [ see https://en.wikipedia.org/wiki/Business_process ]

This viewpoint is typical for an external observer for whom the design of future work and "WHY of processes" are not fully known.

6 Concept ‘architecture’

6.1 Meta viewpoint

Architecture is a fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system. [ adapted from ISO/IEC/IEEE 42010 ]

6.2 Other viewpoints

• architecture as a blueprint
• architecture as a description

See also https://www.linkedin.com/grp/post/36781-6057819803043852292

6.3 Related research

Technical Report №1 String 2015 “Architecture, architecting” http://fess.workem.org/images/papers/Architecture-Archtecting-senses-draft.pdf

7 Concept ‘enterprise architecture’

7.1 A possible approach

A possible approach is used in the article Eight Ways We Frame Our Concepts of Architecture" published by Leonard Fehskens ( see http://c.ymcdn.com/sites/www.globalaea.org/resource/resmgr/JEA/jea_sep2015_final-rev.pdf ). A small fragment from this article is below:

When applied to enterprise architecture, these frames have the following characteristics.

• Concept – the Platonic Ideal (as the “pure” abstraction) of enterprise architecture.
• Class – the class of all possible actual enterprise architectures.
• Instance – the architecture of a specific enterprise or some specific part of an enterprise.
• Representation – the representation or description of an instance of an enterprise architecture.
• Discipline – the set of skills and knowledge required for the competent practice of enterprise architecture.
• Practice – the use of these skills and knowledge in the actual performance of the activities of enterprise architecture.
• Representing – the act of representing an instance of an enterprise architecture.
• Profession – a collegial ecosystem that maintains and enforces a set of constraints (usually implying mastery of a specific set of skills and knowledge to some minimal level of competence, and conformance to certain standards of behaviour) on the practice of the discipline.

7.2 Various viewpoints

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. (See http://www.gartner.com/it-glossary/enterprise-architecture-ea/ )

Enterprise architecture (EA) is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. (See https://en.wikipedia.org/wiki/Enterprise_architecture )

Design or 'blueprint' of a business that depicts the components of a firm employed in its operations, interrelationships of those components, information flows, and how each component supports the objectives or the strategy of the enterprise. (See http://www.businessdictionary.com/definition/enterprise-architecture.html )

7.3 Coordination viewpoint

See “Yet another definition of enterprise architecture #entarch and metrics for enterprise architects” http://improving-bpm-systems.blogspot.ch/2014/12/yet-another-definition-of-enterprise.html

8 Terminology basics

We have to maintain a clear distinction between terms referring to objects, concepts and terms. A term, and more generally a linguistic expression, referring to:

• itself, i.e. a term, is delimited by double quotes;
• a concept, i.e. its meaning, is delimited by single quotes;
• an object, i.e. its referent, is not delimited.

Hence, (the concept) ‘measurement’ is expressed in English by (the term) “measurement” and is about (the object) measurement.

concept
unit of knowledge created by a unique combination of characteristics

NOTE Concepts are not necessarily bound to particular languages. They are, however, influenced by the social or cultural background which often leads to different categorizations.

NOTE Concepts as mental representations, where concepts are entities that exist in the brain.

NOTE Concepts in order to be communicated, stored, etc. indeed require a linguistic form.

object
anything perceivable or conceivable

NOTE Objects may be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. conversion ratio, a project plan) or imagined (e.g. a unicorn).

subject field
field of special knowledge

individual concept
concept which corresponds to only one object

NOTE 1 Examples of individual concepts are 'Saturn', 'the Eiffel Tower'.

general concept
concept which corresponds to two or more objects which form a group by reason of common properties

NOTE Examples of general concepts are 'planet', 'tower'.

characteristic
abstraction of a property of an object or of a set of objects

NOTE Characteristics are used for describing concepts.

type of characteristics
category of characteristics which serves as the criterion of subdivision when establishing concept systems

NOTE The type of characteristics colour embraces characteristics being red, blue, green, etc. The type of characteristics material embraces characteristics made of wood, metal, etc.

essential characteristic
characteristic which is indispensable to understanding a concept

delimiting characteristic
essential characteristic used for distinguishing a concept from related concepts

NOTE The delimiting characteristic support for the back may be used for distinguishing the concepts

intension
set of characteristics which makes up the concept

extension
totality of objects to which a concept corresponds

concept system
system of concepts
set of concepts structured according to the relations among them

definition
representation of a concept by a descriptive statement which serves to differentiate it from related concepts

intensional definition
definition which describes the intension of a concept by stating the superordinate concept and the delimiting characteristics

designation
representation of a concept (3.2.1) by a sign which denotes it

NOTE In terminology work three types of designations are distinguished: symbols, appellations and terms.
term
verbal designation of a general concept in a specific subject field

NOTE A term may contain symbols and can have variants, e.g. different forms of spelling.


Thanks,
AS

Yet another definition of enterprise architecture #entarch and metrics for enterprise architects

My short definition of #entarch from the viewpoint of an enterprise architect

Enterprise Architecture (EA) is a system-thinking applied management discipline about essential decisions for coordinating people, processes, projects and products in 11 dimensions:

1. focus space (biz unit, enterprise, country, etc.)
2. architectural space (business, information, etc.)
3. time span (project life-cycle, solution life-cycle, enterprise life-cycle, etc.)
4. sector span (various industries)
5. problem space (re-structuring, rationalisation, M&A, standardisation, etc.)
6. solution space (from a concept to operations - like ZF rows)
7. cultural space
8. practice space (are you theoretician vs methodologist vs practitioner?)
9. media space (physical vs analog vs digital)
10. financial space (number of zero in the budget)
11. people space (top, management, middle-management, super-users, workers)

Candidates:

• environment
• legal 
• socio-technical vs technical system
• CX span (touch point, journey, storytelling, lifecycle)
• social space (gender equality, consensus building, conflict resolution)
• person span (individual, house, personal cars, public places, etc.)
• technology ?

Using the definitions below:

• System-thinking applied management discipline is an applied management discipline which uses system-thinking approach.
• Applied management discipline is a management discipline which applies scientific knowledge for solving practical problems.
• Management discipline is a discipline for the better management of the enterprise functioning in support of the enterprise goals.
• Discipline is a coherent set of governing rules.

And the self-contained definition will be:

Enterprise Architecture (EA) is a coherent set of governing rules for the better management of the enterprise functioning in support of the enterprise goals by applying system-thinking scientific knowledge for solving practical problems in coordinating people, processes, projects and products in 11 dimensions.

.......

This definition can be used as a metric to qualify enterprise architects. In my books, an enterprise architect must comply with the following:

1. focus space: work for 1000+ people; 
2. architectural space: able to contribute to all architectural domains; expert knowledge in 2-3 domains
3. time span: have experience with complete enterprise life-cycle
4. sector span: min 5 different sectors experience; able to find similarities between sectors
5. problem space: leading min 3 critical enterprise-wide changes
6. solution space: comfortable in min 4 rows
7. cultural space: know culture specifics for the majority of staff members
8. practice space: be good at least in 1 of these roles
9. media space: make fully digital a whole company (100+ people)
10. financial space: 1 M budget minimum
11. people space: able to talk to everyone to explain how EA will address their concerns and change their working habits for the better

Thanks,

AS

Concept "capability" for #BPM, #entarch and #bizarch, version 1

1 Proposed definition of the concept "capability" 

Adapted from: http://www.businessdictionary.com/definition/capability.html

English:
capability, noun
[short] measure of the ability of a component to achieve a particular result
[long] measure of the proven possession of the characteristics and/or means and/or power and/or skills to achieve a particular result

Note1 : Is it necessary "... and/or power ..."?

Note 2: Capability is an attribute of a component - not a component in its own right.


Русский:
результатоспособность или делоспособность(?), сущ.
мера обладания характеристиками и / или средствами и / или навыками для получения конкретного результата

Français:
capacité, nom
une mesure de la possession les caractéristiques et / ou moyens et / ou compétences pour obtenir un résultat particulier

So capability may be:
1. Capability as performance – “Demonstrated Result (DR)” / ”Required Result (RR)”
2. Capability as potential – “Potential Result (PR)” / ”Required Result (RR)”
3. Capability as capacity – “Architected Result (AR)” - maybe non-linear
4. Capability heat map – if RR>DR then (RR-DR)/RR else "1".
5. Capability maturity model – ??

Demonstrated Result – DR (i.e. observed over some time in the past in case of black-box components, e.g. services)

Required Result – RR (e.g. required by the corporate strategy)

Architected Result – AR (i.e. by design in case black-box & white-box components, e.g. processes)

Potential Result – PR (a priori estimation?)

2 Relationships between concepts 

A component may be implemented in three ways:

1. implicit coordination of some assets (e.g. by a service) – capability of a component is based on “demonstrated result” or “potential result” – active approach
2. explicit coordination of some assets (i.e. by a process) - capability of a component is based on “architected result” – proactive approach
3. outsourcing – capability of a component is based on “demonstrated result” or “potential result” – reactive approach (because of the contract life-cycle) 

3 Related concepts 

ability, noun
proven possession of the characteristics and/or means and/or skills to achieve a particular result

system, noun
functional entity formed by a group of interacting, interrelated or interdependent components

Etymology: from the Latin systēma, which in turn is derived from the Greek σύστημα meaning “together”.
Note: enterprise or organisation is a system

structure, noun
internal arrangement of, and relationship between, components

Note: One can say organisational or corporate structure

component, noun
considered as a functional whole constituent part of a system

Note: component may be another system; in this case one can say subsystem

architecture, noun
fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system

capacity, noun
specific feature of a component or an asset, measured in quantity and level of quality, over an extended period

Adapted from: http://www.businessdictionary.com/definition/capacity.html

characteristic of a component, noun
a distinguishing trait, quality, feature or property

asset, noun
something valuable that a component owns, benefits from, or has use of, in achieving a particular result

Adapted from: http://www.businessdictionary.com/definition/asset.html

business process, noun
explicitly-defined coordination for guiding the purposeful enactment of business activity flows

Note: A simple business process is an agreed plan to follow; the plan is a directed graph of (both parallel and sequential) business activities; the plan may include some variants and allow some changes.

business activity, noun
a unit of work

performance, noun
measurement that expresses how well something or somebody is achieving a particular result

key performance indicator, noun
quantifiable performance

throughput, noun
the rate at which a system achieves its goal

4 Groups 

The meaning of the concept “capability” is discussed in the following LinkedIn groups:

1. https://www.linkedin.com/groupItem?view=&gid=84758&type=member&item=5894509808182112260&commentID=-1&trk=groups_item_detail-b-jump_last#lastComment

2. https://www.linkedin.com/groupItem?view=&gid=1175137&type=member&item=5796714327490707456&commentID=-1&trk=groups_item_detail-b-jump_last#lastComment

3. https://www.linkedin.com/groupItem?view=&gid=2639211&type=member&item=5908276236370616321&commentID=-1&trk=groups_item_detail-b-jump_last#lastComment

5 Several variations in opinions about capability 

Q1: Capability – a characteristic of a system (Ravi) or an element of a system (Stephen, Louise) or possibility to reconfigure a system (Lalen)? My current understanding – characteristic of a component

Q2: Capability – an internal characteristic of system or an external characteristic of a system (Christian)? My current understanding – internal characteristic (because I would like to have an opportunity to architect it)

Q3: Capability – a potential only, i.e. to-be, (Ravi, Ben) or can be also demonstrated during operations, i.e. as-is? My current understanding – both

Q4: Capability – only ability or ability + assets (Stephen, Louise)? My current understanding – both are possible depending on situation

Q5: Capability – dimensionless quantity or what is its dimension? My current understanding – mainly dimensionless but sometimes a capacity of the system (i.e. its limiting/design parameter) is used as its capability

Q6: Capability – binary value (only "yes" or "no", "capable" or "not capable") or as a continuous value, e.g. in the rage between 0 and 1? My current understanding – continuous value.

Q7: Capability –it can be applied to components; can it be applied to assets? My current understanding – capability can be applied to both components and assets.

Thanks,
AS

Definition of #BPM and related terms, again

This post is prepared to the LinkedIn discussion "Definition of BPM" http://www.linkedin.com/groupItem?view=&gid=70120&type=member&item=5812680199795388416 which is aimed to prepare a stand-alone definition of Business Process Management (BPM). See also http://social-biz.org/2014/01/02/bpm-definitions/

For me, before talking about a stand-alone definition, let us agree on some basics. Below,  the several terms, related to BPM, are defined.  The definition of a term is in bold; other occurrences are in italic. 

Discipline is a coherent set of governing rules .

Business activity is a unit of work. Individual business activities are interrelated. The relationships between business activities are static (expressed as structure) and dynamic (expressed as behaviour).

Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise.

Business process is an explicitly-defined coordination for guiding the purposeful enactment of business activity flows.
Note: In other words, a business process is an agreed plan (to follow some activities) and its enactment; the plan may include some variants and will possibly allow for some changes during its enactment.

Process template is an abstract description of a process.

Process instance is an enactment of a process template.

Relationships between process template and process instance are described in http://improving-bpm-systems.blogspot.ch/2010/12/illustrations-for-bpm-acm-case.html

Management discipline is a discipline for the better management of the enterprise functioning in support of the enterprise goals.

Process-based management discipline (TQM/QMS, BPR, TPS, 6Sigma, BPM, etc.) is a management discipline which exploit the concept of “business processes”.
Note: They are also called process-based management disciplines.

Business process management (BPM) is a process-based management discipline for the use of any meaningful combination of modeling, automation/implementation, execution, control, measurement and optimization of business processes.

Note 1:
"Meaningful" is an operative word, because execution of business processes differentiates BPM from other process-based disciplines.

Note 2: 

How BPM is differ from other process-based management disciplines? BPM considers all 6 functions (modelling, automation/implementation, execution, control, measurement and optimization) holistically, although they can be distributed in space (e.g. for different divisions of an enterprise) and in time (e.g. optimization based on process feedback). For example: 

• Classic workflow – model, automate, execute, control (primarily by monitoring) 
• TQM/QMS – model, control, optimise (primarily, with corrective actions) 
• BPR – model 
• TPS – everything is potentially in place, but rather implicit 
• 6Sigma – measure, optimise 
• Case management – execute, control 

Note 3:

This definition covers all spectrum from “fixed” to “chaotic” processes.  For example,

• A general plan is agreed and details are for the choice of performer = project (see http://improving-bpm-systems.blogspot.ch/2014/01/is-project-management-bpm-application.html ).
• A general plan does not exist, but there are standard procedures = case
• All pre-defined and fixed = classic workflows
• All pre-defined and changes are possible if justified = some old workflow systems allowed changed but not friendly to users
• Nothing is ever defined = process to be mined

Imagine having all of this in one box, like a gear box - lower transmission -> more manoeuvrability 

A possible stand-alone definition of BPM can be as the following (WHY it is need, HOW it is done, WHAT is used):

Business Process Management (BPM) is coherent set of governing rules to better management of the enterprise functioning in support of the enterprise goals for the use of any meaningful combination of modeling, automation/implementation, execution, control, measurement and optimization of explicitly-defined coordination for guiding the enactment of business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise. 

A variant with the direct substitution:

Business process management (BPM) is < a coherent set of governing rules> for the use of any combination of modeling, automation/implementation, execution, control, measurement and optimization of business processes.

Thanks,

AS

#bizarch artefacts definition; again

This post is written for the LinkedIn discussion "Whats the defference between, a Business Capability, a Business Function, a Business Process and a Service?"
In this post, I collected (and refined) several #bizarch definitions from the posts about #bizarch.

activity, noun
elementary or indivisible unit of work

function, noun
abstract and self-contained grouping of activities that collectively satisfy a specific operational purpose

Remark 1: Functions are unique within the enterprise and should not be repeated.
Remark 2: Some functions can be decomposed into smaller groups of activities, and thus the functional view has a hierarchical structure. (Without taking into account that one function may use other functions to accomplish its purpose.)
Remark 3: The structure of functions is not always the same as that of the organisation chart; in many cases, some organisational units can span several functions. Furthermore, organization charts may change while the function does not.
Remark 4: A business function typically has the suffix ‘management’ in its name (e.g. ‘Customer Relationship Management’), but it can also be a noun (e.g. ‘Marketing); usually, function name specifies something that is performed continuously.
Remark 5: The functional view emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints). Usually, the hierarchical structure of business functions is very static (with a low rate of change).

service, noun
explicitly-defined, operationally-independent, and consumer-facing repeatable unit of functionality that creates a particular result for the consumer

Remark 1: It is considered that there are internal (even within an enterprise) providers and consumers as well as external consumers.
Remark 2: A service may wrap several functions. (In IT, we call them operations.)
Remark 3: A service is self-contained in some extend.
Remark 4: Complex services are created by means of the coordination of more simple services and/or activities (in the same way that an orchestra is a coordination of individuals and their actions). In this sense, an enterprise is a mega-service composed of a network of nano-services.

process, noun
explicitly-defined coordination of services and/or activities to produce a particular result

Remark 1: Processes are HOW of the business.
Remark 2: Services and processes can be considered to be intimately related since in real terms

• all processes are services, 
• some operations (or a very detailed function wrapped by a service) of a service can be implemented  as a process, and 
• a process includes services in its implementation. 

capability, noun
the proven possession of characteristics required to perform a certain kind of work (i.e. as a particular service to produce a particular result) with the expected performance

Remark 1: Capability needs to “understand” the mechanics of delivering that service. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.
Remark 2: Capability is named after the expected result/performance (http://ingenia.wordpress.com/2010/10/19/modelling-behaviour/), e.g. “2CV”.

Why do we need all of them? 
Functions is an internal view of an enterprise (or supply-side). Services is a consumer view of functions (or demand-side). Capabilities is a performance view (or matching demand and supply) including both expected and realised performance.

Each service is associated with an owner who is responsible for delivering the promised results in all instances in which that service has been requested. That owner has

1.  to know/estimate the demand-side needs (the service may have many different consumers who will be using it with different frequencies), and 
2.  to design/organise/create in advance the supply-side capabilities to ensure those needs are satisfied. 

So, how can one ensure that a service has the required characteristics? There are three control options:

1. by contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it; 
2. by measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc.; 
3.  by design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc. 

The first option works with some support services, the second option can work satisfactorily with lead services and the third option should be used for core business services. The core business services can’t be outsourced, can’t be bought and must not be “damaged”.

One of the models of the "mechanics" of provisioning a service is a business process. The explicit coordination brings several advantages.

• It allows planning and simulation of the behaviour of a service to evaluate its performance. If that service uses other services, then the demand-side needs for those services can also be evaluated. 
• It can be made to be executable, thus guiding how work is done. 
• It allows control that the actual behaviour of the service matches its intended behaviour, thus pro-actively detecting potential problematic situations. 
• It allows the measurement within a service of the dynamics of different characteristics, e.g. valuing, costing, risk, etc.

Thus a process is a way to guarantee a capability of a service to perform a function.

And architects are responsible for this how (see http://improving-bpm-systems.blogspot.com/2013/03/architects-are-responsible-for-how-thus.html).

Thanks,
AS