And why you should consider using it

I wrote several blogs about the operation of an enterprise operation and how we can capture that in a DEMO model. Since my first blog, I received many questions related to typical use cases to use DEMO. In my opinion, there is not one typical use case, but there are many. In this blog I outline some of the main reasons for me to use DEMO, including some example use cases. If the examples have made you curious about DEMO, check the overview of all my DEMO related articles.

A DEMO model is objective, human-centred, coherent, concistent, concise, complete, abstracted from implementation and precise. Moreover, it is fully aligned with common (software) architecture design patterns. These properties provide several use cases in redesigning enterprises, in both its human dimension and IT support.

Main Advantages

Objective

A DEMO model is about the construction of an enterprise. Since there is only one construction (at a given time), modelling its construction is an objective exercise. Functional models are stakeholder dependent, and thus require much more time to align with those stakeholders. In my experience, there is far less discussion about the construction of an enterprise (in terms of transactor roles), than about the value of some service or the requirements for some software system.

Human-centred

DEMO puts the actors, human beings, at the heart of the operation; this is also known as human-centred design (in Dutch: menselijke maat). It gives responsibility (and power) to the actors that execute tasks. In contrast to software, humans can truly assess a situation and divert from the rules when this is, e.g., considered better, more customer-oriented, or more ethical.

Coherent

A DEMO model is a coherent whole of responsibilities, products, processes, information (or data) and business rules. No need for other modelling languages and/or to integrate different models, e.g., to link a BPMN process model with a UML class diagram.

Consistent

As DEMO is not just a modeling language, but includes a modeling procedure and validation rules, a DEMO model is consistent, i.e., without internal inconsistencies between the different aspects.

Concise

A DEMO model is concise; it contains nothing more than not needed for its operation. For example, it only contains the entities, attributes and business rules that are needed for execution, and nothing more – if it contains more, this will trigger a validation rule, see previous point.

Complete

A DEMO model is complete in the sense that the transaction pattern defines all possible process exceptions. There is no need to think about the exceptions that can occur, you only need to think how to deal with them. This is also offers benefits in terms of consistency in UI

Abstracted from implementation

A DEMO model is abstracted from implementation decisions, such as who exactly performs some action – a human-being or some physical or IT system. As a result, a DEMO model is relatively stable and the same for, e.g., every pizzeria; differences only occur in its implementation, typically steered by design or architecture principles. This enables

1. 1. Creating reference models for business in the same market;
   2. A deep analysis of the similarities and differences between organizations that (roughly) run the same business – see below for a concrete example;
   3. True redesigns – as opposed to low level optimizations with, e.g., Lean Six Sigma; and
   4. Bi-modal IT support, discerning (stable) core applications from more agile parts in the IT landscape.

Precise

A DEMO model, although abstracted, is very precisely defined. This allows for deep, possible automated, analyses and software generation, as will be shown in the section below.

Aligned with architecture patterns

The ideas behind DEMO align very well with common (software) architecture design patterns such as (micro)service architecture, event-driven architecture, and CQRS.

Example Applications

• Re-allocation of responsibilities, e.g., Dutch Police (5000 FTE)
• Defining responsibilities from law, e.g., HKBA at Dutch Ministry of Justice (in Dutch)
• Standardizing communication patterns, e.g., VISI standard for civil construction projects (in Dutch)
• Designing and guiding mergers, acquisitions and splits, e.g., ING bank, Rijkswaterstaat-Deltares, AirFrance/KLM Cargo
• Process simulation, e.g., Parking
• Application portfolio rationalization, e.g., Rijkswaterstaat
• Detecting similarities and differences between different implementations, as a blueprint for generic IT support, e.g., Dutch subsidy schemes, European Patent Office, Youth Care Netherlands
• (micro) Service design, e.g., Port of Rotterdam, De Lage Landen, AirFrance/KLM, Social Housing
• Software design and generation, e.g., Dutch subsidy schemes (Normalized Systems), Edinet Case management, Dutch Tax Office, Social Housing (Mendix), Smart Contracts (Blockly)

If the examples have made you curious about DEMO, check the overview of all my DEMO related articles.