Prompted by an old discussion on Reddit (link expired), kicked off by the question: "Please explain OOP to me in the language of a five-year old", I found myself musing on the reasons computing seems to stay stuck in the Middle Ages.

It is not for lack of great minds or vision. In fact, I have the impression, the problem seems to be that nobody ever seems to read anything. Why is that? Is there some kind of unspoken consensus that, since we are in the area of computing science which is soooo new and changing so rapidly, that anything older than 1 year should already be considered obsolete?

Let's catalogue a few of the main misconceptions, shall we?

It is all about automation

Basically, this misconception is foremost in the minds of most people wrestling with IT in the context of business or society. We see computers as a kind of machine. A machine is seen as something that helps us, humans, do things. What things? Well, things we already did, such as computing (the mathematical kind), searching, manufacturing, accounting, writing.

If this is your underlying (and, usually, totally subconscious) assumption, then it is almost impossible to see the hidden treasures (and, yes, dangers, but we will come to that later). You live in a world that does not need to change, really. Or rather I should say: you do not need to change. Everything remains as it was, it is just that computers are doing some of it. You do the same things. It is the old Western metaphor of the inanimate world just being there to serve us, superior and in some ways detached, human beings. Computers, the internet, it's all just machinery. It is like a steam engine or clockwork. More complex perhaps, but intrinsically the same.

Older than 1 year is irrelevant

We live in an era of change. At least that is the slogan. Constant change, and we are wrestling to keep up. As individuals, as enterprises. We are constantly introducing "new" ways of coping with those changes, we are officially adhering to the religion of change.

And since these changes are so ubiquitous, we can not rely on the past any more. Past knowledge or experience no longer applies, so anything thought of in the past has become irrelevant.

Computing is an independent discipline

Well, for that matter, I have a deeply disturbin feeling that any discipline is seen as an independent one.

Did any of you read Isaac Asimov's book "Foundation" (part 1 of the famous Foundation Trilogy)? Maybe not. The book started to take form in 1942. But it talked about a problem Asimov, as a biochemist, was acutely confronted with: the splintering of scientific disciplines akin to the blind men and the elephant. Each discipline functioning in a silo, and the scientific community endlessly repeating what other scientists have said earlier.

Ethics don't really come into play

When I started studying physics and mathematics on the university of Utrecht, The Netherlands, I was shocked to find that I was the only student in my year taking on a parallel course in "Philosophy of Science". I could not understand how my fellow students thought they could be effective scientists (I must admit, at the time my main ambition was to be a famous scientist) if they were not taking into account the broader view, in fact as broad as is feasible for a mere individual.

It's about data

This is one of the misconceptions that I worry about most. It creates an endless stream of misery and problems (it's too much, there are privacy concerns, and all this stuff about semantics, how to structure it, to name a few). Why is it about data? Or, still awful but slightly less so, about information? There is already too much information! (maybe you like my article on The Inversion of Big Data, or, about the undervalued distinction between data and information: Business Intelligence, an alternate definition)

The solution

The solution has been around for a long long time. Almost unnoticed, although not really because a malformed and drilled-down interpretation of it is what you currently see all around: personal computers are a direct offspring of one of the most misunderstood projects of the past century, done by the Learning Research Group at Xerox PARC.

A central concept that was realised by that group was something called a live domain. In fact this domain, which bootstrapped for the first time in October 1972, was not just live in the domain part, but everything was live: "turtles all the way down": the operating system, the application development environment, even the compiler! Maybe the world is not yet mature enough to embrace that concept wholly, but a part of it is, and it is about time too.

That part is where the business logic or domain logic of the architecture lives.

Every architecture is wrestling with the problem of where to put the business functionality. Even how to discover that functionality is a problem, resulting in an endless stream of books purporting to offer help.

The centre of any logical architecture should be a simulation model of the organisation. What do I mean with a simulation model?

1. It is executable and able to run independently from other components (such as a database or a front-end)
   1. "independently" is implemented by "connecting" those components with event publishing on state changes
2. It "reflects" the real organisation (but there is something magical in the reflection: The Mirrored World) (ed. 2022: related to the recent term "Digital Twin")
3. It is time-aware: changes of state are events on one or more timelines (time warp should be possible!). Every state is time-bound!

It is quite a different thing to have a simulation model instead of a reified data model, which is what almost every organisation currently has. Not even an information model, mind you, but a data model. It is left to the viewer, the user, through a handicapped tool called a front-end, to make something of the mess, hopefully approaching something that can be called information.

I will leave it up to the reader to come up with the infinite possibilities that will be exposed if you do this - I will come back to you on this in a later article. In the meantime: why did I show the picture above this article? Anyone?

This article introduces a complete, navigable and clickable representation of the ArchiMate metamodel standard. The model is created using UML. This is not because I wanted to translate ArchiMate into UML, but because UML should be well-suited to define a language such as ArchiMate in. And after all, also the standard itself defines its metamodel using something that looks like UML. In fact I think the ArchiMate forum should decide to formally specify ArchiMate in UML and "own" the UML profile for tool vendors and other interested parties to keep up.

Metamodelling and ArchiMate

Any language needs a specification. What are the rules? What is the format (its syntax)?

ArchiMate is no different. Its specification is part of the standard, published in document format by the Open Group, of which you can find the latest version here:

• ArchiMate 3.1: http://pubs.opengroup.org/architecture/archimate3-doc/

The language specification consists partly of what ArchiMate calls its metamodel. For language designers the use of this term in the context of ArchiMate is somewhat problematic, because what ArchiMate calls a metamodel should more properly be defined as a class model. Also the lack of a proper metamodel layer in ArchiMate is revealed by the fact that ArchiMate is not specified in itself, but in what should be regarded as a handicapped UML.

Many people, including myself, have argued for ArchiMate to be specified as a UML profile. Unfortunately this has not happened yet.

(OMG is actually working on this, and the effort is well underway, even to the level of MOF definitions, which I was very happy to learn)

The reasons can only be speculated upon, since most of the tool vendors were forced to do exactly that anyway. Language users (i.e. architects) need a "proper" metamodel, but that is much more so for tool builders. In fact I would think that the language designers need this as well because I cannot for the life of me imagine how I would go about working on the next version of the standard without a proper metamodel, accessible through a repository-based representation such as the one introduced here. But anyway.

Probably as a result of this, the language specification is inconsistent, ambiguous and contains several errors. This has improved somewhat in the latest 3.1 version. This article and especially the models will show these problems because the effort of creating the UML models of the standard made these problems explicit.

The goal of this article is to represent the ArchiMate metamodel as published by the Open Group in a slightly improved format, using "correct" UML. Doing that enabled me to:

1. create (better) UML profiles for use in tools (using an XMI version of the metamodel)
2. create much more usable documentation of the standard itself:
   1. clickable ArchiMate concepts, linking to the specification of that concept. For an example, please visit the model, for example the Business Service concept)
   2. diagrams with all defined/allowed relations of a specific ArchiMate concept (for an example, please visit the model, for example the Artefact concept). The standard itself for example provides a table with all allowed relations, containing several errors which are hoped to be corrected soon.
3. create a "one-pager" of the entire metamodel (something Gerben Wierda also did for his book Mastering ArchiMate, on the 2.1 and 3.0.1 version of ArchiMate) or those parts you want to focus on
4. extend the metamodel for specific customers
5. and of course, for this article, detect and document problems (errors, ambiguities or vagueness) in the standard as published ?

In fact I realised when creating this model that for me as an architect this is an infinitely more usable version of the specification than a stupid thing like a book with pictures.

The metamodel can also be downloaded in XMI format, for you to use in your tool of choice:

• ArchiMate 3.1.xmi (currently under development)

About ArchiMate metamodels

The metamodel for the 3.1 version of the standard is exported in HTML format. To view the metamodel, please use these links:

• ArchiMate 3.1 metamodel (currently under development)

As said earlier, the UML this article refers to should be "correct". Please let me know if you notice issues. However, a few remarks should be kept in mind:

1. The use of colours is in line with the use in the standard. In 2.1 colours were used, in the 3.x standard shades of grey were used. We tried to comply to the colouring scheme in the standard.
2. Attempts have been made to create diagrams that are in line (mainly the layout) with those in the standard as much as possible. The goal was not to improve ArchiMate, but to detect/repair some of its problems.
3. Multiplicity will be added in the future. As ArchiMate 2.1 states (the 3.x standard is ominously silent on this…), most of the relations are zero or more (* in UML parlance) except where explicitly stated differently. Note that when ArchiMate talks about cardinality, UML (on the class level) talks about multiplicity.
4. The direction of a relation is still not clear. It is clear what it means in ArchiMate, and what it means in UML, but the semantics of direction in ArchiMate are different from those in UML. We stick to the ArchiMate semantics for now, but I think this disparity is one of the big problems in ArchiMate. In my view, direction is about dependencies, but that is not how ArchiMate sees it.
5. In this article, stereotypes (for relations or classes) have not been used. Obviously, if you want to create a UML profile for ArchiMate, this must be done.

The ArchiMate 3.1 metamodel

Work is underway, please be patient.

The ArchiMate 3.0.1 metamodel

For the entire model, please visit ArchiMate 3.0.1 metamodel.

The metamodel for ArchiMate 3.0.1, from a language specification perspective, is an improvement over its predecessor. All concepts have now been defined in the model. The above diagram shows the top-level concepts, the most generic ones, this time also including the relationships. It almost looks like a real metamodel!

Of course in the standard these are just pictures, so my hope is you will find these models useful. If you do, please do not hesitate to like this page using the LinkedIn and Twitter buttons in the top right!

List of detected issues

Below is a summary of the issues that I have stumbled on in making the models. The chapter in the standard is provided so that you can compare what the standard says with my proposed changes. The diagram in my repository is also hyperlinked for your convenience.

The elements hyperlinks do not always work correctly (sorry, this is due to the way the tool generated the HTML report, I am working on correcting this).

ArchiMate 3.0.1 issues

"Core Element" and "Element"

There is talk of "Core Element", but it seems equivalent to what is also referred to as "Element".

4.1: Behavior and Structure Elements

Notes

1. Diagram Behavior and Structure
2. For completeness I added the Collaboration concept, which is also an abstract class.
3. There is a problem in the standard with the abstract classes External Behavior Element and External Active Structure Element. These classes are nowhere explicitly specialised, for example a Business Service should be an External Behavior Element. I expect these diagrams to be added in the next revision of the standard.

4.2: Specializations of Structure and Behavior Elements

Notes

1. Diagram Specialisations of Core Elements
2. This diagram is not followed through with the specific subclasses of Process, Function and Interaction. Although it would potentially introduce multiple inheritance, these subclasses should be added, for example Business Process as a subclass of Process. Note that multiple inheritance in metamodels is not a problem, but should be avoided in "instance" models. The Business Process/Function/Interaction element is completely equivalent to Business Internal Behavior Element.

5: Relationships

Notes:

1. Diagram Relationships
2. The associations between Relationship and Element show the labels as UML. In the ArchiMate standard (p. 22) these are shown on the other end.
3. ArchiMate does not specify the multiplicity on the other side (related from). We show that an Element can participate in zero or more relations.

8.2: Active Structure Elements

Notes

1. Diagram Business Internal Active Structure Elements
2. The standard does not explicitly specify a generalisation relation between Business Internal Active Structure Element and Internal Active Structure Element. That seems to be an error.

8.3: Behavior Elements

Notes

1. Diagram Business Internal Behaviour Elements
2. One expects this diagram to repeat in the Application and Technology layers. It does not.
3. I have added the generalisation to Internal Behavior Element, which seems to be lacking from the standard.
4. There is a consistency problem with Specialisations of Core Elements diagram. This problem needs to be resolved!

Application Function/Process/Interaction

Notes

1. Diagram Application Function/Process/Interaction
2. This diagram has been added to model the not-really-existing Application Process/Function/Interaction concept properly. As was mentioned with the Business Internal Behavior concept, this concept should be named "Application Internal Behavior" for consistency.

10.1: Technology Layer Metamodel

Notes

1. Diagram Technology
2. As is noted with the concept, the Technology Process/Function/Interaction should be named "Technology Internal Behavior".

Technology Internal Behavior

Notes

1. Diagram Technology Internal Behaviour
2. This diagram does not occur in the standard. Nowhere in the standard metamodel diagrams a Technology Function, Process or Interaction is shown, but its shared generalisation, incorrectly named Technology Process/Function/Interaction is.

11.1: Physical Elements Metamodel

Notes

1. Diagram Physical
2. In the standard (p. 91) the assignment between Equipment and Technology Process/Function/Interaction is shown explicitly. However since this relation is implied by the already existing one between Node and Technology Process/Function/Interaction in the Technology diagram and thus inherited by Equipment, it is omitted here.
3. The accesses relation between Technology Process/Function/Interaction as shown in the standard (p. 91) is also omitted here, since it is inherited from the same relation between Technology Object and Technology Process/Function/Interaction in the diagram Technology.

12.1: Alignment of Business Layer and lower layers

Notes

Quite a few problems with this metamodel in the standard (p. 96).

1. Diagrams Relationships between Business Layer and Application Layer Elements, and Relationships between Business Layer and Technology Layer Elements
2. The Business Actor/Role element should be the Business Internal Active Structure Element since also a Business Collaboration can use an Application Service. We have put the correct element in this diagram.

13.1: Implementation and Migration Elements Metamodel

Notes

1. Diagram Implementation and Migration
2. The accesses relation between Implementation Event and Deliverable as shown in the standard (p. 99) is omitted here since it is inherited from the one between Event and Passive Structure Element as shown in this diagram.
3. Same thing for all the trigger/flows between Event subclasses.

13.4: Cross-Aspect Dependencies

Notes

1. Diagram Relationships of Motivation Elements with Implementation and Migration Elements
2. Because of the realization relationship between Composite Element and Deliverable the same kind of relation is superfluous in the other diagram between Deliverable and Plateau.

SmallSim is a business process simulation tool. It helps building complex business models, and then execute these models. With SmallSim you create executable models. The important differentiating characteristic of SmallSim is that SmallSim is not only executable, but it executes inside a full-fledged simulation environment.

These business models can be the centre of a business-centred software architecture for enterprise systems (also called the Business Domain or Domain Component).

Using these models you can keep these systems aligned with the business while the technology with which these systems are built changes. Now this technology is J2EE, last year it was Cobol, and next year it will be whatever. As you can read in my article on Business-Centred Architectures there are many advantages in using a business-centred architecture. The base characteristic of such architectures is the strict uncoupling of the business domain components with technological components. This results in a robust and scalable architecture.

The following description is mostly based on a version of SmallSim of several years ago. We are working on a new version which will be multiplatform again (SmallSim became Windows-only for usability reasons that seemed valid at the time) and has a vastly improved look and feel. However, time and money constraints make it impossible to predict when this version will be available.

SmallSim originated from a research project on the University of Groningen, The Netherlands, at the Faculty of Management Science. It was also used in the curriculum for business modelling and simulation for a few years.

Key features of SmallSim

• SmallSim is a generic simulation environment for building simulation models
• SmallSim offers improved and scalable modelling possibilities due to the consistent use of object-oriented modelling
• SmallSim offers full stochastic features such as probability distributions
• SmallSim enables you to build complex models quickly and simply, many times faster than traditional simulation solutions!
• SmallSim was originally developed in close co-operation with the Faculty of Management of the University of Groningen, the Netherlands, with the main champion dr. A.C.M.A. (Ap) Rutges who used the tool with his lectures on business modelling.

Credits

• Dr. A.C.M.A. Rutges, from the Faculty of Management, University of Groningen
• Bart Vijfschaft for some statistical components of the tool
• Students of the course BMT-7 (in 1995-1996), who were (mis-)used for testing the product extensively!

SmallSim's main strength comes from the fact that it models problem domains in an object-oriented way. In this respect it differs from the main simulation modelling tools such as Aris, ®Arena or BP$im™ and Taylor II. These tools take a process-oriented approach, which also is the approach taken by current standards such as BPMN (Business Process Model and Notation). The best thing to compare SmallSim with is not with these tools and standards, but with object oriented modelling languages such as UML. The difference is however that:

• SmallSim models are executable with full stochastic capabilities - we prefer to say they are simulatable
• execution can be monitored to provide rich statistical information and analysis
• strategies can be evaluated in advanced scenario factories

Many process-centric tools, for example for workflow modelling, offer simulation-like facilities. In fact we ourselves built such a modelling tool, LogSim. They enable you to build “virtual” organisations and run the simulation to see how well your design holds under “realistic” circumstances. Well, these circumstances are actually not so realistic, as any simulation expert will be able to tell you. Realistic simulations entail full stochastic behaviour, taking into consideration many different kinds of error-handling (for example to allow for run-in periods to dampen fluctuations in start-up situations). It is possible to achieve comparable results with well-crafted simulation tools. Our extensive experience with advanced simulations has shown us as much. But this can only be achieved by experienced simulation experts, and the resulting models often are complex and very hard to modify or tailor to changing conditions. The resulting models are also hard to explain to business experts.

Another Dutch company, BWise, attempted to develop tools along comparable lines. The difference, again, lies in the emphasis reflektis puts on modelling from an object-oriented and component-based perspective, compared to which the half-hearted but probably well-meant attempts of BWise fall short in many respects.

In SmallSim, you define object types. For example in modelling a mail office, an object type or class could be a Customer Teller (see illustration).

The class Teller contains the description of its instances, objects that are sometimes created and destroyed during the run of a simulation, or live during the entire simulation. Three aspects of objects can be specified: Arrivals, Attributes and Tasks.

Arrivals

An Arrival is a specification of the lifetime of the object: is it always available? Or is it entering the simulation, and if so, with which arrival schedule? Stochastic arrival times can be specified here. You can also specify arrivals that are drawn from real world measurements.

Attributes

Attributes are slots containing values, which can be numbers, strings, dates and so on. These attributes are available during the lifetime of the object, and can be used in the behaviour specification, described in Tasks. They remember the state of the actual object, the instance that is living inside the simulated business world. For example it could be the age of a product, used to determine the chance of breakdown.

Tasks

A Task is the actual behaviour of the object, as you can see in the illustration above. It contains a list of activities, which will be sequentially executed by the object during its lifetime. The list might contain one or more loops, which implies that the object will remain executing those tasks while the loop condition is true (potentially forever), or jumps (analogous to a goto).

There is a quite extensive list of standard activities to choose from, but SmallSim is completely extendible. You are free to specify custom activities, which are written using the powerful Smalltalk language. In the code for these custom activities you have access to the attributes and other activities of the object, as well as the direct collaborators of the object, i.e. those simulation elements that are connected with it on the canvas. In fact this creates infinite possibilities for creating models that can be as complex as you want them to be, and since the Smalltalk scripting language is exceptionally suited for describing complex business behaviour (Smalltalk has sometimes been designated as "the DSL of DSL's") you can do this in the most simple way.

Comment

A Comment contains a textual description that can be used as documentation of the object.

These classes are placed on a canvas, as you can see in the first illustration. After placing these basic building blocks on the SmallSim canvas, behaviour and properties are defined for each class object, as well as relations between the elements. This is done in exactly the same way as object-oriented modelling is done. Several approaches can be chosen, we prefer the Responsibility-Driven Design Approach (Rebecca Wirfs-Brock) combined with CRC sessions to model the behaviour of each object. In these sessions we can build the model live, with immediate feedback to the business experts, to validate the model and play with it.

Definition of behaviour in SmallSim is characterised by the addition of stochastic variables. Methods or operations are specified with a certain duration. In a method many actions can be specified, such as:

1. Acquire, release and consume fixed and shared resources
2. Wait for a specified duration (hold)
3. Wait for or signal specified conditions that can be shared among many objects (i.e. a signal)
4. Specify certain sections of tasks inside a loop
5. Specify any action using scripts with many templates to choose from, or write your own script
6. Create new objects or resources
7. Stop the simulation

Below you can see the tasks list of a Customer object. The loop element of the list is selected. Not only can you specify behaviour of active objects, you can use attributes as information needed for an objects´ behaviour. For example when an objects´ age has reached a certain amount, another path of action is taken (inside a loop or switch).

An important aspect of active objects is their arrival. Arrivals of objects are specified according to stochastic patterns. Arrivals can be stochastic, but also fixed, or upon other events. Each active object can create other active objects (or schedule them to arrive in the simulation at a specified time).

With these predefined behaviours you can model almost any problem, but the powerful scripting language enables you to write your own scripts for behaviour of any complexity. Since the scripting language is Smalltalk, the full functionality of a full fledged programming language is at your disposal.

Resources

SmallSim distinguishes between active objects (of which a property dialog is shown above) and passive objects. Passive objects are used as resources in the simulation. Resources are used to synchronise behaviour of active objects. The active objects compete for access to the resources, and the resources specify whether concurrent access is allowed and how (waiting line behaviour).

Run Configurations

After specifying the structure of your problem domain, the next thing to specify is the run configuration. This entails setting up special runs in batch- or interactive mode, and specifying what information you want to gather. After running the simulation, you can inspect the gathered information, for statistical analysis, and to further fine-tune your simulation runs.

Probability Distributions

SmallSim supports all relevant probability distributions, all of which built on industry-strength random number generators (a shortcoming of many comparable tools, because they often re-use random numbers generated from the standard programming language libraries in C# or Java). The following distributions are available:

1. Uniform
2. Exponential
3. m-Erlang
4. Gamma
5. Weibull
6. Normal
7. Lognormal
8. Beta
9. Pearson Type V and VI
10. Triangular
11. Empirical Distributions (from external datasets).
12. Bernoulli
13. Discrete Uniform
14. Binomial
15. Geometric
16. Negative Binomial
17. Poisson

Introducing LogSim

Note: LogSim is not to be confused with the British company Logistics Simulation Ltd., or with a log-making simulation program from HALCO Software.

LogSim is a process modelling and mining tool. It aims to help in creating executable business process models. LogSim is a business process modelling tool with integrated, full-fledged simulation facilities. In LogSim you not only build business models, but you execute them, you let them run while the software gathers all kinds of metrics to help you statistically evaluate your models for effectiveness, cost, speed etc. LogSim helps in detecting bottlenecks in your current solution so that you can improve your business performance.

Business process models are important in many contexts. They are used for optimising businesses, as tools for reaching a more mature level, as input for creating SOA’s, etc. Most service oriented platforms, such as Tibco, Cordys, SAP and WCF or BizTalk require some kind of process models, and they usually offer their own environment in which you can specify them. However, those environments do not help in actually measuring the performance of your solution. Before you can do that with any level of accuracy, you need to implement the process, run it for a minimum amount of time, and gather metrics. With LogSim you don’t need to do that. With LogSim you can build your models, play with them, and when you are satisfied your solution can perform according to your requirements, you can implement them on your platform of choice.

Currently LogSim is a proof-of-concept. The product does not offer functionality you might wish, such as export to BPEL. Also conformance to BPMN 2.0 is not fleshed out yet, although it is on the roadmap for version 4. It still is a one-man project so our resources are (yes, we are looking for funding) limited. However we believe we already offer more, especially in creating high-quality process models, than others, so we invite you to give LogSim a try.

History

LogSim originated from a research project that took place in 1992-94 on the University of Groningen, The Netherlands, at the Faculty of Management Science. It was a collaborative effort with Moret, Ernst & Young Management Consultants, that wanted to provide their clients with a tool that enabled them to model their business processes. For this they had developed a modelling language called Logistic Model and Notation (LMN), but they had envisioned that “just” making models and pictures was not enough: to build robust business process models you need to be able to run them, using a robust simulation environment that supports scenario’s, stochastic events, statistical monitoring etc.

In the course of 1993 and 1994 various versions of LogSim were produced, showing a gradual increase in understanding the power of combining a modelling language (which already existed and was used extensively, although only as a notational tool) with a simulation environment (which also already existed in the form of SmallSim, a generic simulation environment that I developed). The 1.x versions were multiplatform and were actually developed on a Macintosh. The 2.x versions were Windows-specific for various reasons that seemed valid at the time.

In 2011 we rebooted the project, which resulted in LogSim 3 (a new version still using the original Logistic Model and Notation). We also started work on LogSim 4 (which does not use LMN anymore as the notation but a somewhat extended version of BPMN 2.0). These versions are again multiplatform and available on all supported platforms.

Currently the focus (as far as focus goes…) is on LogSim 3, so that we will flesh-out the simulation engine and statistical tooling before changing the notation.

How to get it

The software will be made available again soon.

Goals of LogSim

LogSim wants to help in creating realistic models. Realistic models are models that reflect the actual complexity of real-world processes, in which stochastic events, uncertainty, waiting lines, in other words, chaos, make most models not optimal in practice.

Also LogSim wants to help the modellers in adapting models to reach goals like cost reductions and optimal efficiency. For this a model is not enough: you need to evaluate whether you are really choosing the correct strategies to reach those goals by playing with the different options and seeing the result of your decisions. Adapting your models should be as lightweight and simple a process as possible.

LMN (the modelling language used) was a remarkably prescient predecessor (10 years ahead!) of BPMN (Business Process Model and Notation). Most of the building blocks of LMN can be mapped to BPMN elements very nicely, as we will explain below. But LogSim contains on top of these modelling facilities a complete and robust simulation environment. Using this environment you can actually run your processes, and validate them against realistic dynamic behaviour, such as waiting lines, stochastic arrivals etc. With LogSim you build executable business process models.

This is different from the executability BPMN offers, and the various vendor tools contained in the products mentioned earlier, such as Tibco. That is because of the high level of realism that is close to what you will encounter in the “real” world. Executing a BPMN model in a service bus or on a process automation platform is actually something completely different than simulating that model.

LogSim 4

Alpha version!

Work is in progress for version 3 and 4. While version 3 will still only support LMN, version 4 will use a somewhat extended version of the BPMN 2.0 notation and syntax in order to be more compliant to the standard as defined by the OMG. BPMN as such lacks a few essential elements to make it complete for simulation purposes, such as Waiting Lines, so we needed to find a solution for those issues that are as much in line with BPMN as possible.

The extensions that we deemed necessary for BPMN to be really simulatable are:

1. Waiting Lines (there is no concept of queing in BPMN)
2. Stateful tokens (instead of the virtual placeholders in BPMN)
3. Stochastic distribution durations for sequence flows (instead of the instantaneous flow in BPMN)
4. Stochastic DMN in Activities (and the connected Gateways)

Probably some more will pop up in the test runs.

LogSim 4 will make it possible to build executable and simulatable BPMN models. Many environments and tools like BPSim promise this, we know, but we believe we make a difference, because our approach is different. Simulation in LogSim is not an add-on to a modelling tool or language, but the modelling tool is built on top of a robust simulation environment, containing robust simulation features such as:

1. run scenario building with bounded parameters
2. unattended runs and information gathering
3. industry-strength stochastic capabilities (probability distributions, random number generators)
4. run-in delays
5. and more!

The same simulation engine was used in another tool we created earlier, SmallSim.

We hope to distribute the software free-of-charge again. Beta versions will be made available for those brave souls willing to participate in early reviews.

LogSim 3

We are currently mainly working on version 3. This is a new version of LogSim, however still using the original LMN for its language. We do this because we believe that the modelling language LMN (short for Logistic Model and Notation) still has many interesting features, and because at the moment our time-resources are very limited and bringing out this version can be done relatively fast, while the work for version 4 will take longer. Remember, LogSim is a spare-time, one-man project at the moment!

LogSim 3 is multiplatform and available on all supported platforms. In this case multiplatform really means what it says: it run bit-identical on Windows, Mac, Linux and many others. You can open and work on the same model on all those platforms.

LogSim 3 uses a business process modelling language called the Logistic Model and Notation (LMN). This language may be regarded as a predecessor (but in a way also as the next generation…!) of BPMN with some interesting features that made it especially suitable for simulating complex logistic processes. The main distinguishing feature is that LMN contains the concept of Waiting Lines, with full stochastic support.

The walkthrough below is using the LogSim 3 engine. The screens are produced on a Macintosh running Mac OS X, but LogSim 3 will run on all supported platforms, and will adopt the look-and-feel of the platform you use. The screen shots are already several years old, modern versions look somewhat better I assure you!

Workorder

Logistic Model and Notation takes objects (defined with various properties) as central concepts, and models the flow of these objects through many stations or Transformators (see below) in a business.

These objects are called Workorders. In the real world these can be documents, actual products on which work is done (reflected by the changing attributes of the products during the flow), or abstract objects that you only use as placeholders for the process flow steps. The closest corresponding concept in BPMN is the Token, however there is a fundamental difference with BPMN in that in LMN a Workorder is stateful and can have an indefinite set of properties which can and will be modified during their processing in the execution flow, while in BPMN a token is stateless. And what is even more powerful: the modification of these properties is specified in stochastic terms as well!

External Agent and Event

The objects (or work orders) flowing through the model are instantiated by External Agents, that send Events into the organisation we are modelling. These events effectively instantiate these objects, with default properties. This is similar to BPMN in that most processes are triggered from external pools by Message Flows. External Agents can also subscribe to receive Events from any element within the model, on certain specified moments.

Objects (the Workorders) are created by Events. We can see here a specific kind of event called an Initial Event called SWIFT-payment, creating objects every 25 minutes according to a stochastic distribution (in this case an exponential distribution).

The objects created by this Event have a set of characteristics, that you can see above. LogSim 3 supports 2 attributes, and an unlimited number of them (as long as the total of percentages is 100 percent of course). Each of these can optionally be assigned a due date, that is we specify that in order to comply with our business rules these objects should be processed after this period of time.

Finally we can specify how many objects or Workorders are created. Again, this quantity can be specified as a stochastic distribution. In this case just one, as a fixed quantity, is produced. But it could just as well have been any distribution quantity.

External Agents correspond to the Triggers of BPMN (usually in the form of Messsage Flows triggering a Message Start Event), originating from other parts of the process environment, called (External) Pools in BPMN.

Waiting Line

These workorders are first dumped into the first Waiting Line, SWIFT-payment arrival in this case. Waiting Lines are interesting, and very important modelling constructs that are completely overlooked in BPMN. They represent the stochastic robustness of modelling in LogSim: it is precisely the stochastic aspect of reality that many modelling techniques fail to address properly, and which LogSim handles well. Waiting Lines do the trick.

BPMN explicitly chose to model only processes, and views waiting lines (or queues) as data structures. This is why there is no explicit way to model waiting lines in BPMN. The only way to “simulate” them is to create a specific Pool to dump the Workorders in, and processes that add to and take from the Pool, or use Data Stores to synchronise processes.

For the simulation facilities in LogSim Waiting Lines are very useful because they will gather any statistics you deem interesting, which helps a lot in determining the optimal process configuration.

In the Waiting Line shown here, there are no Workorders waiting, but since we have done a few runs many Workorders have passed through the waiting line. Click on the bar chart button and you will see a histogram of the period Workorders have been waiting inside the waiting line. We can also see that 168 Workorders have gone through this Waiting line:

This information can be useful in determining whether your business process is optimal or not.

Transformator

Each Transformator is a metaphor of a workplace, where one or more Transformers (think of Transformers as your work force, active agents such as people, departments or machines) work on these objects. This work is modelled as changing one or more of the object’s properties, as explained above. This is an extremely powerful feature, and the most distinguishing one of LogSim, which significantly exceeds the possibilities in BPMN.

Transformators correspond to the Activities of BPMN.

A Transformator is a certain activity or work on an object during a specified time interval, here a Uniform stochastic distribution between 0.3 and 0.6 minutes. Time spent in an Activity in BPMN cannot be specified.

During the work in this specific example no attributes are modified. However, these could be added to the list of transformations under “Actions”. Objects can have any number of basic scalar attributes, such as Strings, Numbers or Dates.

The actual work is not done by the Transformators, but by Transformers. This is analogous to the resources or capacity of an organisation. An Organisation (the containing entity in which the business processes are run) defines any number of them. These Transformers, or the work force, can be persons or other actors or roles such as computers or machines. They are allocated to one or more Transformators using a time schedule with priorities. For example, a desk employee is allocated to the front office during work hours with a priority of 60%, but to a manager with a priority of 70%, which implies that when the manager needs the employee, he or she is forced to stop working on front-office tasks. The activities performed by the Transformers (the workers) can be monitored and statistically analysed, in order to be able to make statements about the efficiency of a process scenario.

The next illustration shows the list of Transformers of an Organisation. The selected Transformer named “Central Computer 1” is allocated to two Transformators, “Receive SWIFT-payment” and “Book on VV-account”. This is done by selecting from a drop down list of currently defined Transformers (the blue rectangles in the model).

Properties window for the workers in the model. This shows the list of workers, as well as the list of scheduled transformations.

Logistic Regulator

What makes LogSim special, and able to closely resemble the complex reality you want to model, is the fact that you can specify special stochastic flow controllers, called Logistic Regulators. There are four kinds:

• Switch: switching on certain conditions (effectively branching the flow, or routing it)
• Splits: splitting objects to enable object copies to go through a different flow
• Joins: joining objects at specified points in the flow
• Timer: switching on time

These components correspond almost one-to-one to the various Gateways in BPMN with some extra functionality:

Above you can see a Logistic Regulator, here a Switch, which routes objects (or work orders) based on a stochastic distribution. When the draw (similar to throwing a dice) from the distribution indicates success the object or Workorder is routed to the node named “prepare, relay”. A Switch corresponds to the combination of an XOR gateway in BPMN, and a previous Decision Task, because the Switch actually decides about the gate that is activated. Also the Data-based behaviour in BPMN is different: there the Gateway routes based on information created and provided in the previous Activity (actually the BPMN standard says "any data known to the Process Instance"). Here the Switch routes based on either properties of the Workorder, or on a probability. This makes it much easier for example to model failure incidents that occur statistically.

The flow of objects is continuously monitored, which enables you to analyse statistically what happens. Running different models can be used as a simple scenario analysis.

Below you can see an example of a finished model, modelling international payments through SWIFT.

Splits and Joins

The application window showing a completed logistic model from which the previous illustrations are generated. The triangles are other flow controllers, called Splits, which effectively split the flow of control. Usually these Splits are later combined in controllers called Joins. The Join effectively combines objects into one new object, while keeping the accumulated flow information about the original objects. No information is lost.

Splits and Joins correspond closely to the concepts of Parallel Gateway, and AND Gateway in BPMN.

Timer

A LMN concept that has not been discussed so far is a Timer. This is a special Logistic Regulator that does not switch on attributes or probability distributions, but on time. For example, in weekends a support request is handled in a different way.

Click on the thumbnail below to see a finished model of a business process, in this case the processing of foreign bank SWIFT payments to a Dutch bank.

LMN Elements

• External object: Objects external to the main process (external pools). Corresponds to external (black box) pools in BPMN.
• Waiting Line: Queues for stateful tokens, from which Transformators take their next job. No corresponding element in BPMN (unfortunately!).
• Transformators: The workplace, where Transformers do their thing. Weak correspondence with BPMN Lanes, although the concept of Transformers in LMN is closer.
• Join: A Logistic Regulator merging objects from several workflows Closely corresponds to a merging gateway (both Parallel and OR).
• Split: A Logistic Regulator splitting objects across several workflows. Closely corresponds to a splitting Parallel or OR Gateway in BPMN.
• Switch: A Logistic Regulator containing logic to decide how to route objects. Corresponds to a combination of a Decision Task and an XOR Gateway in BPMN.
• Workflow: The route taken by objects. Corresponds to a Sequence Flow in BPMN, with some additional properties such as latency (stochastically defined).
• Event: Message sent out to external objects. Corresponds to a Message Flow in BPMN, with the constraint that this is only for messages out of the main pool to an external pool.
• Message: Message sent in from external objects. Corresponds to a Message Flow in BPMN, with the constraint that this is only for messages from an external pool to the main pool.
• Timer: A Logistic Regulator for routing based on time. Decides which route to switch to based on time. Corresponds to an intermediate timer event in BPMN.

Random number generation

Every stochastic aspect in the system is controlled by high quality random number generators. Both the random number generators as the stochastic distributions are built using the latest scientific research in that area.

You use the random generator to specify which one you want to use for a specific stochastic process. Several algorithms are available, and you can also provide your own file with “real” random numbers, or numbers obtained from event logs.

Random generators are the input for the broad spectrum of stochastic distributions that control the real events in the model:

Overview of stochastic distributions in LMN

• Bernoulli: A model for the set of possible outcomes of any single experiment that asks a yes–no question This distribution is used to model a set of yes/no decisions, in the case that each decision is completely independent of the previous one. The Binomial distribution is a special case of the Bernoulli, for a set of 1.
• Binomial: A model for a single yes/no decision A decision needs to be made, usually a succes/failure experiment. A series of such experiments would result in a Bernoulli distribution.
• Exponential: The amount of time until some specific event occurs The Exponential distribution or the Gamma distribution is used to predict the wait time until future events occur. For example: The time between arrivals at an airport or train station. Or the amount of time until an equipment failure. Or even the amount of time until the next earthquake. The difference between the gamma distribution and exponential distribution is that the exponential distribution predicts the wait time until the first event. In contrast, the gamma distribution indicates the wait time until the k^th event.
• Fixed: Not really a distribution! – it is a fixed value The same value is returned each time a sample is drawn from the distribution.
• Gamma: The wait time until the kth event Rarely used directly but it is an important distribution because it is used to generate other distributions that have much more use (e.g. Beta, Pearson etc). Closely resembles Weibull, which is often a better choice because it is much faster.
• MErlang:
• Normal:
• Poisson:
• Triangular:
• Truncated Normal:
• Uniform:
• Weibull:
• Any custom distribution: LogSim allows you to specify any custom distribution, or import a set of variables, for example collected from real-world observations

LogSim has originally been developed in close cooperation with Ernst & Young Management Consultants. The original (that is, before we started working on the tool) Logistic Model and Notation (LMN) is published by the project members from Ernst & Young, as far as I know only available in Dutch:

• Drs. N.A. Brand, ing. J.R.P. van der Kolk: Werkstroomanalyse en -ontwerp: Het logistiek vriendelijk ontwerpen van informatiesystemen
• Werkstromen volgens Nico Brand & Edwin Platier

This is a typical artefact from an architect:

It consists of the typical modelling constructs found in those work products from architects: squares, blocks, rectangular things stacked on each other. For many people, even architects I fear, architecture is more or less synonymous with stacking blocks in layers. The work products in TOGAF are also named as such: building blocks. Blocks.

It reveals a mind set, a paradigm if you will, with which problems of an architectural nature are approached: decompose the world into understandable units, that are of an industrial, artificial, mechanical nature.

It reminds me of an accident in a supermarket my wife went to last week. An assistant was filling crates with white cabbages, and when she walked away after the job, the cabbages started rolling and several rolled on the floor. Sure enough soon after that another crate, this time with mandarins, exhibited the same annoying behaviour. The assistant exclaimed: "why does everything need to be round?"

Indeed, several attempts have been made to create "square" food products, tomatoes, melons, etc. Soo much easier to handle, in transport and storage. Soo much easier to optimise the supply chain. If only nature produced square results…!

However, we all know (I hope…) that nature doesn't work that way. The reason nature's produce is usually some form of round is not to annoy us or to clog the supply chains. It has to do with other constraints that are perfectly logical in the context of another paradigm: that of immensely complex ecological systems operating under evolutionary constraints.

Enterprise architecture has to deal with complexity. The complexity of the enterprise, operating within an expanding economical and industrial world of competing entities. A complexity which has much more in common with ecological systems than with steam engines or clockworks, not to mention Lego.

It may produce nice art. But it is not alive. It is not evolving, changing, adapting, morphing.

Living nature is all that, and most of all: it is not square.

In my country we had a writer/illustrator who, in my view, was an absolute genius: Marten Toonder. His books were a combination of cartoon-like illustrations and text, almost untranslatable because of his very Dutch idiom. He created an unforgettable character, called Kwetal ("KnowAll"), who was a kind of nature spirit:

Kwetal was quite impressed with the mental faculties of the main character called Ollie B. Bommel (Oliver B. Bumble), which he referred to as "denkraam" ("mental case"), because he could think of things Kwetal could never do. Kwetal referred to the "denkraam" of normal humans as "square", which meant somehow not able to grasp the totality of things. That is exactly what we need to do as architect, grasp the totality, create a holistic view of the enterprise (or the problem domain). And using all those squares matches nicely with the square "denkraam" of many architects. But it totally mismatches with the reality of the world, that chaotic, constantly changing, round reality! We want to force the reality in square pictures, and are annoyed it doesn't fit.

Many of the example models I propose in my articles use round representations. The Business-Centric Architecture (sorry, currently in Dutch only) is exactly that. No layers, no rectangles, but round elements, arranged in circles. The difference may be trivial or even topologically no different from representations using rectangles. But it reveals a different mindset, and also functions (for me at least) as a reminder of that natural quality of chaos and roundness. And to work and think from that mental realm, and not the realm of mechanics and machines.

As Alan Kay remarked often, the computer revolution cannot really take place if we keep thinking of computers as steam engines or clockworks.

Estimated reading time: 4 minutes

Recent responses to my article on Mirrors prompted me to attempt to clarify the approach in that article. I think there is a fundamental philosophical discovery to be made in what I try to say, and indeed some of those responses confirm that. But it is as much a path to discovery to me as it is to my readers.

Architects create models. Indeed they do.

People, human beings, use language. Certainly.

The two things are related. In fact they are the same cognitive function, with the same effect. It is creating a map of the world, and through that faculty called language being able to transfer that map to others without requiring them to actually have the same sensory input you had in prompting (and enabling!) you to create that map.

It is also called symbolic representation. What we human beings also do, one might say beyond creating those maps, is manipulate those maps, play with them, morph them. Sometimes so much so that in effect the result is a new thing, unrelated to any original sensory input, a map of a world that can only be called imaginary. This is called symbolic manipulation.

Symbolic manipulation is tremendously powerful. Those imaginary worlds are evoked with those maps. This is what we humans did for countless centuries, roaming the savannahs, sitting by the fireplace in the dusk, and telling stories. The power of storytelling — or should I say story-listening? One listens to a story, and immediately the images spring to life. You have no problems experiencing the story as vividly as you experience your "real" life.

We cycled through a series of powerful inventions that created ever powerful maps, after that first creative leap of genius that created language: drawing, writing, the printing press. Until we stumbled on an invention that was the same, but also in some fundamental way totally different. I am now referring to the invention of the modern computer.

I think that, in order to realise the tremendous hidden promise of this invention, we should learn to see what is different from the previous inventions, not what is the same. What is different is that within a computers' vast memory and ever growing processing powers those maps are beginning, tentatively and for now awfully handicapped, to hatch and spring to a life on their own. Until now those maps only lived in our minds, and the maps we created were static, representations frozen in time: pictures, writing. That is changing, and that change is a fundamental one, of that I am growing more and more convinced.

Some of the "worlds" we have created are almost entirely "imaginary", that is, you cannot actually say they are related to sensory inputs or physical experience. The entire financial system is an example of such a world. However what we usually create in our computer systems of that "world" is static representations. Our accounts are not really "alive". We do not let them. Why can we not let our credit account figure out how to manage itself? Why not create a new insurance product that is alive and tries to sell itself and compute the best business model based on knowledge regarding risks it accumulates itself during its deployment? It may sound somewhat convoluted, but the actual system I envision is not much different from what is usually created. The devil is in the details, and with this other approach I advocate only a few things need change (see the Active-Passive Pattern for an explanation on one of the characteristics of such a system).

For more, you will probably want to read these related articles:

• Through the Looking Glass (i.a. on Alfred Korzybski and the Structural Differential)
• The Importance of Metaphors (i.a. on Alfred Korzybski and Gregory Bateson)
• Why Software Bites Back (i.a. on Gregory Bateson)

Do away with architectural models. What we need to see is the essence of architecture, which is something we realise in software: a mirror of the enterprise.

The idea is not new. It has always been surprising (and, to be honest, somewhat frustrating) that is hasn't been picked up as I thought it would. And should.

The book by David Gelernter: Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean (1993), summed it up so nicely. It succeeded (at least for me) in evoking an powerful image of software replicas of "real" things (like colleges or libraries), with the help of which so much more was possible. It aligned so nicely with my ideas about the computer revolution as a logical next step in the unfolding of our unique human faculty of language.

There is always the same conceptual interpretation of models, derived from mathematical models and such, that I find detrimental to the successful application of the power of the modern computer. Models are seen as "simplifications" of the "real" world. They show aspects or perspectives. Architects talk about viewpoints. You have different models for requirements, risks, structure, testing, etc. It is actually not much different from financial models, even in the personal finance domain: you tend to think your bookkeeping is a model just like the others, while the "real" world is something else, somewhere else. And, well, it is real.

Within the domain of finance this may be easier to argue. We are all starting to realise that money is not "real" at all! It is numbers. Before computers they were numbers in books. Now they are numbers in computers. Money does not "exist" at all, it is all virtual. So the step from using a bookkeeping system that is a "model" of your financial situation to a bookkeeping system that you can see as a thing in itself, no less "real" than what you originally thought as the "real" world, is not so big after all. This is a system living inside computers, as real as anything you can point to in the "real" world. The mental change that will enable you to exploit the power of the computer revolution to the max is just that: to see the system living inside software as an extension, a replica, a mirror of the "real" world. And a lot of tooling to keep both in sync.

Of course the problem is that we do not build our systems that way. Our systems are handicapped by a cognitive error.

Any architecture that confines itself to a bunch of matrices, lists, diagrams and documents, is bound to fall short on "meaning". It only touches the surface of it. It does not extend our faculty of language but hinders it. It does not offer an extension of intelligence or communication, but creates a panoply of artefacts that everyone gets lost in.

Language was a fundamental invention that completely transformed the species that invented it. That species of mammal subsequently enhanced that effect (of transformation) with the inventions of writing and the printing press. Now the modern computer is offering us the gift of another quantum leap in transformation. And we keep clinging to the past, to outdated modes of working. It is about automation, not about transformation. We do what we always did, only now with computers. We fail to see the essence of our human faculty of language which was to create an inner world of meaning, a reflection of the outer world of form. And then to start playing with that reflection and in advance of doing it in the world of form we could experiment in the world of thought.

Einstein did this. His breakthroughs in scientific models of our universe came from exactly that: thought experiments. Experiments that did not need extensive equipment. Only the imaginative mind.

Only now we can extend and enhance that mind, that reflective power of symbolic thought, infinitely.

Architecture can be as simple as that: a reflection, a mirror of the real world. To play with. And with that it will help us create systems that are exponentially more powerful. All it requires is a mental reorientation.

The satellite model is an alternative representation of complex architectures that is propagated by me as a more helpful metaphor than layered models or complex graphs. It helps because it centres on the centre: the business or company domain. The model re-appears in many articles on my site, and in some representations by other authors:

• Alistair Cockburn Hexagonal Architecture
• Robert Martin's plug-in architecture
• Eric Evans' Domain Driven Architecture
• Model-Driven Architecture (OMG)

This article focusses on the simplicity and applicability of this model, which is actually a combination of some patterns:

1. Adapter
2. Observer
3. Publish-Subscribe

Characteristics

The main characteristic is the clear and unambiguous placement of what we call the business domain: in the centre. The most important location is reserved for it. What is the business domain? It is what the system does, its objectives, its strategies. It has nothing to do with tools, technology or ICT, or in fact anything that does not directly capture the semantics of the organisation.

This is not always easy to demarcate. Is an account in a bank a business concept? Or is it a temporary technical construct because we need to track transactions? We need to decide what to include in this domain, and what not. Several rules of thumb help in making these determinations. In the article on eXploratory Modelling you can read about my favourite technique to elicit requirements from the domain experts, and about the importance of applying these two patterns:

1. Time Inversion Pattern
2. Active-Passive Pattern

The domain is not a model or a specification, although it might be realised from them. The idea is to create a running system. Because you have applied the rules above, this is possible. There is no dependency in the domain on persistency services or any of the other technical services. More on these components of the architecture below.

The domain component could conceptually be seen as a replica of the "real" world. I often explain it as a mirror world: it is similar but not identical to the "real" world, mainly because the two patterns are applied. It is "serviced" by technical components with the sole purpose of keeping it in sync with the "real" world. Technical components are the satellites.

Technical Components

In the satellite model the domain is not only a model, but a running component. Say we have it deployed inside a JEE session. Now in order to keep it in sync we deploy a set of technical components around it. These are the satellites.

Common components are the Persistency Service and the User Interface Service. Others might be the Security Service, the Distribution Service, and many others. There is no dependency in the satellite model between the domain component and the satellites, the technical services. The only thing flowing from the domain to the technical services are events. The domain generates these events on relevant moments in its life, in order to keep the technical services up-to-date about changes. For example an insurance policy is prolongated.

As I've said, there is no dependency between the domain and any other components. The technical components are updated through events propagated from the domain. However, this is not done directly. We want the technical components to be pluggable, that is, they should be built and maintained independent from the domains they are connected to.

In order for this trick to work, we need what is called adapters.

Adapters

Although adapters almost look like magicians, doing the magic that makes it all possible: to create completely independent domain components and technical services and somehow link them together, they actually are the simplest things you can imagine.

But there may be a lot of them.

Adapters can be deployed with various strategies, but they all share some characteristics. They are, as I've said, extremely simple. They are parameterisable, that is you can inform them about the specific domain parts and technical service interfaces they need to work with. They are created and brought to life on instantiating the solution, the whole shebang of domain components and technical services, functioning as the glue between all parties involved.

Advantages of the satellite model

As I hopefully explained successfully, the satellite model is basically very simple and easy to understand, but facilitates very complex and large architectures. An important reason for that is the enforcement of the rule that the domain components should be completely technology-independent. This helps those implementing those components tremendously because they can focus on the complexity of the business domain, almost without any burden from changes in technologies, or pollutions from technological constraints. They are free to realise these components apart from the technological hype of the day, in close cooperation with the business.

Another advantage which should not be underestimated is that now we are able to use technology in a more standardised way. The technical services should be built in a much more generic fashion, with teams that need less or in some cases no knowledge of the complex business domains.

A conceptual advantage is one I always emphasise: the domain is in the centre. That is where it belongs, if not technically. This model explicitly focusses the attention on the centre, the domain, which helps us realise why we are doing all this. By the way, in the domain components themselves I champion placing the customer in the centre. Again a reminder of why we are doing all this in the first place.

Conclusion

Although brief, I hope this exposition helps in creating some enthusiasm with the readers about applying this model in their work. If you do something similar of have any suggestions on improving the model, or applying it in specific contexts, please do not hesitate to participate in the dialog by commenting below.

Intent

We want to be able to grow our domain models. They must be infinitely scalable. Growing an already large model should not be more difficult than a small model. Change comes in two forms: changing existing functionality, or adding new. We want there to be as little difference as possible between the two, regarding testing, validating, and modelling.

Also Known As

No known current variants of this pattern are known to me.

Example

A banking system has functioned for years but now an invasive change is necessary: the format of the account numbering system needs to change from a proprietary 9-digit number to a standardised 20-digit one. Since this change will impact all existing accounts it seems to be a daunting job: all accounts will be touched, and this change may have numerous side effects. It may even be impossible to cover all test cases completely.

Context

Large, interdependent systems need a change that has rippling effects.

Problem

Even a small change can have massive consequences, making the changes in large, interdependent systems more and more expensive.

Solution

Don't change existing objects. Not for changing existing functionality, nor to add new functionality. Existing test cases should not need to be modified. Instead functionality is modified by adding more objects. Since the model has been created using the Active/Passive pattern it is a loosely coupled model that does not hinder us in doing this.

Structure

Existing objects will still be used by the existing part of the system. However new parts, those that need to work with the new format, will "enhance" those existing objects by reusing them. This is done by wrapping the existing bank accounts in a new bank account object, delegating all necessary behaviour to the existing object, but (as it were) enriching the object with the new behaviour.

Variants

The Decorator pattern from the Design Patterns book. In fact this is the possible implementation of this pattern.

Known Uses

Consequences

• Changes do not lead to mandatory changes to existing components
• Test cases do not need to be modified (same rule applies: change will lead to new components, in this case test cases, not to changes to existing components, in this case test cases)
• The system may only grow, this is a possible adversary effect of the applying the pattern. As with any pattern, it is not applied in isolation: you will still need to audit your solution for legacy migration, which will phase-out obsolete parts of the system.

See Also

• Open-Closed Principle

Dit is de Nederlandse vertaling van The Mirrored World

Estimated reading time: 4 minutes

Software is de spiegelwereld, a digital twin. De buitenwereld is de "gewone" wereld waarin wij leven. In toenemende mate zien we dat, met de groei van het internet en talloze software systemen waarmee we ons omringen en waar we in toenemende mate niet meer zonder kunnen, er sprake begint te zijn van "twee ikken": de ik in de gewone buitenwereld, en ons ik in de binnenwereld, de persoon die wij zijn als we googlen naar onze persoon, de profielen op allerlei forums, de blog aanwezigheid van steeds meer mensen. De virtuele persoon die we in toenemende mate ook zijn.

Die twee ikken zijn volgens mij een aspect van wat software en taal in het algemeen op een abstractere manier aan het doen is, namelijk een replica van de buitenwereld in de "binnenwereld" creeëren. De enige manier die complexe ondersteuning door software mogelijk maakt op een schaalbare manier, is door die software te zien en te bouwen als een replica van die werkelijke wereld. Dit is hoe je een domein model (domain driven design) zou kunnen zien.

Het "Domein"

Het domein, dat centraal staat in de domeingedreven architectuur, is een simulatiemodel. Een replica van de buitenwereld. Een binnenwereld. Het is ook een actieve wereld: de componenten waaruit die wereld is opgebouwd zijn bezig, doen dingen, dingen die anders zijn dan in de "werkelijke" wereld, en dat verschil lijkt triviaal maar is dat niet. Een stukje uit Alice in Wonderland:

Then she began looking about, and noticed that what could be seen from the old room was quite common and uninteresting, but that all the rest was a different as possible. For instance, the pictures on the wall next the fire seemed to be all alive, and the very clock on the chimney-piece (you know you can only see the back of it in the Looking-glass) had got the face of a little old man, and grinned at her.

De twee werelden zijn synchroon, op een speciale manier, en adapters spelen daarin een belangrijke rol. Zij zijn de lijm, de magie zou je misschien kunnen zeggen. Zoals de wereld die Lewis Carroll verbeeldde, maar die wij altijd in onze geest hebben meegedragen.

Taal

Taal, het label waaronder ik al deze artikelen op deze site plaats, is ook het label waaronder ik de ontwikkelingen rond de moderne computer plaats. In een ander artikel probeer ik een beeld te schetsen van wat taal is. Met taal is de mens begonnen een wereld te vorm te geven die misschien daarvoor ook al in zijn geest aanwezig was, maar dankzij de woorden die er aan gegeven werden concreter werden, en overdraagbaar naar anderen. Een virtuele wereld van verhalen, die een eigen leven zijn gaan leiden, verhalen die misschien honderduizenden jaren geleden begonnen zijn en waarvan de resten in onze huidige verhalen nog steeds teruggevonden kunnen worden. Verhalen die mede hebben bijgedragen aan onze psyche (de archetypen van Jung). In die verhalen brachten mensen de binnenwereld naar buiten, en de luisteraars weer naar binnen. De binnenwereld van verhalen is een aspect van ons mens-zijn.

Misschien is dat spiegelen de essentie van leven en intelligentie. Enige tijd terug zijn biologen in het nieuws gekomen met het concept "spiegelneuronen" (zie ook: Noorderlicht, VPRO). De eigenschap voortdurend de omgeving te spiegelen is niet alleen in neuronen, wat gespecialiseerde cellen zijn, waargenomen, maar zelfs bij ééncellige organismen. In het boek van Jeff Hawkins, On Intelligence , ontwikkelt de schrijver een theorie over de werking van onze hersenen die gebaseerd is op het "weerspiegelen" van de buitenwereld, waarbij de hersenen tevens voortdurend bezig zijn die twee werelden te synchroniseren, maar ook met het "voorspellen" van die buitenwereld.

Professor van den Berg in het boekje Zien : verstaan en verklaren van de visuele waarneming , maakt hierin ook de observatie dat wanneer iemand binnen komt en we zien de betreffende persoon nog niet, dat onze ogen wel al, door de muur heen, die persoon volgen, vóórdat deze zichtbaar wordt in de deuropening. Dezelfde van den Berg, in zijn boek Leven in Meervoud, maakte een diepe indruk op mij toen ik las over zijn waarnemingen betreffende "meervoudige" personen, iets dat volgens van den Berg pas is gaan optreden na de technologische ontwikkelingen van de moderne tijd. Wij zijn spiegelwezens!

Het artikel van Vannevar Bush, waarnaar ik op meerdere plekken verwijs, heeft het over memen, alsof het levende wezens zijn die alles met alles verbinden, een idee dat ten grondslag ligt aan het concept hyperlinking dat zo belangrijk is op het internet.

• Veel vragen, weinig krijgen - Computable
• Business Centred Architecturen I
• Why Software Bites Back
• Business Centred Architecturen III
• Enterprise Architecture’s New Clothes – CSC Blogs