Enterprise Architecture
What “Clean Core” Actually Means for SAP S/4HANA
Clean core gets used as a slogan almost as often as it gets used correctly. Stripped down to its essentials, it means one thing: keep custom code and process deviations out of the SAP digital core, and push extensions, integrations and industry-specific logic onto SAP Business Technology Platform instead, using released APIs and extension points rather than core modifications.
The business reason is simple. Every custom modification to the core is a future upgrade cost, a future testing cost and a future risk. Organisations that spent a decade layering Z-programs and user exits onto ECC are the ones now finding S/4HANA migrations expensive and slow — not because the target platform is wrong, but because the debt has to be paid down somewhere along the way.
In practice, clean core is a governance discipline as much as a technical one. It needs a standing decision process for “does this belong in the core, on BTP, or should we change the process instead” — applied consistently, not just at go-live. Architecture teams that skip the governance and only do the technical extension-point mapping tend to see the debt creep back in within eighteen months.
The organisations that get the most value tend to do three things well: they inventory existing customisations honestly before deciding what to keep, they treat BTP extensions as first-class software with their own lifecycle rather than a dumping ground, and they connect the clean-core decision to a real financial case — total cost of ownership and upgrade cost avoided — rather than treating it as a purely technical preference.
Reverse Greenfield
The Reverse Greenfield Approach, Explained
Most S/4HANA transformation programmes are framed as a binary choice: brownfield conversion (keep the existing system, convert it in place) or greenfield rebuild (start over with a new implementation). Both have real costs. Brownfield inherits every piece of technical debt in the existing landscape. Greenfield demands a business case for replacing a working system all at once, which is a difficult sell when the ROI is diffuse and the risk is concentrated in a single cutover.
Reverse Greenfield, the approach set out in From Legacy to Innovation, inverts the usual order. Instead of migrating the core first and dealing with extensions afterwards, it starts by building the target-state architecture — clean, cloud-native, API-led — around the edges of the existing ECC system, while that system keeps running the business. Only once the new architecture is proven does the core migration itself become a smaller, better-understood step.
This matters for the same reason phased construction matters in any large capital project: it converts one large, hard-to-reverse decision into a series of smaller, reversible ones. Teams get real production experience with the target architecture before betting the core system on it, and the business case can be built incrementally instead of justified up front in a single business case document nobody fully believes.
It is not a shortcut, and it does not remove the eventual need to deal with the core. What it changes is sequencing and risk — and in most transformation programmes, sequencing and risk are exactly what determine whether the programme survives contact with the organisation.
Data & AI
Where AI Genuinely Helps Enterprise Architecture Right Now
Enterprise AI conversations tend to swing between overclaiming and dismissal. The useful middle ground is narrower and more specific than either camp usually admits.
Where I have seen genuine, defensible value: document automation on structured and semi-structured content (invoices, contracts, technical documentation), enterprise search that actually respects existing access controls instead of flattening them, and data-quality triage — using models to flag likely duplicates, mismatches and anomalies for a human to review, rather than to make the final call. In each case, the model is doing pattern recognition at a scale humans can't match, and a human or a deterministic rule is still making the decision that matters.
Where it gets shaky: letting a model make an irreversible business decision without a human checkpoint, and treating model output as ground truth for anything touching compliance, financial reporting or personal data without an audit trail. Responsible AI adoption in an enterprise context is mostly an architecture and governance problem — identity and access controls that follow the data into the model layer, logging that lets you reconstruct why a system produced a given output, and a clear line between “the model suggested this” and “the organisation decided this.”
The architectures that work treat AI capability as another integration to be governed like any other — with the same rigour applied to data residency, access control and auditability as any other enterprise system. The ones that struggle tend to have deployed a capability before deciding who is accountable for what it produces.