# On Domain Modelling and Requisite Variety

Henderik A. Proper, Giancarlo Guizzardi

► To cite this version:

Henderik A. Proper, Giancarlo Guizzardi. On Domain Modelling and Requisite Variety. 13th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling (PoEM 2020), Nov 2020, Riga, Latvia. pp.186-196, 10.1007/978-3-030-63479-7_13 . hal-03434642

HAL Id: hal-03434642

https://inria.hal.science/hal-03434642

Submitted on 18 Nov 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# On Domain Modelling and Requisite Variety

## Current state of an ongoing journey

Henderik A. Proper¹,² and Giancarlo Guizzardi³

¹ Luxembourg Institute of Science and Technology (LIST), Belval, Luxembourg

² University of Luxembourg, Luxembourg

³ Free University of Bolzano-Bozen, Italy

e.proper@acm.org, giancarlo.guizzardi@unibz.it

**Abstract.** In the 1950's, W. Ross Ashby introduced the *Law of Requisite Variety* in the context of General Systems Theory. A key concept underlying this theory is the notion of variety, defined as the total number of distinct states of a system (in the most general sense). We argue that domain modelling (including enterprise modelling) needs to confront different forms of variety, also resulting in a need to “reflect” / “manage” this variety. The aim of this paper is to, inspired by Ashby's *Law of Requisite Variety*, explore some of the forms of variety that confront domain modelling, as well as the potential consequences for models, modelling languages, and the act of modelling. To this end, we start with a review of our current understanding of domain modelling (including enterprise modelling), and the role of modelling languages. We then briefly discuss then notion of Requisite Variety as introduced by Ashby, which we then explore in the context of domain modelling.

**Keywords:** domain modelling · conceptual modelling · requisite variety

## 1 Introduction

In the context of software engineering, information systems engineering, business process management, and enterprise engineering & architecting in general, many different kinds of models are used. In this paper, we consider each of these kinds of models as being valued members of a larger family of *domain models*.

Domain models have come to play an important role during all stages of the life-cycle of enterprises and their information and software systems, which also fuels the need for more fundamental reflection on domain modelling itself. This includes *the act of modelling, the essence of what a model is, and the role of (modelling) languages*.

Such fundamental topics have certainly been studied by different scholars (e.g. [1, 37, 32, 14, 24, 38]), as well as by ourselves (see e.g. [22, 31, 16, 17, 8, 18, 12, 7, 29, 15]).

At the same time many challenges remain (see e.g. [18, 29]).

In this paper, we focus on the challenge of how domain modelling (including enterprise modelling) needs to deal with different forms of variety, also resulting in a need to “reflect” / “manage” this variety. In line with this, we will explore some of the forms of variety that confront domain modelling, as well as the potential consequences for models, modelling languages, and the act of modelling. We will do so from the perspective
of the *Requisite Variety*. This concept has been introduced by W. Ross Ashby [2], in
the context of General Systems Theory, as part of the Law of Requisite Variety, where
*variety* refers to the number of states of a system (system in the most general sense).

We see this short paper as part of an ongoing “journey” we undertake, with the aim
of deepening our insights into the foundations of domain modelling, mixing our theo-
retical work and practical experiences in developing (foundational and core) ontologies
and domain models, associated modelling languages, frameworks, and methods.

The remainder of this paper is structured as follows. Section 2 starts with a review of our current understanding of domain modelling, while section 3 then complements this with our view on the modelling languages. We then continue, in section 4, by reviewing the Law of Requisite Variety as introduced by Ashby [2], and the notion of Requisite Variety in particular. The notion of Requisite Variety is then, in section 5, explored further in the context of domain modelling.

## 2 Domain Models

Based on general foundational work by e.g. Apostel [1], and Stachowiak [37], more recent work on the same by different authors [32, 19, 38, 33], as well as our own work [22, 31, 15, 16, 7], we consider a *domain model* to be: An *artefact* that is *ac knowledged* by an *observer* to *represent* an *abstraction* of some *domain* for a particular *purpose*. Each of the stressed words in this definition requires a further explanation, and as we will see in section 5, results in different kinds of *variety*.

A model is seen as an *artefact*; i.e. it is something that exists outside of our minds. In our fields of application, this artefact typically takes the form of some “boxes-and-lines” diagram. More generally, however, it can, depending on the *purpose* at hand, take different forms including text, mathematical specifications, physical objects, etc.

With *domain*, we refer to “anything” that one can speak / reflect about explicitly. It could be “something” that already exists in the “real world”, something desired towards the future, or something imagined. The *observer* observes the domain by way of their senses and / or by way of (self) reflection. What results in the mind of the observer is, what is termed a *conceptualisation* in [16], but also what is termed *conception* in [13].

When the modelled *domain* pertains to a part / perspective / aspect of an enterprise, then one can indeed refer to the resulting domain model as an *enterprise model*. This may, include enterprise (wide) data models, enterprise architecture models, etc.

As, it is ultimately the observer who needs to *acknowledge* the fact that the *artefact*
is indeed a model of the domain, it actually makes sense to treat *their* conceptualisa-
tion / conception of the domain as the de-facto “proxy” for the domain. As such, we
should also realise that the *observer* observes the model (as artefact) as well, which
therefore also creates a conceptualisation (in their mind) of the modeler. The observer,
therefore, needs to validate the alignment between their model-conceptualisation and
their domain-conceptualisation, using the *purpose* as alignment criterion.

Models are produced for a *purpose*. In the context of enterprise modelling, [28] suggest (at least) seven high-level purposes for the creation of enterprise models: *understand, assess, diagnose, design, realise, operate and regulate*. In specific situations, these high-level purposes will need to be made more specific in terms of, e.g., the
need for different stakeholders to *understand*, *agree*, or *commit* to the content of the model [30], or for a computer to be able to interpret the model in order to e.g. automatically analyse it, use it as the base of a simulation / animation, or even execute it.

A model is the representation of an *abstraction* of the domain. This implies that, in line with the *purpose* of the model, some (if not most) “details” of the domain are consciously filtered out. For domain modelling, important abstraction flavours are [5]: (1) *selection*, where we decide to only consider certain elements and / or aspects of the domain; (2) *classification* (including typing); (3) *generalisation*; and (4) *aggregation*.

As a result, an observer actually needs to harbour (at least) four conceptualisations: (1) a “full” conceptualisation of the domain (as they “see” it), (2) a conceptualisation of the purpose for the model, (3) an abstracted conceptualisation of the domain, (4) a conceptualisation of the artefact that is (to be) the model representing the latter abstraction.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Conceptualisations involved in domain modelling</figcaption></figure>

The latter has been illustrated in figure 1, where we see how the conceptualisation of the purpose modifies the abstraction, and the alignment between the conceptualisations of the model and the abstraction. The purpose may actually already influence the original observation of the domain. When the model-conceptualisation corresponds to the abstraction-conceptualisation, then the observer would agree that the artefact is a model of the domain for the given purpose. As a consequence, different models may indeed result in the same model-conception, in which case (for the observer) they are equivalent models of the same domain (for the same purpose). If the observer is “the modeller”, i.e. the person creating the model, they also need to “shape” the model in such a way that it best matches their *desired* model-conceptualisation.
In line with the above discussion, a domain model should be (the representation of) the abstraction of (the conceptualisation of) a domain. At the same time, for different *computational* purposes, such as the ability to use the model as a base for simulation, computer-based reasoning, execution, or database design, it may be necessary to make “compromises” to the conceptual model. These compromises result in a model that does *not* correspond to (an abstraction of) the original domain. They are essentially models of a “close enough” approximation of (the conceptualisation of) the original domain.

This is where we suggest to make a distinction between *conceptual domain models* and *computational design model* in the sense that a *conceptual domain model* is: “A *model of a domain*, where the purpose of the model is *dominated by the ambition to remain as-true-as-possible to the original domain conceptualisation*”, while a *computational design model* includes compromises needed to support computational design considerations that e.g. support simulation, animation, or even execution of the model.

Note the use of the word *ambition* in the definition of conceptual domain model. We are not suggesting there to be a crisp border between conceptual models and computational design models. However, the word *ambition* also suggest that a modeller / observer, as their insight in a domain increases, should be driven to reflect on the conceptual purity of their conceptualisation and of the resulting model.

Computational design models certainly have an important role to play. However, it is important to be aware of the compromises one has made to the original domain conceptualisation. As such, it is also possible that one conceptual model has different associated computational design models, each meeting different purposes.

## 3 The Role of Modelling Languages

In its most general form a language identifies the conventions to which the expressions in the language should conform to. In a domain modelling context, these conventions are often equated to a definition in terms of a concrete visual syntax, and a grammar in terms of a set of rules, while the semantics are defined in terms of some mathematical structure (*formal semantics* [21]) or an ontological theory (*ontological or real-world semantics* [12]). However, style guides, reference models, patterns, etc, can also be seen as part of the set of conventions that define a (modelling) language.

Sometimes, a modelling language comes in the form of a number of connected sub-languages. Typical examples are ARIS [34], UML [26] and ArchiMate [3, 23], each featuring more specific languages focused on one aspect or layer, as well as (some more, some less) the integration / coherence between these aspects or layers.

We argue that, if a model is represented in some (pre-)defined language, then the (relevant part of the) definition of that language should actually be seen as being a *part* of the model. This also allows us to illustrate the role of the modelling language in the sense of providing a trade off. If, given some purpose, there is a need to represent an abstraction A, and one has a choice between using a language L1 with an elaborate set of conventions (the light grey part), or using a language L2 with only a more limited set of conventions (the dark grey part), then this will lead to a difference in the size of the (situation specific parts of the) model one would still need have to specify. This has been illustrated in figure 2, where we show that the “size” of the two models as a whole
remains the same. Of course, the notion of “size” is to be clarified. We will return to this
in section 5 when discussing the consequences of the Requisite Variety, as the “size”
indeed connects directly to the variety of the model.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Trade off between languages with different sizes of their definition</figcaption></figure>

A final consideration is the fact that the conventions which define a modelling lan-
guage need to reflect the intended set of valid models. Which also means that these
conventions need to accommodate all the possible purposes of these intended models.
For standardised general purpose languages, such as UML [26], BPMN [27] or Archi-
Mate [3, 23], this does lead to tensions, as the set of purposes keeps growing, resulting
in a continuous growth of the set of allowable models, thus also triggering a growth in
the “size” of the body of conventions defining these languages [8, 6].

As such, we should also realise that the grey parts in figure 2 amount only to that
part of the respective languages that are relevant for the interpretation of the white parts.
However, the other parts of the language will also need to be learned by the “users” of
the language, or at least be visible as part of the standard.

4 Requisite Variety

The *Law of Requisite Variety* by W. Ross Ashby [2] is one of the defining contributions to the field of General Systems Theory and Cybernetics in particular. This law postulates that when a system *C* aims to control/ regulate parts of the behaviour of a system *R*, then the variety of *C* should (at least) match the variety of that part of *R*'s behaviour it aims to control; *"only variety can destroy variety"* [2, page 2020]. The notion of *Requisite Variety*, which also builds on Shannon's Information Theory [35], refers to the variety that is *required* from the controlling system, where *variety* refers to the number of states of a system (system taken in the most general sense).

In the context of the *Law of Requisite Variety* it is also important to clearly under-
stand the scope of the system that would need to be controlled. For example, controlling
a car in the sense of getting it into motion and steering it in a certain direction on an
empty car park, is quite different from driving a car through busy traffic. The latter
system clearly needs to deal with a larger variety.

It is also important to realise that the earlier remark "*the variety of C should (at least) match the variety of that part of R's behaviour it aims to control*", is actually directly related to the notion of abstraction as discussed in figure 1. The controlling system *C* does need, in line with its steering goal / purpose, to have access to a relevant abstraction / model of the aspects of *R* it aims to control. More recently, [20] formulated this as (stress added by us): "*The analogy of structure between the controller and the controlled was central to the cybernetic perspective. Just as digital coding collapses the*
space of possible messages into a simplified version that represents only the difference that makes the difference, so the control system collapses the state space of a controlled system into a simplified model that reflects only the **goals** of the controller. Ashby's law does not imply that every controller must model every state of the system but **only those states that matter for advancing the controller's goals**. Thus, in cybernetics, the goal of the controller becomes **the perspective from which the world is viewed.**

In our understanding, domain modelling involves different flavours of variety. In the next section, we will explore these in more detail. The existence of these varieties (as well as complexities) has inspired us to try and follow the logic behind Ashby's *Law of Requisite Variety*, and apply this in the context of domain modelling. In doing so, however, we should indeed not forget that the *Law of Requisite Variety*, is defined in the context of one system controlling (aspects of) another system. As such, it would have been better to refer to it as the *Law of Requisite Variety of systems controlling systems*.

The latter raises three main questions: (1) how to define variety in the context of domain modelling, (2) what is “that” what may need to have requisite variety, and (3) would this indeed result in a law akin to the *Law of Requisite Variety*? In line with the explorative nature of this paper, this paper will certainly not provide the full answer to these questions. In the next section, while discussing (some of the) flavours of variety as we (currently) understand to exist in relation to domain modelling, we will also reflect on these three questions.

# 5 Requisite Variety in Domain Modelling

In this section, we explore (some of) the flavours of requisite variety we may encounter in the context of domain modelling.

*Requisite variety needed to conceptualise a domain* – When conceptualising a domain (see figure 1), an observer needs to deal with *variety* in the domain, *uncertainties about* properties of the domain, as well as *complexity of* the domain. The combination of these yields a requisite variety that needs to be met by the observer(s) of the domain that is to be modelled, in the sense that:

- the observer should harbour a conceptualisation in their mind, catering for the variety-in, uncertainties-about, and complexity-of the domain,

- understanding this conceptualisation (e.g. to be able to make an abstraction in line with a modelling purpose) requires a certain “mental state space”,

- the later corresponds to the need for variety from the observer; i.e. requisite variety.

Towards future research, it would be beneficial to better qualify, or even quantify, how the variety-in, uncertainties-about, and complexity-of the domain results in a requisite variety that needs to be (potentially) matched by the cognitive ability of the observer.

*Residual requisite variety in relation to the model purpose* – Driven by the model purpose, there is a need to capture a relevant (but not trivialised) part of the domain. In other words, the observer(s) will need to make an abstraction (see figure 1) of the domain. As the abstraction involves filtering out “details”, one would expect that the residual requisite variety needed from the observer, to harbour the abstraction in their mind, is less than the requisite variety needed for the “full” domain conceptualisation.
In line with figure 1, the resulting model will also need to meet the residual requisite variety, in the sense that the latter needs to be captured in terms of the “informational payload” of the model (indeed, also linking back to the information-theoretical [35] roots of Ashby’s *Law of Requisite Variety*.

The relation between the original requisite variety of a domain, and the residual requisite variety of an abstraction, is also related to the point made in [20] regarding the need of a controlling system to have a model of the controlled system, tuned to the steering goals.

*Requisite variety trade-offs related to modelling languages* – In section 3, we already pointed (see figure 2) at the need to essentially include the (relevant parts of the) definition of the modelling language in a model. The whole of the specified model (the white parts in figure 2) and the parts provided by the language (the gray parts in figure 2) need to match the variety of the abstraction. The border between these, however, depends on the language used.

Of course, when using a “thin” language with a small set of conventions, it may be easy to learn the language, and also easy to create modelling tools that support the language. At the same time, specifying the actual models (the white parts in figure 2) will require more effort than it would cost when using a language with more pre-defined concepts and conventions. Provided of course, that these (pre-defined concepts and conventions) indeed meet the modelling purpose, and domain, at hand.

Here it is also interesting to refer back to older discussions (in the field of information systems engineering) regarding the complexity of modelling notations. As also mentioned by Moody [25], models need to provide some informational payload. A simpler notation might be easier to learn, and easier to look at when used in models, but when it cannot “carry” the needed informational payload, then the more “simpler” notation may actually turn out to be a liability (given that it transfers the modeling complexity to the modeler).

Towards future research, it would also be beneficial to better qualify, or even quantify, how abstraction actually results in a reduction of requisite variety facing observers of a domain, as well as the “informational payload” needed from the model. In addition, in terms of such insights, it would also be possible to more specifically reason about that part of the variety that should preferably be covered by a (domain specific language), and which part should be left to the actual model.

*Requisite variety originating from social-complexity* – The context in which the model is to be used may involve different stakeholders, uncertainty about their interests, backgrounds, etc. This is where, based on experiences from the IBIS project [9], Conklin coins the term social complexity [10, 11].

Social complexity poses a risk on the successful outcome of development projects. As such, it is an aspect (with its variety) of a system (the development project), which would need to be managed. In this case, the original *Law of Requisite Variety* in the sense of *Law of Requisite Variety of systems controlling systems*, seems to apply.

Part of the variety that is due to the social complexity will need to be met / managed by the overall development / engineering process. However, the more finer grained processes / tasks in which domain models are actually created / used, in particular when multiple stakeholders are involved, will also need to deal with this variety. Especially
since, in terms of figure 1, they will need to agree on the purpose / goals of the model,
the abstraction to be made, and its representation in terms of the model.

A future research challenge would be to, on the one side, once again further qual-
ify or even quantify the involved variety, as well as show how different collaborative
modelling strategies [4, 36] may deal with this variety.

6 Conclusion

In this paper, inspired by Ashby's *Law of Requisite Variety*, we explored some of the
forms of variety that confront domain modelling, as well as the potential consequences
for models, modelling languages, and the act of modelling.

We first provided a review of our current understanding of domain modelling (in-
cluding enterprise and conceptual modelling), and the role of modelling languages.

Using this as a base, we then explored some of the possible consequences / chal-
lenges of the notion of requisite variety in a domain modelling context.

As mentioned in the introduction, we see this paper as part of an ongoing “journey”,
with the aim of deepening our insights into the foundations of domain modelling. In
line with this, we certainly do not claim this paper to be a fully finished work. These
are reflections providing a snapshot of our current understanding of these topics. We
hope they will trigger debates in the modeling community, which we expect to provide
fruitful insights to the next steps of this journey.

Acknowledgements

We would like to thank the anonymous reviewers for their comments on earlier versions
of this short paper.

References

1. Apostel, L.: Towards the Formal Study of Models in the Non-Formal Sciences. Synthese **12**, 125–161 (1960)

2. Ashby, W.R.: An Introduction to Cybernetics. Chapman & Hall, London, United Kingdom (1956)

3. Band, I., Ellefsen, T., Estrem, B., Iacob, M.E., Jonkers, H., Lankhorst, M.M., Nilsen, D., Proper, H.A., Quartel, D.A.C., Thorn, S.: ArchiMate 3.0 Specification. The Open Group (2016)

4. Barjis, J., Kolfschoten, G.L., Verbraeck, A.: Collaborative Enterprise Modeling. In: Proper, H.A., Harmsen, A.F., Dietz, J.L.G. (eds.) Advances in Enterprise Engineering II - First NAF Academy Working Conference on Practice-Driven Research on Enterprise Transformation, PRET 2009, held at CAiSE 2009, Amsterdam, The Netherlands, June 11, 2009. Proceedings. Lecture Notes in Business Information Processing, vol. 28, pp. 52–66. Springer, Heidelberg, Germany, Amsterdam, the Netherlands (June 2009)

5. Batini, C., Mylopoulos, J.: Abstraction in conceptual models, maps and graphs. In: Tutorial presented at the 37th Intl. Conf. on Conceptual Modeling, ER 2018, Xi’an, China (2018)

6. Bjeković, M.: Pragmatics of Enterprise Modelling Languages: A Framework for Understanding and Explaining. Ph.D. thesis, Radboud University, Nijmegen, the Netherlands (2018)
7. Bjeković, M., Proper, H.A., Sottet, J.S.: Embracing pragmatics. In: Yu, E.S.K., Dobbie, G., Jarke, M., Purao, S. (eds.) Conceptual Modeling - 33rd International Conference, ER 2014, Atlanta, GA, USA, October 27-29, 2014. Proceedings. Lecture Notes in Computer Science, vol. 8824, pp. 431–444. Springer, Heidelberg, Germany (2014)

8. Bjeković, M., Proper, H.A., Sottet, J.S.: Enterprise modelling languages - just enough standardisation? In: Shishkov, B. (ed.) Business Modeling and Software Design - Third International Symposium, BMSD 2013, Noordwijkerhout, The Netherlands, July 8-10, 2013, Revised Selected Papers. Lecture Notes in Business Information Processing, vol. 173, pp. 1–23. Springer, Heidelberg, Germany (2014)

9. Conklin, J.: The IBIS Manual: a short course in IBIS methodology. Touchstone (2003)

10. Conklin, J.: Dialogue Mapping: Building Shared Understanding of Wicked Problems. John Wiley & Sons, New York, New York (2005)

11. Conklin, J.: Wicked Problems and Social Complexity. Tech. rep., CogNexus Institute, Edgewater, Maryland (2006)

12. de Carvalho, V., Almeida, J., Guizzardi, G.: Using reference domain ontologies to define the real-world semantics of domain-specific languages. In: International Conference on Advanced Information Systems Engineering. pp. 488–502. Springer (2014)

13. Falkenberg, E.D., Verrijn-Stuart, A.A., Voss, K., Hesse, W., Lindgreen, P., Nilsson, B.E., Oei, J.L.H., Rolland, C., Stamper, R.K. (eds.): A Framework of Information Systems Concepts. IFIP WG 8.1 Task Group FRISCO, IFIP, Laxenburg, Austria (1998)

14. Frank, U.: Multi-perspective Enterprise Modeling (MEMO) - Conceptual Framework and Modeling Languages. In: HICSS '02: Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS'02)-Volume 3. p. 72. IEEE Computer Society Press, Los Alamitos, California, Washington, DC (2002)

15. Guarino, B., Guizzardi, G., Mylopoulos, J.: On the philosophical foundations of conceptual models. Information Modelling and Knowledge Bases XXXI 321, 1 (2020)

16. Guizzardi, G.: On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models. In: Vasilecas, O., Eder, J., Caplinskas, A. (eds.) Databases and Information Systems IV - Selected Papers from the Seventh International Baltic Conference, DB&IS 2006, July 3-6, 2006, Vilnius, Lithuania. Frontiers in Artificial Intelligence and Applications, vol. 155, pp. 18–39. IOS Press (2006)

17. Guizzardi, G.: Theoretical foundations and engineering tools for building ontologies as reference conceptual models. Semantic Web 1(1, 2), 3–10 (2010)

18. Guizzardi, G.: Ontological patterns, anti-patterns and pattern languages for next-generation conceptual modeling. In: International Conference on Conceptual Modeling. pp. 13–27. Springer (2014)

19. Harel, D., Rumpe, B.: Meaningful Modeling: What's the Semantics of "Semantics"? IEEE Computer 37(10), 64–72 (2004). https://doi.org/10.1109/MC.2004.172

20. Hillis, W.D.: The first machine intelligences. In: Brockman, J. (ed.) Possible Minds: Twenty-Five Ways of Looking at AI, pp. 170–180. Penguin Publishing Group (2019)

21. Hofstede, A.H.M.t., Proper, H.A.: How to formalize it?: Formalization principles for information system development methods. Information and Software Technology 40(10), 519–540 (October 1998)

22. Hoppenbrouwers, S.J.B.A., Proper, H.A., Weide, T.P.v.d.: A fundamental view on the process of conceptual modeling. In: Delcambre, L., Kop, C., Mayr, H.C., Mylopoulos, J., Pastor, O. (eds.) Conceptual Modeling - ER 2005, 24th International Conference on Conceptual Modeling, Klagenfurt, Austria, October 24-28, 2005, Proceedings. Lecture Notes in Computer Science, vol. 3716, pp. 128–143. Springer, Heidelberg, Germany (June 2005)

23. Lankhorst, M.M., Hoppenbrouwers, S.J.B.A., Jonkers, H., Proper, H.A., Torre, L.v.d., Arbab, F., Boer, F.S.d., Bonsangue, M., Iacob, M.E., Stam, A.W., Groenewegen, L., Buuren, R.v.,
Slagter, R.J., Campschroer, J., Steen, M.W.A., Bekius, S.F., Bosma, H., Cuvelier, M.J.,
ter Doest, H.W.L., van Eck, P.A.T., Fennema, P., Jacob, J., Janssen, W.P.M., Jonkers, H.,
Krukkert, D., van Leeuwen, D., Penders, P.G.M., Veldhuijzen van Zanten, G.E., Wieringa,
R.J.: Enterprise Architecture at Work – Modelling, Communication and Analysis. The En-
terprise Engineering Series, Springer, Heidelberg, Germany, 4th edn. (2017)

24. Mahr, B.: On the epistemology of models. In: Abel, G., Conant, J. (eds.) Rethinking Epistemology, pp. 1–301. De Gruyter (2011)

25. Moody, D.L.: The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering 35(6), 756–779 (2009)

26. OMG: OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2. Tech. rep.,
The Object Management Group, Needham, Massachusetts (November 2007)

27. OMG: Business Process Modeling Notation, V2.0. Tech. Rep. OMG Document Number:
formal/2011-01-03, Object Management Group, Needham, Massachusetts (January 2011)

28. Proper, H.A.: Digital Enterprise Modelling - Opportunities and Challenges. In: Roelens, B., Laurier, W., Poels, G., Weigand, H. (eds.) Proceedings of 14th International Workshop on Value Modelling and Business Ontologies, Brussels, Belgium, January 16-17, 2020. CEUR Workshop Proceedings, vol. 2574, pp. 33–40. CEUR-WS.org (2020), http://ceur-ws.org/Vol-2574/short3.pdf

29. Proper, H.A., Bjeković, M.: Fundamental challenges in systems modelling. In: Mayr, H.C., Rinderle-Ma, S., Strecker, S. (eds.) 40 Years EMISA 2019. pp. 13–28. Gesellschaft für Informatik e.V., Bonn (2020)

30. Proper, H.A., Hoppenbrouwers, S.J.B.A., Veldhuijzen van Zanten, G.E.: Communication of enterprise architectures. In: Enterprise Architecture at Work – Modelling, Communication and Analysis [23], pp. 59–72

31. Proper, H.A., Verrijn-Stuart, A.A., Hoppenbrouwers, S.J.B.A.: On utility-based selection of architecture-modelling concepts. In: Hartmann, S., Stumptner, M. (eds.) Conceptual Modelling 2005, Second Asia-Pacific Conference on Conceptual Modelling (APCCM2005), Newcastle, NSW, Australia, January/February 2005. Conferences in Research and Practice in Information Technology Series, vol. 43, pp. 25–34. Australian Computer Society, Sydney, New South Wales, Australia (2005)

32. Rothenberg, J.: The Nature of Modeling. In: Artificial intelligence, simulation & modeling, pp. 75–92. John Wiley & Sons, New York, New York, United States of America (1989)

33. Sandkuhl, K., Fill, H.G., Hoppenbrouwers, S.J.B.A., Krogstie, J., Matthes, F., Opdahl, A.L., Schwabe, G., Uludag, Ö., Winter, R.: From Expert Discipline to Common Practice: A Vision and Research Agenda for Extending the Reach of Enterprise Modeling. Business & Information Systems Engineering 60(1), 69–80 (2018)

34. Scheer, A.W.: Architecture of Integrated Information Systems: Foundations of Enterprise Modelling. Springer, Heidelberg, Germany, Secaucus, New Jersey (1992)

35. Shannon, C.E.: A Mathematical Theory of Communication. In: The Bell System Technical Journal. vol. 22, pp. 379–423, 623–656 (1948)

36. Ssebuggwawo, D., Hoppenbrouwers, S.J.B.A., Proper, H.A.: Interactions, goals and rules in a collaborative modelling session. In: Persson, A., Stirna, J. (eds.) The Practice of Enterprise Modeling, Second IFIP WG 8.1 Working Conference, PoEM 2009, Stockholm, Sweden, November 18-19, 2009. Proceedings. Lecture Notes in Business Information Processing, vol. 39, pp. 54–68. Springer, Heidelberg, Germany (2009)

37. Stachowiak, H.: Allgemeine Modelltheorie. Springer, Heidelberg, Germany (1973)

38. Thalheim, B.: The Theory of Conceptual Models, the Theory of Conceptual Modelling and Foundations of Conceptual Modelling. In: Handbook of Conceptual Modeling, pp. 543–577. Springer, Heidelberg, Germany (2011)