Skip to content

Viewpoint · 7 min read

Clean core: what really needs to be governed.

Keep the core of the system at the standard and house extensions outside it: put that way, clean core sounds like a quarrel between architects. It is in fact an economic decision, one that commits the company’s costs, speed and freedom for the decade ahead. In the sub-region, where every State adds its tax rules and its SYSCOHADA statements, the temptation to open up the core is stronger than elsewhere. All the more reason to decide who holds the rule.

A viewpoint from our SAP and architecture teams in Dakar · a clear stance, lessons from the field and recommendations

The principle fits in one sentence. In a clean system, the core stays compliant with the vendor’s standard; everything the company adds lives alongside it, on an extension platform designed for that purpose, behind documented interfaces. SAP has made it the official doctrine of SAP S/4HANA and RISE with SAP, and it would be wrong to see it as a mere sales argument: the promise of regular updates only holds if nobody has welded the core from the inside. But the real reason to care is not with the vendor. It is in your accounts.

Every custom development is a debt

A custom development is always born of a good intention. A process that gets stuck, a regulatory statement the standard does not produce as is, a business request that needs a quick answer: a few days of development and the matter is settled. At the moment it is coded, a custom development looks almost free. It is afterwards that it starts to cost.

It costs at every upgrade: everything that touches the core has to be analysed, adapted, retested, and the bill repeats for as long as the code lives. In a RISE with SAP world, where the vendor pushes updates at its own pace, that burden stops being an event every five years and becomes a recurring toll. It costs in innovation: the capabilities SAP delivers, embedded AI first among them, rely on standard processes and data structures; a core riddled with exceptions watches them go by. It costs, finally, in dependency: over the years, the knowledge of a custom development concentrates in two or three heads, and the day they leave, the company discovers it can no longer explain its own system. In a market where SAP skills are scarce, this last cost is the heaviest.

None of these costs appeared in the estimate for the initial development. That is the whole difficulty: the expense is visible and modest, the debt is invisible and long. An executive team that ignores it will pay it anyway.

The special case of localisation

In the OHADA area, part of the custom development is not a business whim. The financial statements of the revised SYSCOHADA, VAT and the returns specific to each UEMOA State, national payslips and social contributions: all of this must come out of the system, and the vendor’s standard does not always cover every detail of every country. These developments are legitimate. The question is not whether to forbid them, but to decide where they live.

Our position is clear: localisation is built as an extension, on SAP BTP, with documented interfaces, not through modifications in the core. A SYSCOHADA statement developed outside survives upgrades and is maintained by a local team. The same statement coded into the core of the system will have to be revalidated at every update, by the few people who still understand it. The cost difference over ten years is considerable, and it is decided on day one.

The test: a proven differentiator, otherwise the standard

Should every custom development outside localisation therefore be banned? No, and the all-standard advocates are as mistaken as the others. Some processes win customers, margins or days of cash precisely because they do not look like the neighbour’s. Those deserve to be defended, developed cleanly outside the core, and maintained as assets.

Everything is in the criterion. Ours is simple to state and uncomfortable to apply: a custom development is justified if it is imposed by regulation, or if the process it carries is a demonstrable business differentiator. Demonstrable, not felt: who can say what the company would lose, concretely, by moving to the standard? If nobody can answer, the answer is the standard, and it is the process that adapts. Our experience of custom development inventories is constant on this point: the vast majority fail the test. They reproduce a habit, rarely an advantage.

The right question is not “what does this custom development do?” but “what would the company be worth without it?”. If the answer is “the same”, it has no business in the core.

What the discipline demands of governance

A criterion is not enough; someone has to hold it. This is where the subject leaves the technical sphere, because holding a criterion means saying no. No to a business director in a hurry, no to a project that has already promised, no to the easy solution that would reopen the core. An architecture authority that cannot lean on executive leadership will give way. Politely, and systematically.

Governance that works rests on three practices. A decision forum where the business comes to plead its request, with the differentiator test as the rule of the game posted in advance. A register of exemptions, next: every accepted custom development is recorded there with its owner, its justification, its location (core or extension) and its review date, because a debt is badly managed when nobody keeps its books. A review at every upgrade, finally: a custom development must earn its place back at every milestone, or it goes. Without that appointment, drift returns within a few years, through the accumulation of small exceptions, each reasonable on its own.

2027, the purge that will not come round again

Then there is the calendar. The end of ECC standard maintenance, set for the end of 2027 with a possible extension to the end of 2030, requires every company to move to SAP S/4HANA. And a conversion is the only moment when purging costs less than keeping: every development has to be inventoried, analysed and retested anyway. Sorting on that occasion is a marginal effort; taking everything along means converting your debt along with your system, and repaying it for ten more years.

That is why we argue for the custom development doctrine to be set at scoping, before the choice of scenario and integrator, rather than discovered mid-program when every arbitration delays a milestone. The company that comes to the negotiation with its rule of the game, its register and its purge list chooses its program. The other one endures it.

To go further: our reading of the 2027 deadline for companies in the sub-region, our SAP · S/4HANA & ERP offering and our custom applications, where extensions are designed and built.

The custom development test

How many of your custom developments would pass the test?

Thirty minutes with an AGILICIS expert to talk about your portfolio of custom developments, SYSCOHADA localisation, the criterion that should judge them and the governance that goes with it.

Let's talk