A few articles I published on the OpenBOM blog about organizing data before starting PLM implementations and navigating single source of truth concept in the digital age, triggered an interesting discussion about Single Source of Truth. Thank you all for the comments and examples from the past, as well as insights about the future. Check out the conversation on LinkedIn and the comments that I found insightful.
In the evolution of product lifecycle management (PLM) software, vendors used the concept of single source of truth (SSOT) as one of the leading elements of building their strategy. During the last 40 years, companies switched from paper/ink to folders/files, then to databases/vaults. These days industry leaders and researches are speaking about Digital Twins/Threads, while emphasizing an importance of “dynamic threads”. Here is an interesting passage and opinion by Patrick Hillberg Ph.D., which I found insightful.
We should reverse the perspective on SSOT. Oleg’s post gives a good historical perspective, going back a couple of decades, and I would go back even further, to the beginnings of mass production. First there were drawings (ink on paper) of interchangeable parts, then a stack of drawings would get a header page called the “bill of materials”. Then the act of designing parts was computer-aided, and all those computer files needed a database, the product needed a supply chain, and the computers needed to export their BOMs for multiple uses (xBOMs). This is a century old paradigm, which is struggling to adapt.
What if we began with the concept of the Digital Twin, and the Thread needed to support that Twin? If any info about a physical product will be found in its Twin, build the virtual instance first, then align all the data views to the needs of the Twin. If my concern is “how do I avoid product catastrophe?” the xBOM is irrelevant (e.g., 737 Max). You need a cross-organizational Twin, supported by a dynamic Thread. Think first about the Twin, and allow xBOMs to fall out of it.
The concept of a single source of truth (SSOT) stands as a foundation of how information can be organized to support the efficiency and clarity of engineering and manufacturing processes. Over the years, the journey towards achieving this SSOT has undergone a transformation, mirroring the advancements in technology and the changing needs of industries. In my article today, I want to give you a perspective of how SSOT evolved from scattered files and folders to the emergence of digital technologies and advanced data modeling. It includes my take about where these technologies will be evolving in the future.
Paper and Ink: Before Digital Thread Begins
It was paper drawings made on drawing boards. I remember myself many years ago visiting my dad in the engineering department of a large steel factory designing heavy equipments. The drawings were everywhere and organized in the cabinets with indexes and numbers. I wish I’d have a photo from those days, but they are gone. Check the article Life Before Invention of Autodesk (1950-1980) can give you an idea how engineers worked without computers.
Files and Folders: The Early Days
From the first appearance of the CAD system, folders/files started to play the role of single source of truth. The computing paradigm of all operational systems starting from workstations and later PC/Mac architectures was focusing on organizing of files together in folders and later on with the introduction of LANs sharing these folders within organizations. Product data (SSOT) was scattered across multiple files and folders, residing on individual desktops or shared network drives. While this approach allowed teams to create and store data, it quickly led to challenges in version control, data integrity, and collaboration. As product complexity grew, so did the need for a more centralized and structured approach to managing this data.
Centralized Databases: Rise of PDM/PLM Systems
Databases and data management systems were introduced to help organizing the chaos of folders and files. Which brings us to the last 20-30 years were the concept of SSOT was simply about how to collect all information about drawings and (later) 3D CAD files together in a single database, combine with the file storage and claim the victory of organized data. The SSOT slowly, started to be associated with a “single database” managing all information including files. Organizations began adopting dedicated software platforms designed to streamline the management of product data throughout its lifecycle. These systems provided a unified repository for all product-related information, including CAD files, bills of materials (BOMs), specifications, and documentation.
More information, more sophisticated data management and software platform brings us to the current status quo. This is how majority of companies today understand a concept of SSOT- need to place all the data in a single location (folders, databases, software platforms, cloud storage), which will ensure we never lose anything and always can find everything. With features like version control, access control, and workflow management, PLM systems brought a new level of order and efficiency to product development processes.
Can we stop here? Did we get everything we need? Do we need a new concept? Let’s talk about the reality of work in engineering teams and manufacturing organizations and business processes.
SSOT Beyond Single Database
The PLM software dream of a single database and a PLM system that can virtually control all information about the product lifecycle, project management, supply chain management and virtually all software systems that called themselves PLM solutions was very short. Multiple business processes introduced different business systems – EDM, TDM, MRP, MRPII, ERP, SCM, PLM, QMS, PIM, etc. I can bring more three letter acronyms. Where is the single source of truth and how to manage product lifecycle with a such level of complexity of product data management. How to get up to date information for product development process. How engineers, project management, manufacturing planners, procurement and supply chain, suppliers and contractors,
Multiple Systems and Product Models
Introducing multiple applications brings the question of how data can be created, connected and changed in multiple places at the same time. The ideas and concepts of federated data management systems, search indexes, knowledge graphs and approaches that can support consistency of data are raising up. Should we still call the entire data collection a single source of truth (SSOT) or find another name? Some discussions about it brought an idea of a single source of change (SSOC), which allows to identify a single system that is responsible to control the changes of data in a single place. This is kind of master-slave data management approach with adding a flavor of data semantics is promising. You can read more about it in my article about breaking PLM monolithic architecture.A product model is a concept that in my view can be easy achieved from a pragmatic implementation perspective and, at the same time, provides a foundation for modern PLM software technologies going beyond a “single database” or a “single PLM system” vertically integrated and controlling all information.
Digital Twin: Bridging the Physical and Digital Worlds
As technology continued to advance, so did the concept of the digital twin. Originally conceived in manufacturing and engineering contexts, the digital twin represents a virtual counterpart of a physical product or system. By capturing real-time data from sensors, IoT devices, and simulation models, digital twins enable organizations to monitor, analyze, and optimize the performance of their products throughout their lifecycle. This convergence of the physical and digital realms offers unprecedented insights into product behavior, allowing for predictive maintenance, design optimization, and enhanced customer experiences.
While the original ideas about digital twin were more focused on the simulation of physical devices, I can see how digital twins are progressing towards holistically defined digital models of product lifecycle that can provide a comprehensive foundation for product models.
Digital Threads: Bringing Contextual Intelligence into PLM
To solve complexity of connections and volume of product data located in multiple systems, we need to have another model that can connect multiple systems operating together. To make sense of this deluge of information, the concept of digital thread has emerged as a paradigm beyond PLM. Digital provide a contextual framework for organizing and linking related pieces of information across disparate systems and domains. Whether it’s tracing the lineage of a specific requirement through various design iterations or tracking the impact of a change across multiple subsystems, threads help stakeholders navigate the interconnected web of product data with ease and precision. Modern databases such as Graph Databases is a great foundation for managing digital threads. Check some of my articles about Digital Thread:
PLM and Digital Thread Evolution (part 1-5)
Traceability, Digital Thread and Future PLM software architecture
Product Knowledge Graph and SSOT
Knowledge graph is a concept that allows to build informational and semantic models connecting different entities (virtual and physical) as objects and relationships between them. In my view, knowledge graph will play a significant role in the development of future PLM ideas and creating product models that will be able to reflect the process of design, engineering, production planning, manufacturing and maintenance of products. The concepts of knowledge graph will support creation of future digital product models and expand them towards building intelligent and connected data management and collaborative environments. Graph model is a perfect model to absorb multiple siloed pieces of information and will represent a collective single source of truth including reasoning and allowed change behaviors. Graph models will also play an important role in building future AI models for engineering and manufacturing (but I will save this topic for the future blogs)
What is my conclusion?
Looking ahead, the evolution of PLM and the pursuit of a true SSOT will continue to be driven by advancements in technology and the evolving needs of industries. From building intelligent Digital Twins, leveraging Generative AI to find an optional solution and automate routine tasks, new product models will allow to create complex data services to manage various aspects of product lifecycle process. Embracing cloud-based platforms for seamless collaboration and communication will support the future promises of organizing information in a connected network of data and by using it, optimize future PLM platforms.
The importance of a robust SSOT cannot be overstated. By harnessing the power of digital twins, threaded data, and emerging technologies, companies can unlock new levels of efficiency, agility, and innovation in their product development endeavors.
The journey towards a single source of truth in PLM has been marked by great progress and innovation. At the same time, vertical integration and lack of openness, slows down the adoption of PLM ideas. We will continue to push forward the ideas of building complex models to reflect product design and manufacturing innovation. At the same time human behavior of organizational changes will remain significant factor that prevents companies from making progress in PLM adoption. Making complex models and simple user experience – this is a formula that PLM vendors should adopt to bring PLM and SSOT to a greater adoption.
Just my thoughts…
Best, Oleg
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.
Pingback: Beyond PLM (Product Lifecycle Management) Blog Navigating the Path: Opportunities and Obstacles for PLM in Engineering Digital Transformation - Beyond PLM (Product Lifecycle Management) Blog()