Beyond the Product Tour: 6 Things That Make the OpenBOM Platform Different

Yesterday, I introduced the new OpenBOM Product Tour and showed how OpenBOM connects the product development lifecycle from CAD files and Cloud PDM through BOMs, collaboration, changes, procurement, inventory, and ERP.

The Product Tour follows a simple flow: Capture. Structure. Review. Flow. It is an easy way to understand what OpenBOM does.

But there is another question that is equally important: What makes OpenBOM different?

After all, almost every PDM and PLM vendor can draw a diagram that starts with engineering and ends with manufacturing. CAD, BOM, change management, release, ERP. The boxes can look remarkably similar.

The real differentiation is not the boxes. It is the architecture underneath them, and how product information is modeled, connected, shared, and used as it moves between people, disciplines, companies, and systems.

Here are six platform characteristics that I believe make OpenBOM fundamentally different.

1. CAD Files and Product Data Live in the Same Connected Model

For decades, engineering software has separated files from product structures. PDM manages CAD files. PLM manages items, BOMs, and changes. ERP manages manufacturing and business records. Engineers then spend an enormous amount of effort moving information between these systems and keeping everything synchronized.

But a file is not the product. And a BOM is not the product either.

A modern product is a network of files, items, assemblies, revisions, requirements, suppliers, manufacturer parts, costs, changes, and orders. OpenBOM connects these elements rather than treating them as separate domains.

Cloud PDM manages CAD files, versions, revisions, locks, and synchronization. CAD integrations extract structured product information. xBOM manages items and product structures. Change management connects revisions, ECOs, approvals, and decisions. Procurement connects suppliers, RFQs, orders, and inventory.

They become different parts of the same connected product information environment rather than isolated applications. This is why the transition from CAD to BOM to change to procurement in the Product Tour matters. The information does not need to be continuously recreated as it moves through the process.

2. Products Are Graphs. OpenBOM Models Them That Way.

One of the most fundamental architectural differences in OpenBOM is how we model product information.

Most traditional enterprise PDM and PLM architectures were developed on relational database technology. Relational databases organize information into tables and use predefined schemas, keys, and joins to create relationships. This technology is mature and useful, but product information creates a particularly difficult relationship problem.

Think about a single component. It can belong to multiple assemblies. It can participate in an EBOM and an MBOM. It can have several revisions. It can be connected to CAD files, drawings, manufacturer parts, suppliers, inventory records, purchase orders, configurations, and change processes. Now multiply this by tens or hundreds of thousands of items.

Products are naturally graphs.

This is why OpenBOM uses graph database technology as a native part of its data architecture. OpenBOM is built on a polyglot persistence architecture that includes graph and NoSQL database technologies. The xBOM model uses the graph to represent product structures and relationships rather than relying solely on relational tables and joins.

Items become nodes. Product structures and dependencies become relationships. EBOM, MBOM, service structures, configurations, suppliers, and files participate in a connected product graph. At the same time, xBOM allows to model each product as a combination of multi-disciplinary structures (mechanical, electrical, electronics, software). 

This is more than visualizing a BOM as a graph. The underlying xBOM data model itself is graph-based. That distinction is important.

A graph model allows OpenBOM to represent flexible and evolving relationships, traverse complex product structures efficiently, and create multiple product views without forcing every relationship into a rigid predefined schema.

This graph foundation is also becoming increasingly important for something else: AI. More about that shortly.

3. Multi-Tenant SaaS Changes Collaboration, Not Just Hosting

Almost every enterprise software company today uses the word “cloud.” But putting an existing application and database into cloud infrastructure does not fundamentally change the application architecture.

OpenBOM was designed as a multi-tenant SaaS data platform. Multiple organizations operate on a common platform while maintaining controlled and isolated access to their information. More importantly, the architecture makes it possible to securely connect information across companies when the business process requires it.

Think about how products are actually developed. An OEM works with contractors. Engineering works with suppliers. A design partner contributes a subsystem. A contract manufacturer needs released product information. A supplier provides catalog and pricing information. The product crosses company boundaries constantly.

Traditional enterprise software responds by creating more copies, more portals, more exports, and more integrations. A multi-tenant architecture creates a different foundation. OpenBOM combines multi-tenancy with flexible data modeling, role-based access, and cross-company data sharing.

So multi-tenancy is not just about lower IT costs or easier upgrades. It changes what connected product collaboration can look like.

4. CAD Files Sometimes Need Locks. Product Knowledge Should Not.

Traditional PDM was built around documents. Someone checks out a file, changes it, and checks it back in.

For CAD files, this model still makes sense. Two engineers modifying the same SOLIDWORKS assembly simultaneously is usually not what you want.

But structured product information is different. A BOM can be reviewed simultaneously by engineering, manufacturing, procurement, project management, and suppliers. One person can update sourcing information while another reviews quantities and a third comments on a potential design change.

OpenBOM was designed around real-time collaboration and simultaneous editing of structured product information. That creates an interesting combination: controlled PDM behavior for CAD files, and real-time collaborative behavior for product data.

Instead of turning every interaction into a document handoff, teams work together on the same connected information. Comments, changes, approvals, and decisions remain connected to the product rather than disappearing into email threads, spreadsheets, and messaging systems.

5. Engineering Doesn’t Stop at Release

There is another historical boundary that I think needs to disappear.

Traditional PLM architecture often treats release as the finish line. Engineering creates a BOM. The BOM is approved. It is released to ERP. Done.

Except the company still needs to build the product. Someone needs to understand what to purchase. Suppliers need to provide quotations. Costs need to be calculated. Inventory needs to be checked. Purchase orders need to be created. Production needs clean product information. Very often, this is where spreadsheets reappear.

OpenBOM connects engineering product structures directly with vendors, sourcing information, RFQs, purchase orders, inventory, and ERP integrations using graph based xBOM multi-view model. The important difference is not simply that OpenBOM has procurement features. It is that procurement operates on the same connected product information created by engineering.

Release is not where product information stops. It is where product information becomes operational.

This allows a company to move from CAD to BOM to release to spreadsheet to purchasing to ERP, toward a connected flow: CAD, product structure, change and release, sourcing and procurement, ERP, without rebuilding the product context at every boundary.

6. The Same Product Graph Becomes the Foundation for APIs, MCP, and AI Agents

And this brings us to AI.

There is no shortage of AI copilots being added to enterprise applications today. But an AI agent without product context has a serious limitation. To answer meaningful engineering and manufacturing questions, an agent needs to understand relationships.

Which assemblies use this component? What changed between these revisions? Which supplier provides this item? What products are affected if this part becomes unavailable? What should we purchase to build 20 units? Why did this component change six months ago?

These questions are not just searches. They require context.

This is where OpenBOM’s graph architecture becomes increasingly important. The same connected data foundation that links files, items, BOMs, revisions, changes, vendors, purchasing information, and decisions becomes the foundation for what we call Product Memory.

OpenBOM exposes platform functionality through REST APIs, and we are extending the platform with MCP (Model Context Protocol) support that allows AI agents to interact with structured product context. The CAD File Agent for SOLIDWORKS, shown in the Product Tour, is the first visible example. Instead of navigating traditional PDM commands and menus, an engineer can interact conversationally with the system to perform operations and retrieve information.

But the bigger opportunity goes beyond the user interface.

AI is not another module sitting next to PLM. It is a new interface to connected product knowledge.

And the quality of that interface will depend heavily on the quality of the underlying product context.

Architecture Changes the Adoption Model

Put these elements together and another important OpenBOM difference emerges. You don’t need to start with a massive PLM implementation.

Start with a CAD project. Or start with an Excel BOM. Bring engineering and manufacturing into a shared product structure. Add change management when you need more control. Add procurement when you are ready to purchase. Connect ERP after the engineering workflow is working.

The new Product Tour describes this as Start small. Connect everything.

It is important to understand that this is not merely an implementation methodology. It is a consequence of the platform architecture. A flexible multi-tenant platform with a graph-based data model, configurable product structures, integrations, and APIs allows a company to solve one problem first and progressively connect more information and workflows.

This is fundamentally different from the traditional model: define everything, customize everything, migrate everything, integrate everything, train everyone, and go live months later. Companies should be able to get value before they finish designing their entire future PLM architecture.

So, What Makes OpenBOM Different?

If I had to summarize the six differentiators in one sentence, it would be this:

OpenBOM combines Cloud PDM, native graph-based xBOM, multi-tenant product data, real-time collaboration, engineering-to-procurement workflows, and AI-ready product context through REST API and MCP, all operating on the same connected product data platform.

Each capability is useful independently. But the real differentiation comes from how they work together.

A CAD file becomes part of a product structure. The product structure becomes part of a change. The released structure drives procurement. Supplier and purchasing information become part of the product context. Decisions and revisions create history.

Over time, the system doesn’t just store product data. It builds Product Memory.

The Product Tour Shows the Experience. The Platform Explains Why.

The new OpenBOM Product Tour shows what users can do: Capture. Structure. Review. Flow.

Underneath that experience is the architecture that makes the flow possible: a multi-tenant, graph-based, collaborative platform designed to connect product information across engineering, manufacturing, procurement, suppliers, and business systems.

So if you watched the Product Tour already, I invite you to watch it one more time from a slightly different perspective. Don’t look only at the individual features. Watch what happens to the data as it moves between them.

It keeps its context.

And I believe that is one of the most important foundations for the next generation of engineering and manufacturing software.

REGISTER FOR FREE to OpenBOM and start today. As I always do, I invite you to check how OpenBOM can help your team, and contact us with questions.

Best, Oleg