Having worked in different sectors of the industry over more than 30 years, I have seen the same picture again and again.

This is not about one company. It is not about one domain. It is not about one methodology being applied badly.

It is a recurring pattern in mission-critical enterprise software.

Teams are asked to move fast. Business stakeholders are busy. Engineers are under pressure. Security, compliance, legal and operations often have many initiatives competing for their attention.

So it is understandable that we hesitate to gather everyone in the same room early enough.

Business people. Engineers. Architects. Security. Compliance. Legal. Operations. The people who understand the problem, the constraints, the risks and the consequences.

We tell ourselves it may be too expensive. We assume business may not have time. We worry that too many conversations will slow delivery down.

We hope that a few notes, a few meetings, a few Jira tickets and a few acceptance criteria will be enough to move forward.

And then we start.

We create epics. We create user stories. We refine the backlog. We estimate. We plan sprints. We run our ceremonies. Everyone does their best to create clarity from the material available.

Sometimes that works well enough.

But very often, the clarity is thinner than we think.

At best, the happy path is described. Maybe there is a title, a decent description and some acceptance criteria. But the real business rules are often hidden between the lines. The exception cases are incomplete. The decision points are not fully visible. The security implications are not yet explicit. The operational consequences have not been discussed in enough detail.

So the engineer implementing the ticket has to fill in the gaps.

Or ask questions later.

Or interpret intention from fragments.

Or adjust the code after a conversation that never quite makes it back into the ticket, the design, the tests or the documentation.

That is where drift begins. The ticket says one thing. The code does another. The tests cover something else. And the real business process lives partly in people’s heads.

We then wonder why delivery feels slower than expected. But often the problem did not start in delivery. It started much earlier, when ambiguity became part of the input.

And this ambiguity spreads.

Have we thought about authorization at this stage?

Sometimes yes, but often not deeply enough.

Security is frequently treated as something separate. Something that can be added around the system later. But authorization is not just a technical concern. It is a business concern.

A procurement manager may be allowed to approve a supplier contract. Maybe even approve a high-value purchase order. But should the same person also release the payment to the supplier?

That is not primarily a database permission problem. It is a capability problem. It is a separation of duties problem. It is a modeling problem.

The same is true for compliance.

Do we know where personally identifiable information enters the system? Do we know where health data flows? Do we know who can see it, change it, export it or use it to make a decision?

These questions are often asked, but sometimes only when the implementation is already well underway. GDPR, HIPAA, auditability, retention, access control and data minimization are treated as dedicated exercises. Important, yes. But separate. And often later than would be ideal.

Then operations enters the picture.

Do we know what happens if something fails at 2 a.m.? Do we know what the on-call team should look at? Do we know which business capability is affected? Do we know how to stop the bleeding without making things worse?

Again, this is often handled later. In a runbook exercise. In a production readiness checklist. In an operational governance review.

All useful. But also all downstream of design decisions that may already have been made, sometimes implicitly.

Meanwhile, the architecture has become heavy.

Microservices. ESBs. Kafka. Database per service. Caches. Containers. Kubernetes. CI/CD pipelines. Automated release reports.

All of these can be valuable tools.

Yet a pull request may still take hours before it can safely reach production. Deployments may still bundle many changes together. Those changes are often interconnected. They can have side effects. We can list the tickets included in a release because the report is generated automatically. But that does not always mean we understand what is really being released.

To understand that, someone may still have to read the tickets, inspect the pull requests, reconstruct the intent, infer the business impact and hope that the documentation has not drifted too far from the code.

At some point it is worth asking a constructive question.

What are we really gaining?

What do we gain from microservices if the boundaries are not based on real business decisions? What do we gain from Kafka if we do not understand events as a business history? What do we gain from database per service if we cannot explain the flow of sensitive information? What do we gain from CI/CD if every release still feels like a bundle of uncertainty?

The technologies are not the problem. Most of them are useful in the right context.

The challenge is when architectural sophistication is used to compensate for missing business design.

Because that compensation is expensive.

Now compare this with a different starting point. Imagine an information-complete blueprint. Co-designed by the relevant stakeholders. Owned by business and technology together. Visible enough that people can literally follow the flow of information with their finger. Not hidden in tickets. Not scattered across documents. Not reconstructed from pull requests.

One shared model.

In EventModeling, such a blueprint can be divided into slices. And the important point is that these slices are not bespoke every time.

There are only a few recurring types.

A state change slice. A state view slice. An automation slice. A translation slice.

That can sound almost too simple. But that is where the leverage is.

Each slice becomes a self-contained work package. The business rule is visible. The command is visible. The event is visible. The projection is visible. The UI interaction is visible. The automation is visible. The external dependency is visible.

The test scenarios are no longer invented after the fact. They emerge from the model.

Security can reason about capabilities instead of raw data access.

Compliance can reason about information flow instead of asking teams to fill out generic questionnaires.

Legal can see where sensitive data enters and leaves the system.

Operations can see which business capability depends on which flow.

Auditors can see what happened, in which sequence, triggered by whom or by what.

And engineers no longer have to guess what the ticket means. They have a slice. A small, clear, testable and implementable piece of the system.

This does not remove all complexity. Real systems are complex. Regulated domains are complex. Business rules are complex.

But there is a difference between essential complexity and accidental complexity.

Essential complexity belongs to the business.

Accidental complexity is what we create when we do not model the business clearly enough before we build.

That part can be reduced. Not mainly with more ceremonies. Not mainly with more ticket templates. Not mainly with more architectural fashion.

But by doing more of the hard work early.

Gather the right people. Build the shared blueprint. Make the flow of information visible. Model the decisions. Model the responsibilities. Model the capabilities. Model the events.

Then implementation becomes a consequence of understanding, not a substitute for it.

The workshop may look expensive.

But ambiguity is far more expensive.

We pay for it in delivery delays, rework, compliance gaps, security exceptions, operational incidents and architectures that are much more complicated than they need to be.

Originally published on LinkedIn (2026-05-11): https://www.linkedin.com/pulse/workshop-looks-expensive-ambiguity-worse-gabriel-n-schenker-sorge