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:

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.htmlhttp://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.

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.

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

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

set of characteristics which makes up the concept

totality of objects to which a concept corresponds

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

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

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



Enterprise patterns: PEAS - example CUBE platform

An example of a Corporate Unified Business Execution (CUBE) platform.

This platform is architected from the several components. For each components, a set of capabilities was defined and then best-for-fit COTS products were selected.

See all the blogposts about PEAS pattern - http://improving-bpm-systems.blogspot.ch/search/label/PEAS

See all the blogposts about platforms - http://improving-bpm-systems.blogspot.ch/search/label/%23platform



Mistery of end-to-end processes

Inspired by http://bpm.com/bpm-today/in-the-forum/should-processes-be-end-to-end-1

If you want to know how an input into your enterprise (which is a system of processes -- http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ) influences some outputs from it then you must know "End-to-End (E2E) processes". But in the majority of situations, it is not possible to present an E2E process as an BPMN diagramme because there are various coordination techniques (see http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html ) may be used to "construct" E2E processes from classic (presentable as BPMN diagramme) processes.

This is a mystery of E2E processes - they do exist but in many situations they can't be made explicit and machine-executable with the majority of modern BPM-suite tools.