Is Model Context Protocol Replacing Enterprise Service Bus?
An Airport Conversation That Completely Changed My Thinking
Last week, I had one of those unexpected moments of insight that hits you outside work, outside meetings, outside architecture thinking— in an airport lounge of all places.
I was sipping a cold coffee, waiting for my flight, when I overheard a Sales Head from a tier-1 consulting firm seated next to me. He wasn’t speaking — he was shouting into his phone.
And this is what he said:
“Forget ESB and middleware…
we should be selling Model Context Protocol–based AI solutions.
This is the future. Push MCP hard.”
He said it with the conviction of someone giving orders to conquer a territory.
At first, I laughed internally. You can’t just shout away 20 years of enterprise integration patterns.
But the line stuck in my head.
And the more I thought about it, the more I realized: he’s wrong in conclusion, but right in direction.
This blog is the result of that airport moment — and everything it triggered in my mind.
Why ESB Exists (And Will Not Disappear Overnight)
Whenever a company has multiple systems — SAP, CRM, MES, WMS, HRMS, PLM — connecting them directly becomes a tangled mess:
- routing breaks
- security becomes inconsistent
- governance disappears
- version upgrades explode the landscape
- auditability becomes impossible
That’s why ESBs were born. They solved:
- routing
- authentication
- transformations
- central policies
- logging
- message governance
- system-to-system orchestration
For two decades, ESB has been the plumbing backbone of enterprise IT.
So when someone yells:
“Don’t sell ESB, sell MCP!”
…you naturally question their sanity.
But then — the deeper insight emerges.
ESB Solves Machine Complexity. AI Solves Human Complexity.
This was the mental shift.
ESB is built to help systems talk to each other.
But modern enterprise complexity comes from people dealing with too many systems.
Real business questions are not system calls — they sound like this:
“Can we prepone delivery for customer ABC based on this week’s production and logistics capacity?”
And to answer that, a human must check:
- SAP (order status)
- MES (production schedule)
- APS (capacity plan)
- WMS (warehouse availability)
- CRM (customer priority)
- TMS (transport slots)
This is not an ESB problem. This is a human workflow + decision problem.
And ESB was never designed for that.
Enter the AI-First Orchestration Layer
This is what the sales head was trying to articulate — not very elegantly, but directionally correct.
We are entering an era where a new layer is forming above the ESB:
The AI-First Orchestration Layer
This layer does things that middleware could never do:
- Understands user intent (not just API calls)
- Plans multi-step workflows dynamically (no static BPMN diagrams required)
- Uses MCP to call enterprise tools (SAP, MES, WMS, TMS, CRM — securely, live)
- Interprets and reasons over the data (not just route messages)
- Produces decisions, not raw data
For example: “Preponement possible on Thursday because capacity is free.” - Takes action with guardrails
For example: “Created a reschedule request; waiting for logistics approval.”
This layer becomes the brain of enterprise integration.
ESB remains the backbone.
But AI becomes the orchestration layer for humans and decisions.
But Aren’t Data Scientists Already Doing This With ML Models?
A lot of people assume:
“But we have ML models on our data lake… shouldn’t that answer these questions?”
No. Not even close.
Here’s the brutally honest truth:
Data Lake AI ≠ Operational Orchestration
Data science gives:
- predictions
- trends
- forecasts
- charts
- insights
It does NOT give:
- live SAP data
- real-time MES capacity
- logistics slot availability
- customer priority rules
- business exception handling
- system-to-system actions
Because data lake AI is offline, historical, and analytical.
Operational decisions are real-time, cross-system, rule-heavy, and action-driven.
And that’s the domain of the AI-first orchestration layer.
A Real Example That Shows the Gap
To answer:
“Can we prepone delivery for ABC?”
The AI-first orchestration layer must:
- Fetch live SAP order info
- Get MES production schedule
- Check APS capacity
- Check warehouse readiness
- Check transport availability
- Validate business rules
- Interpret all results
- Provide a unified answer
- Trigger a reschedule request
A data lake ML model can do zero of these steps.
This is why the new AI layer matters.
In One Sentence
Data Lake AI tells you what happened.
AI-first orchestration tells you what to do — and does it for you.
That’s the difference.
That’s why ESB isn’t “dead.” But the workload ESB handles will absolutely change.
That’s why MCP is becoming central to enterprise AI discussions.
And that’s why that loud airport conversation stuck with me.
So, Is MCP Replacing ESB?
After thinking deeply, here’s the honest truth:
❌ MCP will NOT replace ESB for transactional, regulated, high-SLA system workflows.
But…
✔ MCP + AI-first orchestration WILL replace a massive portion of the lightweight, user-facing, cross-system workflows ESB currently handles.
Because:
- AI understands intent
- Tools abstract systems
- MCP connects capabilities
- Decisions become dynamic
- Actions become automated
In other words:
ESB integrates machines.
AI-first orchestration integrates minds and workflows.
Both will coexist.
But only one will define the next decade of enterprise interaction.
Final Thought
As I walked to my boarding gate that day, one line kept echoing in my head:
“The new ESB is not a bus. It’s a brain.”
And that’s exactly the shift we’re living through right now.
Comments
Post a Comment