Integration, AI, and the Tollbooth We Keep Rebuilding

For a long time I did XI and PI. Before that I worked with DCOM, RMI and CORBA. That was the distributed computing era before anyone called it middleware. During that time I did a few engagements for both TIBCO and webMethods. I worked on non SAP systems and spent a lot of time talking to people from other teams. BizTalk, Oracle Fusion, webMethods, Mule. Whoever was on the other side. So should you. They saw SAP as an island. Crossing over it meant a toll.

I would map and route. They would pick up, map and route. Sometimes it was nothing more than a bureaucratic firewall. Other times it was translation work, taking the one size fits all SAP message and making it acceptable for a non SAP system.

Then something shifted. They no longer needed an ESB on their side. They did not want to talk competing standards anymore. The REST adapter gave them a way out and they took it. Suddenly they did not need me to translate. They needed me to expose. JCo came and I became the RFC translator, the IDoc guru, the person who could hand them what was behind the wall in a language they could use. I was not maintaining the gate anymore. I was the person who knew where the gaps in the fence were. The curator had become the janitor.

As they moved away from ESB patterns and back to solving things directly in code, using .NET and Spring, I could see the gap widening. They were building. I was enabling. The interesting work had moved to their side and I was handing them the tools to do it. It ate at me because I knew the industry had shifted and I had not shifted with it yet.

Where other teams made the shift, the tollbooth became singular. Where they did not, the landscape got more complicated, not less.

The work had stopped being about the business problem. Somewhere along the way I had become institutionalised. I had gone from building the cool stuff to being the janitor. More focused on mastering the tool than on what it was meant to enable.

The ESB Era

PI/PO was a centralised, on-premise ESB, a proprietary stack that sat at the centre of the integration landscape and over time became a destination in its own right. Everything passed through it. That centrality was both its value and its trap.

The complexity of the tooling coupled with proprietary technical constraints meant the skill couldn’t realistically sit within a cross-functional team. The cognitive load of operating it was too great to hold alongside a domain problem, which made a dedicated specialist function a practical necessity. Delivery teams had to hand off, wait, and depend on that function. The tool created the bottleneck.

But the bottleneck was not just time. It was capability. The specialist function was not only a practical necessity born of tool complexity. It was a structural choice that kept the knowledge concentrated at the boundary. Delivery teams could not experiment, iterate or innovate at the integration layer because they did not own it and could not see inside it. The toll was not just latency. It was everything that could have been built faster or differently but wasn’t because it had to wait at the gate.

This was the broader pattern of the ESB era. The ESB emerged as a reasonable response to a real problem, integration sprawl. Enterprises were managing systems that spoke different languages, built on different standards, owned by different vendors. SOA promised a canonical data model, one common language across the enterprise. But every vendor had their own version of it. My version rarely talked cleanly to your version. Instead of solving sprawl, enterprises often ended up managing three or more ESBs from competing vendors, each with its own team, its own patterns, its own standards, and its own gravitational pull.

Mediation made complete sense in that world. When systems genuinely spoke different languages, you needed an interpreter. The ESB was that interpreter. The trade-off was centralisation, specialisation, and a new kind of dependency. You solved sprawl by creating a bottleneck.

Why the Landscape Has Changed

The move to the cloud and concepts like Clean Core change the underlying assumption. It is not just about staying close to standard. It is about decoupling.

Instead of accepting that systems will always speak different languages and layering mediation on top, Clean Core moves toward a shared foundation built on open standards. Because these standards are open, any team, tool or vendor can, in principle, consume them without a translator in the middle.

The canonical data model has been reborn as the One Data Model, visible in the SAP Business Accelerator Hub through thousands of OpenAPI and AsyncAPI definitions, living, executable contracts that we never had before. SAP built the APIs. SAP published the standards. The promise was genuine and the technical foundation is real.

But a platform cannot pay down an organisation’s standards debt for them. Business cases, legacy contracts, risk appetite, competing priorities. The gap between what is technically possible and what is organisationally executable is where most enterprises still live. The world moved on. Most customers did not. The majority of interfaces running today are still SOAP, IDoc and RFC. The standards debt did not migrate. It just got a new runtime.

Brownfield is not a transition state you pass through on the way to something cleaner. For many enterprises it is the landscape they operate in - IDocs, RFCs, flat files, custom Z logic, vendor adapters that predate the cloud by decades. Some of that legacy will never conform to an API contract. Greenfield and bluefield were the dream. For most it stayed that way.

Where APIs do govern the exchange between systems, the contract becomes the binding agreement between producer and consumer. The API defines what is offered and what is expected. When that contract holds, much of what middleware once existed to do, mapping, transforming, translating, is no longer needed in the same way.

Legacy mediation is about translation and compensation for standards debt. Modern mediation is about coordination, trust, flow control and composability. And some mediation is simply structural. B2B integration runs on EDI, AS2, OFTP and partner-specific formats that will never align to an internal API contract. Async and event-driven patterns need transformation at the boundary between producer and consumer regardless of how clean the underlying systems are. The ESB tried to do all of it from one centralised place. The alternative is not no mediation. It is mediation that is purposeful, applied where it is genuinely needed, and not a bottleneck by design.

Centralisation done well is an accelerator. The trap is when the centre becomes a vertically owned silo, optimised for a single platform rather than for the enterprise it serves.

Where CI Fits

CI is where some of that purposeful mediation lives.

CI is built on Apache Camel, which delights a lot of traditional cloud architects. In practice it surfaces as a low-code tool, but Groovy gives you access to the DSL when you need to get closer to the metal. It pushes hard against the ESB label by design. It is a library, a framework for movement, not a centralised authority. Within the Integration Suite, CI is a tool, not a stack. It is one capability among many, not a destination that everything must pass through.

What it is meant to be is purposeful mediation at specific boundaries, event driven coordination, lightweight flows that sit within a delivery team without consuming it, a tool not a stack.

In practice the lift and shift brought the workload with it. PI interfaces became iFlows. SOAP, IDoc, BAPI, RFC to REST. Not because nobody knew better. Because these flows are business critical. They pay the rent.

Legacy is not debt waiting to be cleared. It is the core of the operation. The workload did not just migrate. It brought its complexity with it.

The transformation work that given time and business case could have moved to a whitelisted API from the Accelerator Hub stayed where it was. The risk of touching it outweighed the benefit of changing it. The tool moved forward. The workload did not

The Blind Spot

Enterprises moved to the cloud for speed. Speed without control is sprawl. Sprawl at cloud scale is harder to untangle than on-premise sprawl.

The ESB was a response to on-premise sprawl. It was slow and centralised, but at least it was legible. You could see the bottleneck. Cloud sprawl is distributed and self-replicating. Every team moves fast in its own direction, and integration debt accumulates silently until something needs to talk to something else and nobody knows how.

The same instinct that built the ESB is already reaching for APIM as a replacement. And to be clear, APIM done right makes complete sense. I have worked on Kong, Apigee and Azure APIM initiatives that introduced me to zero trust architecture, controlled external exposure and proper partner management. These are the right use cases. You want to be deliberate about what you expose to the world and APIM at that boundary earns its place. In regulated industries and government environments that boundary control is non-negotiable. The question is not whether to govern but where the governance actually sits and whether the tool positioned there can do the job.

BTP APIM is not at that boundary. It sits inside the platform, not in front of it. When it appears in every internal flow on the architecture diagram it becomes a proxy. The whitelisting effort, the policy management, the latency on every internal call at the scale of S/4HANA services. You have not removed the bottleneck. You have given it a new interface. The diagram looks like governance. The developer under time pressure sees a queue.

The Next Wave

AI doesn’t just call APIs. It orchestrates long-running intent.

And it authenticates with identity, not topology. An agent holding a user token goes straight to the OData or REST endpoint. It does not need to pass through the integration layer to get there. If governance lives in the middleware and the agent never touches the middleware, that governance is not governance. It is a suggestion. The answer is not no governance. It is governance at the identity, application, and data layer where AI actually operates, not in the middleware layer it never touches.

The right tool still assumes the right foundation. Identity federation, consistent RBAC across silos, data governance that travels with the request. Most enterprises are still building that. The agents arrive before the foundation is ready.

Greenfield and bluefield would have given the chance to build a surface area that was ready for this. Whitelisted APIs, fit for purpose, designed for machine consumption, bounded and tested. AI would have arrived at something deliberate.

Instead it arrives at the brownfield reality. It sees the curated list and everything behind it. The Fiori layer. The services built for screen consumption that were never designed for what AI will do with them. AI does not read the approved list. It sees available. The governance model assumed a curated surface area. AI found the whole kitchen.

The temptation is to put APIM in the flow and call it governed. But you cannot proxy a herd of cats. The surface area is too large, the consumption patterns too unpredictable, and AI will find what it needs regardless of what is on the approved list.

AI expects systems to talk, context to flow and data to be available. It arrives with protocols like MCP and assumes openness. Enterprise controls still exist, but teams will bypass them to meet AI use cases, creating connectors, point-to-point integrations and bespoke pipelines. Integration no longer enforces order. It becomes a network of raw data flows, expanding faster than governance can keep up.

The enterprise is managing a problem that AI treats as already solved. That gap is where the next wave of sprawl will appear. Five years from now, someone will look at the landscape and wonder how it became so complicated.

The Integration Suite is a capable set of tools. CI, Event Mesh, and APIM each serve distinct roles within that landscape. But none of them were designed for AI workloads. AI agents need to manage state across long-running, unpredictable workflows. They need to decide when to spend tokens, how much context to carry and when to stop. When those workflows fail partway through, they rely on compensation logic to unwind what has already happened, or a durable execution engine to store the process in a replayable state. That is a different kind of problem from the one these tools were built to solve.

If a lift and shift places the Integration Suite at the centre of everything, and that suite is not the right foundation for what AI actually needs, you have not just rebuilt the tollbooth. You have built it in the wrong place for the traffic that is coming. The answer is not a better centralised layer. It is a different kind of foundation.

Open standards reduce lock-in, and that is good for customers and uncomfortable for vendors. The incentive to build a proprietary layer in the middle does not disappear because the technology changed. The customer wants sovereign control, the ability to move between vendors, audit what is happening and not be held hostage by a platform decision made five years ago. The architecture should reflect that, not obscure it behind a proprietary layer that recreates the dependency it claimed to solve.

Integration is not a tooling problem. It is an organisational coordination problem. The tools just made it visible.

Looking Back

Now I’m the one who moved on. I work on CAP, distributed cloud integration, EDA, open patterns. After years of Fiori work it felt good to be combining that with integration where the domain problem lives. I’m no longer a T shaped specialist. I’m shaped by the system, not the tool. And everything I have done is coming together. All those years of talking to people, listening, learning their worlds, crossing boundaries, absorbing their pain points, it did pay off. Eventually.

I spent years defending the silo before I understood what I was defending against. And I find myself looking back at the era the way they once looked back at me.

Not in anger. But with enough distance to see the shape of it clearly. The ESB solved a real problem. PI/PO was a response to genuine chaos. It was a coping mechanism born of complexity. The ESB was not the problem. The problem was what it became, a proprietary, monolithic gatekeeper with its own lock-in and gravitational pull.

The same flows are running with a different tool. The pattern is still in production. I was the middleware expert. Someone else will be the AI integration expert next. A new specialism will form around a new tool and the same structural dependency will follow.

It’s the same loop every time. Complexity creates centralisation. Centralisation creates specialists. Specialists become dependencies. Dependencies slow delivery. Teams route around the bottleneck. Sprawl returns, and we build another tollbooth.

But the conditions have changed. And if we don’t carry forward what we learned from that era, not just archive it, we will build it again. It won’t be called an ESB. It will be called an AI integration layer, or an intelligent middleware platform, or something that sounds like progress. And it will carry the same weight, create the same dependencies, and produce the same bottlenecks.

The question I keep coming back to is simple. Are we building a foundation, or are we building another tollbooth?

We built walls to manage chaos. The walls became the problem.

AI doesn’t care about the walls and will route around them.

About the Author

John Patterson is a Principal Software Engineer at Second Phase Solutions. For 25 years he has installed it, architected it, supported it, and spent a significant part of his career decoupling and simplifying what it became. He has been inside the pattern long enough to recognise when it is forming again.

This isn’t a tooling problem. It’s a pattern problem. And patterns repeat until someone names them.

If you’re building the foundation, not the gate, let’s talk.