TL;DR
- Orchestration puts one component in charge of the sequence. Choreography lets each react to events and gives none the whole picture.
- Orchestration fails at the coordinator, which is a visible bottleneck. Choreography fails at visibility, and a request nobody can locate is worse.
- Intake-to-ERP is a sequence and favors orchestration, because a requester is entitled to know where their request is.
- Choreography fits fan-out, such as supplier enrichment, where steps are independent and nobody waits on a combined answer.
- See how Merlin Intake handles procurement requests. Request a demo.
Orchestration puts one component in charge of the sequence. Choreography lets each component react to events and gives no component the whole picture.
For intake-to-ERP the answer is almost always orchestration, and the reason is not technical elegance. It is that somebody has to be able to answer where a request currently is, and in a choreographed design nobody can. That single requirement decides most of the architecture.
This is written for procurement operations leaders sitting in an architecture conversation where the two words are being used and the trade-off has not been made explicit. It assumes an ERP integration is already in scope and that the pattern has not yet been fixed.
What is the difference in practice?
One asks. The other announces. That is the whole distinction, and every consequence below follows from it.
- In orchestration, a coordinator calls each step and waits for the result. Create the purchase order, then attach the budget line, then notify the requester. The coordinator holds the sequence, knows which step is current, and decides what happens when one fails. If you want to know the state of a request, you ask the coordinator.
- In choreography, each component publishes an event and other components react to it. Intake publishes request approved. The ERP subscribes and creates an order. Notification subscribes and messages the requester. Nothing holds the sequence, because the sequence is an emergent property of who happens to be listening.
Where does each one fail?
- Orchestration fails at the coordinator. It becomes a bottleneck under load, a single point of failure, and over time a place where business logic accumulates because it is the convenient place to put it.
- Coordinators grow, and a coordinator that has grown for three years is difficult to change safely.
Choreography fails at visibility. When a request stalls, there is no component that knows the request stalled. Each component knows only whether its own event arrived. Diagnosing a stuck request means reconstructing what should have happened from logs across several systems, which is why choreographed integrations tend to be diagnosed by the person who built them and nobody else. That dependency is invisible until they leave.
The second failure is worse for procurement specifically. Figure 1 sets the two failures side by side. A bottleneck is visible, measurable, and fixable with capacity. Requesters do not distinguish a lost request from a slow one, and remember both as procurement failing. A request that vanished is none of those things, and it consumes procurement’s credibility rather than its infrastructure budget.
Figure 1: Each pattern fails, and one failure is far worse.
Why does intake favor orchestration?
Because procurement requests have an owner who is entitled to an answer. This is a requirement rather than a preference, and it constrains the design more than most technical criteria do.
- A requester asking where their laptop is has asked a reasonable question, and answering it requires some component to know the current state of that request. Orchestration provides this by construction.
- Choreography can provide it only by adding a separate tracking service, which is orchestration reintroduced under another name and usually built with less care, because it was not part of the original design.
There is also an accountability point. Procurement is answerable for the request, so procurement needs a system of record for its progress rather than a reconstruction of it. Choreographed designs distribute that record across subscribers, which is exactly the wrong shape for a function that gets asked where things are several times a day.
Gartner was assessing agent governance rather than integration patterns. The connection here is that governance gaps found only after production is the same failure this piece describes: a design whose state is unobservable until something has already gone wrong.
Download a FREE Ebook – AI Infrastructure Procurement: Why It’s the Critical Path
When is choreography the right choice?
When the steps are genuinely independent and nobody needs to know the overall state. That condition is narrower than it sounds and it is worth testing rather than assuming.
Enrichment is the clearest case. When a supplier record is created, several systems may want to react: risk scoring, tax validation, catalog indexing. None depends on the others, none has to happen in order, and no requester is waiting on a combined answer. Choreography suits this well and orchestration would add coordination nobody needs, plus a coordinator to maintain.
The pattern is that choreography fits fan-out, where one event triggers several unrelated reactions, and orchestration fits sequences, where steps depend on each other and somebody is waiting for the end. Naming which one you are looking at settles most of the argument before it starts, and it takes a single sentence.
Intake-to-ERP is a sequence. Supplier enrichment is a fan-out. Most procurement platforms contain both, and the mistake is choosing one pattern for everything because a preference was formed before the workloads were examined, usually by whoever wrote the first integration.
Forrester studied buying cycles rather than integration design. It matters here because a function acting as decision-maker in most buying cycles is a function whose systems are written to constantly, which makes the coordination question a procurement concern.
Watch – The New Metrics For Measuring Procurement Success In The Digital Age
What should you ask your architecture team?
Four questions, set out in Figure 2, and none requires you to take a position on the technology. Each has a concrete answer that either exists or does not.
- Who can tell me where a given request is right now, and how. If the answer involves reading logs from several systems, the design is choreographed and you should decide deliberately whether that is what you want for requests a person is waiting on.
- What happens when step three fails after steps one and two succeeded. Orchestrated designs answer this with compensation logic. Choreographed designs frequently have no answer, because no component knows steps one and two happened. Ask what the manual recovery looks like, since that is what will actually be used.
- Where does business logic live. If it is spread across event handlers, changing a rule means changing several components, and nobody will be certain they found them all. Approval thresholds change more often than architectures do, so this determines your cost of change rather than your cost of build.
- How do we replay a failed request. This is the practical test, and it is where most designs turn out to be less recoverable than assumed. Ask for a demonstration rather than a description, using a request that has already failed.
Merlin Intake integrates with ERP systems as part of the platform rather than through separately assembled middleware, which means the coordination question is answered by the platform rather than negotiated project by project. The questions above still apply, and any vendor should answer them without reaching for a diagram.
Figure 2: Four questions, none requiring a technical position.
Hackett measured shared services capacity rather than architecture. The relevance is that a widening gap between workload and staffing raises the cost of an integration nobody can diagnose without its original builder.
Request a demo to see how Merlin Intake can help!
Frequently asked questions
Q1. What is the difference between orchestration and choreography?
In orchestration a central coordinator calls each step in sequence, holds the current state, and decides what happens on failure. In choreography each component publishes events and others react independently, with no component holding the overall sequence. Orchestration centralizes control and visibility. Choreography distributes both.
Q2. Which pattern is better for intake-to-ERP integration?
Orchestration, in almost all cases, because procurement requests have an owner entitled to know where their request is. That requires some component to hold current state, which orchestration provides by construction and choreography provides only by adding a tracking service that is orchestration by another name.
Q3. When should you use choreography?
When steps are genuinely independent and nobody is waiting on a combined outcome. Supplier record enrichment, where risk scoring, tax validation, and catalog indexing all react to the same event without depending on each other, is the clearest procurement example. Choreography suits fan-out. Orchestration suits sequences.
Q4. What is the main risk of choreographed integration?
Loss of visibility. When a request stalls, no component knows it stalled, because each knows only whether its own event arrived. Diagnosis means reconstructing the intended sequence from logs across systems, which in practice means only the original builder can do it reliably.
Q5. Does orchestration create a single point of failure?
It concentrates risk at the coordinator, which can become a bottleneck under load and a place where business logic accumulates. These are real costs and they are visible, measurable, and addressable with capacity or refactoring. The choreographed failure mode, a request nobody can locate, is none of those things.
Q6. Can you use both patterns in one platform?
Yes, and most well-designed platforms do. The sequence from request to purchase order is orchestrated because steps depend on each other. Supplier enrichment and notification fan-outs are choreographed because they do not. Choosing one pattern for everything is the more common mistake.
Q7. Should procurement care about integration patterns?
Yes, because the consequences land on procurement. Whether a requester can be told where their request is, whether a failed step can be replayed, and whether changing an approval rule requires touching several systems are all operational realities for procurement rather than abstractions for engineering.
Q8. How do you test which pattern an existing integration uses?
Ask who can report the current state of a single in-flight request and how they do it. If one system answers immediately, the design is orchestrated. If the answer involves correlating logs across several systems, it is choreographed, whether or not anyone described it that way when it was built.
