
For many years, engineering teams relied on PDM (Product Data Management) tools to keep CAD files safe and generate their first Bill of Materials (BOM). These tools served their purpose when products were primarily mechanical assemblies – think of parts, bolts, and subassemblies neatly reflected in a CAD structure.
But times have changed. Products today are more than just metal and plastic. They blend mechanical components, electronics, software, and cloud services, often spread across different teams, tools, and locations. Trying to squeeze today’s data-rich product structures into the old file-vault + EBOM world is like flattening a 3-D CAD model into a 2-D sketch — you can force the geometry to appear, but you lose depth, intelligence, and adaptability.
This article explores why the traditional PDM-based Files+BOM model is no longer enough and how OpenBOM’s xBOM architecture redefines product structures for modern manufacturing.
The Old World – PDM and File Vault BOMs
Traditional PDM systems were built to manage CAD files. They stored everything in file vaults, controlled access with check-in/check-out, and maintained revision histories to keep track of design changes. On top of that, they often generated an Engineering BOM (EBOM) which was technically an expanded view of a CAD structure.
This model worked fine when products were mostly mechanical and team centralized. But over time, teams started to push this CAD-EBOM model to its limits, trying to use them for more than they were designed to handle. The cracks began to show when additional disciplines such as electronics, firmware, or cloud-connected services – joined the product mix. The CAD-centric model simply wasn’t flexible enough to capture all these layers without creating complexity and confusion.
The Complexity of Model Manufacturing Products
Fast forward to today: even a mid-sized company might design a product that combines frames and casings, sensors and PCBs, firmware for motor controllers, and cloud-based dashboards. Each discipline often uses its own specialized tools – MCAD for mechanical designs, ECAD for electronics, code repositories for software.
Each of these tools tends to come with its own mini-PDM, creating silos of data that don’t communicate easily. Meanwhile, manufacturers still need to maintain multiple lifecycle views- EBOM for design intent, MBOM for manufacturing, Service BOM for spare parts and field kits, and Maintenance BOM for ongoing support.
When all these views are maintained separately- often in separate CAD/PDMs stems, then complex Excel or pushed directly to ERP modules – teams end up chasing changes, reconciling versions, and managing data manually. It’s slow, error-prone, and frustrating.
Enter xBOM – A New Foundation
This is where OpenBOM’s xBOM architecture comes in. Instead of treating every CAD structure separately with multiple synchronizations, xBOM uses a multi-view BOM model with graph-based product structure data architecture.
Here is how the multi-view BOM model explained in one of my Beyond PLM articles – How to implement multi-view BOM strategy. The following picture from CIMdata explains it in the best form.

Think of it as a “product memory” where every item, component, or subsystem exists as a single, connected node in a graph. That node can then appear in multiple structures or BOM views – engineering, manufacturing, service—without duplication.
With xBOM, an engineer can see a CAD-driven BOM for design, a planner can see a manufacturing-ready view grouped by assembly steps, and a service team can focus on spare parts—all while referencing the same underlying data. Everyone sees their own perspective, but they’re all tied to the same single source of truth.
Why a Graph-Based xBOM Matters
The power of xBOM is that it solves two critical dimensions of complexity at once. First, it unifies disciplines—mechanical, electrical, and software data can all live in one place. Second, it handles lifecycle views—EBOM, MBOM, Service, and Maintenance BOMs—without creating separate copies that need to be synced.
This approach eliminates tedious manual reconciliation, reduces errors, and builds trust in the data. Instead of worrying about whether a part’s revision is up to date across five different BOMs, everyone works off the same connected product memory.
A Robot as an Example
At OpenBOM, we have many customers manufacturing robots. Let’s take a typical robotic product as an example. Its mechanical BOM might include frames, gears, casings, and brackets. Its electronic BOM lists sensors, PCBs, wiring harnesses, and controllers. Then there’s the software side—firmware that runs the motors and the cloud dashboard that collects performance data.
With traditional PDM-centric BOMs, these layers would live in separate silos. Engineers would manually export spreadsheets to share them with manufacturing or procurement, and service teams would have to create their own lists for spare parts.
In OpenBOM’s xBOM, all these elements are captured in one graph-based product memory. The engineering view stays CAD-centric, the manufacturing view organizes the same items by assembly process, and the maintenance view can filter out just the parts and kits needed for repairs—all without creating extra copies or breaking data links.
Conclusion:
Moving from PDM-centric file vault BOMs to xBOM isn’t just adopting a new tool—it’s adopting a new way of thinking about product structures.
By shifting to a graph-based xBOM model, companies gain the flexibility to handle modern, multi-discipline products while reducing the overhead of duplicate data and manual updates. It also opens the door for AI-assisted workflows—for example, validating BOM consistency, running cost roll-ups, or analyzing supply chain risks—because all the product information is linked in one connected graph.
In the next article of this series, we’ll focus on the collaborative workspace that makes it easy for teams across engineering, manufacturing, and procurement to work together in real time.
Meantime, REGISTER FOR FREE to check how OpenBOM can help you.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.