That is one of the friendlier reactions you hear when you suggest modelling an enterprise system using just four foundational building blocks.

You can see the skepticism immediately. Engineers lean back in their chairs. Business stakeholders nod politely, but their eyes say something else. It sounds too simple.

We have been conditioned for years to believe that enterprise software is inherently complex. And if the system is complex, then the modelling must be complex. And if the modelling is complex, then the implementation must be painful. Almost as if the pain itself is proof that the work is serious.

If it does not hurt, it cannot be real.

But this is a misunderstanding.

A complex business process is not complex because its individual parts are complex. It becomes complex because many simple parts interact with each other. Complexity is something that emerges from composition.

Nature has understood this long before we wrote a single line of code.

The Butterfly

A butterfly looks impossibly intricate. The patterns, the symmetry, the fragile structure of the wings. It feels like something designed with infinite detail.

And yet, at its core, it is made of the same fundamental building blocks as everything else. Atoms. There are no special butterfly atoms. Just combinations arranged in a certain way.

What we perceive as complexity is an emergent property.

The Airplane

An airplane feels intimidating in a different way. Engineered. Heavy. Mechanical. When you stand next to one, it feels like the result of enormous complexity.

But zoom in far enough and you will find the same story. Atoms form materials. Materials form components. Components form assemblies. Assemblies form the aircraft.

Again, complexity emerges from simple parts interacting.

And yet, in software, we struggle to accept this idea.

When you say that a modelling technique like #EventModeling relies mainly on four foundational building blocks, people assume it must be naïve.

It will not work here. Our domain is too complex. This is not a toy system.

So they stay with the pain they know. It feels safer. Complexity feels serious. Simplicity feels suspicious.

Now we have added AI to the story.

Suddenly, many believe that this will solve everything. That the machine will handle the complexity for us.

But AI fails in exactly the same places where engineers fail. When specifications are ambiguous. When information is incomplete. When statements contradict each other.

When something is undefined, engineers make assumptions. Often wrong ones, especially when they are not domain experts. Those wrong assumptions eventually surface as production incidents.

Large language models behave in a similar way. If the instructions are unclear, they fill in the gaps. We call it hallucination. It is not magic. It is pattern completion.

If the input is underspecified, the output will be fiction.

Here is where it becomes interesting.

When we model with #EventModeling and structure slices around one of the four fundamental patterns, each slice becomes information complete. There are no hidden assumptions. No missing context. No ambiguity about what should happen.

Now even a modest LLM running locally can implement it.

Not because the AI is exceptionally intelligent. But because the design is clear.

If you provide one solid template for each of the four building blocks, the rest becomes repetition. The complexity of the business process emerges from the composition of these slices.

Just like in nature. Just like the butterfly. Just like the airplane.

The real difficulty is not technical.

It is psychological.

We have to allow ourselves to believe that something simple can still be serious.

Originally published on LinkedIn (2026-03-03): https://www.linkedin.com/pulse/its-childs-play-gabriel-n-schenker-ginje