Transcript of Bridging Data between OT and IT: A Conversation on Data Management with Jan Meskens

David (00:00) Welcome, you’re listening to the IT/OT Insider podcast. I’m your host David and we bring you the latest insights in shaping the world of Industry 4.0 and manufacturing. Today I welcome Jan Meskens. Jan is a data consultant with over a decade of experience in the data management domain. He also teaches several courses on AI, data management and writes a super interesting blog on medium. I particularly love his sketches he makes about why, how and what around data management, AI and other topics. And that’s actually also the reason why I started following Jan in the first place. Jan, very happy to have you here on the podcast. Jan Meskens (00:46) Thank you for inviting me, David. David (00:49) My pleasure, my pleasure. Today we’re going to talk about data. Now you have experience on the IT side of data management. I’m more from the OT side. So I would say the aim of today’s that we try to somehow make the bridge. But maybe before we start, a short introduction from your side about who are you and what have you worked on in the past years? Jan Meskens (01:17) Okay. So actually my background is in user experience design. I did a PhD in human computer interaction. And that’s because I’m always been interested in how machines and people can work together. Machines in that context were mobile devices, PCs and so on. How can we make those as usable as possible? And later on, I switched to consultancy and I jumped into the data consultancy world and there I saw that usability and data, that’s something that didn’t really exist. Making decisions in data, making conclusions is often done in big Excels, which can only be understood by one person. So all these concepts that I learned before. weren’t applicable anymore in the data world. And that’s something that drives me in every mission that I do. So as a consultant, I worked in different sectors, different assignments, but always from a point of view, how can we make data as usable as possible for the people that should make decisions, should use it in their processes and so on? Because otherwise, it’s very difficult to adopt data -driven approaches. Being a consultant is in different roles. In the beginning, it was more hands -on. And then later on, it’s more project management, team lead architect in data projects. And besides that, like you already introduced, I’m also teaching the data field to undergraduate students. and also in short trainings. And that’s good for me for putting things together. That’s always an opportunity to tell a story around what you do and to see the bigger picture. David (03:27) Yeah, it’s interesting. It’s so many parallels. And of course, also on the shop floor, Microsoft Excel and paper still, I would say, rule the world. I think maybe I would say as a first question is, I would love to understand from your point of view, why companies start data projects. who starts them, why are they started, who drives data projects, I would say from a business point of view, from an IT point of view maybe. Jan Meskens (04:01) I mainly see two directions. As always, there’s in common cases a bottom -up approach at companies that some business domain or some business team sees an opportunity in leveraging data. Leveraging data can be… applying an AI algorithm or an AI tool to simplify a process or to get new value. It can also be a finance team that wants better reporting for their finance numbers and so on. So that’s actually some domains in an organization that see opportunities. And for those opportunities, they would like to implement a use case, a use case where data is being introduced and helps them. On the other hand, you also have visionary leaders in organizations that really see the value from a top -down perspective. They see, as we as an organization, invest more in data, then will this influence how we work, new business value will be created, and so on. So from those two sides, you see projects growing. And what I like or what I believe that can help here a lot is the data literacy that can diverge from the top down and the bottom up. If the leaders don’t understand how to use data or your business teams aren’t aware of the possibilities of data, it’s difficult to find each other. So that’s why it’s in two directions that it often occurs. David (05:54) That’s interesting. I saw on the one hand, I heard you say data domains, which I’d love to talk a bit more on that. I also heard you saying it’s a top down and also bottom up approach. So why don’t we start first on the top down bottom up approach? This is more about, it’s change management. It’s, I think on the one hand, you wanna educate people what is… possible, you want to inspire them, but it’s not probably only inspiration only is not a lone. So you also need that mandate. Have you seen with the customers you worked with, have you seen cases where this goes well or it goes sideways? Jan Meskens (06:45) Actually, the best success stories are when top -down and bottom -up find each other. Because if you only have bottom -up and there’s no one that sees a strategy in this, then you end up with five or 10 different data ways of working in every domain. But somehow you need to connect everything. So then you need someone at the top, that sees the value and sees the broader picture. So that’s for me, a success driver is to find both. And then we come closely to people. Actually, you need right people in your organization to bridge this gap and to find each other. And you need to invest in your people, to educate them and at least to understand what’s the meaning of data. So… When it goes wrong, then it’s often also the case that there are no, not the right people or the value isn’t seen in what you can do with data or only part of the company is seeing what you can do with data. And that makes it hard to deliver value. David (08:04) Yeah. One of the articles you’ve written on your medium blog is called, once you POC, you can’t stop. So once you’re, or POC, so once you start a POC, you can’t stop. I actually use that phrase quite a lot nowadays in presentations. So thank you for that. And I’m crediting you Jan. So I’m crediting you in the presentation. So, but is that… Jan Meskens (08:26) Okay, nice, thank you. David (08:33) I assume that’s linked to what you’re just saying. If everybody just starts running a POC, then you end up not in a good place. Jan Meskens (08:35) Yes. No, indeed. But it goes a bit further because a proof of concept is something that ends. And at many companies, a proof of concept is something that’s being executed and runs forever. And that’s why I wrote the article, because at a certain time, as a company, you would like to do something with data, and you have four POCs, and you should do something in the POC space, image your tools that are… created each POC by a certain manager or a certain team. And that makes it really hard. While if you do it the right way, a POC is a very powerful instrument to understand what are the possibilities of a certain technology or a certain thing. But if you assess it, if you learn from it, then you should do it the right way. Then the POC phase ends, and then you should do the actual implementation. A POC is not the end goal, it’s a learning instrument. David (09:44) It’s a learning instrument that I like that as well. So suppose that you would start a data project and suppose you would start with a POC first. How would you do that? Would you say like, okay, we’re gonna give that a clear, would you put an end date on it? Would you put, I would say desired outcomes on it to achieve? How would you? How would you design the what happens after phase? Jan Meskens (10:15) I think in data projects, I often try to find out for an organization what are the most relevant data use cases in your organization right now. Discuss with different businesses in different domains to check what can we do with data and where do we see the most… valuable use case. Most valuable means in business value that you can get from it, but also the initial investment that is needed to realize the business case. Those both go hand in hand. And then if we identify those use cases, we pick one. And for those use case, you define the possible outcomes, what you would like to prove with a technology. that you say, OK, we would like to assess with this technology, can we solve the use case or part of the use case? We would like to assess if the people that are going to use what we do with the technology, that they can use it, that it’s usable in their processes. And if the process is really simplified, if what is being said around the technology that we use, that it’s… that it can be used in practice. So those are the most value drivers. And then afterwards, you can use the POC, what you learn from it to define the next steps. You learn typically how complex is it to do the implementation, what you all need to do the real implementation. And those are the value drivers or the ingredients for creating bigger value drivers in the future. I usually talk about use cases. For a use case, you start with a proof of concept. Proof of concept is something to learn from, but at a bigger scale, on top of your use cases, I talk about initiatives. Because at some point, you need to do things that go wider than only the use case of one team, and then you should start initiatives. But you learn which initiatives to take by implementing use cases. David (12:39) That’s interesting. If I try to make the parallel to the operational world, the OT world, I think one of the big challenges we have is to really understand that you cannot plan a data project 100 % in advance. And because in operations, in manufacturing, that’s how we, I would say, are used to build assets. So we are used to have a very rigid engineering phase where we… where we actually engineer the position of each and every bolt in a plant. It is designed, it is simulated, you name it. And then we built a plan. It’s a real typical waterfall approach, which is perfectly fine because you don’t want to build a plant in an agile way. It is what it is, right? So you have this waterfall approach, you put in all the equipment, you do the testing, et cetera, et cetera, et cetera. Jan Meskens (13:30) Yes. David (13:37) and we really, really used to work in that way. But then these, I would say these more IT OT teams come in, these data teams come in, especially when IT comes in, and that creates a bit of a clash of the titans where people with a manufacturing background, they go like, okay, how much money do you need? What is your project plan? And when will you be finished? Okay, and from IT perspective, as you mentioned, we go like, yeah, the problem is, I… might not know exactly how much money I need because I also don’t really know how we are going to solve, I would say, all your problems, whatever all your problems might be. And I also don’t really know how I’m going to start with it. So let’s start small. Let’s try to figure out. So I see that clash happening. And that’s something we should, I would say, it’s important that we change that. I just want to. Have you seen that happening as well? Have you seen it happening with maybe within other domains? Jan Meskens (14:40) Yeah, I recognize what you say, David. And I think it’s not only in the OT world, but I understand why it occurs in the OT world. But having a decent plan, a plan that says where we’re going to start, where we’re going to end, and what to do in the middle, and also the budgetary around it. But there are reasons. why a complete plan is difficult to follow in an IT implementation. And as many books have been written about that, why it’s difficult to plan, what are the unexpected things that can happen. And also if you see something, change occurs in the requirements and so on. So that’s all the Agile world that occurs. And… It are different worlds, doing everything through a complete plan or an agile implementation. And then it’s the maturity of an organization in that. If it’s the first time that you’re confronted with this, with doing a software implementation and never had experience in agile implementations, then it’s difficult. But there are organizations that are really used to that. and where also OT people are aware of the agile way of working in an IT landscape. So it’s all about a bit of maturity in this kind of work. But what I mostly do is try to explain very clear the approach to use in running a software implementation because… Many times an Agile implementation is seen as a blank check where you can do whatever you want. But actually, that’s not Agile. Agile is just very structured in the way you work. And Agile is all about communication, having very frequent communication and using frequent interactions above complicated processes. using working tools across documenting things. So that’s our all strong principles. And if you can say, give us two weeks and you have a pretty small thing where you can start working with and two weeks later, later you get an additional thing, it could always give feedback. That’s something you can sell. But the first time will be a bit harder. And you should do it the right way. That’s always the tricky part. Agile is not, we do something, but we don’t know what. No, Agile is following certain principles. David (17:38) and communication, communication, communication, identify your stakeholders. Is that maybe to jump to a totally different topic? Is that also why you started drawing, why you started making sketches to make… Yeah. Jan Meskens (17:39) Indeed, communication is key. Yes. Yes, indeed. Sketching things is very powerful for two reasons. The first reason is just visualization. Visualizing things is something that works. But the power of a sketch is that you can visualize it in such a way that it opens a mind for giving feedback because a sketch is never finished. It sees something draft and then business stakeholders are aware of the draftness of your sketch and they wanted to sketch as well to improve things and that works. That’s something clear enough to explain but draft enough to receive feedback because if you have a top -notch visualization, if you created a top -notch visualization then people say okay or not okay but not really feedback or drawing or no interactiveness. And that works in drawings. David (18:54) That’s interesting. So you basically draw to trigger feedback. Jan Meskens (18:59) You need. And you trigger feedback and you trigger also that the people in your meeting also start to draw and then they can more clearly explain what they want. So it’s a bit a mindset and that’s how it’s, it’s, it’s gross. David (19:14) for a programming nerd as myself? How should I start sketching? What would you advise me to start? Jan Meskens (19:30) Yeah, that’s actually pretty easy. It’s drawing like you did if you were a young kid. It’s just drawing stick people. And if you can recognize people in your drawing, that’s already enough. And a PC is a box and so on. And then you start to improve it a bit. But it’s not about drawing perfectly. That’s what you do sometimes if you draw for a website, a blog article or on social media, but really drawing in a meeting on a whiteboard, yeah, you can do anything wrong, I think. Drawing a factory is just a rectangle with some triangles on top. So that’s one thing you can easily learn and it’s by doing. How I improved it a lot is by drawing during a meeting for myself. doodling all the time. And then the more you practice, the better it works. David (20:29) Yeah. Yeah. So that maybe I can ask my children to create me a template or a library of potential icons. So I just tell them, how do you imagine a plant or how do you imagine a person? And… Jan Meskens (20:48) Yeah. Indeed, and I think they are not yet influenced by the complete PowerPoint generation, so that helps. David (21:00) Yeah, absolutely. Hey, maybe a fun thing which I recall is, as I said in the introduction, I started following you based on your drawings, based on your articles, it’s already a while ago. And then half a year or so ago, we had a first call, I send you a message, I said like, hey, Jan, I think we have some things in common, let’s talk. And I introduced what I was doing. So I said like, yeah, I’m working more on the OT side with sensor data. or IoT data, that type of things. And you said like, yeah, but I’m doing something slightly different. I’m working on the IT side, data management, data governance. And then you refer to me as, ah, yeah, so you’re one of the engineers. Okay, so in your mind, I’m always wearing a hard hat. But maybe besides this joke, what is an engineer for you? What do they do in your world? And also to refer back to the data domains, how do you see engineers fitting in a certain data domain? Jan Meskens (22:04) Yeah, so maybe it’s interesting to start with the last thing you said, the domains. So because I remember our first conversation and I was already thinking about the different buckets of people I’m working with. And that’s why I compared you with the engineering bucket. But actually those buckets are the domains I’m talking about. And a domain is… a certain business domain is a group in an organization that is executing certain tasks, is doing certain work. And if you see it a bit broader, they are using a typical type of data for doing their work. For example, you have a finance domain, people that are doing a lot of things for finance calculations. You can also have a domain for marketing and so on. And that’s why I initially thought, okay, we have OT, we have engineers and that’s potentially also a kind of domain. And you can see it in two ways. You can see the engineers as a complete separate domain, but I’m convinced that they contribute to many other domains because engineers are partially responsible for things that happen with machines, things that happen with sensors, measuring things, certain processes, doing analysis on top of those processes. But the outcome of this is being used everywhere in your organization. Because if engineers have a good analysis of their machine data, that can be the source of doing a good financial calculation about what can you do. with your machines in the coming years and so on. So what I said a half year ago was an engineering domain. And now I think they might be part of their own domain and other domains as well. And what makes up an engineer name for me? Engineers have typical kind of analysis they would like to do. And it’s a lot of time series analysis because you have sensor data. It actually streams of data. And I often see engineers looking at lines. That’s a line and seeing jumps, jumps on the line and seeing patterns. And then if the pattern is identified, seeing how many times is that pattern occurring and so on. And that’s a bit different from other domains. the strength of engineers is that they are quite skilled in doing those analyses themselves. So if you can provide the right tools to engineers, then it should be possible for them to do the analyses by themselves instead of using typical data analysts for this, because that might even slow down what they would like to do. David (25:26) That’s interesting. I’ve noticed that as well. So obviously if you just take, if you go back a couple of years in history, I would see if the problem that needed to be solved was using, it was based on sensor data, then typically you would work with a system holding that sensor data. You would use tools made to… visualize and to analyze sensor data. If the problem was more relational data focused, then you would use typical BI tools on the IT side. And those two worlds, they kind of lift. next to each other and only for, I would say, very specific data exchanges you would build an interface. For example, you need some order data from an ERP system or the other way around you would like to feed your ERP system with the amount of product produced on a certain day or for a certain order or whatever. So you would have these, I would say, almost point -to -point connections which were built. And now there is this strange thing happening. Well, strange. I I think it makes sense, but there is this thing happening where data problems, no matter whether it’s sensor data or relational data, seems to become owned by data scientists, by IT teams. You notice that it might even slow you down. I think that’s a very important remark you made. And I share that remark. I think it’s extremely interesting or important, I’m sorry, to make sure that, well, Both domains, they have their strengths, make sure that they can work within their strengths, but also figure out a way to collaborate. And one of the concepts there, and that’s why I like to go to as a next topic, is to start implementing data products, operational data platforms, as I like to name them. which include expertise from both domains. So maybe as a first question Jan, a data product, what is that from your experience or with your IT hat on? Jan Meskens (27:49) Yeah, a very good question. Because there is some discussion around what is exactly a data product. There are two common definitions. And the first one is the one that is mostly used, that the data product is actually making your data or part of data reusable as information. So actually your raw data, you’re going to… make it trustworthy, reusable as a product, then it can be used by others. And that’s actually the data part. So for example, customers could be a product that you say this product there, that’s a trustworthy source of all customers in your organization. The other definition is more about products, the data part, as well as what you do with the data. So you could say a certain dashboard is a data product, a data product where you also visualize the number of customers that you have. But yeah, I prefer the first definition, but it’s used in both ways. The latter is used product archetype, but product is the data that you create into. information that can be reused, integrated with other products, integrated in different softwares, data can be exchanged and there’s metadata describing what your data means. David (29:31) One of the differences I also typically see from IT versus OT is again, I come back to the more traditional way of building an asset and maintaining an asset is that when we build some data system on the OT side, typically we do a Kpex invest. So we just invest some money, we build a system and then it runs for five, 10. 15 years at a certain point in time, either the system just stops working or somebody shuts it down. But it is mindset of a one -time invest and then we’ll see what happens. On the IT side, it’s a world which is… I think mostly dominated by operational expenses. So it’s a, I would say a running cost. You run a system, you maintain a system for a certain while. So I’d like to, I would say focus a bit on that. So suppose you have this product, a system of systems maybe. So it contains several data sources you do. It contains a pipeline, it contains, I would say, but it’s a product. So that means that the product has a certain, yeah. It has a certain usage, it has certain users. What are the most important aspects about running a product from your experience? Jan Meskens (31:02) I think that’s again a good question. Also, I like the comparison between CapEx and OPEX. First, a very small thing on that, that the shift in IT is even more towards OPEX since we’re working in the cloud. Because before, CapEx was the infrastructure and OPEX were the people working on it. But now everything is OPEX because you hire it by minute. And then to go back to your question, the most important characteristics of a data product, first of all, that’s ownership. Someone should own a product. If I go back to my example of customers, someone is responsible for the customer products to shape it. At some point, if we have a new type of customers or if we have new important information of customers, someone… should take the decision to extend the products that the rest of the organization can rely on that. So ownership is where it starts. If you don’t take ownership of your data products, then at a certain moment they will stop working or become irrelevant. Another advantage of having clear ownership of products is that there is someone with a clear expertise that becomes the owner of a product. And I think that’s particularly relevant with products that you should be able to build on OT data, that it’s someone with experience in that field that can decide how can we shape the OT data in a product. So that ownership there it all starts with. And then you need tools, you need technology. You need to document it, you need security and so on. But if you don’t have ownership, it all becomes irrelevant. David (33:07) And I remember your statement that the product owner of an OT data platform should understand the OT world. Something we also sometimes I would say encounter in the more negative way. Hey, we’re getting to the end of this podcast. I always try to figure out interesting ways to… Jan Meskens (33:16) Yeah. David (33:35) I would say sum up the conversation. And maybe as a generic statement, Jan, if we really want to become a data -driven business, we have to, I would say, it’s the entire business which should work together, I assume. We are indeed one of those OT is one of those buckets, one of those domains. But I assume that there are many roles to fulfill. So if you, your advice to companies today, if they want to become a data driven business, what should they do? What should they implement? Jan Meskens (34:18) For me, it’s very important to see the bigger picture. And with the bigger picture, I mean to see a kind of a strategy around what you would like to do with data. Because in a lot of companies, you have different corners. You have the OT corner, you have an IT corner, you have a finance corner, and so on. And in all those corners, people are doing things with data. But there is not necessarily one thing that connects all those initiatives. There’s no plan behind it. There’s no governance behind it. And those are all things that you can do in a strategy. And if you have a strategy, then you think end to end about data. Data about how is it being produced, who is producing the data, which data are we going to store. where and how can we get this data in a more analytical application to do analysis on top. And what I see now frequently is that companies only see the different steps in this bigger process. Typically, you have a digital transformation in an organization. Digital transformation as in we’re going to set up. new systems to work more efficiently. But we don’t take into account how to get data out of those systems. And then you run a complete implementation. And at the end, you should be able to report on that. But if there’s no way to build an interface on top of the systems that you just built and you bought the wrong system. And that’s how a strategy can help, setting some principles, seeing the bigger picture, and thinking end to end about data. across IT, OT and all other domains. David (36:16) As a final, final, final question, I assume you like to read books, and for the ones who are watching this podcast, there is a bookshelf behind you. I assume it’s a physical one, not a virtual one. Jan Meskens (36:34) It’s a physical one. I can touch them, yes. David (36:37) So I have a couple of books here behind myself as well. So I’d love to know from you what are the books you would recommend our audience? What are your two or three book tips you’d like to give to us? Jan Meskens (36:55) Very interesting question, David. I have two books in mind. The first one is actually a bit broader than only the data field, but it’s such a nice book about running projects, what can go wrong and to learn from, and that is The Phoenix Project. Actually, it’s not a very recent book, but I started to read it only two years ago, and it was really an eye -opener. While reading it, I put faces of former colleagues on top of the people in the book. So it’s really, yeah, you should read it to understand it. And if I talk to people about a book of an IT project that fails, yeah, that seems to be strange, but it’s really funny to read it. I don’t know if you ever read it, David. David (37:50) Yeah, I’m so happy that you mentioned it. I not only myself, but also Willem, we live and breathe that book. I love it. I had exactly the same experience. I was reading it. I think just already in the first chapter, I envisioned projects where I went like, yes, I had that as well. It’s even, I have to say, When I read it, I can’t remember how long ago, four or five years ago, I guess, for the first time, it really triggered me to start thinking about organizational aspects. I would even dare to say that the Phoenix project is the basis, the foundation of everything we started to do around IT/OT conversions. So for me, it’s an extremely, extremely good book. So thanks for pointing that out. Jan Meskens (38:46) Yeah. So that’s the first one. Then the second one is more data specific, and that’s Data Management at Scale from Piethein Strengholt, who’s working at Microsoft. And that’s actually a real good book to explain everything around data, defining clearly what is data, why should you start with data, which systems exists, what is data governance, and so on. But it’s really well written and that shows how everything connects together. And I think this year, the second edition of the book came out and there is also data mesh included. So also that topic is very well introduced. David (39:42) We now already have a topic for a second podcast. I’m sorry, Data Mesh is something we should definitely also talk about. That’s a book I didn’t know yet. So I’m going to put that on my to read or to buy list. Obviously, I’m going to put the book recommendations also in the show notes on whatever platform you’re listening or watching. this podcast. And now that you I would say because you mentioned the Phoenix projects, this wasn’t prepared. So this is just a thought. I’m gonna organize a small giveaway. So for the ones who actually listened to this point, so to the end of the podcast, the full 40 minutes, if you send me just a message on LinkedIn or via email david@itotinsider.com and tell me about your data project. What went good? What are your learnings? Why did it fail? What did you learn from that failure? I’d love to hear from you. And then I’ll ask one of my kids to randomly pick one of the submissions and I’m gonna give you a copy of The Phoenix Project. I actually did it already a couple of times in my past and everyone who read the book send me a message saying like, wow, thanks for that copy. And, Jan Meskens (41:05) It are busy times for your kids, David. First they need to draw icons for you and now they need to select the winner of the book. So… David (41:14) I love to delegate some of my work. Jan, thank you for the super interesting talk. Thank you for joining this podcast. Jan Meskens (41:18) Hahaha! Thank you for the invitation, David. David (41:30) Until the next time, bye -bye. Jan Meskens (41:32) Bye.