ERP never died.
It changed form.
When Gartner coined the term “enterprise resource planning” in 1990, it described a very specific idea. One integrated system to run the core of the business. Finance, HR, manufacturing, procurement, all connected through a single data model and a single process backbone.
For a long time, this model dominated.
Through the 1990s and early 2000s, monolithic ERP systems became the foundation of corporate IT. They were expensive, rigid, and difficult to implement. But they solved one problem exceptionally well. Consistency. Data integrity across the enterprise. One version of the truth, enforced by design rather than by discipline.
Then the cracks started to show.
High costs, limited flexibility, and a growing number of failed implementations turned ERP into a symbol of over-engineering. The backlash was predictable. Organizations started to question the model itself. “ERP is dead” became a common refrain, driven more by frustration than by a clear alternative.
The alternative eventually arrived anyway.
Best-of-breed applications began to replace individual ERP modules. Salesforce for CRM, Workday for HR, and a growing ecosystem of specialized tools for almost every business capability. Instead of one system doing everything, multiple systems would each do one thing well.
In 2014, Gartner formalized this shift with the term “postmodern ERP”.
On paper, it is compelling. Combine specialized applications. Integrate them where needed. Gain flexibility without being locked into a single vendor stack. Replace parts of the system without replacing everything. It sounds like progress.
And in many ways, it is.
But it comes with a trade-off most organizations underestimate.
Traditional ERP optimized for consistency and control.
Postmodern ERP optimizes for flexibility and speed.
You do not get both.
What monolithic ERP solved structurally, postmodern ERP pushes into integration.
The moment you replace a single system with a landscape of SaaS applications, cloud platforms, and legacy components, integration becomes the system. Not a technical layer. The system itself.
And that system behaves very differently from what most organizations are used to.
The first shift is temporal.
In a monolithic ERP, change is controlled. Releases are planned, coordinated, and executed in defined cycles. In a postmodern landscape, every SaaS application evolves on its own schedule. Updates happen continuously, whether you are ready or not. Interfaces change. Data structures shift. Dependencies break.
You are no longer managing releases.
You are managing constant change.
This immediately creates pressure on testing.
Regression testing is no longer an occasional activity. It becomes a permanent requirement. Every change in one component can affect the end-to-end process. The question is no longer whether something works in isolation, but whether the entire chain still holds together.
Most organizations underestimate the operational load this creates.
The second shift is structural.
Environments are no longer under your control in the same way. Development, test, and production environments across multiple SaaS platforms evolve independently. Keeping them aligned becomes difficult. Achieving stability becomes temporary.
The idea of a “stable baseline” starts to erode.
And without a stable baseline, confidence in the system erodes with it.
The third shift is resilience.
Each SaaS provider may have strong backup and disaster recovery capabilities. But your business processes do not run inside one system. They run across many. Understanding what happens when one component fails, and how that failure propagates through integrations, is significantly more complex.
Resilience is no longer a property of a system.
It is a property of an ecosystem.
Then comes the network.
Cloud promises scalability. And it delivers, within boundaries. But data still has to move. Between systems, across regions, through firewalls, and often between cloud and on-premise environments. Latency, throughput, and reliability are not theoretical concerns. They define what is actually possible in your integration design.
At scale, these constraints become visible very quickly.
Data itself becomes a problem.
Movement, transformation, synchronization. These were already complex in traditional integration scenarios. In a postmodern landscape, they become continuous challenges. Different data models, different semantics, different update frequencies. The more systems you connect, the more fragile the overall data consistency becomes.
What used to be enforced by a single schema now has to be managed actively.
And that management is never complete.
Standardization, which was built into traditional ERP, becomes a negotiation.
Each system has its own logic, its own data structures, its own way of evolving. There is no universal standard across SaaS platforms. Every integration is, to some extent, custom. Every update risks breaking that custom layer.
Over time, complexity accumulates.
Finally, there is security and compliance.
Every additional system, every integration point, every data transfer increases the attack surface. Requirements do not disappear in a distributed architecture. They multiply. Ensuring that all components meet regulatory and internal standards, consistently and continuously, is a non-trivial task.
This is where the original promise of simplicity fully reverses.
What looks flexible at the component level becomes complex at the system level.
And that is the core trade-off.
You can increase flexibility and agility by moving to a postmodern ERP architecture.
Or you can reduce complexity by centralizing and standardizing.
You cannot fully optimize for both at the same time.
The mistake many organizations make is believing they have escaped the constraints of traditional ERP.
They have not.
They have shifted them.
From the application layer to the integration layer.
And unless that shift is understood and managed explicitly, the result is not a more agile architecture.
It is a more complex one, with fewer visible boundaries and more hidden failure points.
In simple terms: postmodern ERP does not eliminate complexity.
It redistributes it to where most organizations are least prepared to handle it.