Synopsis
Every interface in an SAP landscape carries a cost that rarely appears on project plans.
Over time, integrations accumulate across platforms, technologies, and teams. SAP CPI, PI or PO, third-party middleware, custom scripts, file transfers, supplier gateways, and point solutions added to solve local problems often remain long after the original need has faded. Each one introduces a recurring maintenance burden in the form of support, monitoring, upgrades, and reconciliation.
This article frames integration as an ongoing economic commitment rather than a one-time investment. The costs are predictable, compounding, and largely invisible until discrepancies surface in finance, planning, or operations. By then, organisations respond with more tooling and more replication, adding another layer without reducing complexity underneath.
Replication platforms and reporting layers can look modern and reassuring. They rarely simplify the landscape. They duplicate data, introduce new failure points, and expand the surface area that must be supported and defended.
The piece argues for a different starting point. Understanding why each interface exists, what decision it supports, and what would actually fail without it often reveals opportunities to reduce cost and risk without launching another programme.
For organisations carrying the hidden weight of integration sprawl, this perspective is worth examining closely.
Main Article
Every interface in an SAP landscape quietly adds a maintenance tax. Typically between 7% and 10% per year on support and business continuity costs. This is not innovation spend. This is rent.
Even medium sized organisations today run at least five interfaces. Large enterprises routinely cross fifteen. Over time, landscapes accumulate a familiar mix of integration technologies. SAP CPI. SAP PI or PO. MuleSoft. Informatica. TIBCO. Talend for a new planning system in one geography. Custom Python scripts doing “just a little logic”. FTP jobs running out of AL11 to stay invisible to digital access audits. IBM Sterling for supplier connectivity. Each added for a reason. None removed when the reason expired.
Then come the maverick designs that grow organically. Material master in S4. Bill of material in a third party PLM. Routings in a separate MES. Customer data living inside a CRM or contact centre platform. That is already four systems of record for closely related data, and four more interfaces to reconcile.
Eventually, someone asks the obvious question.
What is the original system of record for this data?
By then, the answer no longer matters. Timing mismatches creep in. Partial replications go unnoticed. Manual corrections become routine. Interface error messages mislead more than they explain. Weeks later, a financial or planning discrepancy surfaces. Another project is launched to “look into the whole thing”. Another large consulting firm is engaged. Targets are met. The landscape stays the same.
At this point, a new idea appears.
“We will replicate everything to BTP and build reports.”
It sounds modern. It sounds clean. It is neither.
Replication does not remove complexity. It duplicates it.
What happens when a CDS view changes or is deprecated?
What happens when an API version is retired?
What happens to analytical apps built on Azure when the underlying data model shifts?
What happens during certificate renewals, tenant upgrades, or silent IDoc failures that nobody notices for weeks?
You now pay to move data, store data, reconcile data, explain data, and defend data when numbers do not match. The original systems remain. The interfaces remain. You have simply added a new layer that must also be supported.
In many organisations, six people quietly support “just the interfaces”.
At USD 40 per hour, that becomes thousands of man days over a few years.
Pure rent. No asset created. No capability improved.
In vernacular terms, this is called
“चार आने की मुर्गी, बारह आने का मसाला”.
The problem is not integration itself. Integration is necessary. The problem is unexamined integration sprawl and the belief that adding another platform somehow makes it disappear.
At Lydian, we focus on understanding why each interface exists, what business decision it supports, and what would actually break if it did not. Often, the fastest way to reduce cost and risk is not a new project, but removing assumptions that have gone unchallenged for years. Sometimes the starting point is as simple as analysing what your support engineers are already firefighting every day.
If you want to reduce the economic drag of integration sprawl instead of paying rent on it indefinitely, start the conversation at lydian.nishantfadnavis.com/.
No platforms to sell. No tools to push. Just clarity on what should exist, what should not, and what is quietly costing you every month.