Better architecting with – digital models

1 The expression “all models are wrong” is wrong

"All models are wrong" is a well-known aphorism from statistics (attributed statistician to George Box, 1976), which has been used in other disciplines. A modern book on system engineering claims that "The map is not the territory, the menu can’t be eaten, the drawings do not fly, the source code does not store the values of its variables during execution". Let's analyse these statements.

The territory existed before its map. A map is an informational (or digital right now) "twin" of the territory. Since the territory is a natural (made by nature) object, its digital "twin" (made by man) is secondary and approximative.

The menu is the chef's plan and, at the same time, the informational (or digital right now) "twin" of kitchen services. Kitchen services are planned ahead for the several good reasons: discuss them with all the involved persons, organize work, optimize costs and reduce risks. Thus the menu (as a planning tool) helps in achieving the result, but it is not mandatory to provide services. In this case, the informational (or digital right now) "twin" may appear before the physical "twin".

It is clear that the drawings do not fly, but there is no flight without them. Those drawings is a necessary "part" of the aircraft to be manufactured according to these drawings. It is clear that the drawings, in themselves, are not a sufficient "part" of the aircraft because there is a long way from the drawing to the working copy. However, we can consider that the drawings are informational (or digital right now) "ancestors" of aircrafts. In this case, the informational (or digital right now) "twin" is necessarily created before its physical "twin".

Well, finally, the computer program and its source code. What is the relationship between them? There is no program without its source code. The source code can be expressed in several views - in high-level language and in the language of machine instructions (i.e. assembler). This is common but not necessary, because the source code can be interpreted directly without being translated into machine instructions. Wait, this looks rather familiar.

Wow, this is the genetic code for a bionic program! The genetic code does not have all the details, but it determines (albeit partially) the future bionic system. Of course, any bionic system is an adaptive system with a complex "bootstrap" procedure. While modern software systems must be highly-dependable.

So, in ther digital world we copy the mother nature – we create a piece of digital genetic code (in some programming languages) and from it we create a program with the help of the digital environment. Thus, the source code is the main part of the program. Both they are digital artefacts. In this case, there is only an informational (or digital right now) "twin". Well then, it is not a "twin" but an "original"! And this is a digital model.

	Physical form	Digital form
Primarily	1. Territory	2. Menu (probably) 3. Drawings (mandatory) 4. Program (inevitable)
Secondarily	2. Meal 3 Plane	1. Map

2 Obliterating differences between architecture and its description in the digital world

For the digital world, we must slightly adjust some of the provisions of ISO/IEC/IEEE 42010 Systems and software engineering - Architecture description. This standard clearly separates the architecture of the system and the description of the architecture. In accordance with this standard, the architecture description consists of models. But in the digital world, models can be also elements of the system-of-interest.

The usage of digital models:

1. simplifies the choice of elements and system-of-interest options, 
2. allows making predictions about the behaviour of the system-of-interest and 
3. replaces the system-of-interest itself, for example, for training purposes. 

Such digital models are machine-readable and machine-executable. For example, a business process is not only an illustration, but also a piece of the source code of the system-of-interest. This increases the importance of Domain-Specific Languages (DSLs) through which some elements of the system-of-interest can be defined in business terms. For example, BPMN is a DSL. (As many years ago with the advent of SGML and HTML people began to say: the program becomes a document, in a document becomes a program.) Also, the appearance of the machine-executed elements of the system-of-interest in the early stages of its life cycle allows us to speak about the emergence of the BizDevOps culture as a natural up-stream extension of the DevOps culture.

The logic of the architecture viewpoints changes. Now, they are designed to systematically create model-types, some of which will be digital, i.e. machine-executable elements and/or machine-readable elements (or nomenclatures, for example, a list of all roles). Architecture viewpoints become some kind of aqueduct columns that support the logic of creating digital systems.

Fragment of the longest (132 km) Roman aqueduct, Tunisia.
(by the way, some parts of this structure are still working and used by local people)

Relationships between models also change. Previously, it was considered that models and views were created solely for stakeholders and, often, different models were created by different people thus models must be permanently aligned, e.g. by a chief architect. With the digital models, there is a lot of interest in semi-automatic and automatic creation of some models from already existing models. For example, if there is a functional map of the organization, then you can automatically offer the initial version of the organizational structure.

It is observed that the difference between the system-of-interest and its architecture description is disappearing in two directions:

• Some elements of the system-of-interest can be used instead of some architecture description models. 
•  Some architecture description models became the system elements. 

Ideally, the whole system description should be automatically generated from the existing system elements. This reminds us the “literate programming” from prof. Knuth – see https://www-cs-faculty.stanford.edu/~knuth/lp.html

It is clear that for each type of systems some of its digital models are system-forming elements. Imagine a directed and non-cyclic graph of dependencies between nodes as models and let us assign to its edges measure of the complexity of the "transition" between nodes. Then the models from which one can easily create the majority of other models are system-forming models.

All this is partially described in the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW


Thanks,
AS