“PLM is dead” — I hear that again and again. True, maybe. And not true at all. It depends on what you mean by PLM. From a certain perspective, the statement can make sense. Not from mine, mind you. Because I think PLM is more alive than ever. And I’m happy to explain why.
PLM software or PLM discipline? The crucial difference
Let’s start with the question of what PLM actually wants to be.
Reading one
PLM means the big suites — Teamcenter, Windchill, ENOVIA. Monolithic systems that promise to cover the entire product lifecycle. Spoiler: for this reading, the statement “PLM is dead” - maybe - has some merit. Not necessarily, but defensible.
Reading two
PLM is the discipline that encompasses everything that belongs to the product lifecycle. Configuration management, change management, traceability, system integration across the entire lifecycle. For this reading, PLM is anything but dying. It is only now unfolding into what it always wanted to be.
My view of PLM has always been the second reading. To me, it describes what PLM actually means — and if that sounds too idiosyncratic: Gartner defines PLM as “philosophy, process and discipline supported by software”. Discipline first, software as an aid. Even so, many people see PLM more as a product category for suites in the engineering context.
What dies: the monolithic PLM suites
Whether these well-known, often monolithic PLM suites will remain the dominant model is, however, more uncertain today than ever. The direction things are heading is clear, even if the process is slow. Three thoughts on that:
First: The belief that one system can cover everything doesn’t hold up in many cases. Legacy PLM vendors grew through acquisitions, not (only) through architectural innovation. The result, as PLM analyst Oleg Shilovitsky (who, admittedly, sells a decentralized PLM approach himself) describes it, is “conglomerates of tools held together by integrations — sometimes with incompatible data models”. Anyone who has learned this the hard way will nod. Anyone who hasn’t will learn it.
Second: The make-or-buy pendulum is swinging toward make — and AI is accelerating it. Not because developers now code ten times faster. But because clearly bounded PLM edge domains — release platforms, change management workflows, specific traceability solutions — can suddenly realistically be built in-house. What used to fail because of effort and maintenance risk can now be done with much smaller teams. This may not (yet) hold for an entire PLM landscape. But where monolithic solutions are oversized and still generate license costs every year, the calculation shifts.
Flashback to a project I was involved in myself a few years ago: A customer wanted to build its own software release platform. Everything developed in-house. I was skeptical at the time and recommended a review of which off-the-shelf solutions were available. AI-assisted coding, which makes such undertakings far more affordable today, didn’t exist yet. The customer had made up its mind, and given its size it was feasible, if expensive, not to take off-the-shelf software. Perhaps too expensive. Fast forward: with today’s possibilities, my assessment would very likely look different, which doesn’t mean I would rule out “off the shelf” today. But the trends are changing.
Third: PLM as a document archive is a thing of the past — the ambitions were really always bigger. That PLM has to be more than a glorified document archive is by now consensus. But consensus is far from operationalized, and in operational reality action lags behind insight. Yet what a modern PLM system should actually deliver doesn’t sound all that lofty: a structured product data model that represents parts, variants, dependencies and change histories in machine-readable form. End-to-end traceability from requirement through code and CAD to the finished product in the field. Integration of all relevant processes from after sales all the way to the drawing archive.
Only: a tool that is good for everything is not really good for anyone. That is true of Swiss army knives, and it is true of monolithic PLM suites. The data model is generic because it has to be. Full integration doesn’t exist, because there are always other system worlds in the company too (keyword: ERP). And: anyone who wants to build a truly deep, domain-specific product data model — one that precisely represents their own parts, variants and processes — faces customization effort in the monolith that can potentially eat up any added value. Specialized tools built on open standards avoid this problem, at least in part, because they are designed for interoperability from the start, not for completeness.
What doesn’t die: PLM as a discipline — because the need is growing
The fact is: products are becoming more complex. System boundaries between mechanics, electronics and software are blurring.
Take automotive: OEMs lose an estimated $500 million to $1 billion per year to physical recalls that would technically be possible as OTA updates (eSync Alliance, 2023; ABI Research, 2023). That OTA updates are still not as widespread as they could be on purely technical grounds is also down to the complexity of the products. A car is no longer a simple machine like in the past, one that can be repaired in any desert workshop if need be. For an OTA update to work, and I speak from experience, you need a well-oiled machinery that keeps the full overview of all products in the field, their configuration, their software status and all dependencies.
That is why configuration management, change management, traceability across the entire lifecycle… the need to professionalize these disciplines is anything but shrinking. On the contrary, it is becoming more demanding.
Of course, if you say “PLM is dead” and still have a PLM project in your bones that failed to deliver, I can understand you. But then you may have mistaken the symptom for the disease. The tool stumbled, but the discipline, the end-to-end approach and the mindset behind it may never have been truly lived, and perhaps not even understood.
A sentence attributed to PLM veteran Rob Ferrone says more than ten slide decks: “My first five years I didn’t even know we were doing PDM or PLM — but we were.”. If the reverse also holds — if companies buy the software but never implement the discipline — then the frustration is understandable. But it targets the way PLM was introduced, not the discipline itself.
Only 13% say they couldn’t work without PLM
One more number that makes you sit up: Only 13% of companies that use PLM say they couldn’t work without it. Whether it’s 10, 13 or 20% hardly matters. The real message lies in the flip side: most companies believe they could do without PLM. No. They can’t. Every company that develops and produces products practices PLM — in one form or another. The only question is whether it understands what it is doing…
The real challenge: missing architecture and inadequate organization
The Digital Thread — the end-to-end, bidirectional data trail from requirement to operation — is the vision that has always been closely tied to the PLM concept. “Single source of truth,” traceability from requirement to the field: vendors promised this back in the 2000s. Unfortunately, it was all too often not delivered, for a wide variety of reasons:
What it fails on is, surprisingly rarely, the software. It is what is missing around the software: information and data structures. Ontologies. An organization that is ready to take a serious look at its processes. In short: architecture. And that doesn’t come about by itself — whether you buy or build.
Those who buy are buying a prefab house. And anyone buying a prefab house must be prepared to accept predefined floor plans. Even if that means letting go of cherished habits and getting used to new ways of working. That doesn’t happen by itself, of course. It is work. And this is exactly the work people like to shy away from — one’s own existing processes are often something like the holy grail, and past success may even prove you right. Only: those who then bend the standard software instead of adapting bring the customization effort into the house, which can eat up any added value. The failure is then not a software problem. It is a homework problem.
Those who build don’t have the floor-plan problem — but they have a different one. PLM tools that still lack this or that wish-list feature, plus the new availability of AI-assisted software development: that quickly tempts you into deciding to build something of your own. Whether completely “from scratch” or as a very individual linking of various tools. You can do that, see above — the calculation has indeed shifted. But: an end-to-end Digital Thread landscape needs an architecture all the more. Anyone who just starts building ends up with a tool landscape that somehow works at first, becomes barely maintainable after a short time — and eventually blows up in your face. Excel IT sends its regards.
Ergo: investing in organization and information architecture is not an option but the price of admission. On both paths. Those who have understood this — and only they — will find the make option interesting: because if the architecture work has to be done anyway, the monolith’s lead is smaller than its price tag suggests. A decentralized solution approach away from the established suites is then, today more than ever, at least worth considering. It could pay off.
But back to the original question. Is PLM dead?
❤️ PLM lives
If PLM means the discipline (and I stand by that), the answer is clear: PLM is more alive than ever. The requirements are not getting smaller. The products are not getting simpler. And the cost of neglecting this discipline is growing.
Will the big PLM monoliths pass away? I don’t know, and I refrain from prophecies. The arguments in favor are at least plausible. But PLM vendors aren’t stupid either — they see the changes we all see. More open architectures, more modular offerings, SaaS — that’s already coming, and stronger at some vendors than at others. The market will decide whether it takes hold.
Long live PLM 😉🖖
Frequently asked questions
Is PLM dead or not?
It depends on the reading. As a monolithic suite (Teamcenter, Windchill, ENOVIA), the statement is at least worth discussing. As a discipline — configuration management, change management, traceability, etc. — it is simply wrong. This discipline is becoming more important, not redundant.
What is the difference between PLM software and PLM as a discipline?
The software is the tool, the discipline is the purpose behind it. Gartner defines PLM as “philosophy, process and discipline supported by software” — discipline first, tool second. A failed PLM project therefore doesn’t mean the discipline has failed, but often only that it was never truly practiced.
Is building your own PLM (make) now more worthwhile than buying a PLM suite (buy)?
The calculation is shifting, because AI-assisted development makes clearly bounded PLM edge domains realistically buildable in-house. For an entire PLM landscape, that mostly doesn’t hold (yet). And: make doesn’t spare you the architecture work either — anyone who just starts building ends up with a tool landscape that quickly becomes unmaintainable.
What is the Digital Thread, and why does it matter?
The end-to-end, bidirectional data trail from requirement through CAD and code to the field — the vision PLM has promised since the 2000s. It often isn’t delivered because the architecture behind it is missing, not because the software couldn’t do it.