What happens when we treat an ERP system replacement like the replacement of a normal software package? Imagine the first Monday morning after our fictional ERP replacement goes live.
The new system is running. Finance can create an invoice. Procurement can generate a purchase order. The implementation team has completed its checklist.
Then the surrounding enterprise begins to wake up.
The warehouse system cannot interpret a new product identifier. A pricing application is still looking for a field that disappeared during conversion. The CRM system cannot submit an order because the customer IDs do not match. A regulatory report depends on a calculation that everyone assumed belonged to the reporting system—but was actually hidden in custom code inside the old ERP. An apparently minor interface turns out to be the only place where two conflicting definitions of “delivery” were being reconciled.
The new ERP could be functioning exactly as designed, but the enterprise? Not so much.
Of course, few organizations would admit that they are treating an ERP replacement like a normal software upgrade. Many effectively do.
The literature is filled with examples of companies that embarked on expensive ERP projects only to have them fail two years and millions of dollars later. Even consulting firms with excellent reputations can end up with egg on their collective faces, unwinding changes after go-live and leaving cleanup work in their wake. CIO magazine’s collection of 18 widely publicized ERP failures is a harrowing sample of what becomes visible to the public and investors.
There is no surprise in saying that an ERP implementation is not a software project. An ERP platform almost never sits inside the organization as an easily replaceable box. Over time, it becomes entangled with hundreds of hidden or forgotten business rules, overlapping business processes, poorly defined organizational responsibilities, vague data definitions, inflexible reports, point-to-point integrations, process workarounds, and, of course, key dependencies on neighboring applications.
Replacing an ERP system changes the architecture of the enterprise whether anyone planned to change that architecture or not. In fact, resistance to the changes brought on by ERP projects forms a major set of obstacles to implementation success.
Gartner predicts that more than 70% of recently implemented ERP initiatives will fail to meet their original business-case goals, with as many as 25% failing catastrophically. Gartner also describes alignment between an ERP initiative and strategic goals as one of the leading predictors of success. (Gartner’s ERP research page)
Enterprise Architecture is no silver bullet, but EA has a powerful and strategic role to play in avoiding the most costly mistakes that can sink an ERP initiative.
In this article, I will describe three key roles that Enterprise Architecture can play in the successful delivery of an ERP program:
- Understand what the existing ERP, its processes and data, and the surrounding systems actually do for the enterprise.
- Clarify the goals of the ERP program and align the implementation work with those goals.
- Design a feasible series of transitions from the current environment to the intended one.
Without the first, the organization does not understand the real scope of the replacement. Without the second, it cannot build the organizational momentum needed to deliver a new ERP. Without the third, it may understand the destination but still have no safe way to get there.
You have to know what you are replacing
An application inventory may describe the existing ERP as a financial, human-resources, supply-chain, or manufacturing system.
That is a useful description, but it utterly fails to describe the architectural impact of an ERP system. To use the language of architectural descriptions, you have to map the stakeholders, understand their concerns, and create a view of what they use the ERP system for.
To wit, you have to be able to answer these questions about the existing system:
- Which business capabilities depend on it?
- Which business processes pass through it?
- Which decisions rely on information it produces?
- Which systems send information to it?
- Which systems consume its information?
- Which calculations are buried inside it?
- What downstream systems demand a business rule that is implemented in it?
- Which controls are enforced by it?
- Which workarounds have grown around it?
- Which neighboring systems exist because the ERP could not perform a required function?
- Which apparently separate systems would become unnecessary if the replacement performed that function well?
These questions reveal the ERP’s actual role in the enterprise.
A system may be described as the organization’s “financial platform,” for example, while also performing product classification, customer validation, contract interpretation, inventory allocation, regulatory control, and reporting functions. Some of those responsibilities belong in the replacement ERP. Others may belong in surrounding platforms. A few may be remnants that should disappear entirely.
Sometimes the replacement ERP promises a useful feature that a wise implementation team will choose not to implement inside the ERP itself. The organization may deliberately keep that responsibility in a separate component as part of a more composable architecture—especially when doing so preserves flexibility or supports differentiation.
You cannot make those choices from an application name and a list of interfaces.
Research into ERP implementation has repeatedly identified the importance of legacy systems, business-process change, data management, implementation strategy, and the fit between the ERP and the organization’s processes. A review of critical success factors across multiple countries found all of these among the recurring contributors to ERP outcomes. (Read the research review)
In other words, the surrounding architecture is not a secondary technical detail. It is part of the implementation problem.
Start with functional contribution, not interfaces
ERP discovery often begins with an interface inventory. That is necessary, but it can create a misleadingly technical view of the landscape.
An interface tells you that System A sends something to System B. It does not necessarily tell you why the information moves, which business outcome depends on it, or what will happen if the responsibility for producing that information changes.
To add value, Enterprise Architecture should begin one level higher.
An effective EA practice will map the existing ERP and its peer systems to the business capabilities they support. It will then examine the processes through which those capabilities operate. Only after establishing that functional context should the team descend into interfaces, data objects, transformations, reports, and technical dependencies.
This produces a much more useful set of questions for the ERP program to answer:
- Does the new ERP assume responsibility for this function?
- Does the function remain in an existing peer application?
- Does another platform need to be introduced?
- Must an existing application be substantially rewritten?
- Can a custom application now be retired?
- Does the process itself need to change?
- Which information must continue to flow during the transition?
- Who owns the decision?
Discovering these questions late in the process can be frightfully expensive.
You will discover them. You’ll regret not considering them sooner.
The initial implementation proposal may paint a rosy picture of a software replacement project. A good architect will shine the harsh light of reality. The program may actually include one ERP replacement, several rewritten integrations, two substantially changed peer applications, a new reporting approach, new ownership for master data, and the retirement of multiple legacy components.
That is not scope creep. It is scope discovery.
The dependencies were already present. Enterprise Architecture merely makes them visible.
Peer systems are part of the ERP program
The systems surrounding an ERP platform are sometimes treated as separate workstreams whose owners will “handle their part.”
That division may be convenient for project administration, but it does not remove the architectural dependency.
If a warehouse-management platform, customer portal, product-information system, planning tool, data warehouse, or regulatory reporting application depends on behavior in the old ERP, then the future of that system is part of the ERP transition.
Some peer systems will need a modest interface change. Others will require substantial redesign because the new ERP changes the division of responsibility between platforms.
I call this functional partitioning: the intentional allocation of responsibilities among systems in a way that is fit for purpose and not driven solely by the advertised features of any one software product.
Consider:
- A custom order-management application may have grown because the previous ERP could not support a particular sales process. If the new platform can support it, should that custom application remain? If it does remain, which system owns order state? Which system owns pricing? Where are exceptions managed?
- Conversely, the new ERP may deliberately exclude a function that existed in the old one. A peer system must then assume that responsibility before the old ERP can be retired.
- The new ERP may constrain innovation or make the adoption of a competitively important AI capability more difficult. It may be necessary to leave a feature outside the ERP to preserve the flexibility to use an innovative external system.
These are architecture decisions. They cross project boundaries, vendor boundaries, business units, application teams, and data domains. No individual implementation workstream is naturally accountable for the complete picture.
Enterprise Architecture is.
The first architectural deliverable is an enterprise baseline
The baseline does not need to become an enormous documentation exercise.
It needs enough detail to support replacement decisions. At minimum, it should identify:
- Obstacles in the existing system that prevent enterprise innovation or competitiveness
- Business capabilities supported by the current ERP
- Important processes that pass through it
- Peer applications and their functional contributions
- Significant upstream and downstream dependencies
- Critical information exchanged
- Important business rules or controls
- Known customizations and workarounds
- Candidate systems for retention, modification, replacement, or retirement
- Ownership of the affected capabilities, processes, applications, and information
The Useful EA Application Portfolio Manager can support this work by maintaining the application inventory, mapping applications to capabilities, recording upstream and downstream application relationships, and capturing the intended disposition of each system.
The important output is not a diagram. It is a shared understanding of what the existing landscape contributes and what must happen to each part of it to overcome obstacles, address critical needs, and achieve important business goals.
This leads into the second key contribution of Enterprise Architecture: answering the question “Why?”
The second role of EA: building, clarifying, and demonstrating alignment
One of the critical success factors that appears in multiple studies of ERP success is alignment. For an ERP project to succeed, the organization has to be clear about why the work is necessary, what benefits teams will realize, and how the project supports the future of the company.
This is not a small ask. It is not something that you do “when we get toward the end.”
Alignment drives the roadmap, informs functional partitioning, and provides the foundation for change management. It is a first-order requirement—and something a mature Enterprise Architect has in their toolbelt.
The program has to know what the organization expects it to achieve. It must validate that those outcomes are realistic and determine how—and when—they can be delivered. Most importantly, it must press senior leaders to articulate those expectations clearly, repeatedly, and in language people understand.
Alignment is rarely owned by developers, and most project managers are measured on delivery rather than enterprise coherence. It is an enterprise concern, and it shows up from the very first day of planning.
Alignment is the art of making sure that the sum of the efforts to change an enterprise delivers the changes that enterprise actually needs to reach its clearly stated objectives.
Alignment is done mostly from the top down, but the next stage (roadmapping) requires you to demonstrate alignment from the bottom up as well.
From the top down, begin with strategy and capability:
- Which measurable strategic outcomes is the ERP program expected to support?
- Which business capabilities need to improve, and what will happen when they do?
- Where are the largest gaps between current and required maturity, and what is driving that requirement?
- What obstacles are preventing the organization from achieving its goals today?
- For each area affected by the program, what is the benefit for that team, department, or function?
If your Enterprise Architect can answer these questions, you have started to align. If the executives can recite the answers, you are halfway there. If the people affected by the ERP project understand them and can see the value in the project, you have achieved alignment.
The Useful EA Capability Modeler supports the top-down view by connecting strategies to capabilities, assessing maturity gaps, identifying priorities, and organizing gaps into proposed programs.
The third role: design the path, not just the destination
Once the current architecture is understood, Enterprise Architecture has another major responsibility: helping the organization move from the baseline to the target without breaking the business along the way.
In the worst-case scenario, an ERP roadmap is little more than a module-release schedule:
- Finance in January
- Procurement in April
- Supply chain in September
- Human resources next year
That may describe the vendor implementation sequence. It is insufficient to describe a viable enterprise transition.
A credible roadmap must consider:
- Which business capabilities become available at each stage
- Which processes can operate in the interim state
- Which applications remain connected to the old ERP
- Which applications have moved to the new one
- Which data must be synchronized temporarily
- Which business rules exist in both environments
- Which reports and controls must work during every stage
- Which legacy components can be retired
- Which organizational groups must change their work
- How much simultaneous change the enterprise can absorb
A transition state is not simply an unfinished target architecture. It is an architecture the organization may have to operate for months or years.
It must work.
Every stage should deliver a useful enterprise
This is where the concept of Transition Architectures becomes especially valuable.
The TOGAF architecture framework describes Transition Architectures as meaningful intermediate states between the baseline and target architectures. TOGAF also emphasizes that transition states should provide measurable business value and account for dependencies and the organization’s capacity to absorb change. Its migration-planning guidance connects those states with work packages, projects, portfolios, milestones, value, costs, risks, and dependencies. (TOGAF Phase E: Opportunities and Solutions; TOGAF Phase F: Migration Planning)
I insist that you have to go further.
Your transition states have to be stable, valuable, and sufficient:
- Stable: The organization can operate in that state without constant emergency intervention.
- Valuable: The state provides a meaningful improvement rather than merely representing unfinished technical work.
- Sufficient: The organization can remain in that state for a considerable period without accumulating unacceptable new debt.
That part is not in TOGAF. It’s in reality.
Instead of asking only, “When can we turn on the next module?” ask:
What stable and useful version of the enterprise can we operate after this stage?
A stage might introduce a new financial core while retaining selected operational systems. Another might move procurement and supplier management while temporarily maintaining a synchronization mechanism with the old environment. A later stage might consolidate product information, rewrite a planning platform, and finally remove the legacy ERP.
Each state in your Transition Architecture should have an explicit definition:
- What is live?
- What remains?
- Where does each responsibility sit?
- Which temporary components are required?
- What new value is available?
- What risk has been retired?
- What must happen before the next transition?
Case-study research has found that cautious, evolutionary implementation, accompanied by change management and organizational readiness, can positively influence ERP outcomes. (Read the four-case study)
Planning for Transition Architectures is the best way to get support from senior leadership to avoid “big bang” implementation exercises. Anyone who has ever gone through a big-bang implementation knows how painful it is to switch off one system while switching on its replacement.
In over forty years in IT, I have never seen it work. Not once.
Prove that you can deliver on the strategy
In your planning, there is a key step that is missed nearly every time: proof of alignment.
We described above a process of gaining alignment, but ERP programs are not accomplished with a snap of the fingers. They require years of attention, funding, planning, and organizational energy. You cannot declare “we have alignment” on day one and assume it will still be there at the end.
Requirements change. People come and go. Organizations reorganize. Markets shift. Products are created to adapt to changing customer expectations.
This is the point where you have to demonstrate not only that your beautiful plan will work, but that it will keep the strategy in focus even as the strategy changes. This is where the bottom-up alignment mentioned earlier comes into play.
From the bottom up, examine the proposed implementation repeatedly and at every stage:
- Which projects and work packages are being proposed?
- What systems and technologies do they change?
- What benefits are expected?
- Which objectives do they support?
- What dependencies determine their sequence?
- Is any major piece of work disconnected from the stated strategy?
The Useful EA Benefit Dependency Network supports this bottom-up view by tracing strategies through objectives, programs, projects, systems, and technologies. It can help expose proposed work that lacks a visible connection to strategy and show where multiple initiatives converge on the same enabling system or technology.
Critically, it keeps small but essential supporting projects in view before one of them is removed in a burst of cost-cutting zeal, putting the entire ERP program in jeopardy.
Together with the top-down alignment effort described above, these methods help turn an ERP implementation schedule into an enterprise roadmap.
Enterprise Architecture does not end at design approval
A healthy EA practice keeps the architect engaged to the end.
As implementation teams discover new constraints, the target and Transition Architectures will change. A customization may be rejected. A peer application may prove harder to modify than expected. A data conversion may expose conflicting definitions. A planned retirement may need to be delayed.
Architecture must remain involved to answer questions such as:
- Does this decision alter the future division of responsibility?
- Does it introduce a new long-term dependency?
- Is a temporary solution becoming permanent?
- Does the next transition state remain operationally viable?
- Has a capability increment been delayed or removed?
- Does the roadmap still deliver value at each stage?
- Are we recreating legacy complexity inside the new platform?
ERP research also distinguishes between implementation success and the performance improvements expected after implementation. Successfully going live is not the same as producing the desired business result. (See the research on implementation and post-implementation performance)
If you want to deliver the expected performance improvements and not just deliver the software, it is critical to stay focused on the business value you are trying to achieve. Decisions along the way that seem minor, convenient, or politically easy can carve away at those performance improvements to the detriment of the entire program.
Enterprise Architecture is broader than an ERP implementation
When implemented well, an ERP platform quickly becomes one of the most important components in an organization’s landscape. It can standardize processes, consolidate information, remove duplicated applications, and enable new capabilities.
But the ERP is not the enterprise.
It exists inside a larger system of people, processes, information, applications, technologies, controls, and organizational responsibilities. Its value depends on how well that larger system works after the implementation is complete—and during every stage of getting there.
The role of Enterprise Architecture is to keep that whole system visible and, to the greatest extent possible, viable.
Before implementation, EA reveals what the existing ERP and surrounding applications actually contribute.
During planning, EA defines value-adding transition states and connects implementation work to business capabilities and strategic outcomes.
During delivery, EA helps the organization respond to discoveries without losing the coherence of the target.
An ERP program that lacks Enterprise Architecture may still install the software.
The more important question is whether it leaves behind a better enterprise.