OpenBOM Graph-Based Architecture for xBOM Types

In my previous article, I briefly introduced you to upcoming OpenBOM enhancements related to product structure management and the introduction of xBOM capabilities in OpenBOM. Check it out, I’m super excited to share more about the new capabilities of OpenBOM. In our vision of democratization PLM and BOM management, we are thrilled to share more about OpenBOM architecture for multiple BOMs – EBOM, MBOM, SBOMs, and others.

Multiple BOM types provide the capability to create a representation of a product structure in different product lifecycle stages. As such the most typical BOM representations are EBOM (engineering BOM), MBOM (manufacturing BOM), and SBOM (maintenance and service BOM). BOM plays a fundamental role in establishing communication and collaboration between teams. I see Bill of Material as a universal media in cross-functional teams.

Different people contribute to this Bill of Material with a diverse set of information. OpenBOM xBOM will play a key role in supporting collaboration between cross-functional teams.

Best Practice of Multiple BOM Management

In my Beyond PLM articles, I have shared modern best practices, including single, multi-, and multi-view BOM, which form the foundation of digital BOM transformation from separate EBOM and MBOM. In one of my earlier articles, I shared how to implement a multi-view BOM strategy. To understand the strategy, I’d recommend you check on BOM research publications from CIMdata.

The following two slides I captured from CIMdata can give you an idea of the connection between digital thread, digital twin and the BOM. . There is a bit of a “renaming” game there. You can see a “Twin” name shown in many places where many of you are regular to see a “Bill of Materials” – As-designed, As-planned, As-built, etc. I’d not recommend seeing it as a simple renaming. The data companies need to manage is much more complex and relationships between data need to be managed.

The second slide speaks about the future – multi-view BOM. According to CIMdata, this is the future architecture of BOM and Digital Thread allowing for a connection of multiple pieces of information and managing the so-called Digital Web (I will talk about it in my future articles).

The multi-view BOM model is the approach we took to implement xBOM capabilities in OpenBOM. However, the implementation technologies and methods are important as well. And this is where a key OpenBOM differentiator is coming up – graph-based product model.

Graph Database in OpenBOM Data Management Architecture

One of the key elements of OpenBOM’s data management architecture is the use of graph database. Check out more about it in the article – Why OpenBOM Uses Graph Database. It is part of OpenBOM’s Polyglot Persistence Architecture. The usage of a graph database allows OpenBOM to manage flexible relationships between data elements within the OpenBOM platform. As such, we use a graph to model multiple BOM types and BOM views (eBOM, mBOM, sBOM, and others). If you’re interested in learning more about this topic, I highly recommend the Neo4j article – Transitioning from relationships to graph databases and also the Amazon Neptune article – What is Graph Database? The unique capability of the graph database already provide some unique set of features to OpenBOM such as blazingly fast structured queries (eg. Where Used Top Level). More capabilities will be coming such as xBOM and use of graph analytical queries in BOM supply chain models.

OpenBOM xBOM Architecture and Implementation

The flexibility and simplicity are two important elements of OpenBOM architecture. We plan to keep our promise and democratize the way companies can manage multiple BOM types. The need for a simple xBOM architecture is becoming very important these days since companies are looking for a straightforward way to manage the product lifecycle – starting from design and engineering (EBOM), moving to manufacturing and planning (MBOM), and also providing a mechanism to manage maintenance BOM (SBOM).

A simple administration allows you to define xBOM types and then use a standard BOM user interface to visualize each xBOM representation independently.

The product knowledge graph will maintain the entire set of relationships and links using the graph model. OpenBOM’s user experience allows the selection of a specific set of relationships representing one or multiple BOMs, presenting it to the user for viewing and editing.

Of course, all other elements of OpenBOM’s flexible data model will be preserved, such as the ability to manage a flexible set of properties (both item and instance level), filters, and user-defined views. OpenBOM’s instant real-time collaboration allows multiple users to edit xBOMs in real time.

Conclusion

OpenBOM is expanding its unique graph-based infrastructure by introducing the xBOM model to support a multi-view strategy of BOM management. New and unique graph-based technology and modeling are used by OpenBOM to introduce a unique way to manage product data and gives everyone in an organization to connect engineering and design software together with manufacturing organizations, inventory and other data representations. The key element of the technologies OpenBOM uses allows it to complement enterprise PLM and legacy systems with such a new company. OpenBOM focuses on product definition and creation of a holistic graph-based product knowledge model.

New technologies used for data management will allow you to keep multiple BOM representations in real-time. It will include the ability to manage multiple BOM types (eg. engineering bill, manufacturing BOM with raw materials, and assembly production planning. Organizations focusing on the need to manage multiple BOM representations will leverage it to support their product lifecycle processes in engineering, manufacturing, and maintenance.

REGISTER FOR FREE and learn how OpenBOM can help you today. Stay tuned for our announcement about xBOM.

Best, Oleg