Peer Check
Peer Check

Episode 11 · 3 months ago

#11 - The ‘Single Source of Truth’ Myth in Engineering


The future of Product Lifecycle Management (PLM) is not in single sources of data, but in open and interconnected datasets that are optimized for access and accountability, rather than control. At least, that’s what the “Virtual Dutchman,” Jos Voskuil believes. Jos Voskuil is a PLM expert and the founder of, an online blog that helps PLM implementers and customers in their stepped approach towards PLM. Jos joins Adam to talk about the future of connected PLM and the part that systems of engagement will play in shaping it.

Listen to Adam and Jos discuss:

  • The benefits of a connected federated data environment
  • The myth of single sources of data
  • How a connected PLM positively can lead to better systems of engagement
  • How organizations can start shifting to a federated model
  • Multidisciplinary vs. single disciplinary collaboration in engagement systems

More information about Jos and today’s topics:

To hear this interview and more like it, subscribe to Peer Check! Find us on Apple Podcasts, Spotify, or our website—or just search for Peer Check in your favourite podcast player.

M. Welcome to Pierre Check, a Colab podcast. This is a show for engineering leaders who want to challenge the status quo for how design teams work together. You're about to hear a conversation about the ways the engineering world is changing and how top teams are carving a new path forward. Let's do it. Welcome to Pierre Check. I'm your host, Adam Keating, and today we're talking about the future connect to PLM and the role that systems and engaged will play. I'm joined by the virtual Dutchman, a plom Max berts Bush cow. He's been in the PLM space for twenty plus years, you know, as a translator and coach, helping teams figure out connect the business and technoside together, and then also someone sharing knowledge, and you'll find them on the Internet, Sharon bloggs, for the last fifteen years. Yes, welcome to the show. Thank you with Adam, and thank you for having me in this interesting series of podcast. I discovered it also recently and I'm really enjoying and some of the speakers, so I'm glad that I can contribute to the picture of the future in a modern media. I love it. Before we jumping, I got to know where the nickname virtual Dutchment came from. Give me the background. How did you end up there? Because when I google that I find you immediately, which I think is pretty crazy. Okay, well, interesting enough. Before I started my blog in two thousand eight I was traveling around the world, hired by a smart team, that's so IBM, another PLM influenters to to mediate and although I was a Dutchman, I was flying all around the world and I was thinking about the flying Dutchment, but then I realized I'm not at home at all. So I'm a virtual Dutchman because I'm everywhere around the world and later, I think recently, those the choice for virtual is even more significant for the type of business we are in. So it was a lucky choice at that time to choose virtual judgment for my blog. You're ahead of your time. You knew that we were shifting into this cloud based virtual world. At that time I was more thinking about being a virtual citizen. I was food for globalization at the time. So yeah, you were. You were a nomad. I'm curious then, like in twenty years of like getting in the P L M space, you spend more time than almost anyone I've seen thinking about this. Why P L M? What got you into plm being the hook for your career and the thing that you've chose to educate people on? It's a good question because initially I didn't want to start with PLM. I started my company called test it. We will focus on the knowledge management, tested knowledge, that was the knowledge an expert had compared to explicit knowledge, and I was fascinated by the brain. So if you look at my company logo, there is also the brain inside. But then I got dragged into my old context. I knew smarting from, and they asked me to help them in some projects, and for me, PLM is a kind of knowledge management too. I rolled into this type of activity, this and I discovered most of the fund comes...

...from the people, the interaction, the culture, and yes, there is technology, but it has still had to do for me a lot with with knowledge management, and that's why I still enjoy developing it. I'm curious on that. From like getting it in coaching is like one thing, but spending time during the type of research that you've done and putting that together into a medium someone could actually, you know, learn from, is a whole other difficult task. Why did you start the blog? What was the inspiration behind starting the PL unblog? Well, initially, when I started my Plm blog, I discovered that nobody was interested in it when a problem was solved, when I was flying around the world, because if it was an R and d problem, R and D was happy. If it was a sales then the seals or or the customer. And then I said, okay, we need to capitalize this type of knowledge, especially for the small and medium enterprises, because there is the only the academical books and where the rest there is nothing. Order is a vent information. And by doing this job I also discovered it's a it's a learning process and it's continuous learning. I was not as mature as I was in two thousand eight and also my opinion is changing, and that's a beautiful role I had as as a as a coach and then a mediator. You See so many implementations, you follow so many implementations, so it's a continuous learning process and untill now it hasn't hasn't stopped. That's the good news. The really beautiful part of it's created these conversations. I think I've seen every post you've made. There's five, ten, fifteen, twenty people getting in and commenting about concepts, and they're not just small companies. I'm seeing like large companies who, you know, do have the money. You are coming to you now, fifteen years later, with blogs that you might have written five years ago that are still completely relevant, which I think is super cool, and I'm going to dive into a couple of those now at a moment. And maybe the other point is I've been a teacher in physics before and I also learns from blogging. You have to explain things, is simple. Don't use too many academic terms, and and also by by blogging you learn to understand how things are connected, because it's I'm thinking continuously, how is this big fitting in a bigger picture? And if I wouldn't have done the blogging, I might have sitting down in one of the big projects and not get this understanding. I like how too, when you do your blogs, it's not just like a little nugget of a topic and then something completely different. I think one of the unique things you've done, like the series you had here at the road model based and the connected pl ap like there's nine parts to that blog, each of them build upon the other. I really like. But I think with blog three and four in that series where you start pulling out like a thought, and one of those thoughts you had what data driven does not imply it needs to be a single environment, a single datase that contains of information. It's about managing connected data sets that are federated and it's not about owning the data. It's about accessing reliable data. And you took the whole log around that. And that's...

...actually my very first question. And I think you think of PLM. When I got into engineering ten years ago, all I heard was single source of truth. That was the only thing I heard. It was like drilled into my head and I think today I still hear quite a lot. Why take that stance? What drove you to feel strongly about, you know, this connected, federated environment versus like a single source for everything pipes into just to talk me through the inspiration behind that. Okay, so let me first be more precise. When I talk about the data, I mean data sets stored in a database and they can be combined with meaningful information depending on their status and their relations, and also geometry shapes are pieces of information with properties. You can store in in a database, and the advantage of this approach is that all the data can be accessed without going through for people or who system silos, which is very much the traditional single source of truth concept. You store, you're deliverable in a certain place and then you think it's accessible for everyone. But first of all, most of the time only the owner of the data set knows if it's reliable or of the document, where in data sets you're not longer the owner, you're accountable for the information, but anyone who has authority access can use this information in their context, and that that makes it completely different the concept. And then, if you start to keep on thinking, would I like to have everything in a single database, maybe some vendors are dreaming about that, but even as a p discovered they cannot do the full plm scope anymore. So I think we've seen it's a mission impossible. And we have to think about federated data also, because we don't need people to interface if we have connected data sets, we don't need the guards or the people that are transferring data. And then, and I'll come back to my my brain analogy, the brain works the same that the brain is a kind of place where you store the logical connections, but when you find the details, you go to a federated environment where you looking through the details and you make your conclusions, and then also your brain will discover there is no single source of truth in the world. There is always the nearest sort of truth depending on the context that you explore, and and that's, I think, also coming back to the brain, exactly what Daniel Kindaman also says. It is thinking fast and slow. We always want to think fast, but then we go to the easy sources, but we need to be more precise and and think in federated me and more detailed. That's so there's a couple of things that will unpack there. One is like the data set side aside. I think that makes sense. The argument I hear often is we've got multiple vendors sets of tools that don't plug well together, so we want to migrate to something like I recently heard from a big company that they...

...invested a hundred million dollars to move all of their plums across all of their sixty five sites to one PLM. It failed. They end up canceling the initiative and they ultimately never did it. But that thought process right to go all up your C suite and look for a hundred million dollars to make this happen? People are worried about this. What's like your advice to someone in a leadership role or digitization role around how to get buy in on keeping multiple databases and just focusing on how they connect together? How did they even start that conversation? This is very much the discussion I recently had about system of record and system of engagement. If you look to two companies, their traditional approach was to provide a backbone for everyone where you store your information, your your systems of records, and this is relative efficient for traditional companies. But now, when we are getting into more digitalization and much more complex products, we cannot work in the same way anymore. We have to work in multi discptionary teams and we have to be more holistic because we are not just working inside our sidle and it's a different, different type of working. It's a different type of data and you need different type of people and and that's where usually the crash at management level that starts. They want to simplify it into one system again, in just an evolution process of people, instead of ignoring that people from my generation were grown up analog and the new generation is digital, and that processes are not longer than mechanical release, linear process but it's much more iterative. So there is so much, I would say, tension at the management level if you really want to understand what is the future and and therefore one of my points is don't migrate. Try to keep your systems record in place and create new environments with New People and try to connect and share where possible, depending on your product life cycle. Of course, and this concept is slowly, slowly getting understood at management level, that it is not so simple to just my great system to a single system like you mentioned in your example. It will fail. One of the things that I think is interesting is, like we've talked about this like single source of truth, you know, idea, for a decade or more, but the truth is there never was one. Big Manufacturers have at a minimum of PLM and the AIRP and right away that already has two systems. And even if that's all you had, which we know is not true, we've already got multiple record sources that need to be tied together. One of the one of the things that I'm curious about from your perspective is the vendors themselves. There's only really a handful of big vendors that provide PLM solutions. They don't make it super easy to plug into one PLM into the other and some of the argues that...

...the strategy my business perspective is to not actually allow the others to plug into each other. Do you see pressure coming from customers to the big players to sell and see emens and PTC to open up a Pi is like the software world, like what do you think can happen there? Because today it's hard, like it's time consuming. The slog like, how do you get there? So I don't blame the PLM companies because they have to be profitable also, and that's the first point, and I learned from working with the smart team, which had a public API opened and you could build anything. They couldn't maintain enough profitability to maintain the product. Technology changes. So you need to have a kind of Revenue Model S. E. P L M company, either through your Api, through your openings. But first of all, yeah, would you change a profitable business model which you control? Probably not. It's like asking oil and gas companies to be more sustainable. And why would they change that? Because at this moment, who is pushing for an open architecture? It's not the management, it's it's it's coming from users that discover it. Often, when you are very close to the software, you discover that the benefits of open architectures, but there's nobody on management level that has the education or the holistic view of the future, and so they will choose for what they know, which is a system backbound, preferably from one of the big vendors, because then you cannot be blamed for the wrong choice. And slowly, I will say, we will, we will improve, because I think it will not happen bottom up, but the new generation of management will start to understand and start to push and also illustrate the need for more openness, because there is no single closed system that is good enough for managing a connected enterprise. You end up with like a slightly dull Swiss army knife and there's so many functions. Right. Plim itself is so complicated as it is like it does so many important things. One thing that I actually said was if you think about your system of record, you don't necessarily want that to be the easiest place in the world do your work, because it's the place you're making decisions, it's the place that you rely on the data from, it's the place that you're trying to control what's going on. Is that bad things don't happen downstream. That's super easy, which is what you want an engagement system you know as things are gonna go straight. So it's it's a it's a hard balance between even if we could get it all one place, may not make sense. But as you look to the system of record approach, it took a long time to get this implemented before, in the early days of PLM, people said, okay, we have an EARP system and if you want to do something more with intelligence around product please use the PLM functionality from the earp or we add some customization to connect to two earp I think now, at this stage, we see that earp and PLM are accepted as two infrastructure for managing a enterprise and and product data. And... we are in the next wave. Because of digitalization, we're also able to connect people, not necessarily in their disciplines, and to govern the process they're following. But we are creating environments for collaboration and preferably multi disciplinary. The connection of simulation and design is very strong if it happens in real time instead of in a serial phase. The same for engineering and manufacturing preparation. If you do it in a serial mode, you lose down. So this kind of environments were never envisioned in the traditional PLM backbone model based definition is already quite accepted in the automotive and aerospace in the industry. Still we talk about packages, exchanges to the different backbones because there is no connected infrastrure, and I think this is the process where we are now. For the next ten years. Now we have to fight for the connected infrastructure, which is not a single system. It's to set connected systems and the value comes from the connectivity, from the Stream of information. I'm curious on two parts to dig into before we leave the PLM side against some of the engagement system side. You said something a moment ago that, like you know, years ago P L M was not accepted and people told them to say take your R P and use the PLM functionality. I think we hear a lot of that today about systems of engagement and PLM because it's a new topic. People don't fully understand it. What got people over the line that plum deserved a pillar inside of a big organization? However, many years ago that happened. What was it that that changed? I think it in the engagements that I did, was the following the logic of of product design and and and product data. Where is it created? When you have a conceptual part, why should you go to win ear P system to request the part number? Or why can't you ask a part number because you want to save the seven digits for only manufacturing parts? So showing the lack of logic in in in the business flow was it was a reason to explain. Look, this is the more natural flow, without thinking and systems to develop a product. And then you see that even if the EARP system has a PLM module, it's not designed for working progress, it's not designed for conceptual thinking. And more and more we there the term virtual. We're moving to the virtual enterprise before we go to AARP. So companies that I would say are aware of those trends. They see that we need to invest much more in the front end of product design because that's where the costs are defined. That's where the behavior is defined than in the execution part. And then the second point that also contributed to the acceptance of PLM was the fact that companies started to have multiple manufacturing locations...

...where initially, of course the earpiece vendor says, if you standardize on our earp everywhere is the same, but of course the plants are everywhere different, the local purchasing is different, but the probact definition you would like to centralize. So you need to have a centralized environment where you push your probat definition to the local earpiece and and those are the, I think, two major trends that led to the fact that plm became visible outside the engineering environment as a tool for engineers. That's cool. I have interested in that now and the transition to what is the next step in evolution of tools. A year wrote something and your blog talk about. You know, in the sixties we were we were aged paper drawings and electronic drawings and three D cat and now we're moving towards this like much more data centric, item centric, model based system, which I thought I saw one of your blog as a comment about how people interpret model based to just be three D and it being actually more than just three D. There's a whole bunch of acronyms that are very, very close in this space, but I think that makes a lot of sense that. The question I have for you is when we start a collab four as years ago, I remember speaking with an analyst and they talked about product innovation platforms him and I saw that in one of your blogs. I feel like that conversation has slowed a little bit. There still is that right three d experience, you could argue, is, you know, the essence of what that was. But now they're starting to be a ton of like stand alone, very focused systems of engagement that plug into other tools, like you mentioned open bomb with Oleg and like what we're doing with collab. And thenre's SIM scale. On the FE said, there's lots of stuff happening. which path do you think is actually going to take system engagement train? Is it going to be bolted into the big PLM and something bigger, or is it going to be plm with a whole bunch of very specific systems engagement and tied to it? So I think you still need a backbone as a system of record, because even with your systems and engagement, you will have to publish at a certain moment your results to to the enterprise for traditional order thing or manufacturing processes. So in the existing system of records they need to be preferably open enough to be able to receive this kind of domain specific packages, or even, preferably they are connected. But then you you have the challenge if they are connected, which data do you put in your your connection? And that's, for example, the big difference. If you look at this three the experienced platform, they try to be one data model, where PTC and seemings. They have a kind of PLM backbone and they create interfaces from the different tools to this backbone. Of course, interfaces are more limited than a connected data model where you can create everything. But the question is, yeah,... far do you need to go to connect everything to everything? And that's where this discussion about the Federated Enterprise comes from. Your domains need to be optimum, designed for the end users and the working programs, but they need to have a kind of gateway to publish, do a system of records and preferably are those gateways standardized. I think that's the concept I have in mind when I think about the future. Yeah, I mean it makes sense if you look at like the end user and to think about who those people are. They're likely getting pressured to do more right now with less and like a fraction of the time, and then trying to sift through a bunch of data makes it hard. It's the reason why, like you see an automotive, like an open issues list, a lot of companies are still using homegrown stuff or they're using spreadsheets and stuff that doesn't it's because it's easier, not because it's better. It's just easier for them to do because there's so much inside plum to actually unpack, which I think is the danger, and having too much of it, because then you get the same problem in your system engagement, which then you fault. We failed and the biggest challenge is in people, because also with the discussion with all to replace excel by the bond. But the beauty of an excel is you control it fully. Everything is there and you have it not nothing can happen to it. But if your excel suddenly becomes a shareable environment where people can change information, where people can add information, then you lose your feeling of control and that's an attitude that has to change. We have to learn to be accountable for data, but not the ones that control the data. That's why systems of engagement should focus on multidisciplinary collaboration, not a single discipline, because then it's a system tool. But if it's a system of engagement yet you benefit from that other people share the data, contribute to the data and understand what is happening, and that's where the big benefits thone. And on that front, like talking about the systems of engagement, I think most times, like I like to re wrote in your blog about it's not going to be a system of engagement, there's gonna be many, and I think that's true. Like look at get hub in the software world and the ecosystem around get hub, I would argue as not even systems of engagement. They've got systems of automation, they've got little plugins, they've got full engagement tools, they've got a million things, and that's also true in the sales world. SALESFORCE has literally sales loft right on top of it, which, if you look at like what coal I was trying to be the PLM, almost identical positioning. And there's more than just sales loft right there's Gong and there's all these other tools and it's because this data is important in salesforce, but it's hard to use. It's hard to use day to day. I'm curious, like for engineering leader, like where, where to start? Is it architecture first? Is it people problem first? Like this is an overwhelming situation. Now, like where do you actually start unpacking information from? I think for my personal experience, it all...

...starts with educating and experimenting yourself, because if you have faced the problem, if you have under stud the problem, then at least you can also probably define what is the next step and what is the division. I mean the first time I worked with Google docs and somebody was changing my text or adding my text, that was a realization. Yes, you can work together in this way. So I don't have to wait till my form is filled and I ascended by by email. So this is a kind of experience that people have to go through. And also as an organization. So if you work in the team, don't accept if somebody says I will email you or I will send you an update when I'm ready. No, you want to have continuous real time information and visibility. And as an engineering leader, if you're able to implement this for design of Simulation, relation or, for example, designed to manifest regulation, then you start learning the process. That's why I said one of his definition is very nice. First step of learning the future, because the it's a little bit mature, already did the processes thanks to automotive and aerospace, but there's still so much to learn. But the same could be also done with design and simulation integration or later with the service or supplier interaction. So pick your area where you have the biggest gain to expect by working differently and start to imagine the process in the future and don't do it at once. That with with minimum viable products deliveries and learn and improve while doing poc is something I hear constant line and one of the things that you just said is so true. If you're not bought in to making a change, even with the tools, okay, at the tool you pick is not the right one, but you're not botting into the change, the time and money your investors the huge waste, because there's going to be something that comes up and it's easy to stop and it's a decision to just keep pumping through it or not to actually get there, and I like what you said about like starting with a nugget and iterating from there and growing, because that's not the way Plam has been rolled out for the last fifteen years. Most Times it's like four year big implementation windows that are very complicated, and that's why that hundred million dollar example I gave you never happened, although I have the feeling that this type of implementations are also getting less and less because companies that should have invested in traditional plm they have done now their final technology upgrade. Now the battle is really on the best systems of engagement and and here also we have to realize that organizations can be working in a hybrid mode with systems and records, that system of engagement. But make sure your people don't work hybrid. They are committed for the future or they are committed for the Syste of record approach, but if they have to work in two way ways,...'s like the same for you. If you kind of focus on your job, it will be half half. There's something I tell my team all the time. If you're split, you're not effective in both. Your like ten percent effective in both, because the switching class is so high that it just hurts every bit of it. I want to ask you is one thing about P L M before I just lead into a couple of final thoughts here. You said something just then about the system of record. Most of them have matured that process and I think that's true in the big enterprise and most of the small companies are gonna do something different anyways because they didn't want to spend money in best do you feel that most big companies, automotive, aerospace, industrials, medical, have basically married themselves to their infrastructure, like the underlying system of record infrastructure, for the most part, for the next ten, twenty plus years, I think the system of records will remain relative stable unless there is a technology change. I've seen some companies running on main frames say, okay, this technology gets outdated, let's see if we can do the same data model or even the medium data model on on modern technology. But the big shift of data driven is is not part of this. This change is it's more underlying infrastructure and trying to keep as much as possible the same ways of working. Sometimes it might be a pricing issue. I've seen a customer that the cost of maintenance of the main frames worth so high that they say that it makes sense to change technology. But yeah, as I said, I don't expect big changes on this approach. And the medium enterprises, they are always already kind of system of engagement mode because the the interaction, the collaboration is possible in the small company and a lot is done in the brain. And Yeah, what do you want to store outside the brain? That's the question I'm curious. Last start on the model based enterprise and always definition approach out of aerospace ands fans are ahead in that game. What does the like mbd land for you, offer to the brain that you think gives people like that next set of you know, ideas or system engaging like why is it that mbd is like that knowledge system, like that way rewire your brain? Why do you think that that's the path to it? Yeah, so, first of all, I don't think that the automotive and aerospace are ahead of the game, but they are ahead of the game in model based definition because they rely heavily on exchanging in an efficient manner data with suppliers. And then you see that the traditional way of working with drawings, with documents, is too much time consuming, it creates errors, so they learned an efficient way to exchange a model with its related data, kind of mini concept of data driven. Yeah, but aerospace is not so innovative, automotive is not so innovative. What is enough? Eight if it's a test law,...

...which is software on wheels. But the traditional car manufacturers, they don't innovate so much. Also they try to make it now based on batteries. So the real innovation of model based approach is about having different data entries as the legal entity. So the here in model based definition, the three D model is the central entity and you you connect all the information. But in, for example, mode based system engineering, you might have simulation models of a logical model that before you even have a physical model that controls the behavior of the of the product or the system that you will and there you see, there are so many different parts of models, your manufacturing model, your operation model, that it's not a single environment anymore. But they all need reliable data and they need direct access to the data and not through people. It's funny where we are boarded your personal or teams. That and the simple sense. The main thing we were talking about was how do we do even a better job as a software company connecting them to the right data so there wasn't gatekeepers in between. And this is like, you know, a small, relatively small, Software Tech Company, and we still are talking about how do you advance that? And I think when you step back ten steps to the Engineering Worlds deeven harder. Right, you never know what the right which is the right revision, which configuration you're working from, like watch change. How decision was made is so hard to know. But I think the key takeaway from this discussion here is that think of an open architecture, federated model, connecting so you have the right data to do the right job at the right time for the right person. Like that's the way this is moving. It's hard, but start small, start with a nugget, start with the place to move from there. And One interesting thing I've learned recently the data need to be under present accurate, and that's why you need accountable people, because if you want to run algorithms on the non accurate data, you get the worst results and garbage in, garbage out your algorithms. I mean, if the data is not correct, you will create a mess and people will not trust the system and therefore fall back on what they did before. Yeah, I was just gonna say it's all trust, this whole langage trust when it comes back to it. Thank you so much us for being here today. Like I really appreciate the perspective and I'm looking forward to the next you know, five, ten, twenty years of blogs. I don't know how many years you're going to keep making blogs, but I'll be there checking it out and appreciate it. Yeah, it will be a challenge. I mean that the next ten years are going to be quite decisive, I think, for data driven environments, if if we're going to make the bake through. But yeah, there is so much learning to do. If there was a blueprint already that we could use, then it would be easy. We'd be retired and on a beach somewhere. You maybe earlier than me. All right, well, we'll try to figure it out together. The beach doesn't look like the most exciting place to retire. All right, we'll find another place...

...amountain. There's something cool to me. Thanks for this interesting discussion, because I think this is what we should have around the world and I'm looking forward to follow up discussions. The awesome thank you very much. Thank you collab is on a mission to accelerate the pace of engineering innovation by giving design teams a better way to work. As an engineering leader, you know it's crucial to empower your team to do their best work. Let collab help you achieve your goals with our web based tool that makes it easy to share and review cad files with anyone, so you can focus on the work that batters without missing a beat or a bolt. Learn more at COLLAB SOFTWARE DOT COM. You've been listening to pure check, a Colab podcast. Keep connected with us by subscribing to the show in your favorite podcast player, and please leave a rating on the show. That helps us keep delivering conversations about how the engineering world is changing and how you can challenge the status quo. Until next time,.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (18)