3#17 - Håkan Edvinsson - Data Diplomacy, Enterprise Architecture and Data Governance (Eng)

"We don’t need Data Governance where we don’t have anything to fix."

How can Data Diplomacy transform an organization into a data-driven organization? This episode brings Håkan Edvinsson, a visionary in data management and governance, into the conversation, revealing the intricacies and impacts of Data Diplomacy in Nordic organizations. Håkan's journey from business data modeling in the 90s to robust governance practices today offers a treasure trove of insights. Together, we dissect the evolution of enterprise architecture and its role in business innovation.

Discover how data governance is not just about maintaining quality but is a dynamic force that propels organizations forward with each structural change. We discuss the concept of data design and how this approach is shaping the future of responsible data usage in companies like Volvo Penta and Gothenburg Energy. Our dialogue uncovers the importance of integrating governance into decision-making and planning, ensuring data is not just managed but used as a strategic asset for innovation.

The finale of our discussion broadens the horizon, touching upon artificial intelligence and its relationship with traditional data practices. We challenge the status quo, urging businesses to embrace a leaner governance model that aligns with Lean and Agile methodologies. Alongside this, we unravel the subtle yet crucial distinction between data and information, arguing for a proactive business ownership in data design and governance.

Here are my key takeaways:

• If you want an organization to last, someone has to define key terms.
• Data Governance and Data Quality should not be done reactively, but rather by design.

Enterprise Architecture

• Connecting the work of EA to certain project gates, is underpinning a reactiveness in EA.
• EA claims to be the master interpreter of business needs, yet EA artifacts are based on second hand knowledge.
• Architecture as well as Governance are supporting a development, not dictating it.
• EA is NOT the business designer, just an interpreter, a facilitator, that enables those with 1st hand knowledge.
• Don’t generalize away from business reality.

Data Diplomacy

• As long as you are working with operational data, you need to embrace business data design.
• You need to bridge Business with IT.
• The «gravity for change», mainly through external factors provide management attention.
• Use these external triggers to create more with less.
• Dont talk solutions and technology - too many opinions. Stick to the data.
• Focus on what data should look like. Base your work on the facts.
• Enable people to understand data, requires Data Governance to take a facilitator role, not an excellence role.
• «Being a hero once doesn’t mean you are lasting.» - you need to find a sustainable way of doing data work, beyond task based, checklist compliance.
• Establish a Data Governance network that represents the entire organization.
• A common language and established tacit knowledge can speed up processes.
• You need to be ready, prepared, and on the edge to ensure you are resilient to change.
• Integrate your data decisions into the management structure.
• Firefighting gets more credit then fire prevention.
• Traditional Data Governance is too focused on operational upkeep, laking a future outlook.
• Data Governance don’t rely have the means to state: What should it look like in tomorrows world?
• Entity Manager: taking charge of definition, label and structure of a certain data entity, of the data that we should have.
• A Facilitator works with these entity mangers in their respective area.
• Advice against top-down, classical Data Governance implementation.

Transcript

Data Diplomacy in the Nordic Region

Speaker 1 0:00

This is MetaDemo, a holistic view on data management in the Nordics. Welcome, my name is Winfried and thanks for joining me for this episode of MetaDemo. Our vision is to promote data management as a profession in the Nordics, show the competencies that we have, and that is the reason I invite Nordic experts in data and information management for a talk. Welcome to today's episode of MetaDema, and this is a special episode because I have with me both an author but also someone who actually worked on the DM book, our data management Bible from DEMA, and I'm very happy to have with me Okan Etvinson today. Welcome, thank you. Thank you, adrian, happy to be here. We had a bit of a discussion before we did the recording. Yeah, should actually go for a episode in Swedish-Norwegian, but then we thought maybe easier for everyone listening if we do this in English.

Speaker 2 1:13

Yeah, having our accents influencing the whole discussion. We're very Scandinavian.

Speaker 1 1:21

No Data Diplomacy, Keeping Peace and Avoiding Data Governance Bureaucracy A really interesting book that I could recommend everyone to read, and we're going to talk a bit about the approach itself today, but we're going to embed it into two topics that have gained a lot of interest lately, and one, obviously, artificial intelligence and the entire evolution of field of data, but also another topic that is really interesting and has gained a lot of I wouldn't say traction, but there's a lot of critique coming lately, and that is the role enterprise architecture is playing in that modern data-driven organization.

Speaker 1 2:00

When we talk about data diplomacy, we talk about a way to engage people driven organization. When we talk about data diplomacy, we talk about a way to engage people, to engage everyone as data workers and to assist them with the data responsibilities associated with their business function, so everyone in the business becomes an integral part of our data organization. And then we're not talking about a data organization on the one side and a business organization on the other side. We're actually talking about one organization working with data. This is a fantastic approach and we're going to hear more about it, but before that, håkan, please introduce yourself. Okay.

Speaker 2 2:35

I'm Håkan Edvardsson. I live in the very south of Sweden. I can actually see Denmark from the other side here Denmark from the other side here and I'm working as a senior advisor regarding data management matters. Especially in the last 10 years 14 years actually has been dominated by data governance matters and prior to that, I started data modeling and business data design, working with business people in trying to depicting, showing, defining what the business semantics is, structuring and use how. I've been doing so since the middle of the 90s, concentrating on business data modeling. And then just move on what are we going to do with that model? How is that going to be implemented? Not only in the system, because one thing is requirement, but the other thing is, how do we get implemented in the business as such? Because we could use that technique to design what the language, the business language, should be like. We could say product, client, customer and different barriers, and let's have it there and let's define it like that.

Speaker 2 3:41

I have, for many years, been struggling with how do you implement a semantic, a business data design, into the everyday business, not only to a system, and that's how I sort of got into data governance and if someone has decided, this is now the definition of customer and this is how we label it. This is the related data. We need to endure that to have a lasting organization that actually makes it happen over decades. And so I got into data governance in a little twisted way. Not the data is bad. We need to fix it from going from bad to not bad in a reactive way, rather going from the design way, and that has influenced my whole career and eventually ended up with the data diplomacy doing things right from the start. But the world is just about data and data design and data matters.

Speaker 2 4:36

I live in the very south of Sweden, so I use my motorbike a lot to go on various trips and I've also always been playing music on various trips and I've also always been playing music. So since last year, I'm a part of a group, a rock band, that plays elder rock music such as Deep Purple, thin Lissy, acdc and those heroes from back days Making lots of noise. Back to data. I mean I've been interested in the data matter rather than the.

Speaker 2 5:13

Even though I have the background in IT, I've always had interest in the data as such, and that can maybe have something to do with it that I've studied lots of statistics and data analysis and various mathematics behind data analysis how that is used when you process data to make conclusions Very often live with. If we can have better quality of the data, better presentation, better process of the data, maybe we could end up with better decisions. Maybe we can see are we getting what we wished for when making a decision? That's a good wish. I haven't kept on to that, but I think it's still valid. But the each and every detailed, correct data isn't always the answer to any matter. So that's how it went to where I am and what's my messed up mind in this.

Speaker 1 5:56

So many interesting things here. I just wanted to start with the rock band because I really like that and I really enjoy that. There are so many data folks working with music in their free time. There's something of like a creative output, I think.

Speaker 2 6:10

Yes, but you asked the question how many data governance or data architects actually ride a motorbike. That's maybe too dangerous for the profession, I think.

Speaker 1 6:22

I think that is much more rare than the music. Definitely, I really like your background in IT and where your interest from data came from, because that is a different journey than what you normally see and I think that it always focused, as far as I can see it, on the business value what can we create, how can we make better decisions? How can we use data to actually drive an outcome at some place and not trying to, as you said, get the data perfect? And I think that's also a part that if you read the DM book, it comes through in certain chapters. The notion of being fit for purpose from the data quality side and having that data embedded in business processes is an important part. So maybe you can talk a bit about the work you have done with DEMA and the GM book.

Speaker 2 7:14

Sure, I came along in the project of GM book two when my publisher, Steve Hoberman, with Technics Publications that is the label where you can purchase the DM box they needed an author. They had an open slot, a position for upgrading the data architecture chapter with that label. That regarded enterprise architecture in a data-driven world becoming data-centric, with using enterprise architecture as leverage, and that sort of qualified me. I came into question together with 13 other authors, so I got an assignment. We didn't have a table of contents, really no-transcript. We started to have this argument about I don't really recognize my chapter anymore, what have you done? We started negotiating and I got the room to refine it in the way I liked, but I also found that many of my other pages were found in different chapters and now edited by others. So I think I influenced in a way that I'm very pleased with.

Speaker 2 8:53

And the thing is that when Data Management and Body of Knowledge version two was launched, released in enterprise data world in San Diego, where I came to meet Laura Sebastian Coleman for the first time, we started to like each other because now we met in person.

Speaker 2 9:13

We said we have very much in common and she liked my presentation, which I held there regarding how to engage senior management in data governance matters, and I used a different. She's from Sweden and we haven't been in war in 200 years and the US is always at war. So I started with opening try that, Try and have a peace in 200 years. And after that session, Laura Sebastian called me, came up to me and said what you're talking about is actually data diplomacy, because it made a difference that a peaceful country that avoided the second world war. We won't talk about that, but we haven't been in wars in such a long time and still happen to take part in international diplomacy matters. It's actually her idea to call it data diplomacy and it was my job to fill it with sort of a meaning. I think one thing led to another, so it actually was born in that. The idea of data diplomacy was born in that Enterprise Data World conference.

Enterprise Architecture and Data Governance Relevance

Speaker 1 10:23

Wow, really interesting and I like that you tied all our topics together now in just one short presentation about the DM book actually. But I want to start with the enterprise architecture picture, and you said that one of your previous books was an inspiration to both the work you've done with Dayma, but also to actually get onto the writing board for the DM book version two. Lately I've seen a lot of critique on enterprise architecture as a function that's often either seen as maybe too reactive, maybe not really trying to strategize on how we can move forward in the business, but rather just reflecting on what is there and how can we ensure that what we have already on, be it an application landscape or what we have called a modern data stack, just trying to coordinate what is there. That is one critique I've heard. Another critique I've heard is that it's too theoretical, that you're always striving for the perfect version of an organization, not really being able to actually put it into practice. So, with all that critique going on, what is your stand on the relevance of enterprise architecture?

Speaker 2 11:37

I say it's very relevant today and will be in the future if it's done properly. And I think you mentioned two critiques that, depending on what implementation we see and what organization we are looking at, I see really two different problems. One is reactiveness says that well, they hang up their work on sort of gates, project gates, or they have to have their saying before an initiative could move further, and they always just these are all the criteria that you have to formally meet. It's reactive and it's bureaucratic and I'm against bureaucracy, as you know. The other one is that the theoretical part of that is that another critique that what qualifies someone being an enterprise architect. And I mean we know what we would like to a brain. Show that what kind of knowledge you need to have prior to put the knife in someone's head. And I mean the enterprise architecture. If you look what it really is, it's sort of the spine of the entire organization and it's a skeleton, it's a structure, and who do you put in charge of that and what skills do you have?

Speaker 2 12:58

And I said a little bit too often that enterprise architecture the function of certain individuals sort of gets too inspired of that power, that the function of certain individuals sort of gets too inspired of that power. That is sort of, I have a kingdom and I, since I am an architect, I'm entitled to make a model you must follow. And what you do in that situation is that you sort of you claim to be the master interpreter of the business needs and you make diagrams, models, structure on the second-hand knowledge, because now, it's your knowledge is based on, not the first-hand knowledge. And so I sort of renounced that as I do the same thing with business data design that it couldn't be an architect that could design the business data, because data design is business design and architects are not business designers. They are architects of the construction that fulfills that should be done using the architecture.

Speaker 2 14:00

So I would say, as I think it be, that enterprise architecture as a function, as a perspective, as a knowledge, is a part of the movement that improves the company, organize, our organizational structure and how that is reflected in our system landscape, in our data landscape. In order to fulfill that, we need to be very agile as a company, not as a development function. That could be agile, of course, but there are new demands all the time. We need to restructure our business, we need new products, we need to go and electrification from. We need new products. We need to go and electrification from all five solar fumes and everything that the outer world is pushing us towards. And enterprise architecture, as well as data governance and everything else that is sort of the second layer of the development, has to be a part of supporting that, not determine it. We shouldn't put too much power into those roles really.

Speaker 1 15:10

So who would you then say in a modern and what and I mean, there are many different definitions of what a data-driven organization is but in a modern data-driven organization, what role do you think enterprise architecture should then play and who should be in charge?

Speaker 2 15:27

I'd like to quote an acquaintance of mine, chris Potts, who has written lovely books about enterprise architecture and one of them being Recreation with the EA very big capital letters, recreation. He has a scene there where a just recently hired enterprise architect meets the CEO and the CEO asks what are you? What am I paying you for? Well, I'm the enterprise architect. The architect says and the CEO says so am I. Because the mission of the CEO is really to fulfill the strategy not doing the strategy, but making the ship built for the truth that is ahead of them. And a part of that mission is to having enterprise architects making the.

Speaker 2 16:16

I see enterprise architecture as very much in the end of IT outcome, even though you work in business matters and you have to dig in and really understand what the requirements are. But you're not a business designer if you're an enterprise architect. But you have to understand the business design and what ingredients are there, and doing that as a supportive role in the entire development. So practically the business data design posture that I suggest in data diplomacy, but also when training enterprise architects, is that you need to be a facilitator and enable those who have first-hand knowledge of the business and business as it operates today has to go even smoother, or those who understand what the future requirements are that we have to meet. Maybe design the business we're not already doing? We will have to start doing it next year due to regulation, due to market requirements.

Speaker 2 17:18

Of course, you can be inspired as a data designer or an enterprise architect or sort of overall designer, but you can't have all the answers. You have to take a step back and facilitate the real requirements that are out there. I mean, it's a little bit. Use this analogy sometimes. If you have the posture as the X-Files that are looking for the truth that is out there and it's my job to understand it, even though it's not really tangible every time. Or if I'm Michelangelo and I'm the genius, I would say we can use a bit of genius, but you need to improve as an enterprise architect or any designer of this. You need to embrace your X-file posture to understand. It's not my job to tell you mentioned earlier, my friend that there could be theoretical models and just take a small example for that. I work a lot with most of the data cabinet because that's a very good way to start If we have mess with data overall on an enterprise level, start with resolving product and customer and then go from there.

Speaker 2 18:36

If you cleanse those and have one definition that is all valid or a structure that is useful overall, we understand we have different kinds of customers and this is how we deal with them and resolve that, then you can start moving ahead. But an enterprise architect should do a theoretical model, say, well, customers, but we also have suppliers, vendors, and we also have interested parties as authorities and insurance companies and banks, so let's call them party. And then you have sort of created a party diagram model and try to promote that and said those people who works with customers doesn't work with suppliers or insurance companies, and you probably have 100,000 customers and you have maybe 500 suppliers. Why do you want to generalize those into one sort of flussy concept? I mean, then that's an example when you moved away from the business and generalize yourself from the business and say, well, I certainly know better than you, and then you actually failed as an enterprise architect, I think.

Speaker 1 19:40

Oh, this is so spot on. I was laughing in the background. Thank you for that. There's one question that is still open for us to discuss, and that is where do we see enterprise architecture and data governance work together? And we have certain areas where about reference architecture, for example where we definitely need some collaboration, but I think that enterprise architecture, data governance are both on a facilitator and enabler side, as you called it more of a second hand trying to enable the people that have the first hand knowledge. How do you see those two work together?

Data Governance and Diplomacy Strategies

Speaker 2 20:14

I would simply describe how we managed to do this at Volvo Penta the last 10 years as an excellent example. First of all, we have defined data governance as two arenas. One is working with data quality and data content, traditional data governance with data stewardship, data ownership, where you can have data owners that have ownership over data in several systems and you could have, for instance, a product master with different product areas and you can have data ownership for different sets in one database. So we can have all the difference there. That's traditional data governance, one arena. Another arena is to, whenever we make a change, we want to take one step better for the entirety. It's the same idea as the enterprise architecture, but it concerns the data strategy, having that as a separate knowledge, separate responsibility, to make sure that whenever we make a data design or data amendment, we will include the SMEs and those who have a responsibility not for the data sets but for the data design. So that could include it could be very often with the same person. But having a data governance over the data design is a little bit different from the data governance for the data sets, the data coltons. But having so could be, for instance, having a network with, for instance, in an industrial automotive as PELTA. Then you have product design, where there are engineers coming up with new ideas and will be launched maybe next year, and you have the sales and market that you have a different data structure of a product. There you have the assembly and everything, the details of what to put what item together and you have the aftermarket with all the documentation, of course, distractions, but also the installed system and how that would live, maybe in 20 years, being serviced and repairing, have their living boom. And of course these are different data designs with their common concepts and if you can get those as a thread in a common picture, we are very well off for the common digitalization and having new services because data is connected.

Speaker 2 22:39

There. We have a data governance design structure that has to work in every requirement and every change close to the development of the IT and that works very well with the enterprise architecture way of working because they will do the same thing with security or with different solution standards. They have different qualities. So we use the same checkpoints, retrospective meetings, proactive meetings, with both data design matters and every other topic that enterprise architecture. So we share the agenda. We have the same planning, but also very upstreams, with the portfolio planning, the budgeting, what's prior to plan before. We're going to do this with those applications, we're going to do this with the services, and we're going to do this with the data and let's make one plan.

Speaker 1 23:35

Oh, I think you are at the core of it and that is that shared planning, but also that shared agenda, that you're moving towards the same goals and you are coordinated while doing so Fantastic. So let's move a bit on to the main topic of why we are here, and that is the data diplomacy approach. And your book came out, I think, right before COVID hit, which is an interesting time to get the book out. I don't know if that has any influence on how the book was perceived, but maybe you can talk a bit about the book itself and the approach in the book.

Speaker 2 24:13

I do Well, the timing for running around. I had to make a tour of promoting the book that was sort of a little bit disabled in that sense, but it was better received, thank you. Even though my enterprise architecture book Made Simple it's called was what you use success financially in a different way Actually became the best seller that year in the publisher. And data governance wasn't that hot topic. Actually, the same conference that I talked about the enterprise data world in 2019, I think someone claimed that data governance is dead and I said the opposite. Well, I think that sort of the core of data diplomacy as such was to sort of describe those successful implementation I have experienced. I try to recognize what are the ingredients that are important when we have succeeded, because there are lots of description of what fails and I can give you some. But what was the difference? Why did we success? And why did Volvo Penta be the best in class in the entire Volvo group and why did Gothenburg Energy do the same? And we had the Data Governance Best Practice Award last year. We had three finalists, european finalists, and two of them were mine based on data diplomacy, and one of them won. So something has to be right there, I think so. That's really why I started doing it, and I think that I had a few messages that I want to put forward, and a few of them were that IT people could very much be a little bit on the wrong side, saying whatever you require us to do, we will fix it, and if it's not the right requirement, it's your fault. Having that posture, then we're not on the same team. Why are you at all at work in that organization? So we have to bridge that was also the theme of the first book Bridge Business with IT, and very much the spot for doing that is when changing things, when you're developing, try to make one company. Each time we are doing one enterprise, each time we are taking a step forward, and every time we have a new drastic requirement that could shake the organization. That sort of I like the word. Well, we have a gravity for change, for instance, the electrification in automotive, the energy prices and the new regulations that comes with. Just maybe a new regulation becomes valid in 18 months or something. Then we have management attention. Then we have those who are reacting for we have to fix this now because we will lose money or we could be fined or whatever. Then we have actually the best opportunity, a good arena to let's do the least to get the most. And how do we know that? And as soon as people are talking about the solutions and the technology, everybody starts working with the opinions.

Speaker 2 27:36

But if we could stick to what the data looks like, data would enable and what the data, if it's well, could do for us, if it could fix the problems, we get rid of the opinions and the discussions, because relying on this is what the data looks like and this is what the data should look like. I mean, it's inevitable. You can't discuss your way around that, and that's very basic for diplomacy Based on the facts. This is what it actually looks like and instead of starting to use the power in the organization and be a very powerful human being and try to get your will or your wishes, we state that the truth is in the data. We can't really do much different things. We couldn't do anything real about it otherwise. Therefore, discussing data matters, data problems, how to improve the data with the people with the first-hand knowledge, we usually get the best answers, instead of asking the IT or asking a boss that also have a second-hand knowledge about it. So go to Genba, go to the people that knows the best to see what we can do with the data and see what that will lead to. That has proven to be very successful.

Speaker 2 28:53

But it takes two prerequisites that has to be in place in order to succeed with that. First, you have to sort of take all these two convinced enterprise architects, dave Darkis that think that they know better. They have to sort of take all this to convince enterprise architects, data architects that think that they know better. They have to take a step back. The IT had to take a step back to sort of to release the powers with those who knows the best. And secondly, you had to be sort of diplomatic facilitator. For instance, what we need, for instance, in Penta, was to gather people who know data about products, both from financial sales and product development and also other functions.

Speaker 2 29:35

If they would come up with a suggestion that was good, but I could realize it wasn't good enough then I need to encourage that still Now. That's not good enough. Does anyone have anything better? But rather sort of promoting that that's good. Should we do more?

Speaker 2 29:52

And then someone else would come with something more and using the whiteboard behind me and to visualize that in a structure. They could see how data when it's connected and when it's clean, and we could talk the same language from you there to we there and they can see it. This would really help us. This would help us with the financial following up and monitoring the business. This will help us understand what we have sold to our customers that then comes after with the claim and this really understand what to do with the production materials when changing things. So you can see when data is connected. It will help us.

Speaker 2 30:29

But the thing is, in order to get that process going, you need some diplomatic skills. Couldn't just put the minerals and make it happen. You had to facilitate that in a proper way and continue talking about the data and not getting the systems involved or the organization and how that is. Just look how the data should look. I think that's sort of the core of the diplomacy is to find those arenas and that situation, that process, and be able to handle it to get the most out of them. Also, not only a meeting where everybody's unhappy and talking about all the bad things, but actually come up with good solutions.

Data Governance and IT Insights

Speaker 1 31:13

I really enjoyed this and I have I don't know how many questions right now. Just two remarks that I think are quite interesting here in the context, and one is towards business and IT that I think are quite interesting here in the context. And one is towards business and IT and I've said it for a while now because I think that we did something how we set up businesses and IT in the 90s that kind of are still giving like the influence of how we set up data today, because I think data and the entire data field and discipline of data comes from an IT background more than it comes from a IT background, more than it comes from a business background. And now we are arguing for data being really a business function or an IT function. But we still have that IT luggage and mindset with us, and one of the things and you said it yourself is that there's something about being a service, being a service function, having a service mindset. That you come with a problem, I give you a solution that I think is setting for the problem you described, and if it's not, then it's your fault because requirements weren't clear enough. I think that's something about IT classically being seen as a service to a business. That service mindset has a problem on the one side on the IT, but also on the business side because the business can kind of feel like we can choose if we want to use that service or not and use or utilize that service from the data team, and that's not really how it works. We have to get rid of that service mindset and have rather a business mindset in the work with data and IT. So that was one point and the other point is there is really a lot of opportunities in compliance.

Speaker 1 32:46

You said, if there's a new law or regulation coming out, that is an opportunity for data governance to show its value or show its worth as much as it has been an opportunity for IT security to show its worth once there was an incident or a breach. But it's really short-lasting. Get away from just meeting the requirements. That gives you the right level of compliance and I think that's what a lot of companies are doing that. What do we need to do to meet our compliance standards for that regulation? We're not going to do anything more. This is where we're going to stop. But that's not how you create value with data. So you have to think beyond those requirements from the regulation and actually build on that. And I think you, with the approach you're having of being a diplomatic facilitator, having IT enterprise architecture, all the egos take a step back. I think that's where you can actually focus on that value, not just on that compliance.

Speaker 2 33:50

I agree I think we're spot on there that one, being a hero once, doesn't really keep up with that Now. It couldn't get used to that. Things were much easier now to come up with new projects, new systems, new changes, and we had a forum for now we have a change in the product structure and how do we, before launching that, put it in the data governance team and see how will it affect the entire company and then make an informed decision and just go ahead with it and everybody could do that at once. Okay, that used to take months. What happened Now? Because we had established a network, or rather we call it the data governance committee that was represented from various functions and they were very. They had been working for three years. They had the same language. They knew about their differences in what a product, for instance, is for each and one of them. So whenever there is a matter, they could very easily just use the tacit knowledge and speed up the process.

Speaker 2 35:15

But, as you said, it's very delicate because this is sort of built on free will, competence and if you, for instance, we're talking about six or seven persons in a committee, three of them are retired and two of them has a new manager and we reorganize the organization, we could easily crush this, which has taken years to build up, and that is that you can never stop being on the edge.

Speaker 2 35:44

You have to be. Whenever there's a change in your domain that you are looking into, you have to be there and be active and try to include that in the management system, in the structure. Whenever doing a change like this, you have to check with that committee and that committee. They had this structure, they had to go through these steps and not answering before you know what you're talking about, how this will impact the data. Still, even if you do that, if you integrate your data decisions into the management structure, it's still very delicate and it's based very much on the individuals that are in that organization. So I've seen that before that what has taken decades to build up could easily be ruined in three years. Sad hatch, keep me on the edge.

Speaker 1 36:38

There is something that talked about this a lot as well and we are still way too hero-driven in the data work we are doing and it's like a firefighter who gets out there when the fire is burning, saves the kitten out of the third floor. He gets more credit than the people who are doing those fire safety drills on a continuous basis and helping actually prevent the fires on the first place. And I think the same thing in data that we are still seeing that the people, the silent contributors, who are actually providing value and securing that there is no incident, that the data work is running smoothly, they should get more credit for the work they're doing.

Speaker 2 37:20

Entirely true. I have a small story from one of the larger retail companies in Sweden that has realized a problem they have with that, where that the data wasn't really connected, wasn't really used to learning more so but you were quite famous for having a very good data administration from the back all days. What happened to that? Well, there was this manager that said why do we have these data administrators? And it's fire them. Well, they do that. As we told them, they make sure that these things doesn't happen. These problems are avoided. And then they ask the wrong question Do we have those problems? No, so get rid of them. And it took three years and I came back and said, okay, it didn't need very much long time to mess things up, but these gatekeepers actually avoided.

Speaker 1 38:15

Now that we're talking about the gatekeepers, I think we should talk a bit about the role that comes with the data diplomacy approach and if there are any changes to the rules. I think you talk about a data diplomat as a role itself. Where do you see that fitting in with the traditional data road?

Speaker 2 38:31

Well, I see it like this the traditional data governance is about the data contents and the data values really Going from bad to not bad, which is not very high ambition in the first place, but those are the gatekeepers. That makes this From operational purposes very often. This is the accurate data we need and the data processing processes work very smoothly and we don't have very much trouble in the end and that kind of investment is usually very easy to take back from. But I suggest in data diplomacy also to include data design as a profession in data governance organization. If you have a data ownership or someone someone owning customer data, for instance that's usually a formal role and the stewards usually work with different customer categories and different tags and different shortlist and attributes. That goes with that and who does work regarding that Very operational and some IT in detail. But how do we fulfill the data strategy regarding customers in tomorrow's world? I mean, what I think is the traditional data governance organization doesn't take on that responsibility. They rarely have a useful data strategy for a data area and then don't really have the means to understand what should it look like in tomorrow's world. Well, we don't know how that's going to affect us. I mean, then you need the data design arena in data governance, and that includes lots of people in the traditional data governance organization, but they have first-hand knowledge. We shouldn't ruin things that works well. We should do it even better. But you also need some outlook on the future. We need some ideas from enterprise architecture or different data analysts. This is what we would like to do in the future, an expectation from business development what's tomorrow's market going to be? So we need to know all this about our customers, their behavior and so on, data we do not yet have, and one of the quotes.

Speaker 2 40:46

I have a lot of principles in the book. One of them is being that data governance is also about the data we do not have, and this is the design arena. We don't yet have it, and that includes that we should have someone that takes responsibility to actually move towards this data that we should have, even though we don't have the contents yet, and I'll call that person an entity manager that takes charge of the data entity, the customer data entity, the relationship entity, relationship model, the definition, the label and the structure of the data that we should have, so that each and every project, investment, change. We move towards that vision, because that is data statute in practice. You need sort of the entity manager.

Speaker 2 41:36

It could very well be someone that is also in the traditional data governance organization, but sometimes it's a completely different person. On top of that, we also need the facilitator that works with all these entity managers in various areas could be customer area or the market area, finance area, the data to come, and the entity managers should work together so they have a consistent picture of the future. Then the facilitator need to enable these to have their workspace to occur in those situations that they need to clear their throats and speak out. This is the data strategy, because that is very often forgotten whenever doing an initiative. Those minor changes include the data design besides the traditional data governance roles.

Speaker 1 42:27

Very true, and I really liked that. You went into the data strategy space and there's a lot of misunderstanding what the data strategy is or should be, but for me, it's about laying out that very logic. You need to manage that uncertainty ahead. It's not about planning with certainty, it's not about making a five or two year plan ahead, but it's about OK, we have that goal down the road. How do we get there? What are the logical steps we should take? And I think that a role like a data designer is definitely a role that we need, someone who owns that very logic, exactly, and I think that's approaching to the enterprise architecture challenges.

Speaker 2 43:08

They often try to make this on behalf of the business because they know about the future and have time to sit down and think about the future, but everybody's doing today's struggle and I think that you need to sort of distinguish this is business data decision and this is enterprise architecture decisions, and both are needed, and I think that the sort of it starts with the business. Of course. This is the future data structure that we need regarding products, regarding customer and or regarding the installed base and knowledge about the customer. This would need to know, but how that is going to be solved, using what system, how it should be reflected in detail and how we connect the systems. If we make a mesh construction or data fabrics that holds this.

Speaker 2 44:01

That's typical enterprise architecture matters. Definition of data, the structure of data and the name, the labeling of data were never delegated to enterprise architects, but it has very often been decided by enterprise architects, but it was never delegated to enterprise architects, but it has very often been decided by enterprise architects, but it was never delegated. So it has to be a business decision.

Speaker 1 44:20

Very true. And there's one last question I have on the data diplomacy approach, and we had a previous episode where I had Valentina Niklasson as a guest from Volvo Penta and I think both of you have worked together on some of the problems and she talked about quality management as a basis for data governance and also lean approaches in the way we are working with data. So, on the data diplomacy approach, how does it react towards ways of working, delivering in like an agile environment? How does it react towards lean approaches to data?

Navigating Data Governance and AI Evolution

Speaker 2 44:59

I would say it worked very well. When you have an adopting organization that is aware of, we don't waste time, we don't waste work, we have the medium viable efforts for whatever outcome we are wishing for. I think that is rise very well with the mindset that we are using. One of the messages with data diplomacy is that I'm simply against this using this massive data governance implementations where you have a top-down fiscal what do you call it? Juridical system, the entire organization involved, with everybody involved, and try to launch it by adopting what checking? What roles have we assigned throughout the organization and they become sort of sleeping agents, not knowing what they're expected to do. That doesn't work. That's just a waste of money and I've seen several implementations like that. It's just slide wars and people don't really.

Speaker 2 45:59

What does it take to fulfill the intention of data governance? It doesn't be much. You could use your own organization, use what you have and do it a little bit different. The same purposes as you have in Lean, as in Agile and everything. You don't bring out thousands of people and millions of budget to do that. So therefore, we don't need to have data governance whereas we don't have anything to fix really, and don't start with something you haven't done before and do it on the road's game. For instance, master data for products, master data for customers for a typical industrial company. If you stop there and you say, because everything we do in the organization relates on data on the organization, data on sites, data regarding products, data regarding customers, and we have everything in place except for the last two, so let's govern that and see where it goes.

Speaker 2 46:56

If you also have a process management organization with some continuous work there, or a lean organization, I'll say, okay, data governance takes care of master data, product and customer, and we let you to include data quality in your daily lean work. Just add that to what you're already doing, because who does not work with data in your organization? So if you're leaning your daily work that includes data, just include it. It's not a separate thing. I would say, especially when it comes to lean, it works very well. Then, if you have an agile environment in IT, make sure that those same with enterprise architecture. There are some aspects you need to include in certain stages. If you know your data structure, you could easier to the end result if you resolve that with the business prior to starting with. Technology Doesn doesn't matter if it's Waterfall or Agile, you need to resolve that matter first.

Speaker 1 47:57

Very good. I just want to emphasize on one thing you said, and that is you shouldn't have data governance where there's nothing to fix. I think that's a really good quote here. I mean, that's what you get when you go in for the, the traditional organizational based approach and building up a hierarchy for data governance. You get data governance, but it is not a problem to fix, and then, as a consequence, you either get a data governance approach that is not understood, not adopted, or you get a data governance approach that actually generates problems.

Speaker 2 48:28

And you have busy consultants that are expensive very often that don't always know what they're talking about. Sorry for saying that.

Speaker 1 48:37

That's all right. Let's try to get a bit of a broader picture at the end of it, and there is an AI evolution going on, as we call it. There's a hype around the generative AI and some would argue that, with the possibilities we have now for generative AI through large language models, we need to rethink our approach to data and data governance. Certain areas where we really focused on for years in data, like data modeling, for example is there actually still a value to it? Do we, as a business user, need to understand the data model? Do we need to model data in the way that we have done it so far, or can we use AI to help with that and rather focus on understanding of the results and the outcome rather than the process? So do you see there's a change coming, and how does the data diplomacy help to navigate data and AI? It's a big question.

Speaker 2 49:37

As you said, it's a hype and it's quite new and if you ask me again in two years I will probably have a different answer. But I'll answer sort of in my tradition, where business data design has been very important for the business outcomes. I would say, as long as you are working with the operational business, you need to care and embrace your data design. When it's something you do on a regular basis, you have to capture this and this data in order to fulfill the end of the process. That could be a financial settlement or reporting for emissions to authorities or something we can't bypass that, but maybe we could gain from. What kind of data do I need in a situation like this? I'm you on the job. I don't know really about emission reporting. I could benefit from AI informing me what's usually there and then it's not operational anymore. Then it's sort of when it comes to analytical and to make decisions, and that's a different arena than the design of the operational business. So I mean you couldn't just let AI do everything for you. You have to make some decisions yourself. So designing what you are going to do and not do that is still your decision. Even though it could be supported.

Speaker 2 51:06

I got to know some friends in the US that has been working with decisions they call it decision intelligence before the AI, and they started working with that for 15, 20 years ago. And the interesting part of that as I said, I'm into statistics. I started with my statistic foundation. Academically, ai is very much about using the data we have, making patterns, generate new patterns and go from there. Now, if you go into the core of decisions, if you're going to make, as a human, make a decision, how much data do you know to make that decision? Well, data, by definition, is a footprint of something that has already happened. So, whenever you have data, you can see a phone bill or you can see what data, what has happened, the email, everything. Everything has already happened. When it's data, it's recorded. Otherwise it's forecast, but otherwise, data is usually reflecting the past and decision making is always about the future.

Speaker 2 52:17

So what we need is data from the future, and that's where AI comes in. Give me a prediction, give me assumptions, and these are my criteria. This is how I framed it, this is the timeframe, this is the demarcation. This is what I need to know, because if you take a very simple decision, I'm going to cross the road. You don't need very much data to determine if you should stay or if you should wait. You need just a few portions of facts and the rest is your judgment. And we're not going to stop making judgments. So AI is a way to help us with the data from the future, but we had to understand it relied on statistics, so it's all probabilities, and the basis for probabilities is always data. That is true, so we still need to govern the data so we have the right foundation for AI-supported decisions. We can't bypass that. Long answers.

Speaker 1 53:20

Oh, and I would love to get deep into this one because I have a lot of things I wanted to talk about here, but we are at the end of it, so some quick points on what you just said. I think something that is really important is that we, as Manolo has talked about, bridging that gap, or the distance between operational and analytical data On the one side. I think we have looked into a couple years back now, reverse ETL, and I think there's a reason why we have that distance, and I think you made it really clear about there's something about trying to describe what is or what has happened. There's something about the analytical part, about what is going to happen or our prediction for the future, and those are fundamentally different and if we mix them together, we're going to end up in something that is not going to provide us any decision intelligence on the one side, or not any operational evidence on the other side.

Speaker 1 54:14

I use this quote a lot from Ross about. Data is the act of creating a message to people in the future, and I think this is what it's all about. We are creating something for someone else to understand, and that is the basis for the data that we are creating and then, on the other side, you pick it up and you provide some insight to understand and that is the basis for the data that we are creating and then, on the other side, you pick it up and you provide some insight to it. I think those are, as you said, fundamentally different and we have to treat them that way.

Speaker 2 54:42

When I opened my presentation at Data Governance Vision when I released the data diplomacy, there was a room filled with people that are professional data governance in various roles. And I start with asking the question what is data? And I said that my session is scheduled to end at 2.20. I give you a message right now. I'm going to end at 2.18. Is that data? What is so detailed? Of course it is. Then I put a piece of paper and showed that 218. This is data. I've written down what I said. It was just information, which was a message for you who are here.

Understanding Data Governance and Design

Speaker 2 55:25

But Tony that is operating the event doesn't know about me any earlier, but if he got that message as data, it would be meaningful for him. So data is transmittable, registered or something, but otherwise it's just information. For instance, we are capturing data. That has been information for ages. Every time you put down the clutch, when you're switching gear in your car could be registered in your car, but you did push down the clutch 20 years ago also. But we don't have the data, but we have the information I actually did. You see the philosophical difference. So that means that it's all the data where we decided to make it useful, as Ron Ross said that it could be useful.

Speaker 1 56:12

Already at the end of it. To sum it up, do you have any key takeaways or a call to action?

Speaker 2 56:17

I would say that when taking on data governance, be careful Don't do more than what you benefit from. You don't need to cover the whole entire world, but when you do, also include business data design in your data governance initiative, because data governance without data design is only reactive. If you include data design with business ownership, you are also proactive.

Speaker 1 56:47

Fantastic. Thank you so much, thank you. Thank you very much, thank you.