Mark A T Mulder
email: markmulder@teec2.nl

Henderik A Proper
email: e.proper@acm.org

Towards Enterprise-Grade Tool Support for DEMO

Keywords: enterprise engineering, DEMO, modelling tools

The Design and Engineering Methodology for Organisations (DEMO) method is a core method within the discipline of Enterprise Engineering (EE). It enables the creation of so-called essential models of organisations, which are enterprise models focusing on the organisational essence of an organisation, primarily in terms of the actor roles involved, and the business transactions between these actor roles. The DEMO method has a firm theoretical foundation. At the same time, there is an increasing uptake of DEMO in practice. With the increased uptake of DEMO also comes a growing need for enterprisegrade tool support. In this paper, we therefore report on a study concerning the selection, configuration, and extension, of an enterprise-grade tool platform to support the use of DEMO in practice. The selection process resulted in the selection of Sparx Enterprise Architect for further experimentation in terms of configuration towards DEMO. The configuration of this tool framework to support DEMO modelling, also provided feedback on the consistency and completeness of the DEMO Specification Language (DEMOSL), the specification language that accompanies the DEMO method.

Introduction

The Design and Engineering Methodology for Organisations (DEMO) [START_REF] Dietz | Enterprise Ontology -Theory and Methodology[END_REF] method is a core method (based on a theoretically founded methodology) within the discipline of Enterprise Engineering (EE) [START_REF] Dietz | The discipline of enterprise engineering[END_REF]. The DEMO method focuses on the creation of socalled essential models of organisations. The latter models capture the organisational essence of an organisation primarily in terms of the actor roles involved, as well as the business transactions [START_REF] Van Reijswoud | Communicative Action Based Business Process and Information Modelling with DEMO[END_REF] (and ultimately in terms of speech acts [START_REF] Habermas | The Theory for Communicative Action: Reason and Rationalization of Society[END_REF]) between these actor roles. More specifically, an essential model comprises the integrated whole of four aspect models: the Construction Model (CM), the Action Model (AM), the Process Model (PM) and the Fact Model (FM). Each of these models is expressed in one or more diagrams and one or more cross-model tables.

DEMO has strong methodological, and theoretical, roots [START_REF] Van Reijswoud | Communicative Action Based Business Process and Information Modelling with DEMO[END_REF][START_REF] Dietz | Enterprise Ontology -Theory and Methodology[END_REF][START_REF] Dietz | The discipline of enterprise engineering[END_REF]. At the same time, there is an increasing uptake of DEMO in practice. The latter is illustrated by the active usage (and certification) community5, reported cases concerning the use of DEMO [START_REF] Décosse | What does DEMO do? A qualitative analysis about DEMO in practice: Founders, modellers and beneficiaries[END_REF][START_REF] Aveiro | A case study based new DEMO way of working and collaborative tooling[END_REF] and [7, chapter 19], as well as integration with other mainstream enterprise modelling approaches such as ArchiMate [START_REF] De Kinderen | On transforming DEMO models to ArchiMate[END_REF][START_REF] Roland | ArchiMate and DEMO -Mates to Date?[END_REF] and BPMN [START_REF] Caetano | Using DEMO to analyse the consistency of business process models[END_REF][START_REF] Mráz | Converting demo psi transaction pattern into bpmn: A complete method[END_REF][START_REF] Gray | A new DEMO modelling tool that facilitates model transformations[END_REF].

The increased uptake of DEMO, also triggers the need for enterprise-grade tool support. In this paper, we report on a study into the selection, and configuration, of a (generic) tooling platform to support the use of DEMO in practice.

Configuring tool support for DEMO also requires an elaborate formalisation of DEMO's meta-model, which also enables the automatic verification of models. This exercise also provided interesting insights into limitations of DEMO Specification Language (DEMOSL), the specification language that accompanies the DEMO method.

The remainder of this paper is structured as follows. Section 2 provides more background to the DEMO method. In section 3, we discuss the meta-model of DEMO as it should be supported by a modelling tool, as such providing a first set of requirements for tool support. Section 4 then continues by identifying additional requirements for enterprise-grade DEMO tooling. Based on these requirements, section 5 then briefly reports on the assessment of relevant tools and platforms, resulting in the use of Sparx Enterprise Architect for further experimentation. Section 6 reports on the configuration of Sparx Enterprise Architect to actually support DEMO models, also providing important feedback on the DEMOSL, the specification language that accompanies the DEMO method. Finally, before concluding, section 7 reports on some experiences on the use of the resulting tooling in practice.

DEMO

DEMO supports the modelling of the overall, as well as the more detailed, processes in an organisation, and the underlying information processing. As mentioned before, the DEMO method has a strong methodological, and theoretical, foundation [START_REF] Van Reijswoud | Communicative Action Based Business Process and Information Modelling with DEMO[END_REF][START_REF] Dietz | Enterprise Ontology -Theory and Methodology[END_REF][START_REF] Dietz | The discipline of enterprise engineering[END_REF], while, at the same time, there is an increasing uptake of DEMO in practice [START_REF] Décosse | What does DEMO do? A qualitative analysis about DEMO in practice: Founders, modellers and beneficiaries[END_REF][START_REF] Aveiro | A case study based new DEMO way of working and collaborative tooling[END_REF][START_REF] Dietz | Enterprise Ontology -A Human-Centric Approach to Understanding the Essence of Organisation[END_REF]. Meanwhile, it has a proven track record in process (re)design and reorganisations, software specifications based on the organisation, modelling business rules and proving General Data Protection Regulation (GDPR) and other International Organisation for Standardisation (ISO) and NEderlandse Norm (NEN) norm compliance.

The DEMO method involves with four key aspect models. Each aspect model involves its own kinds of diagrams and tables, providing viewpoints on the complete model. Construction Model -The Construction Model (CM) involves the Organisation Construction Diagram (OCD) showing the Transaction Kind (TK), Aggregate Transaction Kind (ATK), Elementary Actor Role (EAR), Composite Actor Role (CAR) within a Scope of Interest (SoI). These diagrams shows the dependencies between roles in execution and information. The high abstraction level makes this a compact diagram in relation to the implementation of the organisation.

The Transaction Product Table (TPT) shows the TK identification and description together with the product identification and description. This table is used to get insight in the products that are being created in the organisation.

Finally, the Bank Contents Table (BCT) shows the contents of the ATK. This contains the identification and name of the ATK and the Entity Type (ET) and attributes of those ETs that are present. This is used to show the extend of (external) data. Action Model -The last aspect model is the AM with its Action Rules Specification (ARS). Per non-trivial process step minimal one specification shows the input and conditions to proceed in the transaction pattern or advance to other transactions. This specification is used to model all details of the (to-be) organisation. Different aspect models contain overlapping elements, therefore, the DEMO essential model is the result of the combination of all aspect models. the ontological part of the meta-model, as well as updates to the verification rules, the data-meta-model and the exchange-meta-model.

On the ontological level, common concepts have been added to the meta-model to support practical hierarchical concepts for actor roles as well as the concept of scope of interest. The data-meta-model extends the meta-model with attribute types that need to be registered as well as property types that that are required in a implementation environment. This, in particular, involves property types that may seem redundant in an ontological model but are necessary during the modelling process have been added. The exchange-meta-model supports the storage and exchange of the allowed elements and connections. This model promotes the interchangeability of DEMO models between possible modelling tools and other verification, simulation or translation tooling available or needed. The verification rules allow for reducing the chance of creating an incorrect DEMO model.

Combining all partial ontological meta-models from DEMOSL and extending this meta-model with the extra information, results in the data-meta-model.

This data-meta-model is automation-oriented includes all the properties we want to register for the concepts, but does not involve the diagram-meta-model which includes e.g. information about the graphical layout of diagrams.

The data-meta-model, as created inside the tool implementation, does contain all meta structures for elements of the model, and connections of the model. Each structure of those elements and connections has some required and some optional properties. Instantiations of these element and connection structures make up the data model.

Subsequently, for every component of the meta-model we will define the data-metamodel, mathematical rules, exchange-meta-model (XML Schema Definition (XSD)), programming model, visualisation model and examples. For every diagram, there is a definition for the set of entity and property types called the diagram meta-model.

Different modelling techniques allow for the representation of different properties of the object that is being modelled. Only a combination of those models will come close to the representation of the whole object. Therefore, for every component of the meta-models we will define:

1. Data-meta-model for the item and its property types. 2. Mathematical rules on the collections of items. With this list of models and meta-models, the representation of the DEMO meta-model proved [START_REF] Mulder | Validating the demo specification language[END_REF] sufficiently complete to validate the model and exchange information to recreate the model. We remodelled the meta-model according to the findings in [START_REF] Mulder | A design evaluation of an extension to the DEMO methodology[END_REF].

The ontological meta-model of DEMO shows the existing property types and concepts in black. The new property types and concepts are added in red. This meta-model is the base for the data-meta-model. The ontological meta-model is the closest meta-model to the meta-model that lists all ontological principles of DEMO models. For example, the CAR cannot ontologically be an initiator of a transaction kind because an underlying elementary actor must be the initiator. Therefore this property type does not exist in the ontological meta-model.

In contrast to the ontological meta-model, the data-meta-model does contain all implementation attribute types and property types for the DEMO meta-model. The data-meta-model of DEMO (see fig. 5) has property types between the concepts. We did not visualise the removed property types, but these can be found by comparing our model with DEMOSL 3.7 (e.g. we removed a domain property type, precludes and precedes property types, TK initiated from the Transaction Process Step Kind (TPSK)).

The example mentioned above, about the CAR not being an initiator, is not valid in the data-meta-model. Whenever one designs a CAR that initiates the transaction, this property type instantiation must be present in the model and needs a representation in the meta-model. Therefore, the data-meta-model also has the property type 'AR is an initiator of TK' from the CAR to the TK. In an ontological model one could reason that behind every CAR an EAR is present that covers the property type for the initiation.

Furthermore, mathematical rules have been designed to make sure only the correct property type instantiations can be present in the final data-meta-model.

Requirements for Tool Selection

For our research, we selected a tool (framework) to implement the DEMO meta-model based on the criteria as listed below. The criteria for selecting a tool are listed below. We do not pretend that this set is complete or adequate for all users of a DEMO modelling tool. However, for the purposes of our research, we deemed these to be appropriate. Additionally, an earlier version of these criteria, as reported in [START_REF] Mulder | Enabling the automatic verification and exchange of DEMO models[END_REF], has also already been used by other researchers [START_REF] Gray | A new DEMO modelling tool that facilitates model transformations[END_REF].

In the selection of the tool (framework), the following overall criteria were used:

1. The tool must be able to support the executability of the final model; 2. The tool must support the ways of modelling and thinking as described in the DEMO methodology; 3. The tool must support the interchange of models, in particular the conform the VISI6 standard; 4. The tool must check the mathematical correctness of the model; 5. The tool must have an efficient storage of the model; 6. The tool must support the validation of a model with the stakeholders.

From this list, we derived the following requirements for the tool.

Modelling an organisation requires the use of all four DEMO aspect models. Therefore, we define the requirement: The specification of DEMO [START_REF] Dietz | Demo specification language 3.7[END_REF] states the meta-model and describes the visualisation. Although the DEMOSL is not complete it certainly is the minimal description and guideline to visualise DEMO diagrams and the minimum set to create a meta-model to describe the internal relationships of a DEMO model. To be compliant with these specifications, we need another requirement:

Requirement 2 The tool must be fully compliant with the DEMO meta-model, as specified in DEMOSL.

One of the research topics in the field of DEMO is the integration and combination of other modelling methods and notations [START_REF] Roland | ArchiMate and DEMO -Mates to Date?[END_REF][START_REF] Mráz | Converting demo psi transaction pattern into bpmn: A complete method[END_REF][START_REF] Krouwel | Combining demo and normalized systems for developing agile enterprise information systems[END_REF][START_REF] Meertens | Mapping the Business Model Canvas to ArchiMate[END_REF]. When we follow the recommendations of these publications, the best way to support the combination of modelling methods is to have a tool that supports various modelling methods and notations. This is such a practical benefit, apart from supporting further research, that we add it as a requirement:

Requirement 3 The tool must support multiple modelling methods and notations.

When going through DEMO models in published papers, we find incompleteness, structural incorrectness, and syntactic failures in various models [START_REF] Krouwel | Combining demo and normalized systems for developing agile enterprise information systems[END_REF][START_REF] Gouveia | Modeling the system described by the EU General Data Protection Regulation with DEMO[END_REF][START_REF] Gonçalves | Capturing activity diagrams from ontological model[END_REF]. To solve this problem, the model should be verified against the specification language. To conduct such a verification, requires a considerable effort as it involves a large body of correctness rules. For example, the Xemod tool (see Section 5) already implements 23 rules for the CM [START_REF] Vos | Business modeling software focused on DEMO[END_REF]. When the task of verification takes more time than the modelling itself, we can accidentally introduce defects in the model. To compensate for the effort, the tool should automate verification of the models as much as possible. This leads us to the requirement:

Requirement 4 The tool must allow for model verification against the DEMO metamodel, DEMOSL.

The DEMO methodology itself does not prescribe the modelling order of the model such that it is the only correct model [START_REF] Dietz | Enterprise Ontology -Theory and Methodology[END_REF]. The Organisational Essence Revealing (OER) method only determines the components that need to be modelled and how these components must be connected. Therefore, the model could not be build solely using requirement 4. Therefore, we need an extra requirement that allows for variation in modelling order:

Requirement 5 The tool must allow for model verification for any order in which a model is created.

Although four meta-models were specified in the original DEMOSL, we created the integration of these four meta-models into a single, integral meta-model. This single meta-model allows for model verification and reuse of components of the model. We find the usage of a single repository useful, and therefore, we state the requirement:

Requirement 6

The tool must keep produced models in an integral repository.

Modelling tools have been around for several decades, and still, there is no common modelling tool that is the de-facto standard for DEMO. The tools that are used for modelling DEMO seem to be missing something or are not capable of modelling all the aspect models. We looked at a selection of used tools. Although there might be more tools that are in use or that are capable, we limited our research to this set of tools. We conjecture that existing tools are not optimal for DEMO in the standard available version. Therefore, we introduce our last requirement:

Requirement 7 The tool must allow for extending the tool capabilities when this is deemed necessary for full support of DEMO.

Finally, considering the need to support the use of DEMO in larger enterprises, a selected tool needs to be enterprise-grade in the sense that is must be backed by a company / organisation that can provide after-sales service and maintenance. This is not actually a requirement towards the actual tool, but rather on the provider. As such, the tools considered in this study (see section 5) were already pre-selected on this enterprise-grade requirement.

Considered Tools

In searching for modelling tools that support modelling in DEMO and that comply with the requirements as listed above, we have found ten candidates. In searching for possibly relevant tools, the enterprise-grade requirement was used as a pre-selection criterion. The resulting ten candidates have been studied and checked against the requirements. ARIS -by Software AG [START_REF]ARIS[END_REF] is a business modelling tool. With the use of the ArchiMate modelling possibilities (Req. 3), the set of objects has been extended with a transaction and actor role to allow for OCD modelling (Req. 1). CaseWise Modeler -by CaseWise is a business modelling tool that collects and documents the way in which organisations work. The tool has an Application Programming Interface (API) and can, therefore, be extended. Information about the extent of the API is unavailable [START_REF]CaseWise: The CaseWise Suite and CaseWise Modeler[END_REF]. The tool provides multiple diagrams, e.g. Entity Relation Diagram (ERD), Calendar and Process simulation (Req. 3). Its diagram features can be used to create DEMO diagrams except for the AM, which is too complex for the tool (Req. 1). The repository can contain standard and extended objects for one model (Req. 6). Regretfully, no validation business rules can be added to the tool. Connexio Knowledge System -by Business Fundamentals [START_REF] Severien | Business Fundamentals -Verbeteren vanuit de essentie[END_REF] documents representation of the current organisation implementation using the OCD diagram (Req. 1). It also stores ARS and Work Instruction Specification (WIS) to enable people to do and understand their job knowledge management. It does not support all aspect models of DEMO. It is proprietary and for internal use only. DemoWorld -by ForMetis [START_REF]Formetis: Online modeling tool for process design and animation[END_REF] is an online modelling tool for DEMO processes (Req. 1). It does verify some business rules of the OCD (Req. 5) and allows for OCD modelling and process animation. The tool cannot model all aspect models and has no verification options. It is available for commercial use. Students pay e 50 per 6 months, professors get free usage for 6 months. EC-Mod -by Delta Change Consultants can visualise organisational flaws in the transaction kinds and actor roles, using a modified OCD(Req. 1). This OCD shows organisation flaws and can be verified (Req. 4). It was presented in 2016 but is for internal use only. Enterprise Architect -by Sparx is an analysis and design tool [START_REF]Sparx: Enterprise architect[END_REF] for Unified Modelling Language (UML), SysML, Business Process Model and Notation (BPMN), and several other techniques (Req. 3). It covers the process from analysis of requirements gathering through to model design, built, testing, and maintenance. Furthermore, it allows for the creation of meta-models to model one's objects, connections and business rules (Req. 5, 7). The repository stores all objects to enable reuse on multiple diagrams (Req. 6). ModelWorld -by EssMod [START_REF] Hommes | ModelWorld[END_REF] can support ArchiMate, DEMO, BPMN, UML and Mockups (Req. 3). The repository contains all models (Req. 6). It can visualise three aspect diagrams of DEMO (Req. 1), but these are not validated using business rules. Though the model can be simulated, no extensions can be written on this tool. Unfortunately, this tool is no longer available. Open Modelling - [START_REF] Santbrink | Open Modeling[END_REF] uRequire Studio -by uSoft is a requirement management tool [START_REF]uSoft: uRequire Studio[END_REF] that has the option to add OCD (Req. 1). The requirements repository cannot store DEMO models. Thus, diagrams are stored and only connected to the requirement definitions by object description. No other aspect diagrams of DEMO are available. The tool also supports BPMN diagrams (Req. 3) and is available for commercial use.

Visio -[18] by Microsoft is a drawing aid with templates for DEMO resembling the graphical representation (Req. 1). Multiple diagram types can be made in a single file (Req. 3). It does not have a repository of objects. Diagram validation is possible using programming in Visual Basic for Applications (VBA) (Req. 7), but diagram objects cannot easily be related.

Xemod -by Mprise has the ability to integral three DEMO aspect diagrams within a single Scope of Interest per project file [START_REF] Vos | Business modeling software focused on DEMO[END_REF] (Req. 1), which might result in an inconsistency between multiple scopes of interests, scattered in models. Business rules can be used to verify the model on consistency between several elements (Req. [START_REF] Décosse | What does DEMO do? A qualitative analysis about DEMO in practice: Founders, modellers and beneficiaries[END_REF][START_REF] Dietz | Enterprise Ontology -Theory and Methodology[END_REF]. Furthermore, the tool can show the OCD, PM, and FM as diagrams and lists (Req. 6). Unfortunately, this tool is no longer available on the market.

DEMO(1) DEMOSL(2) Multi-model()3) Verifiable(4)
Business Rules( 5) Repository( 6) Extendable( 7)

Total score Cloud/Local Simulation Available ARIS C - ----2 L - CaseWise Modeler CP-F - -- -3 L - Connexio Knwl. system C -------L -- DemoWorld C -- --2 C EC-Mod CP -- ---1 L -- Enterprise Architect -- - 4 L - ModelWorld CP-F --- -3 C uRequire Studio C ------1 C - Visio C F - --- 3 L - Xemod CP-F -- -3 L --

Table 1. Summary of the findings

Table 1 provides a summary of the findings. We conclude from it that DEMOSL has not been completely implemented in any tool yet. Moreover, we conclude that no current tool can integrally model the whole method. To get beyond this impasse of tool builders waiting for the usage and vice versa, we decided to extend a commonly used tool. The scores suggest that Sparx Enterprise Architect (SEA) is the best candidate to fulfil the requirements, by extending the tool with DEMO. SEA is broadly used, supports multiple models, can apply business rules, has a repository, is extendable and is already used for architecture modelling. Therefore, this tool has been chosen to model the meta-model and implement DEMO as precisely as possible.

Implementation

The modelling tool SEA allows for extending the basic UML model with the extenders own concepts. These extended concepts are called profiles. During this research, we used the tool version 13.0.1310 up to 14.1.1429. The modelling tool SEA has a metamodel base consisting of UML data types. By creating a new profile, these data types can be extended. Many meta-models in SEA are using these UML data types as a base for their own model (e.g. ArchiMate, BPMN). Therefore, the used UML types for our meta-model are Class for entity types and Association for the relations between entity types.

To model the stereotype profile of the CM, we need to create an implementation of the DEMOSL concepts into the SEA modelling options. SEA uses a stereotype for each potentially visible object. Therefore, the meta-model of the CM needs to be reduced to visible entity In the Construction Meta-model of DEMOSL 3.7, we can see that the meta-model contains six entity types. The entity type Independent P-Fact Kind (IFK) or EVENT TYPE is the link between the CM and the FM. It is not displayed on the OCD and can be left out of the SEA meta-model for the CM, just like the FACT KIND. We already mentioned the missing Scope of Interest Boundary (SIB) in the CM meta-model. We will use the CAR concept instead and remove IFK and reduce the number of stereotype s concerning the CM to four, as shown in fig. 6.

Fig. 6. OCD profile

We extended the meta-class Class for EAR, CAR, ATK, and TK and added properties, attributes, and shape scripts to the stereotypes. Each stereotype has a 'metatype' property showing the default name of the instantiated model element. The how and why of other properties are available on request and will not be discussed in this section. We extended the meta-class Association to create connectors between the elements.

The SEA allows for each element link to be represented by a graphical shape. The creation of the shape is supported by the programming language shape script. Shape script has a syntax similar to C but has a limited set of commands and functionality.

Within the shape scripts, it is possible to get the element properties or the containing diagram properties. These properties can be used in simple logic to determine the required shape to be drawn on the diagram. When choosing the visualisation of a CAR, the programming features are too limited to either draw it as an internal rectangle and use it as SoI or draw it as a grey-filled rectangle automatically. The programming features do not allow for a context check of the visualisation. Therefore, these visual properties of the elements within SEA must be set manually at the moment.

We implemented the verification of the model for multiple reasons. First of all, the elements and connections can be added to the SEA repository by third parties using the API. Using this API entry path will bypass the checking of the business rules because only User Interface (UI) events are available. The presence of a verification engine allows modellers to create valid models. Subsequently, the model may be entered to the best ability with all information available but is still incomplete. The verification emphasises the gaps and allows for corrective measures. Furthermore, the tool has its limitations on keeping the diagrams within specifications of DEMOSL. Therefore, the diagrams can be corrected after new elements have been entered into the model.

The SEA tool has a flexible model extension feature but does not allow for a complete set of configurable business rules. Although some restrictions for inter-dependency can be made using, e.g. the Quick Link feature, most restrictions and checks have to be made using the API. This API allows for checking business rules at UI events such as menu click, element creation, deletion, and drag and drop onto a diagram canvas. We have used this API to implement business rules on relevant events.

The business rules that have been implemented for the OCD are:

1. Elementary actor roles may only be the executor of a single elementary transaction kind 2. Every pair of actor role and transaction kind can only have a single connection of the type initiator, executor, or bank access 3. On an OCD diagram, only ATK, TK, EAR, and CAR elements can be added.

All equations have been programmed info the verification model.

We need to verify the action model with the mathematical model and the exchange model. Therefore, we built five program parts of visualisation:

1. A verification model in code in the memory model (closely resembling the exchange model). This verification model is restricted to the action rule name, the TK and TPSK on which the rule applies, the entities involved in the with clause and, finally, the relations between the entities involved. For testing purposes, we used a simplified example. 2. A verbalisation generator to create the ARS from the memory model.

This generator takes the memory structure tree and follows the structure depth-first towards the end of the action rule, thereby writing the language. The tree navigation is in compliance with the action rule grammar. More structures are allowed in the memory model than in the grammar due to the inherent strictness of the memory model.

3. A model converter to split the connected CM, PM and FM concepts needed for the AM.

Although it would be more efficient to fetch the information directly from the original model, the assumed requirement of independence of the grammar module makes it necessary to create a new lookup structure for the model element. 4. An interpreter on top of the lexer-parser-listener of the created grammar that produces the exchange code.

After lexing and parsing the input string, we can navigate through a tree which, again, follows the grammar structure. Now, instead of the language, we will fill the XML nodes into the XSD structure. Afterwards the nodes can be serialised to create an XML string. 5. A direct conversion from the memory model to the exchange model.

The serialisation of the memory model can also be done via the XSD structure directly. This step creates an XML from the memory model.

At the end of the path, we have two XML files that have to be identical for the AM part.

The AM must represent the same information in all formats.

Cases

Over the past two years, we have created business models for five organisations. We used our tool for the creation and presentation of these models. DEMO is a nondomain specific methodology which allows us to use the tool throughout the various domains. The cases, which are labelled A-E, have been created in five companies in the Netherlands. Case A, D, and E were used at logistic wholesale companies. Case B was used at a small property management company whereas case C regards a small call centre.

Case A is a medical wholesale organisation which needs a only construction model and a fact model of their organisation for the purpose of being aware of the organisation and communication structure. We modelled around 49 TKs, 38 EARs, 12 CARs, 17 ETs, 4 ARSs, 0 WISs. We modelled the organisational structure in DEMO and combined it with the landscape in ArchiMate. Though only OCD have been made, the combination between the OCD of DEMO and the ALD of ArchiMate have been very useful, therefore confirming the need of requirement 3. In this case the connections between DEMO and other notations have been identified.

Case B is a property management company that needed their processes and data modelled to be able to choose the right automation for their business. We modelled around 222 TKs, 191 EARs, 36 CARs, 149 ETs, 0 ARSs, 9 WISs. The complexity in this case was in the implementation. The OCD and OFD were the start of the implementation of both the landscape that was modelled in ArchiMate, as well as the application mapping. The OFD has been used for the base of the configuration of the domain application. The combination of the OFD and implemented entities is a concept that fulfills some demands and can be expanded. The security model that was needed for the application could neither be registered in DEMO nor in ArchiMate and needs further attention.

Case C is a small call centre that needed to choose a process and data matching application. We modelled the organisation and their landscape using DEMO (OCD and OFD) in combination with ArchiMate. We modelled around 58 TKs, 21 EARs, 19 CARs, 32 ETs, 0 ARSs, 55 WISs (see fig. 7). By reverse engineering the software towards DEMO models we found a 80% match in process and data model. This was complete enough to buy the software licenses. Matchin implementation and the organisation model is a part that is not completely covered by the tool in the used version. The meta-model lacks some connections between the various entity types. Case D is a logistic wholesale company that is seeking for business optimisation. We mainly used the OCD to gather all products and processes in the organisation. We modelled around 200 TKs, 168 EARs, 81 CARs, 107 ETs, 0 ARS, 3 WISs. With the help of the integration of the Disco process mining tool we gathered information at main TK and related that information to cash flow, processing time and material flows. The tool supported this modelling by combining proces mining information, ArchiMate landscape information and transaction and role information. Business optimisation was found in the analysis of the connections between the different departments [23].

Case E is a logistic wholesale company that lacked insight in the invoicing system. We modelled around 23 TKs, 20 EARs, 10 CARs, 12 ETs, 0 ARSs, 0 WISs. This analysis using just the OCD resulted in the insight that the communication was scattered around the organisation and the responsibilities were not defined. Implementation of a single actor role was among several subjects. The presentation of this information needs some improvement in the tool.

Conclusions and Future Research

After two years of testing and optimizing the tool we can conclude that, though not completely finished, the tool is capable of storing all DEMO models and visualise the business processes. The data meta-model that we implemented in the tool appears to be sufficient to store the information of the mentioned cases. The base of the tool, SEA, is capable of supporting the modelling in DEMO 3. Although SEA has not been build to display tables, we have been able to visualise tables within the add-on.

The visualisation engine of SEA is based on a 100x100 pixel image that is resized to the required dimensions. This allows for most graphical visualisations (squares) but fall short for independent resizable shapes (see fig. 3). This same graphical concept is applied to connections between elements and is also quite restricting. Business rules have been implemented in the add-on and the freedom within this add-on compensates the lack of possibilities of the internal tool framework.

Besides the tool discoveries, modelling DEMOSL in SEA revealed some missing definitions and inconsistent definitions in DEMOSL. These will be discussed in another paper. More research is needed on the compliance of DEMO 4 and DEMOSL 4. Some rules of new diagrams and tables seem to complicate the modelling in SEA. We are also starting research on a number of newly found tools to investigate if these tools can also use the add-on that has been developed to extend the modelling capabilities towards DEMO.

Fig. 1 . 2 .

 12 Fig. 1. Poligyn OCD modelled in the tool Fig. 2. Poligyn TPT modelled in the tool Process Model -The PM involves a single diagram kind, the Process Structure Diagram (PSD), which shows the relations between the process steps of interrelated transactions.This is used to explain the order and dependencies between transactions. Business rules are partially covered as well.

Fig. 3 . 4 .

 34 Fig. 3. Poligyn PSD modelled in the tool Fig. 4. Poligyn OFD modelled in the tool Fact Model -The FM also involves a single diagram kind, the Object Fact Diagram (OFD), which shows ETs and Product Kinds (PKs), and the Information Use Table (IUT). This model is often called the data model although it shows much more information.Action Model -The last aspect model is the AM with its Action Rules Specification (ARS). Per non-trivial process step minimal one specification shows the input and conditions to proceed in the transaction pattern or advance to other transactions. This specification is used to model all details of the (to-be) organisation. Different aspect models contain overlapping elements, therefore, the DEMO essential model is the result of the combination of all aspect models.

3 .

 3 Exchange-meta-model of the objects: (a) XSD specification for the set (b) XSD specification for the item (c) XSD specification(s) for the types (d) XSD specification for the diagram element 4. Programming model to implement the rules and meta-model. 5. Visualisation model in the selected tool platform. 6. Example model on the selected tool platform.

Fig. 5 .

 5 Fig. 5. DEMOSL data-meta-model

  is a multi-model tool that supports Flowcharts, Integration Definition (IDEF) scheme, Application landscape, DEMO, ArchiMate, Use Case diagram, Component diagram, State diagram, ERD, Data Flow Diagram (DFD), and Screen sequence diagram.

Fig. 7 .

 7 Fig. 7. Partial CM/OCD case C

http://www.ee-institute.org/en https://www.linkedin.com/company/enterprise-engineering-institute

The DEMO Meta-ModelEarlier work[START_REF] Mulder | Validating the demo specification language[END_REF] towards DEMO tool support for DEMO already resulted in improvements to DEMOSL 3.7[START_REF] Dietz | Demo specification language 3.7[END_REF]. This has, amongst others, resulted in extra concepts in

The 'Voorwaarden scheppen voor de Invoering van Standaardisatie ICT in de bouw' (VISI) standard originates from the construction sector, where a considerable workflow automation group has developed a DEMO-based set of standards


Henderik A Proper
email: e.proper@acm.org

Giancarlo Guizzardi
email: giancarlo.guizzardi@unibz.it

On Domain Modelling and Requisite Variety Current state of an ongoing journey

Keywords: domain modelling, conceptual modelling, requisite variety

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.

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 lifecycle 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. [START_REF] Apostel | Towards the Formal Study of Models in the Non-Formal Sciences[END_REF][START_REF] Stachowiak | Allgemeine Modelltheorie[END_REF][START_REF] Rothenberg | The Nature of Modeling[END_REF][START_REF] Frank | Multi-perspective Enterprise Modeling (MEMO) -Conceptual Framework and Modeling Languages[END_REF][START_REF] Mahr | On the epistemology of models[END_REF][START_REF] Thalheim | The Theory of Conceptual Models, the Theory of Conceptual Modelling and Foundations of Conceptual Modelling[END_REF]), as well as by ourselves (see e.g. [START_REF] Hoppenbrouwers | A fundamental view on the process of conceptual modeling[END_REF][START_REF] Proper | On utility-based selection of architecture-modelling concepts[END_REF][START_REF] Guizzardi | On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models[END_REF][START_REF] Guizzardi | Theoretical foundations and engineering tools for building ontologies as reference conceptual models[END_REF][START_REF] Bjeković | Enterprise modelling languages -just enough standardisation?[END_REF][START_REF] Guizzardi | Ontological patterns, anti-patterns and pattern languages for next-generation conceptual modeling[END_REF][START_REF] De Carvalho | Using reference domain ontologies to define the real-world semantics of domain-specific languages[END_REF][START_REF] Bjeković | Embracing pragmatics[END_REF][START_REF] Proper | Fundamental challenges in systems modelling[END_REF][START_REF] Guarino | On the philosophical foundations of conceptual models[END_REF]). At the same time many challenges remain (see e.g. [START_REF] Guizzardi | Ontological patterns, anti-patterns and pattern languages for next-generation conceptual modeling[END_REF][START_REF] Proper | Fundamental challenges in systems modelling[END_REF]).

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 [START_REF] Ashby | An Introduction to Cybernetics[END_REF], 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 theoretical 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 [START_REF] Ashby | An Introduction to Cybernetics[END_REF], 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.

Domain Models

Based on general foundational work by e.g. Apostel [START_REF] Apostel | Towards the Formal Study of Models in the Non-Formal Sciences[END_REF], and Stachowiak [START_REF] Stachowiak | Allgemeine Modelltheorie[END_REF], more recent work on the same by different authors [START_REF] Rothenberg | The Nature of Modeling[END_REF][START_REF] Harel | Meaningful Modeling: What's the Semantics of "Semantics[END_REF][START_REF] Thalheim | The Theory of Conceptual Models, the Theory of Conceptual Modelling and Foundations of Conceptual Modelling[END_REF][START_REF] Sandkuhl | From Expert Discipline to Common Practice: A Vision and Research Agenda for Extending the Reach of Enterprise Modeling[END_REF], as well as our own work [START_REF] Hoppenbrouwers | A fundamental view on the process of conceptual modeling[END_REF][START_REF] Proper | On utility-based selection of architecture-modelling concepts[END_REF][START_REF] Guarino | On the philosophical foundations of conceptual models[END_REF][START_REF] Guizzardi | On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models[END_REF][START_REF] Bjeković | Embracing pragmatics[END_REF], we consider a domain model to be: An artefact that is acknowledged 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-andlines" 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 [START_REF] Guizzardi | On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models[END_REF], but also what is termed conception in [START_REF] Falkenberg | A Framework of Information Systems Concepts[END_REF].

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 conceptualisation / 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, [START_REF] Proper | Digital Enterprise Modelling -Opportunities and Challenges[END_REF] 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 [START_REF] Proper | Communication of enterprise architectures[END_REF], 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 [START_REF] Batini | Abstraction in conceptual models, maps and graphs[END_REF]: [START_REF] Apostel | Towards the Formal Study of Models in the Non-Formal Sciences[END_REF] 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. 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.

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 [START_REF] Hofstede | How to formalize it?: Formalization principles for information system development methods[END_REF]) or an ontological theory (ontological or real-world semantics [START_REF] De Carvalho | Using reference domain ontologies to define the real-world semantics of domain-specific languages[END_REF]). 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 sublanguages. Typical examples are ARIS [START_REF] Scheer | Architecture of Integrated Information Systems: Foundations of Enterprise Modelling[END_REF], UML [START_REF]OMG: OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2[END_REF] and ArchiMate [START_REF] Band | ArchiMate 3.0 Specification[END_REF][START_REF] Lankhorst | Enterprise Architecture at Work -Modelling, Communication and Analysis[END_REF], 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.

M1: A in L1

M2: A in L2 Fig. 2. Trade off between languages with different sizes of their definition A final consideration is the fact that the conventions which define a modelling language 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 [START_REF]OMG: OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2[END_REF], BPMN [START_REF]OMG: Business Process Modeling Notation, V2.0[END_REF] or Archi-Mate [START_REF] Band | ArchiMate 3.0 Specification[END_REF][START_REF] Lankhorst | Enterprise Architecture at Work -Modelling, Communication and Analysis[END_REF], 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 [START_REF] Bjeković | Enterprise modelling languages -just enough standardisation?[END_REF][START_REF] Bjeković | Pragmatics of Enterprise Modelling Languages: A Framework for Understanding and Explaining[END_REF].

As such, the 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.

Requisite Variety

The Law of Requisite Variety by W. Ross Ashby [START_REF] Ashby | An Introduction to Cybernetics[END_REF] 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 [START_REF] Shannon | A Mathematical Theory of Communication[END_REF], 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 understand 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, [START_REF] Hillis | The first machine intelligences[END_REF] 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, [START_REF] Ashby | An Introduction to Cybernetics[END_REF] 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.

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 [START_REF] Shannon | A Mathematical Theory of Communication[END_REF] 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 [START_REF] Hillis | The first machine intelligences[END_REF] 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 predefined 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 [START_REF] Moody | The "Physics" of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering[END_REF], 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 by 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 [START_REF] Conklin | The IBIS Manual: a short course in IBIS methodology[END_REF], Conklin coins the term social complexity [START_REF] Conklin | Dialogue Mapping: Building Shared Understanding of Wicked Problems[END_REF][START_REF] Conklin | Wicked Problems and Social Complexity[END_REF].

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 qualify or even quantify the involved variety, as well as show how different collaborative modelling strategies [START_REF] Barjis | Collaborative Enterprise Modeling[END_REF][START_REF] Ssebuggwawo | Interactions, goals and rules in a collaborative modelling session[END_REF] may deal with this variety.

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 (including enterprise and conceptual modelling), and the role of modelling languages.

Using this as a base, we then explored some of the possible consequences / challenges 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.

Fig. 1 .

 1 Fig. 1. Conceptualisations involved in domain modelling

Acknowledgements

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