From ERP-Centric to Capability-Centric Architecture

"That's in the ERP"

Listen to how your organization answers questions. Can we change the approval flow? That's in the ERP. Can we onboard this acquisition faster? Depends on the ERP. Can we try a new pricing model? Not until after the ERP upgrade. Somewhere along the way, the system bought to run the back office became the answer to every question — and the constraint on every plan.

Then comes the upgrade. Years of effort, eight figures of spend, hundreds of people — to arrive, if everything goes well, exactly where you started, on a newer version. No new capability. No new market. The biggest technology investment of the decade, spent standing still.

The Vendor Owns Your Operating Model

The usual diagnosis is "too much customization," and the usual prescription is discipline: adopt vanilla, adapt the business to the software. That's half right. The deeper problem is architectural: the organization is organized around a system instead of around what the business does. When the ERP is the center, its data model becomes your business vocabulary, its release calendar becomes your roadmap, and its limitations become — invisibly, permanently — your strategy. Decades of customizations aren't the disease; they're the symptom of differentiating work forced to live inside a commodity platform, the one place it can never evolve at your pace.

The Capability-Centric Shift

The alternative doesn't start with technology. It starts with a capability map — the stable list of what the business does, independent of any system. Then four moves:

• 1. Sort every ERP-hosted capability into commodity or differentiator. General ledger, payroll, procurement — commodity: you win nothing by doing them differently. But somewhere in those customizations live the two or three capabilities that are actually how you compete — the pricing engine, the scheduling logic, the claims workflow. Most organizations find 80% commodity, 20% differentiator. The entire strategy follows from that sort.
• 2. Keep the core clean. Commodity capabilities run vanilla in the ERP, adapted-to, not customized. This isn't vendor obedience — it's refusing to spend engineering effort where no competitive return exists, and it's what makes every future upgrade a routine event instead of a program.
• 3. Move differentiators out — behind contracts. The capabilities you compete on become their own applications, built or bought deliberately, integrated with the ERP through versioned contracts and events — never through database links or bolt-on customization. Now your differentiators evolve at your pace, and the ERP quietly becomes what it should have been all along: an important commodity supplier, not the center of the universe.
• 4. Migrate by rebuild-on-touch, not big bang. Nobody funds a five-year "ERP exit program," and nobody should. New capability work follows the target architecture from today. Existing customizations move out when business change touches them anyway. The upgrade you were dreading becomes the forcing function — each customization it would break is a candidate to extract rather than re-implement.

What Good Looks Like

The end state is measurable in decisions. The ERP upgrade is priced as a commodity platform swap — months, not years — because nothing strategic lives inside it. Roadmap questions are answered by capability owners, not by the vendor's release notes. An acquisition is onboarded by connecting contracts, not by a re-implementation. And the sentence "that's in the ERP" changes meaning — from therefore we can't to therefore it's standard.

Where you sit on this journey is exactly what our free Architecture Assessment measures — twelve questions on capability clarity, coupling, changeability, and executive visibility, with specific next steps for your band.

John

Founder, Splendor Technologies

20+ years in AI, enterprise architecture, and application development. Helping organizations modernize technology and drive measurable business outcomes.