The difficult part is often between the systems

Many system failures are obvious.

An API returns an error.

A database is unavailable.

A scheduled process crashes.

A user sees an exception.

Those problems are relatively easy to classify because something has failed inside a defined system boundary.

The more interesting failures are often less visible.

Two healthy systems can still disagree

Consider a simple example.

Licence Management says:

EPM-10001 complianceStatus = AtRisk

Programme Assurance says:

EPM-10001 complianceStatus = OnTrack

Both applications are online.

Both databases are healthy.

Both APIs return 200 OK.

Neither application contains an internal error.

Yet the organisation has an inconsistent operating position.

The failure exists between the systems.

Integration is not the same as orchestration

Traditional integration answers:

How do I move information from System A to System B?

That may require:

• REST,
• JSON,
• webhooks,
• database connectors,
• CSV,
• transformation,
• authentication,
• field mapping.

Those capabilities are essential.

But orchestration adds another question:

What should happen because this information changed?

For example:

Licence obligation becomes High risk
        ↓
publish event
        ↓
update Programme Assurance risk
        ↓
include in next investor update

The route and sequence matter, not only the transport.

The orchestrator should not own the domain decision

There is an important boundary here.

Licence Management should decide whether an obligation is at risk.

Programme Assurance should decide how that risk affects the programme.

The orchestrator should not duplicate either piece of business logic.

Its job is to:

• receive the event,
• understand the route,
• transform the payload if necessary,
• deliver it,
• retry if delivery fails,
• record what happened,
• and verify whether the expected downstream state exists.

That is enough.

Central routing reduces coupling

Without an orchestrator, applications gradually learn about one another.

Investment Screening needs the Programme Assurance URL.

Programme Assurance needs the Licence Management API.

Licence Management needs an ERP endpoint.

Another application needs all three.

Soon every system contains integration logic for several others.

A hub changes the model.

Applications publish events to one known place.

The orchestrator understands destinations.

That means the producing application does not need to know who is listening.

This is particularly useful for generated applications because their domain code can remain focused on the domain.

Scheduling belongs here too

Time-based execution creates a similar boundary problem.

A licence system may need to evaluate obligations every morning.

The business rule belongs in the licence system.

But the scheduling infrastructure does not necessarily need to.

A central scheduler can invoke:

evaluate_obligations

at 06:00 each day.

That becomes even more useful when application containers can be stopped when idle. A sleeping application should not be responsible for waking itself to run its own cron job.

Orchestration creates visibility

Once integration routes, scheduled jobs and deliveries are centralised, the operating environment can answer questions such as:

• Which systems are registered?
• What was the last successful synchronisation?
• Which events are waiting?
• Which routes failed?
• What jobs ran overnight?
• What information was transformed?
• Which target application received it?

That provides something individual applications cannot: a view across system boundaries.

But even this is not enough.

The orchestrator may successfully process every event it receives and still miss something important.

Because events can only describe things that happened.

They cannot automatically describe things that should have happened, but did not.