A presentation making rounds in the PLM community right now opens with a question that every analyst, vendor, and enterprise architect has been asking for the better part of two decades: who can replace the Big 3 PLM vendors?
Doug Macdonald, a veteran PLM consultant, frames the question with a memorable image. He asks whether PLM is “The Great and Powerful Oz, controlling the entire product lifecycle” or “the Man Behind the Curtain, looking after MCAD files.” His answer, after 21 slides of careful argument, is mostly the second one. Despite decades of investment and remarkable marketing ambition, PLM systems today are not meaningfully different from the PDM systems of the 1990s. They manage files, BOMs, and release processes. Everything else — requirements, manufacturing planning, procurement context, engineering discussions, supplier negotiations, cost decisions — leaks into spreadsheets, Slack threads, email chains, and the heads of experienced engineers who eventually leave.
His data point is arresting: the Big 3 MCAD vendors have spent the last 20 years focused on rebranding, rehosting, and re-monetizing. Product complexity has grown exponentially, from purely mechanical assemblies in the 1980s to today’s products that combine mechanical, electrical, embedded software, and firmware components. PLM’s ability to manage that complexity has barely moved. The gap between what products have become and what PLM can actually handle has never been wider.
I agree with most of Macdonald’s diagnosis. But I want to argue that his central question — who replaces the Big 3 — may be the wrong frame entirely. Not because the Big 3 are fine. They are not. The problem is that “replacement” assumes the future will look structurally like the past: one big application category, a handful of dominant vendors, and a competition for the single source of truth about the product lifecycle. I don’t think the AI transformation points in that direction.
The future looks more like a puzzle. And the most interesting question is not who holds the biggest piece.
The short answer to who replaces PLM is: probably nothing, in the traditional sense. The more interesting answer is that AI is assembling a new architecture around PLM — intelligence layers, orchestration platforms, engineering AI operators, and collaborative context workspaces — that will shift where product work actually happens without necessarily displacing the systems of record underneath. This post-PLM architecture is not a single product category. It is a product context layer forming across the enterprise, piece by piece, and the competition to build it is already underway.
Why the PLM Replacement Question Made Sense — Until Now
The replacement question was always about control over product records. Teamcenter, Windchill, and 3DEXPERIENCE became dominant not only because they were technically superior to what came before, but because they sat at the center of gravity for engineering data. CAD files, item masters, BOMs, revisions, configurations, engineering changes, approvals — whoever controlled these records controlled the architecture. Every integration, every downstream system, every workflow had to eventually connect back to this center.
Challengers tried to break this monopoly. Arena pushed early SaaS and cloud architecture. Aras built a powerful open-source enterprise strategy. Propel brought PLM concepts into the Salesforce platform. Each carved out real customer bases. None fundamentally restructured the market.
The reason is that the Big 3 incumbency is not simply a software product. It is a system of gravity. CAD tools tie to their sibling PDM systems. Enterprise contracts, implementation ecosystems, customization layers, and decades of organizational habit make switching costs enormous. You cannot replace the Big 3 the way you replace a SaaS billing tool. You are replacing the accumulated product memory of an entire organization.
But now AI has changed the competitive question in a way that previous challengers could not.
How AI Changes the PLM Competitive Landscape
The conventional PLM premise is that you need one authoritative system to trust your product data. The digital thread idea extended this: connect everything back to a single governed record, and you have a defensible foundation for downstream decisions.
The problem is that this ideal was never real. As Macdonald notes, companies filling the gaps with spreadsheets, Slack, and email is not a failure of discipline. It is a symptom of a structural mismatch. PLM manages formal records. Work happens in informal context. And the informal context — why this part was changed, which supplier was originally considered, what the manufacturing team complained about, which requirement was actually driving the decision — is precisely what gets lost.
AI agents expose this problem in a new way. A well-designed agent does not just need to know the released BOM. It needs to understand the situation around the BOM: what is changing, why it is changing, what the downstream effects are, and what has been tried before. That kind of reasoning requires not just data records but working context.
This is where Nate Jones’ analysis of the AI infrastructure wars becomes directly relevant to PLM. His key observation about the Codex vs. Claude competition is that the two approaches represent two fundamentally different theories about how agents reach enterprise software. One path runs through structured integrations — APIs, MCP servers, webhooks, connectors — which requires the ecosystem to cooperate and vendors to build for agents. The other path runs through computer use — agents operating the same graphical interfaces that humans operate — which requires no vendor cooperation at all.
The PLM implication is significant. An enormous share of real engineering and manufacturing work happens in software that has no clean API: legacy ERP screens, supplier portals, custom internal dashboards, Excel-based planning tools, PDF quote packages, procurement systems built in 2009 and never touched since. Under the old integration model, all of that software was effectively outside the automation boundary. Under the computer-use model, it comes back inside, through a door that does not require anyone’s permission.
What this tells us about post-PLM architecture is that the question is no longer which application owns the product record. The question is which platform can build and maintain the product context layer that agents need to act intelligently across all of these systems — formal and informal, clean and messy, API-enabled and GUI-only.
That is a very different competition.
What Siemens Intelligence Center X Tells Us About the Future of PLM
Before describing the new puzzle, it is worth acknowledging what Siemens showed at Realize Live this week, because it complicates any narrative that frames the Big 3 as static.
Siemens announced Intelligence Center X, a new addition to its Xcelerator portfolio that brings together enterprise data with industrial ontologies and the company’s knowledge graph capabilities in a governed environment. The components include Graph Studio and AI Studio (both based on Altair Rapidminer technology), Mendix repositioned as a platform for agentic development and orchestration, and a set of industrial ontologies. The explicit goal is to enable AI to work confidently on industrial data — not as a feature layered onto Teamcenter, but as a dedicated intelligence layer sitting above the application portfolio.
Tony Hemmelgarn, CEO of Siemens Digital Industries Software, framed the problem with a wildfire analogy: conditions change without warning, and yesterday’s data becomes dangerous. The implication is direct. A PLM system that manages static records is insufficient. What enterprises need is a real-time, connected picture of engineering, manufacturing, and supply chain — with AI that can act on that picture.
This is the incumbent move. Siemens is not waiting for someone to build a better PLM system. Siemens is building an intelligence layer above its existing application portfolio, using the installed base, the industrial domain knowledge, and the enterprise relationships it already has.
It is a smart bet. It is also a bet with a real tension inside it. A portfolio-centric intelligence layer built on Teamcenter relationships and Siemens ontologies is powerful for Siemens customers. It is less obvious how it serves enterprises running heterogeneous environments — PTC Windchill alongside Oracle ERP, Altium Designer, custom ALM tools, and a supplier portal nobody built an API for. Governing context across a diverse ecosystem is a different challenge than governing it within a single vendor’s portfolio.
Big-3 are moving. Here is the DS strategy presented a few months ago at the NVIDIA GTC conference by Florence Hu, Executive Vice President of R&D. Here is the How Virtual Twins are Shaping the Next Industrial Revolution.
At PTC Next in Chicago next week we will see the future of PTC. Stay tuned.
That tension is where the new puzzle pieces become interesting.
The New Post-PLM Puzzle: Five Emerging Architecture Layers
What I see forming in the market is not a replacement race. It is a set of emerging architectural layers assembling around the existing systems of record. Let me describe the pieces as I currently understand them.
The first layer is the one everyone recognizes: systems of record. Teamcenter, Windchill, 3DEXPERIENCE, SAP, Oracle, MES, QMS, ALM. These systems remain essential. They manage formal truth — released configurations, approved changes, controlled revisions, lifecycle states, compliance records. Nothing in the new architecture eliminates the need for governed records. What changes is the assumption that the system of record is also the system of context.
The second layer is what I would call the orchestration and ontology layer. This is where Violet Labs fits most cleanly. The Violet architecture, as Macdonald presents it, is built around four elements: an ontology that makes AI functionality performant and accurate; a context layer providing universal connectivity across disparate systems with relationships and version history preserved; a workflow engine for configurable data orchestration with auditability; and an AI-native interface that exposes structured, cohesive data via MCP for agent-ready orchestration. The value proposition is not replacing the systems underneath. It is connecting them through a shared semantic model, so that data from CAD, PLM, ERP, ALM, and procurement can be understood together rather than separately. This is the pattern that makes AI useful across a heterogeneous enterprise: normalize the data, preserve the relationships, make the context available.
The third layer is engineering AI operators. CoLab Operator AI (just announced earlier this week) is the clearest example here. Rather than starting from data architecture, CoLab starts from the engineering workflow — design reviews, CAD analysis, drawing interrogation, cross-disciplinary search — and builds an AI-native interface that lets engineers talk to that knowledge. CoLab describes its Operator as connecting product data, AI agents, and an interface that can trigger workflows across major PLM systems including Windchill, Teamcenter, and 3DEXPERIENCE. This is not a replacement for PLM. It is an interface that makes PLM data more usable for the people doing actual engineering work. The control point it competes for is not the database. It is where engineers actually spend their attention.
The fourth layer is what I would call the Collaborative Context Workspace, and it is the one that almost every discussion of enterprise AI architecture skips over. The Collaborative Context Workspace is the layer in post-PLM architecture where human collaboration and AI context meet and to name it honestly you have to start with spreadsheets.
Walk into any engineering or manufacturing company, from a ten-person hardware startup to a ten-thousand-person industrial manufacturer, and you will find the same thing. The formal systems (PLM, ERP, CAD, QMS) hold the official records. Everything else lives in spreadsheets. Supplier comparison matrices. BOM cost rollups built by hand. Change impact assessments copied out of PLM and annotated in Excel. Procurement tracking sheets maintained by one person who knows which columns matter. Configuration options explored in a tab nobody else can interpret. Engineering assumptions documented in a cell comment that will be invisible in six months.
This is not a failure of process discipline. It is a rational response to a structural gap. Spreadsheets are flexible, shareable, immediate, and human-readable. They let people work with product information in ways that formal systems do not support: comparing alternatives, annotating decisions, combining data from multiple sources, exploring scenarios before committing to a change. The spreadsheet is where working knowledge lives because no enterprise system was ever designed to hold it.
AI makes this gap consequential in a new way. An agent that can read a released BOM from PLM but cannot see the supplier comparison that drove the sourcing decision, or the cost scenario that was rejected last quarter, or the manufacturing constraint that the team discussed in a spreadsheet three months ago, is an agent operating with partial context. It can process records. It cannot reason about the situation. The spreadsheet layer is exactly what falls outside the automation boundary — not because agents cannot read Excel files, but because the knowledge in those files has no structure, no relationships, no connection to the systems it refers to.
The Collaborative Context Workspace is the architectural response to this gap. It is not a replacement for spreadsheets and it is not a replacement for PLM. It is the layer where human collaboration and AI context intersect — where product information can be worked on, compared, annotated, and decided before it becomes a formal record, and where that working knowledge is structured enough for agents to reason across it. The defining characteristic is not the interface. It is the combination: people can collaborate with the flexibility they need, and agents can access the context they need, in the same place at the same time.
Spreadsheets solved the human side of the problem and left the AI side dark. Traditional PLM solved the governance side and left the working side rigid. The OpenBOM Collaborative Context Workspace sits at the intersection, and the companies that build it well will determine where AI can actually be useful in the daily reality of product development — not in the clean pathways the architecture diagrams show, but in the messy middle where most of the real decisions get made.
OpenBOM is one example of this pattern. The more important point is that this layer is not yet occupied by a clear category leader, and the companies building here are not competing with PLM on PLM’s terms. They are building the infrastructure for a kind of enterprise intelligence that the current generation of systems was never designed to support.
The fifth layer, cutting across all the others, is agents and automation. Agents need all the previous layers to be useful. An agent with access to a good context layer can answer why a part changed, not just whether it changed. An agent with access to an engineering operator layer can analyze a design review and flag issues without being told which systems to consult. An agent with computer-use capability can reach the supplier portal or the legacy ERP screen that nobody built an MCP server for. The agent layer is not a product category in itself. It is the reason the other layers matter.
What Is Product Memory and Why Does It Matter for AI in PLM
There is a concept that I think ties all of these pieces together, and I have been calling it Product Memory. It is not a better PLM database. It is not a knowledge graph bolted onto a file vault. It is the connected, continuously updated layer of product knowledge that explains not just what the product is, but how and why it got there.
Product Memory expands the horizons of system of records and capture things that current PLM systems cannot: the reasoning behind an engineering change, not just the approval date; the supplier that was evaluated and rejected, not just the one that won the PO; the manufacturing constraint that drove a redesign, not just the new version of the part; the cost scenario that was discussed and abandoned, not just the BOM that was released. It connects formal records with the working context that surrounds them.
This concept is what the new architectural layers are all converging on, from different directions. Siemens Intelligence Center X is trying to build it within the context of a governed industrial intelligence platform. Violet Labs is trying to build it through ontology and universal connectivity. CoLab is trying to surface it through an AI engineering operator. OpenBOM is trying to provide it through a collaborative product context workspace.
None of these is Product Memory in the complete sense. Each is a piece of it. The puzzle is still being assembled.
The Real PLM Competition in 2026: Context Layers, Not Replacement
I want to return to Macdonald’s diagnosis, because his strongest argument is not about replacement. It is about the cost of staying with legacy architecture. He calculates tens of thousands of hours lost daily to searching for and recreating information that should be findable. He identifies poor collaboration across technical disciplines as a direct drag on development time. He argues that broken downstream communications raise costs and delay product launches. And he adds a line that I think is the most strategically important of all: the realization that legacy PLM is not the place to start deploying AI.
That last point is where I think the real competitive shift happens. If AI agents require context to be genuinely useful, and if legacy PLM cannot provide that context, then the companies that build the product context layer are not competing with PLM on PLM’s terms. They are building the infrastructure that determines where AI can actually work.
The Big 3 won the system-of-record era. The competition for the system-of-context era is just beginning.
And the answer to who wins may not be any single vendor. Macdonald’s slide 19 shows Violet Labs integrating across requirements, CAD/PDM, PLM, test and simulation, dev tools, purchasing, and MES/ERP — a vast ecosystem of specialized systems that will not be replaced by a single platform on any realistic timeline. What that ecosystem needs is not a new center of gravity. It needs a set of layers that make all its pieces coherent and AI-accessible.
That is the puzzle. The companies building pieces of it — the orchestrators, the operators, the context workspaces, the intelligence platforms, and yes, the legacy systems of record that still hold the formal truth — are not competitors in a zero-sum replacement race. They are pieces of an architecture that nobody has fully assembled yet.
The question that matters now is not who replaces the Big 3. The question is who can connect what the Big 3 manage to all the context they cannot.
Conclusion: Replacement or Recomposition?
Macdonald opens his presentation by telling his audience they have a choice at the end: throw their PLM plans out the window and start over, or doom their company to a continuing struggle with broken processes built around legacy technology.
I want to suggest a third option.
The future of PLM is not replacement and it is not complacency. It is a recomposition. The systems of record remain important. The new intelligence layers, orchestrators, operators, and context workspaces build on top of and around them. Product Memory becomes the connective tissue that makes the whole architecture useful for AI.
This recomposition is already happening. Siemens announced it this week at Realize Live. Violet Labs is building it. CoLab is building it from the engineering interface direction. Dozens of other companies on Macdonald’s ecosystem slide are building pieces of it.
The post-PLM puzzle is not a riddle with one answer. It is a market architecture in the process of being assembled. And for manufacturing companies trying to figure out where to invest, the strategic question is not which vendor will eventually win. It is which layers are missing in your own organization right now — and which ones, if connected, would let your people and your agents finally answer the questions that have been hiding in spreadsheets and email for the last twenty-five years.
Just my thoughts…
Best, Oleg
Oleg Shilovitsky is CEO and co-founder of OpenBOM and author of the Beyond PLM blog, where he has written about PLM strategy, architecture, and the future of product data management since 2007.
