One of my earlier articles The death of MBOM and EBOM divide raised interesting debates earlier this week. You can follow comments on LinkedIn. My special interest was caught by the discussion about the Bill of Materials and data management.
Mathias Ahrens, PLM solution architect brought his dream data management model for the future of BOM management. I like this dream model and I will talk about it separately in connection to the development I do at openbom.com (disclaimer – I’m CEO and co-founder). Here is my favorite passage:
I hope that we will get in future in the backend a kind of a knowledge graph data model to store the BoS (Bill of Something). Such graph could connect numerous nodes of different classes (Materials, Processes, CAD Parts, Requ., Func., …) with named edges (isComponentOf, isManuf.As, isDeliveredAs, isSupporting, isSuccessorOf, etc.). By that compositions, traceability, RFLP dependencies, etc. aspects could be stored in the same core network of nodes and edges. On the FrontEnd relevant fragments could be filtered an presented to the user as Bill of Materials, Bill of Processes, Bill of Docs, Bill of CAD Parts, Bill of Func., etc. with the ability to reflect them in different perspectives resp. timestamps (AsDiscussed, AsDesigned, AsReviewed, AsNegotiated, AsBuild, AsServiced, etc.) and with the ability to visualize a second dimension of connected nodes in addition (linked Requirements, linked Funtions, linked Procceses, linked Documents, etc.). The challenge would be to find a feasible access and privileges model! Who is allowed to see, change and create what and when? Based on that access to certain nodes, edges, fragments must be managed.
What database or architecture or system can solve this problem?
The last 10-15 years of database and data management development took the industry to a completely different level of understanding about what can be done with the data in terms of scale, complexity, and velocity. Traditional SQL-based architecture is too expensive and won’t scale for global and complex systems needed today in manufacturing. But as it happened many times in the past, the industry is looking into magic database solutions to solve the problem. It was relational-databases back in the 1980s, object databases back in the 1990s, NoSQL databases back in the 2000s. The last stage in the debates is Graph databases that became more popular in the last 5-7 years. Will one of the database solutions provide the ultimate answer to the problem of engineering and manufacturing data? This is a good question to ask.
Two decades ago, the data management dilemma was described as the following diagram – looks like a document, then you need Office, otherwise you need RDBMS.
The database was the subject of IT approval and was a key element of the PLM system. It still is, but things are changing. In programming languages, we’ve been moving from a single programming language to polyglot programming. The set of languages is a toolbox. You chose the combination of languages to develop the solution. The same is happening to databases. From the world where developers had to select a single database, we moved to the world where multiple databases can be used as a toolbox (just choose the right tool for the job). Combined with the microservice architecture, the architecture removes the question about what is the best database and replaces it with the question of what is the right data architecture to support a specific set of problems.
The product information model described earlier as a “dream solution” introduces an interesting data management challenge, which has 3 dimensions -(1) data type; (2) lifecycle stage; (3) organization. The combination of these three elements brings the question about what would be the possible data management architecture to solve it. Existing PLM systems have too many limitations coming from the history of single-tenant systems with the core model stored in relational databases. The reality of manufacturing organizations is complex network relationships between a variety of data elements, history of changes, and organizations. What is needed is a set of coordinated services capable of managing data in an optimal way, scale globally, and provide a flexible data management abstraction.
What is my conclusion? In my view, we are at the end of the debates about what is the best database to solve the problem. The database is a tool in the modern architecture solution toolbox allowing to development of global, scalable platforms to manage data across multiple organizations and lifecycle stages. In the next decade of data management in engineering and manufacturing software, we will see growing efforts to build such platforms to solve complex manufacturing problems. Just my thoughts…
Best, Oleg
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital network-based platform that manages product data and connects manufacturers and their supply chain networks. My opinion can be unintentionally biased.
