Clean Core

An enterprise runs a packaged ERP with 1,400 customer-written objects, 300 of which modify the vendor's own code. Each modification was reasonable: the behaviour was needed, the vendor's extension point did not exist, and a developer with source access wrote the twelve lines that worked.

The bill arrives at the next major upgrade. Every modified object has to be re-applied against a changed baseline by hand, and each needs a regression test somebody writes. An upgrade the product documentation describes in weeks becomes an 18-month programme, and the organisation starts skipping versions - which makes the next upgrade larger. Clean core is the discipline that prevents this: build extensions only on interfaces the vendor has published and committed to, and run anything that does not fit outside the product.

Why it matters

Packaged software is bought for a 10 to 20 year horizon, so an organisation will take somewhere between five and fifteen upgrades on it. A modification costing two days to write and about 5 days to re-apply and retest per upgrade is not a week's decision; it is 25 to 75 days spread over a decade, plus the risk that one re-application introduces a defect into a core financial process.

The second reason is optionality. A clean estate can take the vendor's hosted or cloud offering; a heavily modified one cannot, because the modifications have nowhere to live. They do not only cost upgrade effort - they remove deployment choices the business may later need.

Implementation patterns

• Use only released extension interfaces. SAP's guidance describes extensions built on released APIs and declared extension points, with side-by-side extensions on a separate platform connecting through supported APIs and events. The rule generalises: if the interface is not documented as stable, it is not an interface.
• Classify every extension by upgrade exposure - released interface, internal object with the deviation logged, or direct modification - and report the counts. One number, modifications outstanding, is the estate's upgrade cost in disguise.
• Put the rule at the gate, not in the guidance. A build-time check costs a pipeline failure; a standards document costs an upgrade programme.
• Treat a missing API as a vendor request, not a licence to modify. Wrap the gap behind your own interface so one adapter changes when the vendor ships it, instead of forty call sites.
• Record a governed exception where modification is genuinely required, with an owner and a review date, so the upgrade team inherits a list rather than a surprise.

Industry example

SAP has published clean core as a named strategy: extensions use released APIs and extension points inside the product, and side-by-side extensions run on its business technology platform for anything that does not fit, with the stated goal that the standard core stays unchanged so upgrades remain routine. SAP's own material is explicit that this does not mean moving every customisation outside the product - it means choosing the supported extensibility model that fits the requirement.

Practitioner commentary on the same strategy names the friction honestly: the released API surface is not always complete enough for the requirement, particularly in on-premise and private-cloud deployments, which is why wrappers and formal API requests to the vendor are part of the practice rather than an admission of failure.

Failure scenarios

• Modification by default, because the developer has source access and the extension point is three days of research away.
• A skipped upgrade taken to defer re-application cost, which makes the next one span two versions and roughly doubles it.
• Clean core declared, not enforced. With no build-time check the count grows quietly and is discovered during upgrade planning.
• Everything pushed outside the product in the name of clean core, producing a side-by-side estate with its own integration surface and latency for logic an in-product extension point handled.
• An extension on an undocumented internal object the vendor changes in a patch, so the breakage arrives with no upgrade programme around it.

Trade-offs

The decision rule that holds up: a modification is justified when the requirement is load-bearing for the business and no released interface reaches it, and then only as a logged exception with an owner. "The API does not do quite what we want" is not that; "there is no API" sometimes is.

When not to use it

When the product is being replaced within one upgrade cycle. If the ERP is on a two-year exit, the modification will never be re-applied and the discipline pays for an upgrade that will not happen.

When the extension surface genuinely does not exist. A product with no published extension model cannot be extended cleanly. Name that as a vendor-selection defect rather than a developer discipline problem.

For software you own. Clean core is about a boundary with somebody else's release train; applied inside your own codebase it becomes an argument against refactoring.

Interview question

Q: You take over an ERP estate with 1,400 custom objects, 300 of which modify vendor code. Mainstream maintenance ends in 26 months and the business will not fund an 18-month upgrade programme. What do you do in the first quarter, and what do you tell the board the modifications have already cost?

What a strong answer covers: classifying the 300 by upgrade exposure first, since most will prove dead, configuration-equivalent or reproducible on a released interface · installing the build-time gate so the number stops growing · costing the remainder as re-application effort per upgrade times the upgrades left in the product's horizon, which is the number the board has never seen · and being clear that the modifications have already removed the option of the vendor's hosted deployment.

Quick check

Quiz: Why is a five-day modification to vendor code not a five-day decision? — It is re-applied and retested at every upgrade across a 10 to 20 year horizon, so the real cost is per-upgrade effort times five to fifteen upgrades, plus the deployment options it forecloses.

Flashcard: What distinguishes a clean extension from a modification? — Whether it is built on an interface the vendor has published and committed to keeping stable. If the interface is not documented as stable, the extension is a fork you will re-apply by hand.