Digital Web and What Is Wrong With Traditional PLM Systems?

Digital Web and What Is Wrong With Traditional PLM Systems?

The digital transformation revolution has taken the manufacturing industry by storm. It is clear that many companies have begun to embrace digital technologies to increase efficiency and productivity. Digital Thread and Digital Web are top priorities for PLM industry analysts and vendors. Last month CIMdata Industry Forum was completely focused on the topic of Digital Thread. The vision of the Digital Web was presented during the presentation, which in a nutshell speaks about what was considered a PLM “holy grail” for many years – providing a complete informational model for all aspects of product lifecycle management. It includes all elements of product information – requirements, engineering, manufacturing, and service. You can see it as a network of combined data sets with multiple BOM anchors representing a graph of connections between the data intertwined as a giant global network.

I like the idea of the digital web presented by CIMdata. It visualizes the power of networks. PLM systems are supposed to play a critical role in the organization of digital threads and the digital web. However, it made me think about the technological gap in existing Product Lifecycle Management (PLM) platforms. Unfortunately, the traditional PLM data management architecture lacks the necessary capabilities to support it. In my article today, I want to address key elements of data management that make existing PLM systems, not the best candidate to manage digital threads and the digital web. Let’s explore what exactly is wrong with traditional PLM — and how leveraging modern web platform data management principles can help alleviate these issues.

The World Is Not Flat and Data Is Siloed

Every manufacturing enterprise is a complex organization that is built from departments responsible for particular tasks and activity – planning, sales, engineering, manufacturing, and maintenance. Each of them is built around data and processes to hold the “data” created and maintained by each department. These are silos that we all know very well. Like in the past, people thought about flat earth, the same is today – data architects are thinking about data tables first.

While most web-based organizations embraced a holistic data modeling paradigm to represent the information, for all PLM developers the world looks like the box-shaped data structures we developed over the last decades. This is one of the biggest factors that hold existing organizations from being digitally transformed and rethinking the way they manage information. This factor also holds organizational information technology transition.

When you check your product and organization data stored in PLM (and many other connected systems), you are likely to see that it is currently scattered in a set of isolated tables including Excel spreadsheets and various databases.

For example, if I would be capturing information about items, products, vendors, and orders, we will be in fact creating multiple tables for each of these data types – product, vendor, and order. This type of thinking sits very deep in people’s minds and this is why an Excel spreadsheet is a simple and most beloved example of a table of data.

Excel tables are simple and awesome, but you cannot run an organization on Excel (although many people are trying to do so to a certain level of success. It ends us with the “connectivity mess” when you need individually connect all these tables together. The PLM (and any industrial) answer to connecting tables together is SQL (or relational) database. All relational databases are modeling data using unique IDs in each table’s row to represent the information. These unique IDs (codes) are used to connect tables. So far, the industrial world runs these databases as a foundation of existing PLM (and not only) for decades. It works, you can say. What is wrong?

Digital Web and Integration Mess

Imagine thousands of rows in each database table, tons of tables in every PLM system, and each database managed by organizations and often thousands of databases. Customized PLM systems allowed the creation of tons of data and turned into monsters holding companies hostages. Flexible PLM data management allowed us to parameterize these data tables but still created data silos with tables, IDs, and tons of relationships managed as a separate set of tables. Think about these data sets and you will get an intuition of the very real problem we are trying to address by thinking about how to turn all these data sets into a nice chart representing digital thread and digital web.

In all enterprise organizations and their IT departments, the box-shaped table thinking is so ingrained that most of them are not even thinking much as they parcel up the data into these separate tables. It feels so natural. Existing PLM systems make it a bit easier and allow to them to think using these boxes. But this is a ticking bomb of existing PLM architectures.

On the face of it, PLM SQL architecture feels simple, but it created a very real integration cost to holding the data. The existing PLM data models require building table after table and often separating databases for different business units. M&A and joint ventures create more databases and more tables. Withing time these tables introduce a heavy load on organizational fragmentation and the integration of information. The cost of building a digital web and digital thread using existing PLM architecture will be skyrocketing.

Can We Support Digital Web Using Existing PLM Platforms?

PLM vendors are speaking about the future of digital thread and digital web to support digital transformation. I like these ideas and the digital future vision as presented by many PLM companies. However, we should not forget that existing PLM architectures are not ready for the future.

There are five fundamental problems with existing PLM architectures you will discover when you will try to apply them to build digital threads and digital web models.

  1. Tables are the foundation of the model and introduce a basic element of data isolation. Each record of the model is an isolated piece of information with an ID that then later requires to be “linked” together. Using these IDs is very clunky.
  2. All relational databases use local IDs that cannot be used to integrate information across multiple domains. Single-tenant PLM data architecture is the best demonstration of that. Linking data from one specific PLM database to another is a huge integration task.
  3. Data created in multiple systems cannot be easily combined together with the data created in another system, which requires complex integration efforts and data mapping. Therefore connecting EBOM and MBOM using such models is very often a dream combined with expensive data hardwiring.
  4. It is very hard to find relationships between different pieces of information – the data is hardwired with IDs and cannot be easily discovered using natural system data models. For example, if to find what suppliers are used for a specific product S/N from my engineering database will not be an easy task and will require special system coding.
  5. Application logic is tightly connected to the data in the current systems and won’t allow for the transformation of the data from one system to another or to use it in multiple systems.

What is my conclusion?

The problem with existing PLM architectures are real, but the future is not as gloomy as you might think. What can help is to bring network thinking to solve data management problems. This means we need to turn a “connection” to the first-class citizen in the future PLM data architectures. Future product lifecycle management must embrace graph data models and switch to a new way of building product data management and digital tools around these models. This is a future of product knowledge graphs and digital thread platforms that step beyond the limitations of current data architectures. In my next articles, I will talk about product knowledge graphs and how this model will allow the transformation of the product development process and many other disciplines of product lifecycle management to build a digital web and support digital threads. Even more, these new technologies will allow to the management of diverse data sets, support flexible semantic metadata modeling, and become a foundation for future machine learning and PLM AI tools. 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 networksMy opinion can be unintentionally biased.


Share This Post