Why Value Streams Don’t Map Cleanly to Systems

Governance Problem

Value streams make things look simple.

  • stages are clear
  • flow is linear
  • responsibilities are defined

You can point to a step and say:

“this is where validation happens”

Then you try to implement it.

Where it starts to break down

Take a stage like:

“Validate Booking”

In practice, that rarely exists as a single action.

It’s spread across:

  • multiple forms
  • several records
  • partial updates
  • checks happening at different times
  • sometimes different users

There is no single “validate booking”.

There are a series of smaller decisions.

Systems don’t operate in stages

They operate in smaller units:

  • field updates
  • record saves
  • state transitions
  • background processes

Each one is:

  • local
  • specific
  • tied to a moment

A value stream stage is none of those things.

It’s an aggregation.

Where the mismatch shows up

If you try to enforce governance at the stage level:

  • checks get applied too early
  • or too late
  • or too broadly

You end up with rules like:

“booking must be valid before release”

Which is correct.

But incomplete.

The system still needs to know:

  • what defines “valid”?
  • which fields matter?
  • when is that checked?
  • what happens if it changes after validation?

A more practical mapping

Value streams are still useful.

But not as execution logic.

They work better as:

  • indicators of where control might be needed

Then you map that to actual system points:

Stage: Validate Booking
→ Checks at:

  • form validation (data completeness)
  • before commit (consistency)
  • before transition (approval or final check)

Now the system has somewhere to act.

What this avoids

Trying to force a one-to-one mapping leads to:

  • oversized forms
  • overloaded validation logic
  • unclear ownership of rules

Everything gets pushed into a single step that doesn’t really exist.

Where this becomes obvious

This shows up quickly in:

  • legacy migrations
  • spreadsheet replacements
  • partially automated workflows

Because in those environments:

  • the stages are known
  • but execution is fragmented

Trying to collapse that into a single system step usually creates friction.

What actually works

Treat value streams as a guide.

Not a blueprint.

Use them to:

  • understand flow
  • identify likely control points
  • highlight responsibility

Then let the system operate at its natural level:

  • fields
  • forms
  • commits
  • transitions

A useful distinction

Value streams describe:

  • how work moves

Systems define:

  • where decisions happen

Those are not the same thing.

Closing thought

Value streams give clarity at a distance.

Systems deal with detail up close.

Bridging the two works best when you respect both.

But don’t try to make them line up too neatly.