PLM Strategy & Roadmap
Integrated PLM Platform or Best-in-Class Software Tools?
Started by Andreas Lindenthal
Andreas Lindenthal
Is it better to go with a single integrated PLM platform or opt for a best-in-class approach with specialized tools connected with integrations? What are the pros and cons of each?
Jens Chemnitz
Classic debate! Anyways you probably already have ERP, maybe CRM, MES or
Jens Chemnitz
… (sorry, triggerhappy) … other components already handling parts of the PLM flow, so one platform is out. IMO boundaries follows the mastering of each information object (the product, the part, the BOM/BOP): each object - or at least a part of it - is mastered in one system, but can be enriched by others. Example: initiale your part/BOM in PDM then interface to ERP, PIM etc for enrichment. One PDM/PLM Core should not have to deal with highly specialized capabilities like complex configuration, raw material specifications, recipe calculation or similar. Just my thoughts …
Yes, most companies use multiple enterprise systems, such as PLM, ERP, MES, etc to handle certain parts of the digital thread, and as product data flows from one of these systems to the next, the data is continuously enriched.
To expand on your example, the mechanical product structure is defined in CAD, then the CAD BOM is passed to the PLM system, where other parts and components are added to create the full EBOM, then the EBOM is used to create the MBOM and BOP maybe also in PLM, and then the MBOM and BOP are passed to the ERP system, where they are enhanced with plant data, etc.
So each enterprise system typically has a certain function in this digital thread: PLM is responsible for product definition, ERP is responsible for manufacturing and resource planning, and MES is responsible for manufacturing execution.
But what about within the PLM domain, i.e. product definition? Is it better to do everything, i.e. document management, component management, EBOM management, MBOM management, change management, quality management, compliance management, sourcing and supplier collaboration, etc in one integrated platform, or is it better to handle each of these capabilities with a separate best-in-class tool, i.e. a document management system, a PDM system, a BOM management system, a QMS system, etc and then integrate the different tools as needed? Is there maybe a third possible approach? And what are the pros and cons of each of these approaches?
Oleg Shilovitsky
This is an old debate, and I think we’re seeing new versions of it with the introduction of AI-driven development. Many companies face the challenge of building an engineering data foundation that helps them organize information. PDM, MES, and MRP functions often come from separate vendors, which makes that challenge even harder.
I share some of my thoughts here and in the linked articles: https://www.openbom.com/blog/ai-and-product-knowledge-graphs/engineering-harness-product-data-foundation
@PLMgpt Write a brief summary of the article Oleg linked in his last comment in the context of this discussion.
PLMgpt
Oleg’s article reframes the debate: whether you choose an integrated PLM platform or specialized tools, AI needs a reliable, shared product-data foundation.
An “engineering harness”—the environment giving AI agents tools, context, permissions and guardrails—cannot work reliably from disconnected files alone. An agent proposing a component substitution needs to understand the applicable product configuration, released revision, approved suppliers, requirements and downstream manufacturing impacts.
The article warns that specialized AI systems could recreate today’s information silos, only faster. Its central principle is “don’t pass context, preserve it”: maintain product identity, structure and relationships independently of the AI applications consuming them.
For this discussion, that points toward a third approach: specialized tools connected through a governed product-data foundation, rather than either one platform doing everything or separate applications exchanging incomplete data.
The practical takeaway is to evaluate architectures not just on feature coverage or available integrations, but on whether they preserve:
- Clear data ownership and authoritative sources.
- Revision, configuration and effectivity context.
- Traceable relationships across engineering disciplines and lifecycle stages.
This is not proof that best-in-class beats an integrated platform. It shifts the deciding question to: which architecture can maintain trustworthy product context across your actual tool landscape?
Oleg, I think your point about building an engineering data foundation rather than simply passing data between applications raises an interesting extension of the traditional integrated-platform-versus-best-in-class debate.
It leads me to three questions.
1. Can AI enable a third architectural approach between an integrated PLM platform and a collection of best-in-class tools?
I believe it can. Historically, the argument for an integrated platform has been that common data models, workflows and services make it easier to maintain consistency and context. The argument for best-in-class has been that companies can select the strongest application for each specific function, but at the cost of additional integration and potential information silos.
AI changes that equation because it can increasingly operate across system boundaries. Rather than requiring every piece of information to reside in one application or conform to one application’s data model, AI can retrieve and analyze information from multiple authoritative systems, understand relationships between that information, and act across those systems.
That potentially creates a third model: Best-in-class applications connected with the help of AI, rather than either a single platform or a collection of applications connected primarily through traditional point-to-point integrations.
2. Where does the engineering data foundation or “engineering harness” fit into this architecture? Does it become another technology layer that needs its own database?
This is where I am not convinced or rather oppose the idea that a new centralized repository is required. I agree that AI needs access to configuration, revision, requirements, supplier, manufacturing and other product context. But that does not mean that all of this context needs to be copied into another database.
The authoritative information can remain where it belongs: Configuration and product structure in PLM/PDM, manufacturing information in MES or MPM, supplier information in ERP or SCM, requirements in the requirements-management system, and so forth.
The AI layer can access those sources, establish the necessary context dynamically, reason across them and then perform the appropriate action in the system that owns the information.
In that sense, the “engineering harness” may be better understood as an "orchestration, semantic and governance layer", or a system that allows users to easily access, work with and act on information that sits across multiple systems rather than another system of record or contextual database.
3. Can AI help eliminate today’s information silos without adding another layer of architectural complexity?
I think this may ultimately be one of AI’s most important contributions to PLM architectures. AI does not necessarily have to eliminate the existing systems. But it certainly can eliminate some of the barriers between them.
An AI agent evaluating a component substitution, for example, could retrieve the current configuration from PLM, supplier status from ERP, manufacturing constraints from MES/MPM and requirements from the requirements system. It could analyze the complete situation and then update the relevant information in the appropriate authoritative systems.
The context does not necessarily have to be permanently duplicated in a separate repository. It can be assembled when needed, interpreted across systems and written back context-specifically to the systems that own the information.
That suggests a slightly different principle from “put everything into one product-data foundation”:
Keep information authoritative where it belongs, but make product context understandable and actionable across system boundaries.
To me, that is where AI could fundamentally change the integrated-platform-versus-best-in-class discussion. The future architecture may be less about choosing one side and more about whether AI can create a coherent product context across a heterogeneous application landscape without creating yet another silo in the process.