Program architecture — Designing the landscape, the integrations, and the extensions

Fourth in the white paper Inside a Large ERP Program*. The opening chapter set out the triple lens the book reads each phase through, technical, business, organizational. The chapters after it covered what gets decided before anyone talks about software, and how vendors, integrators and contracts get chosen. This one goes into the machine room: the landscape, the integration layer, and the extensions. It is the most technical chapter of the book, and the one where the worst decisions hide the longest.*

Architecture is the only part of an ERP program whose mistakes are invisible at the moment you make them. A bad scope decision shows up in the next steering committee, a bad integrator in the first delivery. A bad architecture decision shows up two years later — in a performance incident at month-end, or in an upgrade that runs three times longer than the vendor promised, long after everyone has forgotten who decided what, and why.

This chapter walks through the three places where that happens: the landscape, the integration layer, and the extensions. Three different technical subjects, one identical failure mechanism.

The landscape: complexity is not a virtue

I have worked on landscapes in every shape you can imagine, and the pattern is consistent: the more environments and the more transport tracks you add, the more conflict you create. Complexity in a landscape does not buy you safety. It buys you surface area for things to collide.

The textbook setup is a three-tier line — development, quality, production — with a sandbox in front. The version I have seen cause the most pain is the doubled landscape: a full project line and a separate maintenance line, the maintenance track rejoining the main track in quality. On paper it looks responsible. You keep your run-the-business fixes away from your change-the-business project. In practice, every retrofit becomes a negotiation, every release becomes a sequencing problem, and the moment you layer in a migration or a version upgrade, you are managing collisions between objects that two different teams touched for two different reasons.

Then there is the dedicated integration environment — the one inserted between development and the UAT environment specifically to test interfaces. It sounds rigorous. It rarely works as intended. You cannot meaningfully test an interface without end-to-end data flowing through it, and that data lives in UAT, not in the integration box. So one of two things happens. Either you test the interfaces twice — once in integration with synthetic data that proves nothing, then again in UAT with real data — or the consultants quietly test in UAT and never mention to their manager that the integration environment went unused. I have seen both. Neither is the clean story that was sold when the environment was provisioned.

The setup I would defend is leaner: sandbox, development, UAT, quality, production. Drop the dedicated integration line. Separate project work from maintenance not with a parallel track but with project codes inside the transport requests, so you can filter, sequence and retrofit by code rather than by maintaining a second physical line. You lose nothing real and you remove an entire category of collision.

That is an opinion, and I will own it as one. There are landscapes complex enough — multiple concurrent projects, heavy regulatory separation — where more tracks genuinely earn their cost. But the default should be the lean line, and the burden of proof should sit with whoever wants to add the next environment, not with whoever wants to keep things simple.

The integration layer: the interfaces we built three times

On one program, for a large consulting firm, we built the interfaces three times.

First as point-to-point. Then we moved to SAP BTP. Then the group decided on Google Cloud Platform. Three architectures, three rounds of rebuilding, on the same set of flows. The delay was real, the team was overloaded, and by the end nobody could say cleanly why the second choice had been wrong, only that a third one had now replaced it.

Here is the thing worth sitting with: none of those three choices was stupid on its own. Point-to-point is what you fall into when there is no platform decision at all. BTP is a coherent choice — it is SAP's own integration platform, it sits natively against S/4, and if the group is already on RISE there are credits that may already cover it. GCP is also a coherent choice, made for a different reason: it is more open, less tied to the SAP stack, and for a group with a large estate of non-SAP applications that openness is more attractive over the long run. That is my read, and a BTP advocate would push back — native integration and a single SAP-governed monitoring view are real arguments on the other side. Reasonable people land differently.

The point is not which platform wins. The point is that the criterion that decides between them — native integration versus openness — is knowable at design time. It could have been argued once, written down once, and settled once. Instead it was settled three times, each time by conviction in a meeting, each time at the cost of a full rebuild. The waste lived in the missing decision, not in any one of the choices.

On the substance, the direction of travel is not really in dispute anymore, and you do not have to take my word for it. SAP has set end of mainstream maintenance for on-premise Process Integration and Process Orchestration — the classic middleware backbone — at the end of 2027, with extended maintenance available until 2030, aligned with the NetWeaver 7.5 timeline. Whatever you think of the replacement options, the old on-premise middleware has a published expiry date. Point-to-point as a default, and aging on-premise middleware as a home for it, is a position with a clock on it.

What a platform buys you, when you do pick one, is worth stating plainly because it is the actual engineering argument under the marketing. You mutualize transformation logic instead of re-implementing the same mapping rule in five different interfaces. And you push computation into a back-end platform built for it, rather than loading it onto user-facing systems that were never meant to carry that weight. That is the mechanism. It is also why the trend is real and not just vendor noise — though when an integrator tells you their platform "replaces legacy middleware," remember they sell the migration, and read the claim accordingly.

Extensions and clean core: a strategy against deep habits

"Clean core" is one of the most repeated phrases in SAP conversations and one of the least precisely understood. Ask five people on a program what it means and you get five answers — an architecture principle, an upgrade strategy, shorthand for "less custom code," or a nod from someone not quite sure what they just agreed to.

The official definition is more reasonable than the slogan. SAP describes a clean core as keeping the ERP core as close as possible to the standard, vendor-delivered state, and handling customization through decoupled, upgrade-safe extensions — on BTP, side by side, rather than as modifications inside the core. Notably, SAP itself is explicit that a clean core does not mean zero custom code; it means custom code that is decoupled from the core so upgrades stay stable. As a design philosophy, that is defensible. I am not going to argue against the principle.

What I will argue against is the idea that the principle survives contact with a real program. Clean core is a marketing argument that does not hold up against the program committee, the finance department, and twenty years of deep habit. It can work for a client that has never run SAP — a greenfield estate with no legacy processes to defend. But for a company that has run SAP for two decades, where the business has built its identity around the way the system behaves, you can push to stay close to the core all you like; you will rarely convince the business directors to change how they work. The gravitational pull of "this is how we have always done it" beats an architecture slogan every time it comes to a vote.

For an example closer to the system — because this runs from the governance vote down to the code itself — most of what I see is still classic RICEFW, ABAP development much as it was built before. In-app extension exists, but it shows up less often than you would expect, because the standard leaves comparatively little room to maneuver. The clean-core future is real on the slides. On the floor, the ABAP is still being written.

The code nobody wants to take over

There is a specific failure I see because I read the code, and most reviews do not.

When a new team takes over an existing program, the developers almost never make the effort to move to current best practices — CDS-based modeling, modern extension patterns, the things that would actually pay off. The center of excellence gets inherited more or less identically. Sometimes that is a deliberate speed call: rewriting working code to a newer pattern is effort with no visible feature at the end of it. More often it is something quieter and worse — the new team has lost the historical knowledge of what the code actually does, so they dare not touch it. They build around it and leave it alone.

That is technical debt that was inherited, not created, and it is the most dangerous kind, because no one currently on the program feels responsible for it. On a system handling modest volumes you can live with it for years. On a program moving serious data, you cannot. The old patterns that were fine at pilot scale turn into performance problems at production scale, and the incident arrives at exactly the wrong moment — period-end, year-end, the close that cannot slip. By then the people who could have explained the code are gone, and you are debugging archaeology under time pressure.

This is the quiet cost of treating an inherited codebase as a black box. The debt does not announce itself. It waits for volume.

The decision that was never made

Step back from the three subjects and the same shape appears in all of them.

The landscape got an extra track because it felt prudent in the moment. The integration platform got chosen three times because the criterion was never written down. The extensions stayed in classic ABAP because clean core lost the vote it was never really allowed to win. The inherited code stayed untouched because no one owned the history. In every case the architecture decision was made fast, by conviction, in an arbitration meeting, without a decision matrix and without a trace. The result is application spaghetti — reworked partially when there is time, not reworked at all when there is not, and carried forward as debt either way.

The temptation is to call this a technical failure. It is not. The engineering choices, taken individually, were mostly defensible. What failed was governance: the discipline to name the criterion before the meeting, write the trade-off down, and make the decision once so it does not get made three more times at three times the cost. Architecture debt is a decision that was never made, compounding quietly until someone has to pay for it.

The same trap is waiting in the next phase, where the arbitrations are functional rather than technical but the mechanism is identical. That is where the next chapter goes: Design — Trading off fit-to-standard against custom requirements.