PLM Was Built for MCAD. OpenBOM Is Building What Comes Beyond PLM

Twenty years ago, designing a product mostly meant mechanical design. A mechanical assembly captured most of what needed to be managed: parts, drawings, versions, tolerances, and release packages. The tools built to manage that data reflected this reality. They were built for files, and those files were mostly 3D MCAD models or 2D drawings. Electronics was often treated as an add-on, and product lifecycles were much longer, giving teams more time to “settle in” before release.

That world is gone. A modern product is not a mechanical assembly. It is a system. It combines mechanical design with printed circuit boards, embedded firmware, software applications, supplier components, compliance certifications, manufacturing process instructions, and field service data. The teams building it span mechanical engineering, electronics, software, procurement, manufacturing, and operations. The data describing it lives in CAD tools, ECAD platforms, version control repositories, spreadsheets, ERP systems, and shared drives. No single file, and no single tool, contains the whole picture.

Traditional PLM is not ready for this reality. It was built for the one that came before it.

However, the reality is that the majority of engineering data is still located in files – CAD files. They are not only MCAD, but they represent a lot of what engineering managed and created over the years. And those CAD systems are still here and unlikely to disappear overnight. 

In my article today, I want to give a bit of perspective to connect the reality of CAD file management we have today with our “Beyond PLM” vision. 

When engineers hear about a new tool that connects to SolidWorks Design tools and helps manage CAD files, the natural assumption is that it is another MCAD utility. A smarter PDM. A file organizer with a better interface. Something built for the same problems that mechanical CAD tools have always created.

That assumption is understandable. It is also exactly what OpenBOM’s CAD File Agent is not.

CAD File Agent starts with SolidIWorks because that is where one of the most visible and painful engineering file data management problems exists today. But the platform behind it is not MCAD-centric. The architecture does not assume that SOLIDWORKS is the center of the product universe. It assumes that products are multi-disciplinary, that engineering data comes from many sources, and that the job of a modern data management platform is to connect all of it into something coherent and useful.

This article explains why that distinction matters, and what it means for engineering teams who are thinking beyond MCAD.

Why PLM Became Grounded in MCAD

The history of PDM and PLM is inseparable from the history of mechanical CAD. When MCAD tools became widespread in the 1980s and 1990s, they created a new class of engineering data problem. Assemblies with thousands of dependent parts. Drawings tied to specific file versions. Multiple engineers working on the same geometry. Files that could only be opened correctly if every reference was in exactly the right place.

PDM systems were built to solve those problems. Vault the files. Control who can check them out. Version them correctly. Manage the release process. It was the right response to the right problem at the right time.

The consequence is that PLM architecture became deeply organized around MCAD concepts. The EBOM came from the CAD assembly structure. The drawing was the primary release artifact. The part number scheme was built to match mechanical design outputs. Downstream systems, from procurement to manufacturing to ERP, learned to receive data in formats that MCAD-centric PDM tools produced.

This was not a mistake. It was a natural evolution of a software category that started where the hardest problem was. The problem is that products changed faster than PLM architecture.

The Problem Is Not MCAD. The Problem Is MCAD-Only Thinking.

Mechanical CAD remains one of the most important sources of product information. Geometry, assembly structure, mass properties, tolerances, drawing packages — MCAD is where shape and design intent begin for most physical products. None of that is going away.

But look at what most modern products actually contain. A consumer electronics device combines mechanical enclosures, printed circuit boards, embedded firmware, supply chain components, compliance certifications, software applications, manufacturing process requirements, and service instructions. An industrial machine combines structural assemblies, pneumatic or hydraulic systems, electronic control systems, software PLCs, vendor-supplied subsystems, safety documentation, and field maintenance data.

A system organized around MCAD files can capture the mechanical portion of this reality. It cannot capture the rest. Electronics teams do not think in mechanical assembly hierarchies. Software teams organize their work in repositories, branches, builds, and releases, not drawing packages. Procurement teams care about availability, lead time, cost, and approved alternates. Service teams think in terms of installed configurations, serialized assets, and field replacements.

If the data management platform assumes everything must orbit around MCAD, it creates a distorted and incomplete picture of the product. The mechanical team is well-served. Everyone else works around the system rather than inside it.

Why CAD File Agent Starts with SOLIDWORKS

SOLIDWORKS is used by millions of engineers worldwide. It is one of the most widely deployed mechanical CAD tools in the mid-market. And despite decades of PDM and PLM investment in the SOLIDWORKS ecosystem, a very large number of SOLIDWORKS teams still manage their files in local folders, shared drives, and Pack-and-Go packages. They still lose file references when projects are moved or renamed. They still email drawings and STEP files back and forth. They still maintain BOMs in spreadsheets that are manually kept in sync with the CAD model.

CAD File Agent starts here because this is where real, daily engineering pain exists. It is the point of friction: the place where engineering data is created and where context is most consistently lost.

But starting with SOLIDWORKS and being limited to SOLIDWORKS are very different things. CAD File Agent is the first expression of an agentic data management capability built on top of OpenBOM’s platform. That platform was not designed around MCAD. It was designed around product data, regardless of where that data originates.

OpenBOM Is CAD File Neutral by Architecture

OpenBOM does not treat a CAD file as the product model. It treats a CAD file as one important source of product information among many.

The underlying data model captures files, metadata, part records, BOM structures, revisions, references, vendor information, costs, compliance data, documents, and lifecycle status. These objects can originate from a SOLIDWORKS assembly, an Autodesk Inventor model, an Autodesk Fusion design, a KiCad schematic, an Altium or OrCAD PCB project, an Onshape workspace, a supplier spreadsheet, or an ERP export. The platform does not privilege one source over another. What matters is how the data connects, how it is structured, and how it can be used by the teams who need it.

This is a deliberate architectural choice, not a roadmap promise. The data model was built to be source-neutral from the beginning. CAD files are inputs. Structured, connected product knowledge is the output. The distinction between those two things is what separates a file management tool from a product memory platform.

CAD is the source. Product data and product memory is the destination.

Agentic Skills Extend Across Every Engineering Domain

The most architecturally significant part of CAD File Agent is not the SOLIDWORKS integration. It is the agentic operating model it introduces.

Agents work through skills. A skill is a defined capability that an agent can apply to a dataset: inspect a file set and resolve dependencies, extract metadata and populate item records, generate derivative formats like PDF drawings or STEP exports, compare two revisions and identify what changed, detect missing required properties, classify components by type or source, or validate that an assembly is ready for release. These skills are not conversational features. They are operational capabilities that work on real engineering data.

The key insight is that these skill patterns are not inherently mechanical. Consider what ECAD data looks like: a PCB project in Altium or KiCad contains components with manufacturer part numbers, reference designators, net connections, layer stackups, approved vendor lists, and compliance attributes. An ECAD agent skill could extract component data from that project, validate that every component has an approved manufacturer part, identify missing AVL entries, and connect the resulting BOM to the same item records that the MCAD team is using for mechanical components. The output is a single connected product BOM that includes both mechanical and electronic parts, sourced from two different CAD environments.

The same logic applies to software and firmware. A software release has a version, a set of dependencies, a build artifact, and a relationship to specific hardware configurations. A skill that connects a firmware version to the hardware BOM that it runs on is not conceptually different from a skill that connects a PCB BOM to a mechanical enclosure assembly. The pattern is the same. The domain is different.

Requirements follow the same model. A requirement has ownership, validation criteria, a status, and relationships to the design items that fulfill it. An agent skill that links requirements to BOM items and flags unvalidated dependencies is applying the same capture-and-connect logic that a file agent applies to assembly references.

The skill model is domain-neutral by design. What changes between domains is the data schema and the specific operations. What stays the same is the agentic pattern: understand the data, extract what matters, connect it to the product record, and surface what is missing or wrong.

xBOM: The Layer That Connects Multi-Disciplinary Data

Capturing data from multiple sources solves only part of the problem. The harder part is making captured data from different disciplines usable together.

This is where xBOM becomes essential. A mechanical assembly, an electronic board, a software module, a purchased component, a supplier qualification, and a manufacturing routing are all different views of the same product. Traditional PLM systems either force these views into a single rigid structure that was designed primarily for mechanical data, or leave them disconnected across separate tools with no common record.

xBOM is the OpenBOM service that manages multiple connected product structures simultaneously. Engineering BOM, manufacturing BOM, purchasing BOM, service BOM, functional structure, project breakdown — each view can exist independently, can be maintained by the team responsible for it, and can be connected to the others where the product logic requires it. A mechanical part that is also a purchased component that is also a field-replaceable unit can exist coherently across all three views without being duplicated into inconsistency.

When agent skills capture data from SOLIDWORKS, Fusion Electronics, Altium, or Onshape, the result flows into xBOM as structured items with relationships, not as files attached to a record. The data becomes part of the product memory, not just an artifact stored near it.

Capture, Review, and Flow: How Product Memory Builds Over Time

The value of a product memory platform is not in any single capture event. It is in the accumulation of structured, connected knowledge over time, and in what becomes possible when that knowledge is complete enough to act on.

OpenBOM organizes this around three connected activities. First, capture: agents gather product data from wherever it lives, whether that is a SOLIDWORKS assembly, an Altium schematic, an OrCAD project, a supplier spreadsheet, or a specification document. The data is structured into item records, BOM views, and relationships inside the platform.

Second, review: once data is captured and structured, it can be validated for completeness, correctness, cost targets, compliance status, and release readiness. Review agents and workflows help teams find what is missing, assign responsibility for gaps, track approval status, and build confidence before release. This is where the data moves from raw capture to trusted product knowledge.

Third, flow: validated product data moves downstream to the systems and teams that need it. ERP systems, procurement platforms, manufacturing operations, and service organizations all need accurate, current product information. Flow agents prepare and deliver that information in the format each downstream system expects, without requiring engineering teams to manually export, reformat, and transmit data as a separate task.

This cycle is not a one-time process. Products change. BOM components are substituted. Designs are revised. New requirements emerge. Each cycle of capture, review, and flow adds to the product memory and makes the next cycle faster and more accurate.

What This Means for PLM Architecture

The next generation of PLM will not be defined by which CAD system it controls. It will be defined by how well it captures, connects, validates, and moves product knowledge across every engineering discipline involved in building the product.

This is a meaningful shift. Existing PDM and PLM systems were built with MCAD at the center and everything else as an extension or integration. The assumption was that the mechanical model was the primary product representation and that other disciplines would connect to it.

A product memory architecture reverses that assumption. There is no single primary representation. There are multiple disciplinary views of the same product, each authoritative for its domain, all connected through shared item records, BOM structures, and relationships that the platform maintains. The organizing principle is not the CAD file. It is the product itself: what was decided, what was designed, why it changed, who reviewed it, how it connects to requirements, what was released, and how it flowed into manufacturing and operations.

The center of PLM is moving from CAD files to product memory. That shift is what OpenBOM is building toward.

CAD File → xBOM → Product Memory 

CAD File Agent starts with SOLIDWORKS because that is where millions of engineers work and where the file management problem is most acute. But the architecture behind it was designed for a broader reality.

OpenBOM’s platform connects data from SOLIDWORKS, Autodesk Inventor, Autodesk Fusion, Fusion Electronics, Altium, OrCAD, KiCad, Onshape, and other sources into a single connected product record. Agentic skills can be applied across mechanical, electronic, software, and requirements domains, because the skill pattern is not CAD-specific; it is data-specific. xBOM connects the resulting information into multiple product views that different teams can use without forcing everyone into a single MCAD-derived structure.

Teams that are evaluating CAD File Agent because they have a SOLIDWORKS file problem will find a solution to that problem. But they will also be adopting a platform that is ready to grow with them as their products grow more complex, their teams grow more distributed, and their data management needs grow beyond what any MCAD-centric system can support.

SOLIDWORKS is the entry point. Product Memory is the platform to capture product data and knowledge. 

REGISTER FOR FREE to check how OpenBOM can help you.

Best, Oleg