Why OpenBOM Built a Collaborative Workspace Architecture Instead of Traditional PDM/PLM

For almost three decades, most PDM and PLM systems followed the same architectural assumptions.

A product was represented as a collection of documents managed through relational databases, object lifecycle states, SQL transactions, and controlled release workflows. Engineering work was serialized through check-in/check-out processes, object ownership rules, and release events designed to control how files moved through organizations.

That model worked well when products were mostly mechanical assemblies, engineering teams were organized by isolated disciplines, and changes moved relatively slowly. A mechanical engineer checked out a file, made modifications, checked it back in, and eventually released it through a controlled workflow. The architecture matched the process.

But modern products no longer behave this way.

Today’s products combine mechanical systems, electronics, software, firmware, supply chain information, manufacturing planning, and operational feedback. Product development became continuous, collaborative, distributed, and multi-disciplinary. Engineering work now happens simultaneously across people, systems, APIs, suppliers, automation pipelines, and increasingly AI agents.

The underlying architecture required to manage this environment is fundamentally different. This realization became one of the foundations behind OpenBOM Collaborative Workspace.

The Limits of Traditional PDM Architecture

Traditional PDM systems were built around a consistent and coherent technical architecture. At the center sat relational SQL databases used to manage objects, metadata, lifecycle states, and document references. Around these databases, vendors built object wrappers, CRUD transaction models, lifecycle state machines, and document release workflows. In many ways, traditional PDM systems behaved as relational object state machines connected to controlled document processes.

This architecture was not arbitrary. It reflected the engineering reality of its time. File-centric engineering meant that controlling files was effectively the same as controlling product knowledge. Slower release cadences meant that serialized workflows introduced acceptable delays. Disciplinary isolation meant that exclusive object ownership rarely created serious collaboration bottlenecks. The architecture fit the work.

What changed was the nature of the work itself. Modern products span MCAD, ECAD, software, and firmware simultaneously. Engineering teams are distributed across geographies, disciplines, and organizations. Suppliers, contract manufacturers, and customers participate in product development continuously rather than at discrete handoff points. Automation systems, APIs, and increasingly AI agents contribute to product data as active participants alongside humans.

Traditional PDM architecture assumes exclusive object ownership, serialized change sequences, and single document release events. Those assumptions were reasonable twenty years ago. They become structural bottlenecks when modern products are simultaneously evolving across multiple engineering disciplines, supplier networks, cloud services, and AI-driven workflows.

Modern product development is no longer a sequence of isolated document transactions. It is a continuous evolution of structured product knowledge.

What Is OpenBOM Collaborative Workspace?

OpenBOM Collaborative Workspace is a modern collaborative data management architecture designed to support continuously evolving structured product knowledge across people, applications, and AI agents.

It is important to understand what this architecture is not. It is not a document vault, a folder hierarchy, a traditional BOM editor, or a workflow engine. Those descriptions would place it in a category it was specifically designed to move beyond. Instead, OpenBOM Collaborative Workspace combines collaborative editing, structured product context, automatic history capture, revision snapshots, flexible product structures, and dynamic visualization into a unified environment.

The most important conceptual shift is this: the workspace is not centered around files. It is centered around evolving structured product context.

This distinction matters because modern engineering work is no longer defined only by files and documents. Organizations increasingly need systems capable of managing relationships, structures, dependencies, contextual information, and collaborative evolution across many participants and systems simultaneously. The six architectural foundations described below explain how OpenBOM Collaborative Workspace was designed to meet that need.

Foundation #1 — Collaborative Editing

Traditional engineering systems serialize work by design. A user locks an object, checks out a file, performs modifications, and eventually releases the result back into the system. The assumption is that engineering changes happen sequentially, one authorized contributor at a time.

Modern engineering work behaves differently. A mechanical engineer modifies an assembly while a sourcing team simultaneously updates supplier assignments. A manufacturing engineer creates MBOM structures while a software team manages firmware dependency changes. APIs synchronize external systems while AI agents validate completeness and flag inconsistencies. All of this happens continuously and often at the same time.

Collaborative editing in OpenBOM is not simply multi-user access to a shared file. Grounded in OpenBOM’s Collaborative Bill of Material patent, it is a real-time synchronization architecture where simultaneous edits from multiple users, multiple applications, and multiple agents are continuously reconciled within the same structured workspace. There are no isolated editing sessions and no serialized ownership queues.

The strategic importance of this design extends beyond human collaboration. Collaborative editing is no longer only about multiple people. Applications and AI agents are becoming active engineering participants. The same workspace architecture that allows two engineers to work simultaneously also allows an AI agent to validate product completeness, an ERP integration to synchronize procurement attributes, and a CAD connector to push geometry metadata — all without interrupting or serializing each other’s contributions.

Foundation #2 — Flexible Structured Data Model

Modern products are not simply collections of CAD files. They are networks of relationships connecting mechanical systems, electronics, software, procurement information, manufacturing definitions, service structures, and operational dependencies. Managing this complexity requires a data model designed not to constrain product knowledge into predefined categories, but to evolve alongside the product itself.

Structured context is the mechanism that allows OpenBOM to represent physical and system product definitions as a product knowledge graph. Every component, assembly, attribute, relationship, and reference participates in a structured network of connected product knowledge rather than sitting as an isolated record in a rigid relational schema. This graph can span mechanical definitions, ECAD structures, firmware dependencies, procurement catalogs, manufacturing process information, and service data simultaneously.

The flexibility of this model is architectural rather than cosmetic. Traditional PDM systems rely on object data schemas built around relational data models because their underlying SQL databases require structured tables with columns and foreign key relationships. Extending those schemas requires database modifications and complex work. This is why even them most flexible PLM data models are somewhat limited to SQL data. OpenBOM’s structured data model relies on modern NoSQL and Graph Database allows users to define custom properties, create new relationship types, and extend product context needed for product design, manufacturing and maintenance. 

The data model is designed to evolve with products rather than constrain them into SQL data structures defined in advance. As products grow in complexity across more disciplines and lifecycle stages, the workspace grows with them.

Foundation #3 — Automatic History Tracking

Traditional revision systems primarily capture released states. They record the result of an engineering process — a released drawing, an approved BOM, a finalized specification — but they do not capture how the product arrived at that state. The intermediate decisions, the collaborative edits, the evolving relationships, and the contextual changes that produced the final result are largely uncaptured.

Modern collaborative engineering requires a different level of historical visibility. Organizations need to understand not only what changed, but how the product evolved through collaboration over time. Which properties were modified and when? Which structural changes preceded a significant design decision? Who contributed which changes across a concurrent development period?

OpenBOM Collaborative Workspace automatically captures granular change events continuously and invisibly: property edits, structure changes, additions, deletions, replacements, timestamps, and contributors. This is not a manual bookkeeping process requiring engineers to annotate their changes. It is an automatic infrastructure layer that operates beneath collaborative editing without adding friction to the engineering workflow.

Revisions capture released states (snapshots). Chage history captures how the product evolved.

This distinction becomes foundational as AI systems begin participating in engineering workflows. A persistent collaborative history is not only valuable for human traceability and audit trails — it creates the structured record that AI agents need to understand product evolution, identify change patterns, and reason about why product structures exist in their current form. Automatic history tracking is the foundation of Product Memory.

Foundation #4 — Version and Revision Snapshots

One of the important structural distinctions in OpenBOM Collaborative Workspace is the separation between an active collaborative workspace and immutable revision snapshots.

The workspace is alive. The revision is frozen memory.

Engineering teams continuously evolve product definitions through collaborative editing. Properties change, structures are modified, relationships are added, and contextual information accumulates. This is the normal condition of a product under active development. At significant milestones — design completion, manufacturing release, supplier submittal, regulatory submission — revision snapshots preserve an immutable representation of the product’s state at that moment.

This separation allows organizations to maintain traceability, compliance, and released product definitions for manufacturing and procurement while simultaneously allowing collaborative development to continue evolving on the active workspace. The released revision remains frozen and trustworthy. The collaborative workspace continues to evolve toward the next milestone without being constrained by the immutability of the previous release.

Traditional PDM systems often blur this boundary by treating revisions as the primary working mechanism, forcing engineering teams to create new revision objects simply to continue development (typical sequence – create revision, set “in-work” state, release). OpenBOM treats revisions as preserved checkpoints within a continuously evolving collaborative environment — a fundamentally different relationship between working product context and released product state.

Foundation #5 — Item Reference and Instance Model

Modern products require more than single hierarchical BOM structures. The same physical product must be understood differently depending on who is looking at it and why. A mechanical assembly that engineering defines as an EBOM becomes a different structural arrangement in the MBOM that manufacturing plans against, and a different view again in the service BOM that field teams use for maintenance. A software component participates in firmware dependency graphs, procurement BOMs, and system architecture views simultaneously.

OpenBOM uses an item reference and instance model that separates item definitions from contextual instances. An item definition represents the shared product truth — the part number, the core attributes, the fundamental identity of a product element. A contextual instance represents how that element participates in a particular structure — its quantity, its position in an assembly, its relationship to adjacent elements within a specific BOM perspective.

The same product element can participate in multiple structures simultaneously while preserving shared product definition and contextual behavior.

This is the architectural foundation behind OpenBOM xBOM. Rather than maintaining separate disconnected BOM documents for engineering, manufacturing, procurement, and service, xBOM allows multiple structural perspectives to coexist within the same collaborative workspace, all drawing from the same underlying item definitions. When a core attribute of a part changes, every BOM structure that references that part reflects the change. The structures remain contextually distinct while the product knowledge remains unified.

Instead of forcing organizations to choose a single rigid hierarchy, the item reference and instance model allows product structures to evolve into connected contextual representations of the same underlying product knowledge.

Foundation #6 — Collaborative Grid Experience

Architecture determines what a system can do. User experience determines whether people actually use it.

This distinction has been one of the persistent failures of traditional PDM and PLM systems over the past two decades. The systems were powerful but complex. Adoption outside engineering was difficult. Collaboration across departments remained limited because the tools required specialist knowledge to operate effectively. The result was a well-documented organizational pattern: engineering teams used the PDM system for what it mandated, and then exported data into spreadsheets for everything else.

Despite decades of PDM and PLM systems, engineering and manufacturing teams still rely heavily on spreadsheets — not because spreadsheets are structurally superior, but because they provide flexibility, immediacy, visibility, and low-friction collaboration. A spreadsheet is immediately understandable to a sourcing manager, a program manager, a manufacturing planner, and a design engineer. The interaction model requires no training.

OpenBOM Collaborative Grid combines spreadsheet simplicity with structured product knowledge management.

The interaction model is familiar: rows and columns, direct cell editing, bulk operations, and immediate visual feedback. There is no learning curve for the basic mechanics of working with product data. But underneath that familiar surface, every cell participates in structured product context. Attributes are typed and validated. References connect to real items. Structures are maintained automatically. Lifecycle indicators provide visual context without requiring navigation away from the working view.

The Collaborative Grid is inherently multi-participant. Multiple users, applications, and AI agents can simultaneously contribute to evolving product structures through continuous synchronization. A sourcing engineer updating supplier information, a manufacturing planner adjusting quantities, and an AI agent flagging missing attributes can all operate within the same grid view simultaneously — each seeing the contributions of the others in real time.

Equally important is the grid’s relationship to underlying product data. The same structured product knowledge can be visualized as a hierarchical assembly tree, a flat procurement list, a manufacturing structure, or a discipline-specific view. These are not separate copies of the data maintained in parallel. Views are not copies of data. They are contextual visualizations of the same collaborative product knowledge foundation. Changing a value in one view changes it everywhere, because the view and the data are the same thing seen from a different perspective.

Collaborative Grid combines the usability of spreadsheets with the structural integrity of a product knowledge graph.

Why This Architecture Matters for Product Memory and AI

AI systems are increasingly entering engineering workflows. CAD file analysis, BOM validation, completeness checking, supplier intelligence, and design optimization are all areas where AI agents are beginning to contribute meaningfully alongside human engineers.

But AI cannot operate effectively on disconnected documents, isolated revisions, rigid transactional systems, and fragmented context. The architecture that traditional PDM systems were built on — SQL transactions, lifecycle state machines, document release events, serialized ownership — is not a foundation that AI systems can reason over effectively. The data is there, but the relationships, the history, the collaborative evolution, and the structured context that AI needs to be genuinely useful are largely absent.

AI requires structured context, relationships, granular history, collaborative traces, and evolving product knowledge. These are precisely the properties that OpenBOM Collaborative Workspace was designed to produce and maintain as a natural byproduct of collaborative engineering work.

The automatic history tracking that captures collaborative evolution becomes the training signal for AI reasoning. The flexible structured data model that connects mechanical, electronic, software, and procurement information becomes the knowledge graph that AI agents navigate. The item reference and instance model that allows multiple simultaneous structural perspectives becomes the relational foundation that AI can query contextually. The collaborative editing architecture that treats applications and agents as first-class participants becomes the integration layer through which AI operates.

OpenBOM Collaborative Workspace was designed not only for human collaboration, but as a persistent collaborative environment where people, applications, and AI agents continuously evolve product knowledge together.

This architecture becomes the foundation for Product Memory, the CAD File Agent, the BOM Review Agent, and the broader set of collaborative engineering AI systems that will increasingly define how products are developed, manufactured, and maintained.

Traditional PDM systems were designed to manage documents and transactions.

OpenBOM Collaborative Workspace was designed to manage the continuous evolution of product knowledge.

Interested in experimenting with OpenBOM Collaborative Workspace? 

REGISTER FOR FREE and check how OpenBOM can help you today. 

Best, Oleg