Intro
Mid-market and enterprise SAP landscapes in 2026 are rarely “ERP plus a website”. They are ERP plus eCommerce, marketplaces, EDI with logistics partners, POS, data warehouses, payroll, banking, warehouse systems, and a growing set of SaaS tools. Each usually arrives with its own integration history.
Failures rarely appear first as “middleware problems”. They show up as revenue leakage, stock errors, delayed orders, manual reconciliations, audit findings, and support teams who know which fragile interface must be watched every morning.
Executives do not need more pipes. They need fewer approved patterns, clearer ownership, and standards that projects must use rather than reinvent.
Executive summary
Integration strategy is not a tooling debate. It is governance over how business-critical data moves.
Leadership should expect a single catalogue of interfaces and events, named owners by business domain, clear rules for when to use APIs, files, events, or enterprise messaging, and a funded path to retire duplicates.
Without this, every transformation programme recreates complexity at the edges while the ERP core appears to go live “on plan”. The result is a landscape that looks modern in steering packs but still depends on fragile handoffs, manual fixes, and unclear accountability.
Catalogue what you actually run
The first step is an honest inventory of what moves through the landscape today: orders, stock, customers, products, prices, invoices, payments, suppliers, and financial postings.
For each integration, leadership should know four things:
1. What business process does it support?
2. Who owns the data being moved?
3. How often does it fail?
4. Who is accountable when it does?
This exercise often reveals parallel routes for the same data because previous programmes delivered locally, under pressure, without a shared integration model.
The catalogue does not need to be perfect on day one. It needs executive sponsorship so new projects register integrations before build, not after go-live.
Set standards projects cannot skip
A practical integration strategy should define a small number of approved patterns. For example: SAP as the system of record for product and price, event notifications for stock changes, REST APIs for synchronous customer-facing checks, managed file exchange where legacy constraints remain, and enterprise messaging for high-volume asynchronous processes.
The exact patterns matter less than the discipline of using them consistently.
Exceptions should be allowed, but not casually. Every exception should have a named owner, a reason, an expiry point, and a retirement plan. Otherwise, “temporary” integrations become permanent architecture debt.
This is especially important for mid-market organisations. They may not need a large integration factory, but they do need enforceable rules. Clear standards help teams move faster because projects stop debating the same design choices from scratch.
Funding retirement, not only build
Every new interface should trigger a leadership question: what does this replace?
If the answer is “nothing”, the next question should be: what is the carrying cost?
Boards often fund new capabilities but rarely fund the removal of old ones. Over time, this creates integration drag: duplicate feeds, unclear ownership, brittle cutovers, expensive hypercare, and support teams managing complexity the business thought had been modernised.
A credible integration roadmap should therefore include retirement work, not just new delivery. Simplification must be funded as part of transformation, not left as a future clean-up exercise that never receives priority.
Practical leadership takeaway
The right question is not “Which integration tool should we use?” The better question is “Do we know how critical business data moves, who owns it, and which patterns every programme must follow?”
Before approving major SAP, commerce, data, or SaaS transformation work, leadership teams should ask:
1. Do we have a single catalogue of critical integrations and events?
2. Who owns integration decisions by business domain?
3. Which integration patterns are approved, and who can approve exceptions?
4. What duplicate or legacy interfaces will this programme retire?
5. What evidence will show the post-transformation landscape is simpler than the one we started with?
Good integration strategy does not stop delivery. It prevents each project from adding another private shortcut to the enterprise landscape. The goal is not more middleware. The goal is fewer routes, clearer ownership, and a business that can change without breaking its own nervous system.