Why three decades of enterprise architecture failures look different on the surface and identical underneath — and what the discipline has been failing to name the whole time.
Anyone who has built IKEA furniture has experienced the moment where the instructions start drifting away from the parts in front of you. A dowel that does not look quite like the one in the diagram. A pre-drilled hole that seems to be in the wrong place. A wrench that does not quite turn the bolt the way the picture suggests. At small scales — a BILLY bookshelf, a side table, a lamp — the drift is recoverable. You improvise, the piece goes together, the result holds books for a decade.
The drift becomes harder to recover from at scale. A KALLAX-PAX wardrobe-and-storage combination has hundreds of decision points. Most are minor. A few are load-bearing. The probability that at least one load-bearing decision diverges from the original design is high enough to be effectively certain at sufficient complexity, even with the instructions in front of you. Which is why IKEA’s system is not just the parts. It is the parts, the instructions, and the provided tools — engineered specifically for each other. Remove any one of the three components and the system stops being self-coherent. You can technically still assemble something. Whether what you assemble has the structural properties the original design depended on is a different question.
I have been thinking about IKEA recently because of how often the procurement-technology discipline has reproduced the structural failure of an IKEA assembly with the parts moved out of the box and into the wrong workshop. It has happened three times in the last thirty years. It is happening again right now. Each iteration looks different on the surface. Each iteration is structurally identical underneath.
Era One: The Bolt-On Era
Through the late 1990s and 2000s, large organizations bought core ERP systems — SAP R/3, PeopleSoft, Oracle Financials — that did not quite fit their actual operations. Vendors and integrators responded by selling bolt-on modules to close the gaps. Best-of-breed procurement add-ons. Spend analytics tools. Third-party contract management. Supplier portals layered on top of the core. Each bolt-on solved a real problem. Each one extended the surface area of what the organization had to manage, validate, and reconcile against the master system.
The discipline of the era treated bolt-ons as an integration problem. Get the data flowing. Get the interfaces stable. Get the workflows synchronized. Once integration was achieved, the system was assumed to be working. What the discipline did not ask — because the discipline did not yet have a name for the question — was whether the integrated system was producing decisions that held up under conditions the organization had not yet experienced or recognized internally.
The 2008 CATA Alliance white paper I authored on SAP Procurement for Public Sector documented this directly. The Hershey, FoxMeyer, MFI, HP, Cadbury, and King County cases were not failures of integration. The integrations worked. The data flowed. The interfaces ran. What failed was that the integrated systems collectively produced decisions the organizations could not defend when conditions shifted — the chocolate-bar overproduction at Cadbury, the order-fulfillment collapse at Hershey, the £12 million write-off, the $38 million King County maelstrom. The validation altitude was where those failures originated. The altitude had no name. The failures were attributed to integration management, change control, or stakeholder buy-in.
The IKEA equivalent: buying parts from a different store and assuming they fit because they look similar to what was in the box.
Era Two: The SaaS App Sprawl
By the mid-2010s, SaaS had collapsed the cost and timeline of deploying software. What used to take a six-figure license, a multi-quarter implementation, and procurement-committee approval now took a credit card and a thirty-minute signup. Departments stopped waiting for IT. Procurement teams stopped being consulted. By 2020, large organizations were running fifty, eighty, one hundred SaaS applications in parallel — each with its own data model, its own decision logic, its own assumptions about what the master system was responsible for and what the application was responsible for.
The discipline of the era treated this as a governance problem. Shadow IT. Procurement bypass. Master data management. Data quality. The vocabulary multiplied. The structural pattern stayed the same. The applications were producing decisions. Those decisions were being made against data the applications did not own and against guardrails the applications did not enforce. The organization was operating on the implicit assumption that the source systems were governing the decisions the SaaS apps were making. The source systems were not. The SaaS apps were producing decisions independently, against assumptions the original master systems would never have permitted, and the organization recognized the displacement only when something visible failed.
The IKEA equivalent: workshops accumulating better tools than the original instructions assumed. The builder is now confident enough to improvise. The improvisations look reasonable. Whether the finished piece has the structural properties of the original design is a question the workshop has stopped asking, because the workshop is no longer aware that there was an original design.
Era Three: The Replicated Lakehouse Era
We are in this one now. AI agents are deploying against replicated lakehouses — Snowflake, Databricks, Microsoft Fabric — that hold copies of data extracted from source systems like SAP. The data moves. The decision logic that was previously embedded in the source-system processes does not move with it. SAP’s procurement workflows have thirty years of accumulated guardrails — three-way matching, approval thresholds, vendor master data validation, segregation of duties, audit trails. Those guardrails are not data. They are decision logic. When AI agents operate against the replicated lakehouse, they do not inherit them. The guardrails have to be rebuilt, often by people who do not know the guardrails exist.
The discipline is currently treating this as an access problem (the SAP API policy debate is a marketplace-altitude argument about access), an integration problem (how do we keep the lakehouse synchronized with the source), and a governance problem (who is allowed to deploy agents against what data). All three framings are operationally legitimate. None of them name the structural problem. The structural problem is that the agent workflow is producing decisions, the organization is acting on those decisions, and nobody has validated whether the decisions hold up against the conditions the original source-system guardrails were designed to anticipate. The displacement has occurred. The organization has not yet recognized it internally.
The IKEA equivalent: workshops where the builders no longer remember which piece of furniture they were originally trying to build. Something is being assembled. It looks plausible. It holds books. Whether it is the bookshelf the original design specified, with the structural properties that design depended on, is a question the workshop has stopped asking.
The Cadence Has Compressed
The bolt-on era took roughly fifteen years to surface its structural failures, because the systems ran slowly, the data flows were limited, and the failures had time to manifest in human-recognizable forms — a chocolate-bar surplus, an order-fulfillment collapse, a financial write-off the auditors could trace. The SaaS app sprawl era surfaced its failures in three to five years, because the apps proliferated faster and the failures were less visible until something material broke. The agent era will not have those buffers. AI workflows operate at machine cadence. They propagate through context layers that scale the failure rather than contain it. Failures that took fifteen years to manifest in 1998 will manifest in fifteen weeks in 2026. The grace period is gone.
This compression is the part most current commentary about AI in the enterprise misses. The structural risk has been with us for thirty years. What changes in 2026 is not the existence of the risk. What changes is the speed at which the risk converts into consequences the organization can no longer absorb gracefully.
What the Validation Altitude Has Always Been Doing
For thirty years the discipline has had a vocabulary for everything except the actual problem. Integration management. Change control. Governance. Master data. Data quality. Shadow IT. API access. Each vocabulary is operationally legitimate. Each addresses a real concern. None of them ask the IKEA question: what was this supposed to look like, what guardrails were in the original design, which guardrails survived the move to your workshop, and which decisions are being made under conditions the original design did not anticipate or the organization has not yet recognized internally?
That set of questions is what the validation altitude is built to ask. The altitude has been missing from procurement-technology discourse for three decades because the discipline did not have an apparatus for it. It has one now. Phase 0™ surfaces the readiness conditions before the assembly begins. The Hansen Fit Score™ measures whether the assembled system’s capability has translated into outcomes the organization can defend. RAM 2025™ instruments the assembled system in flight, watching for the moment a load-bearing decision starts diverging from the original design. The Real-World Condition Substrate™ — twenty-one years of continuous procurement-technology coverage in the Procurement Insights archive — is the evidence base that makes the divergence visible across eras.
The apparatus is not new. Each component has been operating in production for years. What is new is the recognition that the apparatus has been answering the IKEA question all along, and that the IKEA question is the one the discipline has been failing to ask for three decades.
What Comes Next
The IKEA box has been opened three times. Each time, the contents have been moved to a different workshop, with different builders, different tools, different opinions about what the finished piece should be. Each time, the discipline has named the resulting failure with the vocabulary available at the time, and that vocabulary has consistently mistaken the integration layer or the governance layer or the access layer for the actual problem.
The pattern is not going to stop. There will be a fourth era. There will be a fifth. The question is no longer whether the structural failure will keep recurring. It will. The question is whether, this time, the discipline can recognize the pattern in real time rather than documenting it thirty years after the fact.
That is the work the validation altitude exists to do. The IKEA box is open. The workshop is busy. Someone has to ask whether what is being built has the structural properties the original design depended on, and whether the conditions the original design did not anticipate are already in the room.
The Pattern Is Not New
In 2008, I documented multiple SAP and ERP failures where the integration worked but the resulting decisions could not be defended when conditions shifted. Hershey. FoxMeyer. MFI. HP. Cadbury. King County. Different industries, different scales, different vendors, different consultants. Same structural failure pattern. The vocabulary of that period named the failures as integration management problems, change control problems, stakeholder buy-in problems. The vocabulary was wrong. The validation altitude was where those failures originated. The altitude had no name yet.
Eighteen years later, the product names have changed. The architectures have changed. The structural failure pattern has not. The cases I documented in 2008 read as the bolt-on era’s contribution to a recurring problem the discipline has now lived through three times. The IKEA box has been opened, closed, and re-opened. The workshop has changed. The structural question has not.
For readers who want to see the original cases as they were documented at the time, the 2008 SAP Procurement for Public Sector white paper is available here: https://www.slideshare.net/slideshow/sap-a-propensity-for-failure/5241489. The contemporary record is the foundation the current analysis rests on. The Real-World Condition Substrate™ is what makes the foundation visible across eras.
Phase 0™ · Hansen Fit Score™ (HFS™) · ARA™ · RAM 2025™ · Real-World Condition Substrate™ Hansen Models™ · Founder: Jon W. Hansen · hansenprocurement.com
-30-
Procurement Insights
Bolt-Ons. App Sprawl. Replicated Lakehouses. Same Open IKEA Box.
Posted on May 1, 2026
0
Why three decades of enterprise architecture failures look different on the surface and identical underneath — and what the discipline has been failing to name the whole time.
Anyone who has built IKEA furniture has experienced the moment where the instructions start drifting away from the parts in front of you. A dowel that does not look quite like the one in the diagram. A pre-drilled hole that seems to be in the wrong place. A wrench that does not quite turn the bolt the way the picture suggests. At small scales — a BILLY bookshelf, a side table, a lamp — the drift is recoverable. You improvise, the piece goes together, the result holds books for a decade.
The drift becomes harder to recover from at scale. A KALLAX-PAX wardrobe-and-storage combination has hundreds of decision points. Most are minor. A few are load-bearing. The probability that at least one load-bearing decision diverges from the original design is high enough to be effectively certain at sufficient complexity, even with the instructions in front of you. Which is why IKEA’s system is not just the parts. It is the parts, the instructions, and the provided tools — engineered specifically for each other. Remove any one of the three components and the system stops being self-coherent. You can technically still assemble something. Whether what you assemble has the structural properties the original design depended on is a different question.
I have been thinking about IKEA recently because of how often the procurement-technology discipline has reproduced the structural failure of an IKEA assembly with the parts moved out of the box and into the wrong workshop. It has happened three times in the last thirty years. It is happening again right now. Each iteration looks different on the surface. Each iteration is structurally identical underneath.
Era One: The Bolt-On Era
Through the late 1990s and 2000s, large organizations bought core ERP systems — SAP R/3, PeopleSoft, Oracle Financials — that did not quite fit their actual operations. Vendors and integrators responded by selling bolt-on modules to close the gaps. Best-of-breed procurement add-ons. Spend analytics tools. Third-party contract management. Supplier portals layered on top of the core. Each bolt-on solved a real problem. Each one extended the surface area of what the organization had to manage, validate, and reconcile against the master system.
The discipline of the era treated bolt-ons as an integration problem. Get the data flowing. Get the interfaces stable. Get the workflows synchronized. Once integration was achieved, the system was assumed to be working. What the discipline did not ask — because the discipline did not yet have a name for the question — was whether the integrated system was producing decisions that held up under conditions the organization had not yet experienced or recognized internally.
The 2008 CATA Alliance white paper I authored on SAP Procurement for Public Sector documented this directly. The Hershey, FoxMeyer, MFI, HP, Cadbury, and King County cases were not failures of integration. The integrations worked. The data flowed. The interfaces ran. What failed was that the integrated systems collectively produced decisions the organizations could not defend when conditions shifted — the chocolate-bar overproduction at Cadbury, the order-fulfillment collapse at Hershey, the £12 million write-off, the $38 million King County maelstrom. The validation altitude was where those failures originated. The altitude had no name. The failures were attributed to integration management, change control, or stakeholder buy-in.
The IKEA equivalent: buying parts from a different store and assuming they fit because they look similar to what was in the box.
Era Two: The SaaS App Sprawl
By the mid-2010s, SaaS had collapsed the cost and timeline of deploying software. What used to take a six-figure license, a multi-quarter implementation, and procurement-committee approval now took a credit card and a thirty-minute signup. Departments stopped waiting for IT. Procurement teams stopped being consulted. By 2020, large organizations were running fifty, eighty, one hundred SaaS applications in parallel — each with its own data model, its own decision logic, its own assumptions about what the master system was responsible for and what the application was responsible for.
The discipline of the era treated this as a governance problem. Shadow IT. Procurement bypass. Master data management. Data quality. The vocabulary multiplied. The structural pattern stayed the same. The applications were producing decisions. Those decisions were being made against data the applications did not own and against guardrails the applications did not enforce. The organization was operating on the implicit assumption that the source systems were governing the decisions the SaaS apps were making. The source systems were not. The SaaS apps were producing decisions independently, against assumptions the original master systems would never have permitted, and the organization recognized the displacement only when something visible failed.
The IKEA equivalent: workshops accumulating better tools than the original instructions assumed. The builder is now confident enough to improvise. The improvisations look reasonable. Whether the finished piece has the structural properties of the original design is a question the workshop has stopped asking, because the workshop is no longer aware that there was an original design.
Era Three: The Replicated Lakehouse Era
We are in this one now. AI agents are deploying against replicated lakehouses — Snowflake, Databricks, Microsoft Fabric — that hold copies of data extracted from source systems like SAP. The data moves. The decision logic that was previously embedded in the source-system processes does not move with it. SAP’s procurement workflows have thirty years of accumulated guardrails — three-way matching, approval thresholds, vendor master data validation, segregation of duties, audit trails. Those guardrails are not data. They are decision logic. When AI agents operate against the replicated lakehouse, they do not inherit them. The guardrails have to be rebuilt, often by people who do not know the guardrails exist.
The discipline is currently treating this as an access problem (the SAP API policy debate is a marketplace-altitude argument about access), an integration problem (how do we keep the lakehouse synchronized with the source), and a governance problem (who is allowed to deploy agents against what data). All three framings are operationally legitimate. None of them name the structural problem. The structural problem is that the agent workflow is producing decisions, the organization is acting on those decisions, and nobody has validated whether the decisions hold up against the conditions the original source-system guardrails were designed to anticipate. The displacement has occurred. The organization has not yet recognized it internally.
The IKEA equivalent: workshops where the builders no longer remember which piece of furniture they were originally trying to build. Something is being assembled. It looks plausible. It holds books. Whether it is the bookshelf the original design specified, with the structural properties that design depended on, is a question the workshop has stopped asking.
The Cadence Has Compressed
The bolt-on era took roughly fifteen years to surface its structural failures, because the systems ran slowly, the data flows were limited, and the failures had time to manifest in human-recognizable forms — a chocolate-bar surplus, an order-fulfillment collapse, a financial write-off the auditors could trace. The SaaS app sprawl era surfaced its failures in three to five years, because the apps proliferated faster and the failures were less visible until something material broke. The agent era will not have those buffers. AI workflows operate at machine cadence. They propagate through context layers that scale the failure rather than contain it. Failures that took fifteen years to manifest in 1998 will manifest in fifteen weeks in 2026. The grace period is gone.
This compression is the part most current commentary about AI in the enterprise misses. The structural risk has been with us for thirty years. What changes in 2026 is not the existence of the risk. What changes is the speed at which the risk converts into consequences the organization can no longer absorb gracefully.
What the Validation Altitude Has Always Been Doing
For thirty years the discipline has had a vocabulary for everything except the actual problem. Integration management. Change control. Governance. Master data. Data quality. Shadow IT. API access. Each vocabulary is operationally legitimate. Each addresses a real concern. None of them ask the IKEA question: what was this supposed to look like, what guardrails were in the original design, which guardrails survived the move to your workshop, and which decisions are being made under conditions the original design did not anticipate or the organization has not yet recognized internally?
That set of questions is what the validation altitude is built to ask. The altitude has been missing from procurement-technology discourse for three decades because the discipline did not have an apparatus for it. It has one now. Phase 0™ surfaces the readiness conditions before the assembly begins. The Hansen Fit Score™ measures whether the assembled system’s capability has translated into outcomes the organization can defend. RAM 2025™ instruments the assembled system in flight, watching for the moment a load-bearing decision starts diverging from the original design. The Real-World Condition Substrate™ — twenty-one years of continuous procurement-technology coverage in the Procurement Insights archive — is the evidence base that makes the divergence visible across eras.
The apparatus is not new. Each component has been operating in production for years. What is new is the recognition that the apparatus has been answering the IKEA question all along, and that the IKEA question is the one the discipline has been failing to ask for three decades.
What Comes Next
The IKEA box has been opened three times. Each time, the contents have been moved to a different workshop, with different builders, different tools, different opinions about what the finished piece should be. Each time, the discipline has named the resulting failure with the vocabulary available at the time, and that vocabulary has consistently mistaken the integration layer or the governance layer or the access layer for the actual problem.
The pattern is not going to stop. There will be a fourth era. There will be a fifth. The question is no longer whether the structural failure will keep recurring. It will. The question is whether, this time, the discipline can recognize the pattern in real time rather than documenting it thirty years after the fact.
That is the work the validation altitude exists to do. The IKEA box is open. The workshop is busy. Someone has to ask whether what is being built has the structural properties the original design depended on, and whether the conditions the original design did not anticipate are already in the room.
The Pattern Is Not New
In 2008, I documented multiple SAP and ERP failures where the integration worked but the resulting decisions could not be defended when conditions shifted. Hershey. FoxMeyer. MFI. HP. Cadbury. King County. Different industries, different scales, different vendors, different consultants. Same structural failure pattern. The vocabulary of that period named the failures as integration management problems, change control problems, stakeholder buy-in problems. The vocabulary was wrong. The validation altitude was where those failures originated. The altitude had no name yet.
Eighteen years later, the product names have changed. The architectures have changed. The structural failure pattern has not. The cases I documented in 2008 read as the bolt-on era’s contribution to a recurring problem the discipline has now lived through three times. The IKEA box has been opened, closed, and re-opened. The workshop has changed. The structural question has not.
For readers who want to see the original cases as they were documented at the time, the 2008 SAP Procurement for Public Sector white paper is available here: https://www.slideshare.net/slideshow/sap-a-propensity-for-failure/5241489. The contemporary record is the foundation the current analysis rests on. The Real-World Condition Substrate™ is what makes the foundation visible across eras.
Phase 0™ · Hansen Fit Score™ (HFS™) · ARA™ · RAM 2025™ · Real-World Condition Substrate™ Hansen Models™ · Founder: Jon W. Hansen · hansenprocurement.com
-30-
Share this:
Related