PLM and “The Whole Truth” Problem

by Oleg on March 30, 2012 · 23 comments

It is hard to find somebody in PDM/PLM business that is not familiar with the idea of a “single point of truth (SPOT)”. The idea is not new. In my view, it was one of the most powerful model that convinced people to implement PLM during the last decade. Similar to the idea of technological singularity, the idea of single point of truth assumes the ability of PLM as a business system to absorb all aspects of a product development lifecycle from early idea generation and requirements building through manufacturing and disposal. Architects of PLM systems took ERP resource and accounting as a model to build a complete model of product development processes in an organization. In the past, I addressed this topic in my posts. Navigate to Back topan> basics: PLM and Single Point of Truth or PLM and a single point of disagreement posts to read more.

Practical application of “single point of truth” model was far from ideal. High level of diversity in engineering and manufacturing processes combined with a significant cost needed to implement a singular model, ended up with very limited implementations. Lots of data elements and processes weren’t covered by PLM implementations. The discussions around “holistic” or “total” PLM implementations is not an unusual topic discussed during every PLM implementation. Earlier today I was listening to the tweet stream coming from CIMdata PLM forum. I learned a new term coined by Stan Przybylinski of CIMdata – “The Whole Truth model”. You can see below tweets about that. What I learned is that “whole truth model” supposed to expand PLM to domains not well covered by PLM today – electronic, software, process (and not only limited by traditional “mechanical orientation” of PLM).

This conversation made me think about possible trajectories of PLM model development into so-called “The Whole Truth”. I decided to make a picture to illustrate that. On the right side of the picture, you can see a PLM model growing and absorbing various domains of product development. Extra data elements represent supplemental aspects of product development PLM model needs to cover. It includes additional data elements as you can see on the picture.

At the time, I can see clear advantages and logic behind this “the whole truth” model, I have concerns about overall scalability and feasibility of such data model organization. The complexity and cost of this model will create difficulties in real-life implementations. Change management will be costly and complicated. Therefore, I decided to predict an alternative model. I called it “web truth” model. The idea behind isn’t new and present an organization of scalable network to represent multiple aspects of the product development. This model can have all advantages of a “single model”, but at the same side assumes some level of Independence in data organization, which will make overall data architecture mode lean and agile.

What is my conclusion? PLM vendors need to learn more about last decade of web development and organization of large scalable web systems. In my view, an attempt to build a “singular” system won’t be successful and create a complex system that hard to maintain, change and scale. The future belongs to data networks and more flexible data organization. Just my thoughts…

Best, Oleg

Picture Victor Habbick / FreeDigitalPhotos.net

Share

Tagged as: Model, PLM, Single Point of Truth, Web Truth model

  • Klaus Brettschneider

    Hello Oleg,
    Your illustration hit the nail right on the head and describes the difference between a system architecture where several satellite systems are integrated into each other and a deep integrated architecture where one central system builds the single source (or point) of truth very well. (The fact that CIMdata tries to coin a new phrase is amusing and their job I guess.)
    Business analysts and IT architects have to decide in their evaluation what model they choose for their organization. It is also clear that there is no black and white and a combination of both models is necessary to be able to represent most of the life-cycle business processes.
    However, I do not agree with the assumption that a ‘web-truth-model’ has all advantages of the ‘single model’. Even if web technology makes integrations easier, it would be careless to ignore the fact that an architecture with data exchange and synchronization always loses information and a 100% integration between these systems won’t be possible anyway.
    The ‘web-truth-model’ shows five integrations to the central system and five additional integrations if each ‘satellite’ system is integrated to only two other satellites. Yes ‘single-source’ PLM systems are complex, but to maintain, change and scale a system with ten integrations is a nightmare from an IT perspective.
    - Klaus

  • Stan Przybylinski

    Hi Oleg,

    We know we have made it now that we got quality time in your blog. Actually we were not coining a model (there is enough of that going on now as it is). We were merely commenting on out experience with our industrial clients who have issues because either their “single source of truth” systems do not manage all aspects of their development process seamlessly (e.g., mechanical and process, or mechanical and software, etc.), or when they try, they do not support true systems engineering, where you can really collaborate and trade off between mechanical, electrical, and software elements.

    Stan Przybylinski
    CIMdata, Inc.
    s.przybylinski@cimdata.com

  • MarcL

    Oleg – Great post, couldn't agree more w/ your conclusion. The “all in one system” approach is not practical or economic.

    Networked architecture is the future… and is already here in Consumer Internet we all use everyday, don't you think?

    Have expanded on this is a blog awhile back called 'Why the Networked Business will be Cloud Connected' http://aras.com/plm/001206

    MarcL
    http://www.aras.com

  • tbrown1775

    With a web based model we are making one major
    assumption.  Each of the different
    systems must be able to accept and share data. How many times, for various
    reasons, do we implement a system where the integration between systems are
    part of the second stage or so complex that it is scheduled for 9-12 months
    out?  Without these connections
    visibility is lost to any potential problems or product development
    relationship.  Without these connections
    the potential for duplicate information increases.

     

    How often is a PLM system viewed as multiple applications?
    The definition of a web based PLM model must be clearly documented. Each system
    ends up with its own requirements and validations.  Any connections are also documented. 

     

    Having multiple systems also requires users to learn and
    manage multiple systems and processes.  
    The maintenance of these users in each system now also becomes a
    requirement.

     

    Is all of this additional activity worth the separation of
    data?  The additional cost of ongoing
    maintenance and implementation must be a factor in evaluating the different
    systems and types of controls.

     

    Tim

  • Jim Mckinney

    Oleg,
    Nice post! I think the idea of “the whole truth” really speaks to the ability to provide access to ALL the information within the enterprise required during the product lifecycle. It does not necessarily point to one specific architecture, or configuration, as that will vary from one company to another. I think the promise of PLM is to provide tools that can be used to provide the right information at the right time to the right people to support the lifecycle of the product. People don't really care where the information is, and how they get it as long as they know it is accurate, valid, and complete.

    And, that's my “whole comment”.

  • beyondplm

    Jim, you “whole comment” makes perfect sense to me. People want to have an access to the information doesn't matter where that information is… אָמֵן. 

  • beyondplm

    Tim, thanks for the comment and sharing you insights! You are right, web architecture assumes sharing of data. Exactly, in the same way web apps / site are doing. FB, Google, Amazon and many others. In my view, this is the model that will win because of the ability to survive and expand. The biggest problem is not an initial cost, but the cost of change. The high cost of change made enterprise application completely not scalable and not changeable. Every 7-10 years, company drop a lot of things they are doing and goes to “new stack”. The biggest problem today is that companies cannot tolerate such a high level of change cost. Web model is more agile and lean. Pay attention – what is integrated is not “databases”, but “applications / systems”. This is true web. If you talk to enterprise IT today, they will take you back to “the database world”, which is wrong. The next big thing is to switch towards “application networks”. Just my thoughts… Oleg

  • beyondplm

    Marc, thanks for the comment! Remember you “connected web” blog, thanks for sharing the link. In order to succeed in multiple application approach, the integration needs to be on the level of application and services (not on database import / export). Just my thoughts… Oleg

  • beyondplm

    Stan, thanks for clarification. Learning from your “industrial” clients, what approach they prefer in order to cover all aspects of their development process seamlessly? These answer and deep analyzes about that can help us to coin the future direction. Just my thoughts… Best, Oleg

  • beyondplm

    Klaus, thanks for your comment! In my view, the assumption of “synchronization and data exchange” is wrong. This is a pattern that many “integration” technologies are following. In a nutshel it means synchronize/exchange data between systems. It requires expensive data mapping, and (you are absolutely right) data loss. At the same time, web architecture that allows web apps to expose data and mashup it for different purposes (services, visualization, calculation) can be more powerful and sustainable. I found that very few people in the company follow “network” pattern. Opposite to that “databases” are easy to get, since it is mature for the last 20-30 years. Just my opinion. YMMV. Best, oleg

  • Ganesan

    Hi Oleg,

    In my view, Single source of truth never meant that all product information needs to be stored in one single system. I think what it really means is, for a specific data element, there is only one source  of truth (one system) across the enterprise.  So, far example, if all the product line requirements are managed in a single RM system across the enterprise, then we follow the “single source of truth” even though the Parts, BOM and documents are managed in a separate PDM system. It is impossible to manage Requirements, portfolio plan, parts, BOM, Doc, EC… on one system and there is no need also.

    In real world, PLM is not a single application doing everything,  it is rather an integrated set of applications. 

    Thanks

    Ganesan

  • beyondplm

    Ganesan, thanks for your comment and insight! I think, if you talk to many PLM vendors, they will tell you that PLM means “a single database” which includes either data or references (so-called federated data). However, for most of the real examples of “federation” it is cached data from other systems. Just my thoughts and observation. Best, Oleg

  • beyondplm

    Klaus, In my view, the question is much beyond how to integrate 2-3 PDM/PLM systems in different divisions. It is not about single PLM vs. multiple PLM/PDMs. I think, modern data-management landscape in organizations assumes many systems with natural silos (PLM, ERP, CRM, SCO). On top of that landscape, we have a potential impact of M&A activities as well as extended value chain. Fast introduction of cloud applications and social tools just increased the level of diversity. 

    I don't think (correct me if I'm wrong) there is a possibility to converge all these systems into a single database or product development system (aka PLM). It will be a very costly process that will take too long to be considered as something a company can benefit from in a business sense. 

    So, the question is how to create systems that can operate on the “network level” similar to solutions available today on the web. 

    I hope I succeeded to explain that. Interested to know what is your take on this? 

    Best, Oleg

  • Klaus Brettschneider

    Oleg, I agree that web technology can make system integration easier in the realization, but especially in product life-cycle you have to be able to alter information, play them back and forth and it is not enough to only expose and mash up data. Data synchronization is mandatory. Take your youtube example (http://youtu.be/RCvu2ezB3rk) where a quantity change in SolidWorks initializes a change in the inforbix BOM and also in the Autodesk PLM360 Manufacturing BOM. You have already to deal with two interfaces. Put a workflow system on top of it and the integrations you would have to built and to maintain are quite complex and difficult to maintain.
    - Klaus

  • Klaus Brettschneider

    Oleg, agreed, there is no IT system what can cover all functions to realize a product life-cycle management approach from end-to-end. However, there are systems which cover more functions like Teamcenter, SAP, Windchill, Agile etc. which are able to realize a single-source/database approach.
    Regarding M&A activities – I have seen more success where the leading company forced the acquired company to migrate onto its systems than I have seen success with  'flexible' integration. Tim made a good point with the typical – integration w/ the next phase – approach.
    My point is not that the single system approach is always the most efficient solution, but over all this web and cloud excitement, we should not underestimate the cost and complexity of 'network' integration.
    - Klaus

  • beyondplm

    The technology is moving forward. Our world becomes more distributed. I wish I can believe that I can put my life in a single database. Email, FB, G+, Twitter, Various web hosting sources, etc. The same happens to businesses. It is a very interesting move, in my view. How do you solve the problem of supply chain, regulation, and many others that “naturally distributed” with a single database solution? Can you share your view on that? Thanks, Oleg

  • beyondplm

    Klaus, thanks for the comment! I think, you miss the point of the integration presented in the video. There is no separate BOM to manage – this is a key point of this integration. I'd be glad to discus it with you in details and explain. Please contact me oleg [at] beyondplm [dot] com. Best, Oleg

  • Klaus Brettschneider

    Oleg, the goal is not to put your entire life in one database and it should not be the goal for a company to put all processes in one system either, but if companies can get the most important processes which are fundamental for their business in one system and with it under control it is possible to create a central system as a single source of truth. Web technology gives an distributed environment the access to such a system and allows organization to incorporate external processes into their business.
    From our experience it is much more difficult and expensive to unify and integrate distributed systems than to built a single source of truth and to integrate the supply chain from a process and access perspective.

  • beyondplm

    Klaus, Thanks for sharing your insight! I agree- this is how it happens in reality. Company is trying to put “the most important” processes and some “fundamental stuff” in a single system. As a result – few big islands like ERP, PLM, SCM. At the same time, company stack to bring other “less important” data to a single “important” system. As a result lots of legacy system continue to stuck around. As time goes, the situation becomes more and more complicated. Multiple divisions, M&A and similar situations just multiple the problem. In supply chain, the situation is even worst. In my view, to answer on this problem is a combination of integration technologies and openness.  Just my thoughts… Best, Oleg

  • Pingback: PLM and Multi-Tier Strategies

  • Pingback: PLM: How to Cut Tree Hierarchies and Empower Data Networks

  • Pingback: PLM: How to Cut Tree Hierarchies and Empower Data Networks « Daily PLM Think Tank Blog

  • Pingback: The End of PLM Communism?

Previous post:

Next post: