From Build to Last, to Build to Change
Why enterprise modernization is not a technology project — and what it means for how your organization competes.
Series: Build to Change — Part 1 of 3
"Tools are many, Perspective is key. A flexible mindset is the engine of change, driving real business value before the first line of code is written."
Most organizations treat enterprise modernization as a technology migration. The ones that get it right treat it as an architectural paradigm shift — a deliberate move from systems built to last to systems built to change. Here is what that shift looks like, and why it matters to business leaders before it matters to IT.
There is a question I find myself returning to at the start of almost every enterprise modernization engagement: what is this organization actually trying to be able to do that it cannot do right now?
The answer is rarely "run a newer version of the software." It is almost always some version of the same thing — move faster, respond to market changes without waiting months for a system update, make decisions on data that reflects today rather than last night's batch cycle. The technology is not the goal. The capability is the goal.
That distinction — between modernizing the technology and building the capability to change — is where most transformation programs go wrong. And it is where Strategic Enterprise Architecture, applied well, makes the difference between a technology migration and a genuine competitive shift.
THE PROBLEM WITH SYSTEMS BUILT TO LAST
For decades, the dominant logic of enterprise software was consolidation. Build one system that does everything. Integrate deeply. Standardize on a single platform. The stability this produced was real. So was the rigidity.
In a monolithic enterprise system, the business logic, data, and user interface are tightly coupled — designed to work together so completely that changing one requires coordinating all the others. A modification to the procurement approval process touches the finance module. An update to vendor management ripples through inventory. A new regulatory requirement in one market requires a development cycle that affects the entire platform.
The result is what architects call tight coupling — and what business leaders experience as the inability to move. Feature requests that should take weeks take quarters. System updates that should be routine become organizational events. The technical debt accumulated through years of customization becomes a constraint on the strategy, not just the IT roadmap.
In a business environment that rewards speed and penalizes delay, this is not an IT problem. It is a strategic liability.
WHAT IS A COMPOSABLE ENTERPRISE?
A Composable Enterprise is an organization whose capabilities — the discrete business functions it performs — are structured as independent, interchangeable modules rather than a single integrated system.
Think of it as the difference between a building poured from a single mold and one assembled from precisely engineered components. The poured building is strong and stable but nearly impossible to modify once set. The assembled building can be extended, reconfigured, and updated component by component without dismantling the whole.In practice, a Composable Enterprise separates the core system of record — the ERP that manages transactions, financial data, and master records — from the innovation layer, where new capabilities are built, tested, and deployed independently. The two layers communicate through well-defined interfaces rather than direct integration.
The business value: new capabilities can reach the market in weeks rather than quarters. Problems are isolated to the module where they occur rather than cascading across the platform. And the organization is no longer dependent on a single vendor's release cycle to compete.
Ref: Composable Enterprise: A strategic framework introduced by Daryl Plummer (The Future of Business Is Composable, Gartner, 2020) to drive organizational agility through modular business architecture.
THE ARCHITECTURAL SHIFT: FROM PARADIGM TO PRACTICE
The move from Build to Last to Build to Change is not primarily a technology decision. It is an architectural decision — and more fundamentally, it is a strategic one.
Two principles govern this shift in practice:
[1] The first is Core Integrity. The enterprise system of record — the ERP — is kept as close to its standard configuration as possible. Customizations that would previously have been built directly into the core are instead developed outside it, on platforms designed for extension and innovation. The benefit is significant: the core remains upgradeable, auditable, and stable, while the organization retains the freedom to build new capabilities without accumulating the technical debt that eventually makes the system immovable.
[2] The second is Composability. Rather than treating the business as a set of functions that must all live inside a single system, the organization identifies its core capabilities — procurement, finance, customer management, inventory — and architects each one as a discrete module that can be developed, updated, and replaced independently. The connections between modules are managed through defined interfaces rather than hard-wired integrations.
Together, these principles transform the enterprise architecture from a constraint into what it should always have been: a platform for competitive capability.
THE PROCUREMENT CASE: WHERE THE PRINCIPLE MEETS THE PROBLEM
To understand what this shift looks like in practice, consider the procurement function — the process through which an organization manages vendor relationships, purchase orders, and approval workflows.
In a monolithic system, procurement is embedded deeply in the core. Vendor data is stored in internal tables that no external system can easily access. Approval workflows are built on logic that was designed for the system's architecture, not for the user's experience. Adding a new capability — automated vendor risk assessment, for example — requires writing new code inside the core, which violates the integrity principle and adds to the technical debt the organization is trying to reduce.
The procurement function was selected as the starting point for modernization not because it was the most broken, but because it was the most instructive. It sits at the boundary between back-office systems — finance and inventory — and external relationships — vendors and users. That boundary is where architectural decisions become business decisions. It is also where the value of getting those decisions right is most visible.
The approach taken was not to replace the entire system. It was to begin separating the procurement capability from its monolithic foundation — incrementally, with clear sequencing, and without disrupting the business processes that depended on it. The logic of how that separation was designed is the subject of the next article in this series.
THE FIT-FOR-PURPOSE QUESTION
Before any pattern was selected, any platform was chosen, or any migration was planned, the architectural work began with a more fundamental set of questions.
What specific business decisions are currently blocked by the existing architecture? In procurement, the answers were concrete: approval workflows that could not be accessed on mobile, vendor data that could not be shared with external systems, and new capability requirements that would take a full development cycle to address inside the core.
What is the minimum architectural change that would unblock those decisions? Not the most comprehensive redesign, and not the fastest shortcut — the minimum that resolves the identified concern without creating new dependencies or ambiguities.
Is the investment proportionate to the value it generates? Every architectural decision carries a cost — development time, migration risk, governance overhead, and the opportunity cost of what the team is not building while building this. That cost must be recoverable through the business value it enables.
These questions — concern-driven, right-sized, value-justified — are not a methodology imposed on the project. They are the diagnostic discipline that determines whether the architecture being designed is fit for its purpose or simply technically impressive.
The distinction matters more than most modernization programs acknowledge. A technically sophisticated architecture that does not resolve the concerns that motivated the work is not a partial success. It is a complete miss, delivered at full cost.
A CLOSING THOUGHT FOR BUSINESS LEADERS
Enterprise modernization is often presented to executive teams as a technology imperative — a necessary investment in keeping systems current and avoiding the risk of obsolescence.
That framing is not wrong. But it undersells what is actually at stake.
The organizations that emerge from modernization with genuine competitive advantage are not the ones that replaced the oldest systems with the newest ones. They are the ones that used the modernization as an opportunity to change the relationship between their strategy and their technology — to build an architecture that can respond to the business, rather than one the business must work around.
Build to Last was the right philosophy for a world that changed slowly. In a world that rewards the ability to change faster than the competition, it has become the constraint.
The question worth asking is not whether to modernize. It is whether the modernization being planned is building the capability to change — or simply replacing one system that cannot move with another that eventually will not either.
Next in this series — Part 2: Why We Chose These Patterns, and What That Choice Actually Means. An examination of the architectural reasoning behind the four patterns that governed the procurement modernization — and what each one reveals about how strategic architecture thinks.
Ref:
Gartner (2020): "The Future of Business Is Composable"
Gartner (2020): "Composable Business Index"
Compose Platforms that Adapt to Business Needs: https://www.gartner.com/en/infrastructure-and-it-operations-leaders/insights/deliver-platforms-and-services-to-enable-digital-transformation
Raschada Nootjarat is an Enterprise Architect with a focus on AI strategy, architecture governance, and the intersection of human and machine systems in organizational transformation. She starts this website together with her "Fit-for-Purpose Enterprise Architecture" book in April, 2026.