This site is inspired by the passion to design and engineer business solutions with the same professionalism that is applied in industrial engineering.
One aspect of this professionalism is to help our clients to conceptualise and capture their business reality using a business prototype: A business prototype is a collection of models and simulations that enable our clients to experiment with new business designs and business policies in a risk-free environment. Thus the ability to create a model of your (business) reality is a key factor in successful prototyping – this section covers the concept of modeling in more detail.
Before we go into the details of modeling, we need to define what we mean by the term “model”: A model is an external and explicit representation of a part of reality as seen by the people who wish to use that model to explore, to redesign and to transform that part of reality.
- External, because they are externalized on some medium such as paper, a whiteboard or some diagramming or modeling software on a computer.
- Explicit, because they are explicitly characterised as models by their creators and not implicit in some verbal description
Whatever approach to modeling you follow, the fundamental activities in modeling are always the same:
- Define the model purpose. Define the models purpose and formulate the questions you want to answer using the model
- Define the model boundary. Answer the question “which part of reality do we need to look at to achieve our purpose”. We refer to everything within this boundary as the modeling domain.
- Identify relevant constructs. Identify the concepts that are relevant to the modeling domain by filtering away does that are not relevant and grouping those that can be treated as identical with regard to the models purpose. Create abstractions for the groups that have been identified and decide how to represent them in the model (i.e. which notational element will you use to represent this concept). We refere to these abstractions as constructs that are represented by model elements.
- Identify the relevant relationships. Identify the relevant relationships between the constructs and decide how to represent them in the model.
These activities are illustrated in the drawing below: the picture of a pile of fruit slices on the left represents the part of reality we want to model. Through filtering and grouping we find that we are dealing with apple slices, lemon slices and orange slices. We can abstract this in our model and decide that we are dealing with three kinds of fruit (namely apples, lemons and oranges), and fruit can consist of slices. Note that we are dealing with two different types of relationship here (a “whole/part relationship” and a “kind of relationship”) that are represented by different notational elements. Even though the part of reality that we are modeling is very small, the model is already a simplification: e.g. we have not said anything about the slices being stacked above each other, so the same model could also represent slices of fruit lying next to each other. The notation used in the diagram on the right is part of the UML.
- Structural and behavioural models using the UML (Unified Modeling Language).
- System dynamics models using causal loop diagrams or stock and flow diagrams.
- Agent based simulation models.
Learn more about modeling in our Business Prototyping Methodology course.
By relieving the brain of unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect, increases the mental power of the race.
Alfred North Whitehead
British mathematician, logician and philosopher.
… and Metamodels
A metamodel is itself a model that is used to describe another model using a modeling language. The term “meta” (“behind” or “above” something) is therefore relative – depending on the perspective, a model is either a model or a metamodel. It is important to note that a metamodel is not an aggregated or less detailed view of another model: A metamodel is a model at a different level of abstraction that makes statements about the structure of another model (or a whole set of other models), without making statements about their content.
There are many reasons why it is desirable to formalise a modeling language using a metamodel to do so:
- Formalisation of a modeling language helps to ensure that everyone uses the language in a consistent way.
- A metamodel allows a model to be checked for syntactic correctness using automated algorithms that implement the rules and constraints defined by the metamodel.
- Models that are created using the same metamodel can easily be exchanged between tools that implement the same metamodel.
You can find some concrete examples for metamodels here: