The Evolution of DEMO

Abstract

Since its inception in the nineties of the 20th century, the Design and Engineering Methodology for Organisations (DEMO) has evolved in four phases, simply denoted as DEMO-1, DEMO-2, DEMO-3 and DEMO-4. The changes in every phase are based on the various discussions and evaluations, both in practice and in the academic communities. In this paper, we present and discuss the major improvements of DEMO-4, announced in 2020, in comparison with the previous versions. DEMO-4 is considered quite full-fledged: it is theoretically mature as well as based on over 25 years of practical experience. The paper discussed several critiques that were published in the course of time. Two of them are written after the publication of the DEMO-4. It also contains a section in which the online discussion of the theoretical importance and the practical impact of DEMO-4 during the EEWC 2020 (Enterprise Engineering Working Conference) is summarised.

1. Introduction

The incentive for the first author to develop the methodology was his dissatisfaction with the practice of requirements determination when he was designing computerised information systems in the seventies of the 20th century, mainly in the manufacturing industry. The practice in requirements determination at the time was interviewing the future users of the systems, as well as other stakeholders, if deemed useful. Basically, this practice has not been changed since then; it has only been perfected. The dissatisfaction consisted of the ever recurring mismatch between the functionality of the developed systems, i.e. the collective services they offered, and the expectations of the users. It was clear to him that further improving the interviewing techniques, which was the main remedy at the time, would not solve the problem. Consequently, the requirements determination problem became the core of his doctoral research in the eighties, which resulted in the conception of a new notion of information system and its formalisation [ 1 ] [ 2 ]. Only after having discovered Language Philosophy (Austin [ 3 ], Searle [ 4 ] and notably Habermas [ 5 ]) and subsequently having mastered the subject, the insight emerged that the practice of interviewing will never be satisfactory. There is an abundance of literature on requirements engineering in practice that support this position: people easily forget to specify information they need, and they tend to ask for information they don’t need.

This insight was the starting point for the development of DEMO in the nineties. With DEMO the requirements determination problem for the class of enterprise information systems is solved in the following way. The feedback of people ‘on the shop floor’ in numerous practical applications of DEMO, supports the observation that they lack in general the (complete) knowledge of the decisions they are responsible for, and consequently of the information they need in order to make these decisions. The essential model of the organisation, as produced by applying DEMO to the organisation, offers the insight and overview they need. In this model, they find all the actor roles they fill, the precise specification of the involved responsibilities, and the complete information needs for every identified actor role. The only thing that is missing, is the specification of the user-system interface. But that has never been a stumbling stone.

Although this quality of DEMO was actually enough to justify its development and practical application, it appeared to offer much more. Due to the completeness, the consistency, the coherence and the conciseness of the essential model, DEMO can be applied to a variety of organisational and managerial problems, not only to the design and engineering of enterprise information systems. It offers e.g. help in addressing organisational transformation, in- and out-sourcing, authorisation & responsibility, process and data ownership, and employee satisfaction. In addition, it offers the insight that a computerised information system should not be considered something that is produced ‘at the side’ and then ‘brought in’, but that is is just a part of the organisation, only implemented in ICT1. Chap. 19 in [ 6 ] contains many illustrating examples. Following the definition of Enterprise Engineering in its founding article [ 7 ], DEMO (Design and Engineering Methodology for Organisations) can rightly be called its principal methodology.

This paper is not a typical research paper, but a discussion by the authors of the latest scientific book on DEMO [ 6 ] of the evolution of the methodology since its inception in the early nineties. The referred book defines DEMO-4, the most recent version of the methodology. In Sect. 2 the history of DEMO is sketched, from the first version (DEMO-1), which in hindsight was quite immature, to the current version, which looks fully fledged. In Sect. 3 we present and discuss the major improvements in DEMO-4 in comparison with the previous versions. Sect. 4 contains the discussion of two critiques that were written after the publication of the book [ 6 ], whereas Sect. 5 contains a summary of the discussion about the theoretical importance and the practical impact of DEMO during the EEWC 2020. 1 ICT stands for (modern) Information and Communication Technology.

2 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

2. The history of DEMO

2.1 DEMO-1 through DEMO-4

In order to compare methodologies, or different versions of one methodology, the framework in Fig. 1 appears to be very useful. It is developed and published in the eighties of the 20th century [ 6 ]. It tells us that a methodology can only truly be called so if it comprises a Way of Modelling (WoM) and a Way of Working (WoW) that are embedded in a Way of Thinking (WoT). The Way of Controlling and the Way of Supporting are optional.

The first version of DEMO, for referential purposes labeled DEMO-1, was developed in the nineties of the 20th century. It is described in the unpublished book “DEMO Modelling Handbook” [ 8 ]. The WoT of DEMO-1 is constituted by Winograd & Flores [ 9 ], Taylor [ 10 ], and Habermas [ 5 ], and the doctoral thesis of Van Reijswoud [ 11 ]. The WoM comprises five integrated aspect models: The InterAction Model (IAM), the InterStriction Model (ISM), the Business Process Model (BPM), the Transaction Process Model, the Action Model (AM), and the Fact Model (FM). The WoW, in Fig. 1 referred to as method-1, is contained in the explanation of the WoM. The leading case for illustrating the WoM is the case Conciliation Board for Consumers (in Dutch: Stichting Geschillencommissies Consumentenzaken), which is extensively discussed in [ 12 ] and [ 13 ]. The DEMO Modelling Handbook has been used in courses at Delft University of Technology from 1999 on.

DEMO-1: < no specific theories > DEMO-2: Operation, Transaction, Composition, and Distinction Axiom; Organisation Theorem DEMO-3: FI, MU, TAO; PSI, DELTA, OMEGA, ALPHA (-3) DEMO-4: FI, MU, TAO; PSI, DELTA, OMEGA, ALPHA (-4)

DEMO-1 -2 -3 -4 IAM-ISM IAM-ISM CM CM BPM-TPM PM PM PM FM SM FM FM AM AM AM AM

Way of Thinking

Methodology Way of Modelling Way of Working

DEMO-1: method-1 DEMO-2: method-2 DEMO-3: OER method-3 DEMO-4: OER method-4

TOGAF Way of PRINCE2 Controlling Way of Supporting

DemoWorld OERA Plena

In 2006, the book “Enterprise Ontology - Theory and Methodology” was published [ 14 ]. Its contents define DEMO-2. As the title suggests, The WoT of DEMO-2 is explicitly and extensively discussed, as is the WoM, which basically comprises the same partial models, now called aspect models. However, three major changes were introduced in the way of expressing the aspect models. First, the transaction symbol was replaced by the one that is still is use. In addition, the way of indicating the executor role was changed. Both changes are still considered great improvements. Second, the so-called ‘sausage’ diagram of DEMO-1 was replaced by a diagram that was based on the TPD and therefore showed more details. Third, the flow chart like way of expressing the AM, was replaced by a much more formal and concise textual language. Like in the book of DEMO-1, the WoW is contained in the WoM. Several cases are included for illustration. From 2006 on, DEMO-2 was taught in courses at Delft University of Technology, at several Polytechnic Schools in The Netherlands, in commercial courses, as well as in courses that were provided by members of the CIAO Network2, like the University of Antwerp, the University of Lisbon, the University of Madeira, and the Higher School of Economics in Nizhny Novgorod.

After a few years of teaching DEMO-2, it became clear that the second and the third change were not considered an improvement by everyone. Therefore it was decided to re-introduce the ‘sausage’ diagram, be it in a slightly different form, as the main way of expressing the PM, and to replace the (too) concise and (too) algorithmic way of expressing the AM by a more readable way that also did justice to the basic character of action rules, i.e. being expressions of human interaction. These changes marked the birth of DEMO-3. DEMO-3 has never been written down in a scientific publication, like DEMO-2 was in [ 14 ]. Instead it was documented in two books: “Red garden gnomes don’t exist” [ 15 ] and “The essence of organisation” [ 16 ], which were published privately, as well as in course material, collectively defining DEMO-3.

Around 2016, the first author of the current paper felt that a major revision of the book “Enterprise Ontology - Theory and Methodology” was needed, in order to have one scientific publication regarding DEMO, which would replace the DEMO-3 sources and at the same time would position DEMO as the principal methodology in Enterprise Engineering, following its founding article [ 7 ]. For several reasons it took more time than anticipated to complete it. In April 2020, the book “Enterprise Ontology - a Human-Centric Approach to Understanding the Essence of Organisation” was published [ 17 ]. Its contents define DEMO-4.

4 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

2.2 Evaluations of DEMO

Since the conception and articulation of DEMO (first ‘Dynamic Essential Modelling of Organisations’ and later ‘Design & Engineering Methodology for Organisations’) there have been many evaluations of the methodology. Those evaluations took form in many conferences, such as the ten Language Action Perspective conferences between 1996 and 2006 and since 2007 the ongoing Enterprise Engineering Working Conferences, but also in the form of PhD and Master theses as well as many fruitful discussions in institutions and groups, such as the Enterprise Engineering Institute, DEMO Lectures and the CIAO! community. Because a complete overview of 25 years of discussion and evaluation would be too extensive, we highlight a selection of evaluations which fuelled the development of DEMO-4, namely [ 21 ], [ 22 ], [ 23 ], [24], [ 25 ] and [ 26 ].

Dumay et al. [ 21 ] in ‘Evaluation of DEMO and the Language/Action Perspective after 10 years of experience’ in 2005 state: “To provide a structure to a critical analysis of DEMO [..] this paper utilizes a paradigmatic framework [..] augmented by the opinion of several DEMO practitioners by means of an expert discussion. The paper concludes by outlining an agenda for further research if LAP is to improve its footprint in the field.”

The first agendum [ 21 ] concerns the way of thinking: “Although at a first glance the incorporated communicative theory of Habermas might suggest DEMO is a social theory, in reality it only determines the socionomic laws that regulate communication. Nevertheless, DEMO has the remarkable position that human beings are responsible for the working and effects of Information Systems. Actually, DEMO states that ultimately these human beings are responsible for a part of organization’s operation, including its supportive systems. This could provide an opening to supplementary methodologies that analyze organization from a more social, interpretivist perspective.”

The second agendum [ 21 ] is directed to the field of practitioners: “Out of the three identified areas of research, only Information Systems Development and Business Process Redesign are applied by DEMO practitioners. Organization Engineering therefore seems more of a theoretical concept than a practical one. Although DEMO methodology offers an integrated design approach, in practice most professionals use aspects of DEMO as they see fit. Particularly within the field of ISD many de facto standards compromise full application of DEMO methodology. But as the concepts of DEMO theory remain appealing for projects of different scope and complexity, practitioners seek combinations and interfaces between DEMO methodology and other methods and techniques.”, “To support the combination of methodologies as applied in practice, further research into possible combinations, supported by practical interfaces, is needed. Although being a very complicated research area, the research on multi-methodologies indicates these combinations are not unattainable.” 5 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

Sattari Khavas [ 22 ] evaluated the Adoption of DEMO in Practice in 2010. The major conclusions are: “In this research we were able to identify several factors that influence the adoption of DEMO. We realized that the support of DEMO by management, coworkers, other individuals with the same skills as the individual and the eagerness of the individual to keep him self updated about DEMO can increase the adoption of DEMO to a great extent. Furthermore, uncertainty one’s position in the organization has a negative effect on the adoption of DEMO. Finally, the ability of the methodology to produce results in a way that can be communicated with all the individuals with different levels of knowledge about DEMO is also influencing the adoption of DEMO.” Sattari suggest - just as Dumay et al. - to include case studies, success stories and to support the combination of methodologies as applied in practice.

Iijima and Suga propose in [ 23 ] a Formal Specification of DEMO-3 Process Model and Its Submodel: Towards Algebra of DEMO Models in the EEWC 2017. They evaluated the Process Model and concluded: “There is an intrinsic limitation in that the formalization only captures the static aspect of DEMO PMs. Considering each transaction kind is a finite state machine (FSM) in the sense of the universal transaction pattern, a PM is a composition of FSMs. [..] However, the PSD is invalid in the presented formalization because the waiting condition in question is not included in the given global PSD. This observation implies that the formalization could be improved, probably by revising the definition of part of to reflect the dynamic aspects. This limitation also implies more case studies are required for further validation.”

Poletaeva et al state in [24] revisited the DEMO-3 Transaction Pattern with the Unified Foundational Ontology (UFO) at the EEWC 2017: “Despite the conceptual quality of DEMO, we observe that there are still opportunities for clarification and generalization of its conceptual basis, in particular considering some aspects of social relationships that evolve in business transactions. In addition to that, there are little guidelines on how to integrate knowledge conceptualized with DEMO to other (non-DEMO based) organizational conceptual models that are widely employed in practice (such as, e.g., reference organizational models captured in UML).”

Gouveia and Aveiro in [ 25 ], Towards an Executable Artefact for Organizations based on DEMO Paradigm, provide an timeline of their research to improve DEMO-3 at the EEWC Doctoral Consortium 2017:

“This PhD. program is based on Gouveia’s master dissertation in informatics engineering completed in 2014, [..] These ideas were then presented on the CIAO! Doctoral Consortium in Madeira.

In 2015 Gouveia produced the paper Two Protocols for DEMO Engines: PSI or Tell&Agree, presented at CIAO! Doctoral Consortium in Prague. This paper analysed two existing demo implementations and showed through state machines and a 6 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). prototype that those existing solutions did not fully implement the DEMO/PSI pattern, [..] We then proposed a few small improvements to the DEMO/PSI pattern regarding the elimination of the quit and stop acts. [..] In that same 2015 work we also proposed a new pattern called Tell&Agree that tried to solve five identified problems on the improved DEMO/PSI pattern that was presented: In several states in that pattern, only one of the actors can take action, and therefore, the other would become blocked forever if the first one refuses to act. That contradicts the “ideal speech situation” as defined by Habermas which states that all actors should be able to act at all time. [..]

In 2016 at the CIAO! Doctoral Consortium, in Madeira, the author presented the work Core Components of Communication (CCC). In that work we proposed a unification of DEMO/PSI and Tell&Agree. [..] and produced a paper called Things, References, Connectors, Types, Variables, Relations and Attributes – A Contribution to the FI and MU Theories.

So far, in 2017 we have produced two papers: DEMO/PSI and the Law of the Land [35] and Modeling Exchange Agreements in DEMO/PSI and Core Components of Communication.”

Since 2014 Mark Mulder works on validating the DEMO-3 Specification Language and presented his findings at several DC’s and EEWC’s such as EEWC 2018 [ 26 ] and EEWC 2019. In [ 26 ] he concludes: “Our findings provide insight into the amount of changes and the complexity and direction of change to complete the metamodel and make it usable for automation. We found that some incomplete, inconsistent or inadequate specifications in DEMOSL hinder its use as a prescriptive metamodel. We describe these limitations as a whole and in the separate Construction Model (CM), Process Model (PM), Action Model (AM) and Fact Model (FM)”.

3. Improvements in DEMO-4

3.1 The Way of Thinking (WoT)

The theoretical foundations of DEMO consist of a number of theories, which are referred to by Greek letters, phonetically expressed in Roman capital letters. Fig. 2 exhibits the complete list of Enterprise Engineering (EE) theories (in Greek alphabetic order). Next to the Greek letter based reference, the full name is mentioned, which gives more insight into the scope of the theory.

Fig. 3 contains the framework that is used in [ 17 ] to divide the EE theories in four categories: philosophical, ontological, technological, and ideological. In [ 17 ], the philosophical and the ontological theories are discussed and applied. It means that the current edition of DEMO-4 is only applicable to ontological modelling and analysis.

7 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). Fortunately, this has been the main purpose of using DEMO in practice since the beginning. It also means that the methodology has to be extended in the near future in order to cover also design and implementation, and consequently also being based on the technological3 theories. The SIGMA theory, the only one in the category of ideological theories, is extensively discussed in Jan Hoogervorst’ books on Enterprise Governance [ 18 ] [ 19 ].

ALPHA theory EE organisational essence theory BETA theory EE organisational design theory DELTA theory EE system theory IOTA theory EE organisational implementation theory MU theory EE model theory NU theory EE normalisation theory SIGMA theory EE governance & management theory TAO theory EE function-construction theory

FI theory EE information theory EE Fra mPSIethweoroyrk ofEE Torghaneisaotiorniaelopseration theory

OMEGA theory

EE organisational construction theory

One of the remarkable theoretical differences between DEMO-4 and its predecessors is in the standard transaction pattern (part of the PSI theory). It is shown in Fig. 4. Instead of performing the promise in response to a request (the green path from [rq] to (pm)), one can perform the decline, thus taking the yellow path and ending up in the discussion state (dc). If the initiator and the executor agree about an adapted product, the initiator will perform a renewed request (yellow path from (dc) to (rq)). If not, the state of transaction process remains (dc). It is an impasse or deadlock state which can be eternal, but from which the initiator can ‘escape’ by revoking her/his request. A similar situation occurs when one ends up in the state (rj) in the result phase of the 3 The term “technology” originates from the Greek words “technè” and “logos”, together meaning “knowing how to make (things)”. Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). transaction. In DEMO-1 through DEMO-3 such an impasse was considered to be undesirable, but on second thought it is quite realistic: people may disagree for ever. in: initial state dc: decline(d) rq: request(ed) pm: promise(d) in rq dc dc 0..1 rq pm pm initiator executor ac ac da da

Another remarkable new insight is provided by the ALPHA theory (Chap. 11 of [ 17 ]). It concerns the notion of information system and it is the key to appreciating what was already mentioned in Sect. 1, namely that the requirements determination problem for enterprise information systems is solved: the essential model of the enterprise contains all functional requirements.

remembering

sharing saving

providing

Oorganisation

Iorganisation

Dorganisation

What the ALPHA theory clarifies convincingly is that an information system is just a part of the enterprise it is supposed to support. More specifically, it is a part of the Iand the D-organisation, as exhibited by Fig. 11.12 in [ 17 ], which is copied in Fig. 5. The yellow lined trapezium marks an arbitrary information system. It comprises the executor roles of the remembering and the sharing transaction kinds (which are purely informational), as well as all informational and documental transactor roles in their process trees.

3.2 The Way of Modelling (WoM)

Another noteworthy theoretical achievement, brought up by the OMEGA theory, is the insight that every business process (kind) can be conceived as a tree structure of which the top is a self-initiating transactor role. The insight results into a major simplification and clarification of the Cooperation Model (CM) and the Process Model (PM) in DEMO-4. To illustrate this, Fig. 6 shows the CM of the case GloLog (Global Logistics), discussed in Chap. 18 of [ 17 ]. There are four business processes, each with its own case kind: the sales process, of which the top is the composite transactor role called client, and of which the case kind is sale; the purchase process, of which the top is the self-initiating transactor role called purchase controller, and of which the case kind is purchase; the sea transport process, of which the top is the self-initiating transactor role called sea transport controller, and of which the case kind is ship content; and the land transport process, of which the top is the self-initiating transactor role called land transport controller, and of which the case kind is container content. The ‘loose coupling’ of the four processes consists of inspection links between actor roles and transaction banks (dashed lines) and wait links between transaction kinds and actor roles (dotted arrows). sea transport

12 control er 14 land transport

13 control er 1..* 15 purchase completer sea transport completer land transport completer

Note that only the part of the sales process that is relevant for the scope of the case is presented: the composite transactor role called client ‘hides’ the part of the tree on the side of the client organisation, of which the top is, by definition, a self-initiating transactor role (most likely the stock controller, resembling to a large extent the purchase controller within GloLog). For all flow-based approaches to business process modelling, it is very hard if not practically impossible to discover, and subsequently solve, the ‘structure clashes’ (a very appropriate term that we borrow from Michael Jackson [ 20 ]) that emerge from the different case kinds that an organisation is dealing with. The tree structure, as shown in Fig. 6, also allows for a direct deducing of the PM from the CM of an organisation.

10 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

This is illustrated for the sales process of GloLog in Fig. 7. It also contains the wait link from transaction kind TK02 to actor role AR10 in a precise way: from the state (TK02/ac) tot the act [TK10/ex].

Another major improvement of DEMO-4, compared to its predecessors, brought up by the OMEGA theory (Chap. 10 of [ 17 ]), is the application of reference models. It appears that there are only a limited, and even small, number of really different kinds of business processes, based on a limited number of distinct product categories, which are shown in Table 1. Each of the four categories has its own typical business process model. 16 10 The OMEGA theory - understanding the construction of organisations creating and changing transporting and

storing obtaining usufruct transferring ownership buying/selling goods tangible things manufacturing, changing, repairing (movable and

immovable) goods transporting and storing goods or files hiring/renting space-time capacities TaTabblele 11.0.P2rpordouduccttccaatteeggoorrieises intangible things making and adjusting decisions, advices, judgments, etc.

* not applicable * acquiring owner rights, paying, trading shares * not applicable *

In Chap. 8, the product of a transaction is defined as an independent production fact, together with its dependent facts, and a product structure is defined as a tree of 3.3 TheiWndeapyenodfenWtporrodkuicntigon( WfacotsW.T)he BoM of the bicycle in Fig. 10.3 becomes a product structure when “bicycle” is replaced by “assembled bicycle”, “wheel” by “assembled wheel”, “spoke” by “acquired spoke”, etc. Note that only the real ‘leaf’ parts, like the The WoW in DEMO-4 in order to arrive at the ontological model of an organisation is rim and the hub, are acquired (or taken from the shelf), all other parts are assemblies. the OERFigm. e1t0h.1o4dex(hOibrigtsanthiesaCtSioDnoaflthEescsoernrecsepoRndeivngeabluisninge)s.sIptroecxeissstekidnda.lready in DEMO-3 but it has been considerably improved, based on numerous practical experiences. In a preliminary form, it even already existed in DEMO-1 and DEMO-2 (cf. Fig. 1). The

CTAR00 OER method consists of four steps (cf. Chap 12 in [ 17 ]): 1. Distinguishing Performa-Informa-Forma, also called the PIF analysis. By applying this distinction to the case documentation one determines those parts that are essential, i.e. that belong to the O-organisation of the concerned enterprise. 2. Identifying transaction kinds and actor roles. Next to identifying the essential transaction kinds and actor roles (combined: transactor roles), one verifies the correctness of the findings against the theoretical basis. 3. Composing the essential model. In this step, the four aspect models (CM, AM, PM and FM) are built up in an incremental, spiral way. This is particularly new, since in DEMO-1 and DEMO-2, it was common to produce the aspect models one after the other. In DEMO-3, the incremental, spiral way was recommended already, but in DEMO-4 it is almost compulsory. It can even be enforced by the applied supporting (software) tool. 4. Validating the essential model. Extra emphasis is put on this step because validation is often the closing entry in practice. Validating means checking the model transactor role per transactor role, while taking all aspect models into account, with the people on the ‘shop floor’. It can for sure not be done behind one’s desk.

4. Critiques on DEMO-4

The introduction of DEMO-4 in May 2020 [ 6 ], received two critiques, which are online available at https://www.linkedin.com/pulse/tools-theories-understandingchanging-organisations-van-reijswoud [ 27 ] and https://www.linkedin.com/pulse/review-enterprise-ontology-dietz-mulder-bas-van-gils/ [ 28 ]. In this paper the critiques are summarised in 4.1 and 4.2.

4.1 Critique by Van Reijswoud

Van Reijswoud [ 27 ] concludes: “Most of the theories are well developed and grounded in philosophical, linguistic, sociological and information theories which gives them a solid basis. At the same time, the theories are complex and not always easy to understand. Some of the theories are still elementary (Iota and Nu) and need to be further developed as the authors state. [..] As the proof of pudding is in the eating, the last part shows the reader how the Enterprise Ontology theories are operationalized in the Enterprise Engineering practice. After a brief explanation of DEMO (Design and Engineering Methodology for Organisations) and its specification language, some simple case-based illustrative exercises, we really get a taste of how and where the theory can be applied. Chapter 19 presents seven real-life applications of Enterprise Engineering and DEMO. The cases, based on the work of various enterprise engineers and DEMO practitioners, are reported in the STARR framework (Situation, 12 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). Task, Approach, Results, Reflection) which makes them easy to read. It is this chapter that really shows the strength and the potential of this new approach that is being presented by Dietz and Mulder.“

4.1 Critique by Van Gils

Van Gils [ 28 ] provides an extensive evaluation of DEMO-4. A short summary of the review is as follows: “My favorite publication on DEMO so far was written by Victor van Reijswoud and Jan Dietz in 1999 with the title: DEMO Modelling handbook - Volume 1. Now that the new book is out, it is time to take another look and (re)form a founded opinion on the approach [..]

In my view, DEMO is an approach for digital transformation. DEMO adopts the engineering mindset as a given: the engineering mindset is the way forward. It gives very little clues (the last chapter being a very useful exception to this rule!) for using the approach in Cynefin's complex domain. In my view, many of the digital transformation challenges that we face fit within this complex domain and therefore I doubt whether DEMO is the silver bullet for all digital transformation challenges. I would like to elaborate with two points: 

This is by no means intended as a disqualification. There is nothing wrong with an engineering approach. Based on my studies and experience in the field, I just happen to believe that other approaches are equally valuable and that it is up to practitioners to make an informed decision about what tools to use in which situation.

After a detailed study of all the theories underlying DEMO, I do believe that parts can be used also in the complex domain. Most notably, the way of thinking about transactions through a request/ promise/ declare/ accept pattern offers useful guidance for forming hypotheses about the state of affairs in a complex domain and may help decide in an initial course of action. I also believe it can be used nicely in conjunction with other modelling approaches (i.e. there could be a good fit with the notion of 'service' in ArchiMate).”

5. Discussion

In this paper, we have sketched the evolution of DEMO since its birth in the nineties of the 20th century. The child is referred to as DEMO-1. Evolution is a continuous process, meaning in this case that the applicants of the methodology learn by doing, as the lecturers learn by teaching. The experiences of both groups have been collected continuously by the Enterprise Engineering Institute (formerly the DEMO Centre of Expertise). It has lead to three new releases: DEMO-2 in 2006, DEMO-3 in 2010, and DEMO-4 in 2020. We have focused in this paper on the last version.

13 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

Next to the feedback from individual practitioners and lecturers, we have learned also from major collections of experiences of practitioners, students and researchers, such as the paper by Dumay et al [ 20 ] and the master thesis of Sattari [ 21 ], and from the discussions at the annual EEWC (Enterprise Engineering Working Conference), like [ 22 ], [ 23 ], [24], [ 25 ]. They are included in and reflected on in the latest book [ 7 ].

After the publication of this book, we have received two critiques on LinkedIn, one from Victor van Reijswoud [ 26 ] and one from Bas van Gils [ 27 ]. These critiques have confirmed to us that DEMO is quite mature now and is moving in the right direction. One of the conclusions is that it needs to be extended soon in such a way that it does also cover Enterprise Design & Implementation.

As proposed by the EEWC committee 4 the new reviewing process is in a more open format, involving a broader, and open, discussion within the community using an on-line discussion platform. Below, a summary of the outcomes of these online discussions is provided. 4 http://ciaonetwork.org/events/10th-enterprise-engineering-working-conference-eewc-2020/ call-for-papers

14 Copyright © 2020 for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

References

1. Houben , G.-J., Dietz J.L.G. , Hee K.M. van. The SMARTIE framework for modelling discrete dynamic systems . in Discrete Event Systems: Models and Applications . 1988 . Springer-Verlag, New York.

2. Hee , K.M. v ., G.-J. Houben , and J.L.G. Dietz , Modelling of discrete dynamic systems; framework and examples . Information Systems , 1989 . 14 .

3. Austin , J.L. , How to do things with words . 1962 , Cambridge: Harvard University Press.

4. Searle , J.R. , Speech acts: an essay in the philosophy of language . 1969 , London,: Cambridge U.P. vii, 203 p.

5. Habermas , J. , The theory of communicative action. 1984 , Boston: Beacon Press. v.

6. Dietz , J.L.G. and H.B.F. Mulder , Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation, in Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation . 2020 , Springer International Publishing: Cham.

7. Dietz , J.L.G. , Hoogervorst , J. A.P. , et al., The Discipline of Enterprise Engineering. Int. j. Organisational Design and Engineering . Vol. 3 . 2013 . 28 .

8. Reijswoud , V.E.v. , Dietz , Jan L.G., DEMO Modeling Handbook . 1999 .

9. Winograd , T. and F. Flores , Understanding computers and cognition : a new foundation for design . 1987 , Reading, Mass. ; Don Mills, Ont.: Addision-Wesley. xiv, 207 p.

10. Taylor , J.R. , Rethinking the theory of organizational communication : how to read an organization . The Communication and information science series . 1993 , Norwood, N.J.: Ablex Pub . Corp. xiv, 302 p.

11. Reijswoud , V.E.v. , The Structure of Business Communication: Theory, Model and Application . 1996 , Delft: Delft University of Technology.

12. Mulder , J.B.F. , Rapid Enterprise Design , in Faculteit Elektrotechniek, Wiskunde en Informatica . 2006 , Delft University of Technology: Delft. p. 160 .

13. Reijswoud , V.E.v. , J.B.F. Mulder , J.L.G. Dietz, Communicative Action based business process and information systems modeling with DEMO . Information Systems Journal , 1999 . 9: p. 21 .

14. Dietz , J.L.G. , Enterprise ontology : theory and methodology . 2006 , Berlin ; New York: Springer. xiii, 243 p.

15. Dietz , J.L.G. , Red garden gnomes don't exist. 2012: Sapio Enterprise Engineering, The Netherlands .

16. Perinforma , A.P.C. , The essence of organisation . 2015 : Sapio Enterprise Engineering.

17. Dietz , J.L.G. , H.B.F. Mulder , and SpringerLink (Online service), Enterprise Ontology A Human-Centric Approach to Understanding the Essence of Organisation . 2020 , Springer International Publishing : Imprint: Springer: Cham.

18. Hoogervorst , J.A.P. , Foundations of Enterprise Governance and Enterprise Engineering . 2017 , Cham, Switzerland: Springer International Publishing. 574 .

19. Hoogervorst , J.A.P. , Practicing Enterprise Governance and Enterprise Engineering . 2017 , Springer International Publishing: Cham.

20. Jackson , M.A. , Principles of program design. A P I C studies in data processing . 1975 , London ; New York: Academic Press. xii, 299 p.

21. Dumay , M. , J.L.G. Dietz , J.B.F. Mulder , 2005 , Evaluation of DEMO and the Language/ Action Perspective after 10 years of experience , International Working Conference on the Language Action Perspective on Communication Modeling , Kiruna, Lapland, Sweden, June 2005 .

22. Sattari Khavas , S. , The Adoption of DEMO in Practice, Master thesis , Delft University of Technology, March 19 , 2010

23. Iijima , J , R , Suga, Formal Specification of DEMO Process Model and Its Submodel: Towards Algebra of DEMO Models , EEWC 2017 : Advances in Enterprise Engineering XI  24 .  Poletaeva, T. , G.  Guizzardi , J.   Paulo,  A.  Almeida , H.   Abdulrab, Revisiting the DEMO Transaction Pattern with the Unified Foundational Ontology (UFO) , EEWC 2017 : Advances in Enterprise Engineering XI pp 181 - 195

25. Gouveia , D. , D. Aveiro , Towards an Executable Artefact for Organizations based on DEMO Paradigm, EEWC Doctoral Consortium 2017

26. Mulder , M.A.T. , Validating the DEMO Specification Language , EEWC 2018 : Advances in Enterprise Engineering XII, pp. 131 - 143

27. Van Reijswoud , V.E. , Tools and theories for understanding and changing organisations in turbulent times , LinkedIn https://www.linkedin.com/pulse/tools-theories -understandingchanging-organisations-van- reijswoud , May 5 , 2020

28. Van Gils , B. , Review of "Enterprise Ontology" by Dietz & Mulder , LinkedIn https:// www.linkedin.com/pulse/review -enterprise-ontology-dietz-mulder- bas- van-gils/ , June 19, 2020 15

Copyright © 2020 for this paper by its authors .

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4 .0).