This time, I want to explore the flip side of that problem. What happens if we do have such a blueprint? What would it change about predictability, efficiency, cost, security, and compliance in the SDLC?

Because if we’re honest, today’s reality is hard to defend.

Despite all our ceremonies—backlog grooming, sprint planning, refinements, technical modelling sessions, coordination meetings, status syncs—we still regularly get it wrong. Every new feature feels bespoke. Every business process feels like a special case. We keep re-explaining the same ideas in different words, to different audiences, in different formats.

And yet, the systems we’re trying to build are often not that unique.

Wouldn’t it be nice if we could take a business process we want to automate and break it down into a small set of easy-to-understand, repeatable building blocks? Even better, what if the number of those building blocks was very small—say, a handful?

This is not a pipe dream. Nature has been doing this successfully for billions of years.

The universe is built from a limited variety of atoms. An overwhelming amount of complexity emerges from just a few elements like carbon, oxygen, hydrogen, and nitrogen. Water—so central to life—is composed of a single type of molecule: H₂O. DNA, the blueprint of life itself, is built from just four base elements.

And then there’s Lego. From a small set of simple bricks, we build cities, rockets, and entire worlds.

Enterprise software doesn’t have to be different.

When we use EventModeling, we can identify similar building blocks—patterns—that repeat across virtually every non-trivial business process.

Take a simple example from Life & Health insurance: a policy owner requests an increase of the sum assured.

When we model this with EventModeling, a familiar structure emerges. There is an actor. The actor sees information on a screen, enters data into a form, and triggers an action. That action is a command. If the command is valid and successful, it results in a business event.

That combination—actor → command → event—is our first building block.

This is a Change State pattern. Someone intends to change something in the system.

Once you notice it, you see it everywhere:

• • cancelling a policy

• • changing an address

• • correcting a date of birth

• • updating a name after marriage

Different business intent. Same structural pattern. Always an actor. Always an explicit command. Always a resulting business event.

There is another equally fundamental pattern.

Sometimes an actor doesn’t want to change anything. They just want to know. For example, a policy owner wants to see a summary of all premium payments made this year.

This is a View State pattern.

Under the hood, a set of past business events is aggregated into a view or projection representing the current state. The UI queries that view and displays it to the actor. Again, once you see it, you can’t unsee it:

• • viewing policy details

• • listing past premium payments

• • showing a policy summary

Same pattern. Repeated endlessly.

With just these two simple but powerful building blocks—Change State and View State—we can already compose remarkably complex enterprise systems. Yes, there are a few more patterns, but they are equally small in number and equally reusable.

This is where the missing blueprint starts to pay off.

If we model our systems from the outset using a small, shared set of patterns:

• • the SDLC becomes more predictable

• • implementation becomes more efficient and affordable

• • security and compliance stop being afterthoughts and start being designed-in

• • teams spend less time translating and more time building

Most importantly, everyone—from business to engineering—can literally point at the same picture and say: “Yes, that’s what we’re building.”

That, to me, is the real promise of a shared blueprint.