 Hello and welcome my name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today Donna will be talking about data governance and data architecture, alignment and synergies. Just a couple of points to get us started due to the large number of people that attend these sessions you will be muted during the webinar. For questions we will be collecting them via the Q&A panel or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DA strategies. And if you like to chat with us or with each other we certainly encourage you to do so. And just to note the chat defaults to send to just the panelists but you may absolutely change that to network with everyone. And to open the chat and the Q&A panels you will find those icons in the bottom middle of your screen to enable those features. And as always we will send a follow-up email within two business days containing links to the slides and recording of this session and any additional information requested throughout the webinar. Donna let me introduce to you our speaker for the series Donna Burbank. Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategy Limited where she assists organizations around the globe in driving value from their data. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia and Africa and speaks regularly at industry conferences. In fact she'll be at our DGIQ conference in June. And with that let me give the floor to Donna to get today's webinar started. Hello and welcome. Hello Shannon, always a pleasure to do these webinars and see some familiar faces or names on the chat. So thanks for everyone who has been joining pretty regularly over the years. So for those of you who might be new to this series or new diversity, welcome. One of the first questions we always get is will we get the slides and will this be recorded? And yes to both. Another good news, little bonus is that all of the previous webinars and we've been doing this series for a few years now are all sort of kept in the digital library at data diversity. So if you missed any of the previous ones on data strategy or master data management, they all are recorded and Shannon and team always send out a link after this with all the links to this in the upcoming events as well. So today's topic is going to be on data governance and data architecture and alignment and synergies and sort of what does that mean? So what we'll cover today is that difference between governance and architecture and where are they the same and where are they the difference and how do they fit together. So cut to the chase. They are separate separate areas that relate together. You can just send the webinar now. I hope there's a little more nuance to that and we'll sort of get into the details of what those differences are, what the overlap is and how you can really make the best of both worlds in your data architecture and your data driven initiatives. So without further ado, another thing that the university does, which has been really popular over the years is do a number of surveys and I've done a few with them. One is that we've been doing is trends and data management and kind of seeing some common trends. One common one is always data governance and some things that kind of have been flow over the years. So I found these statistics fairly interesting that when we look at data governance over 75% or 76% have a data governance initiative already in place or are planning one in the near future or kind of in the nascent early stages, that feels about right to me. I see a higher percentage in our practice. I kind of do this as a day job, but I know we have a select audience kind of by definition of who we work with. But I do see that trend increasing, which is really, really positive. The second one I like is not a surprise to me because we do this a lot, but I think maybe it's not the stereotypical vision of data architecture where you think of data architecture and people say, yes, that's a great way for us to collaborate with different team members. That might be a surprise. And there's different areas of data architecture. If anyone's heard me speak before or know me, you know, a huge fan of data models, especially that business centric data model. And we've had really great, which is a part of data architecture, and we've had really, really great collaboration with the business through something like a conceptual or even logical data model. And some of the comments are like, we never, we knew we had these problems. We could never express it in a way that made sense to IT and vice versa with kind of the data and more technical data side. And how do we really translate these business rules? And we've had some really good conversations around data models. The other one we do a lot is just that high level system architecture. You know, often what we just did a really successful data strategy and what sort of a couple of months ago and what really hit home with the senior managers was our architecture diagram with all those spaghetti lines, right? That stuff that we've all seen. We've all seen the spaghetti diagrams. But sometimes it's just pointing out that one line between system A and system B that doesn't integrate or something. So, you know, picture is worth a thousand words. I mean, data architecture, there's a lot of, we'll talk about that, a lot of nuance in different areas of data architecture. But often it's those, you know, high level or kind of enterprise level architecture diagrams, whether it's a data flow or it's a data model or it's a system architecture diagram, et cetera, et cetera, are often, you know, really nice tools to really get at the, you know, suss out the, as we say, the so what of the different problems you need to solve. So we'll get into that in a little more detail, but I thought these statistics were fairly interesting. A lot of us are architects or, you know, data governance folks on this call and we love our definitions. So would be remiss if I didn't point to the DEMA DMBOK. If you're not a member of DEMA or the Data Management Association, they have chapters around the globe. Super, super helpful. I've been a member for years now. And they have a data management body of knowledge or the DMBOK. If that's new to you, definitely get a copy. I am a contributor to that as well. You know, we've got the PMBOK for product project management. We've now got, you know, I guess it's not new anymore. It's been around for years, but you know, that data management body of knowledge and I know every single implementation is different. But a lot of this has been done before, so it has some good foundation. So I'm going to take their definitions, which I think are fairly solid. So what is data governance? And what I like about their definition is they show a little bit of that nuance. The data governance is the exercise of authority, control and shared decision making or the management of your data assets. And I sort of like that. And some of my presentations, I kind of almost call it, you know, the yin and yang of, of in some cases, that's the authority, the planning that you can't do this, don't do this and your different rules and policies. But the other aspect is that collaboration, right, that shared decision making. I may be naive, some older I get. I feel like I may be, but I tend to find that most companies that we work with, that people are adults and most people come to work wanting to do a good job. So very rarely, I think one in my entire long career did so whatever say, you know, I'm going to work to try to hide data or not share data. People are trying to get their work done or they only see their piece of it. So generally when you have things like governance committees and you get those people in the room, people see the other side or they can at least, you know, agree to disagree and create those kind of shared decisions. So to me, that's a lot of that governance, getting that balance of control, also getting the different voices in the room, et cetera. When you look at data architecture, that's more on that. I would call the data management. And that's the I talked before on the previous slide about, you know, representing the organizational data at different levels of abstraction so you can understand it. So when you get those people in the room, what do you talk about? Right. How do we, how do we show in a way? I always say, I like to say that I'm a visible thinker, but I think we all are, right? You see a picture of something you're trying to find, you know, go somewhere in the road, you look at a map. A map is just a visual representation of the roads. You're really hard to go somewhere without having something like that. So similar to that to me, that's the data architecture. And there's a lot of different architect artifacts of a data architecture. There's some there listed. There's data requirements, you know, data integration. There's a lot of data models to the flow diagrams, et cetera. And so my my definition there at the bottom is maybe overly simplistic. I'm sure there'll be some heavily chat, heavily, you know, vibrant chat saying they may be too simplistic here. There's always a never a shy audience at diversity. But I almost think that, you know, data architecture, you could probably say is that technical side of data governance. There's technical data governance, there's business data governance. And then there's some overlap. And there's there's, you know, a progression there that we'll talk about. And sometimes it's both together. But that might be the easiest way to think of it. You know, architecture is architecture and governance is governance. But, you know, there's some overlap there. Again, if you've done this before, you've seen this framework. So this is our framework at Global Data Strategy that I often use here in these webinars, because it really kind of shows a lot of these pieces in a data management or data strategy that people can kind of fit together. So, you know, this is our framework for a data strategy. Whenever we do a data strategy, a huge component of a data strategy is data governance and collaboration and data architecture. So there's some reuse here. So with governance and with architecture, it needs to start with business drivers. There's no reason to do anything in data unless it has a business impact. And I use business, you know, loosely, that's an organization. It could be a hospital, it could be a nonprofit, it could be a school. But your organization, what are you trying to do? What what benefit are you trying to get? And then how can data enable that? So that's kind of that top down that drives the governance. Again, huge difference. And again, we're consultants. So that's what we try to really suss out in our first few days and engage, you know, what is the governance? Are you a hospital? And this is patient information, very, very different than something like a social media company that maybe people are, you know, putting public information out and they wish to have that information out very different than the patient diagnosis. Right. So, you know, what data needs to be governed is very important. So then the architecture is kind of that bottom up. Do we have data and databases? Are we using IoT and big data and unstructured data? Do we have data in documents? Super, super important. You know, a snarky comment I always like to make when we're doing a data strategy or data governance or data architecture and folks say, well, we don't look at documents. I mean, that's knowledge management. That's document management. Right. And I say, well, you know, if you get your credit card information stolen and someone says, oh, that's OK. That wasn't a PDF. It wasn't in the database. You care. We're still data there. That's still your credit card number. It might be in a document. So you really need to look holistically when you're looking at an architecture and governance, right? Because you need to govern it at all. And then loosely, architecture, you'll see that there's a box in the middle right there talking about architecture, data model, modeling. But I would say, in a way, architecture kind of encompasses a lot of this. You're doing an architecture for master data management or for data warehousing. And I would also argue a piece of data architecture is metadata management or data integration. So again, they all fit together. But each one of these can and actually is generally a webinar that you can spend a whole hour or more talking about master data or data quality. And then I see data governance, again, is that glue between what does the business want to do and what do we need to do technically? And there's people in this process and this policies. And there's a whole culture, a data driven culture, around information sharing or lack of sharing, et cetera. And that really drives your architecture. So again, they all fit together. But there is definitely some overlap that I thought was kind of worth talking about. Back to the surveys, because we are data driven people and we love our data. So this was, I guess, from a more recent 2021 survey. I think the new one is going to be coming out shortly. We're kind of compiling that this year. But I found this interesting because when we talked to companies, I think there was, Shannon probably has a statistic, but it's several hundred across the globe. So this isn't just North America, it's Europe, it's Asia, it's Latin America. That basically said, across all industries too, what are your priorities in place? And we compared that from what is in place in 2021 and are kind of currently in place. And what are you planning to do moving forward? So I found this interesting. When you look at the top priorities for 2021, all about business intelligence data warehousing, probably not a surprise. When most people say they want to be a data driven company, mostly it's analytics or reporting. That's kind of the front face of data. Is data more than that? Of course, it's your operational data, it's your real time, run time data. But I think when people talk data driven and so much of that tends to be behind reporting. So that's fine. I was pleased to see that data security was sort of top of mind up there. But you'll see data governance and data architecture where good news is in the top 10, actually in the top five, it isn't top of mind. Top of mind is I want my report. So my color commentary on that is when you look then at 2022 and 2023, what bubbles up to the top? Data governance is number one. My color commentary is, well, maybe we started looking at those reports that were top of mind and they weren't quite right or I didn't trust them. Or we had a disagreement on how you calculated a metric or a KPI. That's often where data governance starts. We know we can't agree on the numbers and we're reporting numbers to the street. We're reporting numbers internally. We need to agree. So not a surprise to me that data governance is top of mind for 2022, 2023. Sometimes I tend to be a, when they call it the offense or defense or carrot and stick tend to be the offense, carrot, positive, glass half full. And what we're seeing is a lot of governance for data-driven business decision-making. But the CEO says, I need to be data-driven and we want to be a data company. We want to, you need to have governance for that. The other aspect or kind of the defense or I don't want to say class offense, but kind of the, you must do it type of aspect is regulation. If you're financial services or your education or your healthcare, you really can't get away with not doing governance or if you're reporting your finances to the street, you need to have data governance. So not a huge surprise. I think that the close second of data strategy sort of goes to that previous point of, companies know they need to be data-driven and you need to figure out a way to do that. I was a little disappointed that my very favorite data architecture kind of ended up at the bottom is still again in the top 10 there. But I guess the positive could be if you look at the numbers in 2021, more people were already doing data architecture. So maybe there's a good foundation there. She says, and I, you know, I, that said, I have, as Shannon pointed out, I've been doing this for a long time. And I would say that the overall general maturity level of a lot of companies we go into are good, despite the commonly vaunted demise of data models. I'm not seeing that. I think a lot of companies just, it's just a standard best practice. So maybe it's not on the upper edge of the gardener hype cycle anymore. It's just a business as usual thing. So I'm trying to stay positive that data architecture at the bottom because it is probably a business as usual activity that people don't necessarily have as their, you know, top driver for 2022. I hope governance gets the word, you know, up there. You know, probably like every company has a finance department. You don't necessarily say that's gonna be a new trend or initiative to have a finance department. You just have one. So I think sometimes being BAU or business as usual is good. So maybe data governance and data architecture will never be a trend anymore and it won't be a future priority. It'll just be a future activity. That's of course we will do it. That's my color commentary there as well. So again, numbers can always, as we know, we're data driven and there's data literacy and that's my interpretation of these numbers. You may have your own, but I did think that this was kind of a helpful thing to look at as we have a whole webinar here on data governance and data architecture and how they fit together. Speaking of governance and I may be a little heavier on the governance side in this webinar because the whole series is on data architecture and a lot of these things on data architecture are maybe covered in more depth than another webinar. So if I don't cover data models to your liking or I don't talk about metadata enough, be assured that there's probably a webinar either in the future or in the past that you can delve down deeper. And I hope you are asking for more because those things are near and dear to my heart. But this is a framework that again, we use in our practice for our data governance. And when you look at data governance, everything has its own framework, right? Each one of these probably has its own framework within it. But key to any successful governance or architecture is that vision and strategy that that relates to that in the previous framework that, we need to align our business strategy with our data strategy. If you don't have that common vision, why bother, stop, get a vision, understand why you're doing it before you do anything. And then I would say kind of the bottom of that sandwich or the foundation of the house is that culture and communication. Again, call me naive, but I generally have a positive feeling about human beings that generally when people didn't know why they do something or they see that it's tied to the mission of their organization or their own job, they're a little more aligned to do it. So again, we've had a lot through things like data architecture, a lot of positive results. And I'll share a case study at the end of, people are busy and they're doing a data entry screen and asked for something like, I don't know, NAIC code. I don't know what that even means. I just have to sell this product and that's how I get my commission of moving on. But once you have something like data governance, we show a business process workflow or we show a data flow and we show where that code is used for another department to do analytics or to do invoicing or something people say, oh, okay, well, if you're using that, I'll spend the extra time to put it in, right? So that kind of builds that communication in the culture. Now that I know why and that we're a team and the data I'm using is used downstream, we're more likely to spend the extra time to do that, but we're all human and we're all data driven and our brains to some extent, if I have a lot of work to do and one of these tasks, I have no idea why I'm even doing it, I'm not gonna prioritize that one. But once I know that my piece in the wheel with Kong or with a bad analogy, piece of the puzzle is important then you'll be more likely to do it. So back to what is data governance? What is data architecture? What is data management? What is data gosh we could spend, probably would a whole day discussing those nuances. So I kind of step back and I don't care what you call it as long as you do it, probably put some arguments on that one. So, but when you think of the different pillars of data governance in general, there is that organization and people aspect. Do you have a data governance committee? Do you have data stewardship and data owners? Do you have a lead of data governance that's really gonna help to drive that? A huge part of governance is that people and that's gonna drive your culture, et cetera, et cetera. There's also processes and workflows and I'll delve a little more into this as well. Part of that is the processes, this is very meta, the processes for data governance. How do I log an issue around data when there's a problem? How do I require a data model as part of my agile sprint cycle? These are certain data-centric processes. There's also business processes that generate data. So how do I onboard a vendor? And do I get the right data from the get go or onboard a customer or an employee? That's all data and that's data driven. So it's a bit of both to really get governance working correctly. Do the business processes that create or edit or update or delete data, good old crud, are those in sync? And do we have the right processes if they're not in sync or as we develop things within the data management space or data architecture space to support data? And then there's data management measures, which is I see really where data architecture fits. Do we have data models? Do we have data flow diagrams? Do we have data standards? Do we have a project lifecycle for data development, et cetera, et cetera, et cetera? That pillar to me is where I see data architecture fitting. And then tools and platforms that I put at the end there, if I could put it a little tiny thing in the corner. Love tools, Emma Bicknerd was actually on the vendor side, developing several of the tools in the market today for a little many years. So not that I don't like tools, but maybe that jaded me. It shouldn't be tool first, right? Tools should fit the project at hand. So not that I'm not a fan of tools, please don't ask me in this webinar, which one to pick, I will not answer. And we're vendor neutral here, but we'll talk about that at the end of make sure tools are as a result of your data architecture goals and your data governance goals. And don't start with a tool and try to make it fit, right? So moving ahead, this I will not read every row or be here all day. But often when we show something like this, like we call it our house, our data governance house, what goes in each one? What do you mean by organ people? What do you mean by processes and workflows? So these are just some kind of questions to help delve in. Again, each one of these cells could be probably a whole webinar, right? But am I aligned to my business strategy? Is there a clear understanding of the goals and why we need governance? Organization and people both many things. Who are the key stakeholders? Who are the consumers? Who's the users? Who are the stewards, et cetera, et cetera, et cetera. And you can kind of read through each of these to really get an understanding of some of those ideas in each of the pillars. So I'll go through some of those pillars and just kind of a little, I guess I call it a visual mnemonic. Here is that organization and people that kind of, oops, sorry, the people that you saw in the house here, right? We'll kind of go through, you'll see the people, you'll see the process, you'll see the data management and then you'll see the tools. Again, all at a super high level, but just to kind of set the stage. So when we look at the organization and people, then this is something that, again, if you're not familiar with the data manager, Dama Diembach or the data management body of knowledge, that they've got some good best practices. I would say the kind of the line up top, but there's no one size fits all. You may not have these roles. You may call these roles a different thing. You may have a subset of these roles, et cetera, et cetera. These are sort of standard, generally used best practices. Again, I'm not, don't say that Donna Burbank said we need to have technical data storage, you may, but that might not fit with what you're doing as an organization. So with that caveat, generally back to that everything should be vision led. There's generally some sort of executive sponsor and I feel strongly that this executive sponsor should be from the business, not from IT. It was having a bad day the other day. A project was not going well and I said, okay, what was almost no events to what I'm going to say. What have been the themes of when we've had a data governance initiative that hasn't gone as well as we would have liked to is generally when it's IT led. Not that IT is not great, not that the technical themes are great. I consider myself a technical person, but people expect the data team to say you need to have good data, right? Your executive champions should come from the business. Your chief marketing officer, your chief financial officer, your CEO, your chief medical officer, whatever that is, not your chief CIO or even your CDO, your chief data officer, right? You need to make the show that this is driven by the business and it should be that business. We need this data to be a better so we can drive our business, right? Then generally, there's some sort of business data owner or data owner. I mean, it could be redundant. Generally, your data owners and data stewards are from the business, but we kind of just say that to stress that point. And to me, your data owner is gonna be more at your director, manager, VP level, depending on your company. They're really gonna kind of set that high level business rules and strategy and maybe some KPI thresholds and things like that. Your data steward is a little more into the day to day into the weeds. They're probably gonna understand some of those key business rules, et cetera, et cetera, often report up to a data owner. And then your technical data steward, one of my many rants that I will hold back from today is you don't do your data management or your data governance by saying, well, that's the Salesforce data or the, I used to vendor, but I think it's common enough, right? Or the PeopleSoft vendor or the clinical data management that, we tend to almost use the tools as explaining the type of data or a business process. It shouldn't, your business process should live outside any software and your data should be independent of any software. That said, that software does drive things you need to have and a lot of your rules are embedded in that software. So generally having a technical data steward who is a PeopleSoft expert or your clinical data management expert or whatever, whatever, whatever. So you need them to live together with your business data stewards. But key to this conversation, took my time getting there, apologize. Or are the two at the bottom? I would say your data governance lead in your enterprise data architect. So I would say where those business roles up top like your data owner and your data steward and very much your executive sponsor, those aren't like you have a day job and you should have a day job because that's your representation. I'm representing again, patient advocacy or I'm representing student registration or sales onboarding, right? And I look at data for that area. And that should be a part of that role. By definition, you have a day job and you're looking at the data as part of that day job. But when we look at data governance or data architecture, that is your day job, right? Generally for data governance to be successful and I know there's companies of different sizes and different budgets, but having that data governance lead be a full-time role. Often that data governance lead turns into your chief data officer, right? Is that champion of the whole data effort. That person should be technical enough to know what data lineage is and data architecture is. But that's, they're more of a business role. And so where you fill that gap is with a enterprise data architect or a data architect. And if you've heard the phrase of purple people, right? That kind of, if you think of maybe red is technical and blue is business, a purple person can kind of see both. And I think both the data governance lead and enterprise data architecture are purple. I should have made the purple, but I didn't purple people because they can kind of see both sides, but it's probably the percentage. Whereas data governance lead is the high percent businessy that can talk just enough about data catalogs and data lineage and data models and data flow, but wouldn't hands on do it. Similarly, the data architect should be able to speak to the business. You should be able to take a complex data architecture and present it in a way at a conceptual or logical level that the business can understand, but they're primarily a technical role. And that's why I will see them as like two heads of the same coin or brother, sister, whatever, but they should be sort of joined at the hip and that to really make this whole thing successful, they can really augment each other. So I see those as really why they're at the bottom there is that they are full-time roles and they are the foundation of that governance as it fits together going forward. So kind of to that point in why I started out with definitions because the more older I get in life and the longer I do consulting or data management or anything is like, what do you mean by that? Could you define that term? We've all, I see a lot of folks in this call that probably been doing this a long time and we can all get a chuckle about, what do you mean by customer? What do you mean by vendor? How does, I was a vendor different supplier, right? Some of these things that seem so obvious can have massive differences in how we define our data and like to define that. So data governance is one of those, right? What do you mean by data governance? Some people think it's the, I don't know, Azure data type naming standards on our platform. They're right. That's a very technical part of data governance. Someone might say, oh, it's our data literacy campaign for our data steering committee. It's a very people-y side and they're right as well, right? And that's sometimes where you can either embrace that and say, yep, yes, and you're both parts of governance where some people get in the head spin and kind of start arguing over it. Again, I seem to be mean to IT today or technical, but I didn't really mean the technical would be a devil in the business to be the angel who's just a picture. I like creating databases too. But again, the point is that probably again, there are very few people, they're the unicorns of the world that can be heads down in AWS and understanding everything about that platform and all the technical business roles and being a champion for change and working with the C level to understand business drivers and things. They're kind of different personality types and just time and bandwidth, right? So generally there's kind of several people who work together with those different pointy parts, I guess. And I may have pointed to Tech or I'm pointed to the people and that kind of thing. Okay, so this is a little more detail. I kind of dusted off and changed this one from years ago. We were at IS, so that's to do a webinar and kind of the different roles and data management, what they mean. And gosh, there's a definition. What's the data engineer? What's the data? Again, could be a whole argument in the webinar on that. But there are some general trends here that I'm just trying to show. We can again, argue on exactly what we mean by these. But I kind of broke them out. There's data architect or technical roles and then there's data governance or business roles. And what are some of the things they do together that can augment each other? So if we started at kind of the technical up top, if you think, so it's technical and business and then kind of from the left is top down business vision. And then on the right is kind of bottom up technical architecture. Hopefully this is helpful and not totally confusing. But if you think of who's setting the vision, the technical vision, that could be your CIO, right? What is our business and design of the whole thing we're doing? Are we going to go digital transformation? Are we going to go cloud first? You know, what are we looking to do? And then as we go down into the business requirements that might be your high level business capability models, your design thinking, you know, what are we even trying to do at a high level? That's going to be your data architect, business analyst, enterprise architecture, maybe data modeler. Again, a whole argument of data modeler versus data architect, which we'll save for another day, right? But that's kind of your high level, maybe your conceptual data model, right? As you go more into designing the data landscape and then down to your database and then down into your execution and into your data source and your platform, you'll see that those roles get a little more technical from architect to engineer to platform engineer. And you'll see that there's a whole range of skills. It takes a village to create a successful data strategy and data implementation. And you can see some of the artifacts that it may be created. I would say almost all of these are governancy, right? So do I have a backup or recovery plan for my platform way over on the right? I hope so. To me, that's governance. That's technical data governance. Do I have back to the database level, database naming standards and data type standards and data platform configuration standards, those are technical data governance. When we go to the left and kind of the business and vision side, if you look at the bottom, that's to me where some of that data business led data governance comes in. So who might be at the vision of the CEO? Again, I feel very strongly and I'm kind of backed up in the industry there. I don't think I'm saying anything crazy. The data governance should be business led, right? It should be your CEO, your chief marketing officer, your chief financial officer. And you'll see there that I put chief data officer in the business. That could be a webinar discussion, right? Why isn't that up with the CIO? Probably could be one of those purple roles in the middle. I like to put it in the business because a chief data officer should be data-driven business. Why are we doing this? Not because we need a better tack is because we need a better business driven by data. Kind of a nuanced there. But then as you go down to the business requirements or the vision, that there's going to be your data owners, your business data owners. What do we want to do with data? How do we high level design it? And that's, excuse me, probably where your data governance lead comes in. That's a little more hands-on. And again, if you're a smaller organization, maybe the data governance lead is also kind of wearing that chief data officer hat, setting the vision mission of why we're doing this. Kind of as I mentioned before, anyone on this call is that career and they're aspiring to a chief data officer. I often feel that the data governance lead is perfect for that trajectory. Because again, we understand tech, but you really have to be a champion for change there. And then as you kind of go further down the stack, the data governance lead really should have at least a high level of vision over all of it. But your data stewards, they're probably going to be more into your, more detailed data models and your glossaries and your, you know, a little more on the technical side, maybe more with the data modelers understanding those detailed business roles. So hopefully that's helpful and not confusing, but it is sometimes where we get ourselves tied and not of what do we mean by governance? Yes, there's a lot of things of governance. What I didn't add and actually had in here and took out as another layer is security. And you may say, why didn't I put it here? There's so much on the slide in a webinar, but there's security and privacy controls or even legal that has a kind of a layer on this. So that's why data governance in terms of the people and getting the right people in the room part is so powerful, but that can also make it complex. So to me, it's also a little bit of that division of duty that yes, the data architects are responsible for those business rules and how they're implemented on a platform or how we handle data life cycle management. You know, maybe security is more, you know, on PII and where the where the lineage of PII is across the organization and legal sets those rules for PII. So they all have touchpoints with governance, but they also have their own ownership in that technical ownership. And I guess to me that's where that data governance and data architecture, those touchpoints, data architects should be in the room and say we have a data governance council. My advice or opinion is it should be 80%, 90% business people, but you should have a data architect in the room. They're almost your technical advisor, right? So you're not gonna go on A, they should understand the business and B, they could help guide down a path that you're not creating something that's not gonna be executable down the road. Similarly, you should probably have security in the room as well. Advisors not drivers of the, this doesn't make sense. So a big slide, lots I rambled about, but hopefully that was sort of helpful there. Moving ahead, if you remember our little now we're on process and workflow. And this is high level, but it kind of hits on what I was talking about before where there's several, you know, meta layers of process. So there's your data governance process. How do we, you know, log a data governance issue? How do we define the definition of customer? Who decides? Do we vote? Do we battle it out with, you know, punching bags or, you know, how do we handle this? So how we handle data governance? Again, these are all overlapping. So how does that align with your data management processes? Sure, data management. Yeah, we're creating business rules and we're putting that a data model or an application. How do you have that touch point for what the developers need or the architects need and how that has a touch point with your data governance and there should be one. And then again, as I mentioned, your regular old business processes. So often when we develop a business data governance council, you know, how do you create that? Again, could be a whole webinar. How do you decide who's in that council? Is it by org? You have finance and we have sales and or is it by business process? We have source to pay. We have, you know, product development, you know, onboarding or whatever. That's often something to think about. But often those process owners are a really good candidate for being in your data governance because they're the ones driving how the data is, how do we onboard a vendor? What do we do when we get a new employee or we off-board an employee? Those are all the business processes that are driving your data implementation, journey maps. And I kept that kind of generic. We often hear customer journey maps. My cynical side is that's kind of the hipster version of a process flow. It's a product data business process from the customer's point of view in a way or, but the reason I left it generic is, you know, we do a lot of journey maps for we've done student journey maps. You know, what is the journey of a student in the university or even a preschool? What's the patient journey map, right? What's an employee journey map, right? So good way to look at that flow charts is that the, you know, I know discount version of a business process workflow, whatever. But again, understanding how data is entered that that really and managed, that's the key part of your data governance operations as well because that's your operational side. So just don't want to forget that when you're doing your data architecture and your data governance because they all fit together. Okay, that's all I'll say about that again could be a whole webinar. Now the other part that it makes this confusing and maybe this will help and maybe again, we could argue was one of these go in the left or the right or does it really sit in the middle? But in general, there's certain artifacts that would live or activities that live with the business side of the data governance. Here's where I did kind of the blue and the red and the purple, right? So if we think business is blue, those are the things in the left. You know, your pure technical stuff is on the right and the things that need to be shared or sort of that purple in the middle, right? So if you say pure business, you know what is our data-centric business goals should be by the business, right? I team might have a, you know, opinion and often, you know, some of the best ideas come from the people who know the data or know the systems but really it should be owned by the business and what are our priorities? What is good look like? What's our success criteria? Business glossary in terms of what are our business terms? What are these acronyms that every company wants to have, right? Then if you go kind of to the right what would be owned just by tech your data architecture strategy or roadmap, you know, again, should be informed by the business but the business and this happens the business shouldn't say, hey, we're moving to AWS or we're going to use a lake versus a warehouse or they should have the requirements and then IT decides that maybe that's controversial but really IT should own that or I'm using IT just to be more of the technical side I know that doesn't always make sense with data but, you know, what tool we pick I'll have a whole rant at that in the end of should be chosen by IT, you know input from the business or requirements from the business but that's an IT thing. Once we get to physical data model physical data setting platform change management definitely on kind of that red technical side where things are shared let me go back to business glossary, right? So maybe that's a shared but there's a certain aspect of a data dictionary data catalog that were sometimes as pure business terms and sometimes it gets into that now we're talking about a critical data element or a metric that needs to be defined with the BI team that's kind of that shared side if you literally had a business glossary just of, you know what is a credit default swap me or what is this acronym mean? The business could own that but right once it starts to get more data centric or you want to put that in a big fancy tool that's where it starts to be shared. So similarly, if we start up at the top you know there's data centric business rule what goes in the data model what goes in the application conceptual logical data models I already talked about the data catalog and then things like data lifecycle and retention rules like maybe you could argue that should be owned by IT but the rules themselves how long do we keep patient information often that's defined by law or defined by the business so that again it might be implemented by IT IT actually moves it to cold storage or sends it off in a box to iron mountain or something but the business really defines that and I think IT was probably the first to say yes I don't want to be responsible for what you tell me and then we get it done et cetera et cetera et cetera there's plenty more I'm sharing this many but the point is data governance is a team sport or for the non-athletes it's an orchestra not a solo or whatever it's people who work together to get there it's not a one person thing and that's often hard when I guess that's both on architecture and governance we're all human we all want to make it in this world but sometimes I'll see a data governance lead that I want to run this and I'm going to make it my project and that's great but to order to make that successful everyone else has to feel like it's their project you get the most success when somebody else gets up at the executive meeting and says yes it is important and you didn't, everyone expects you to say that right so that's that you got to make it the orchestra not the solo and similarly with the architecture there's plenty of really brilliant data architects but if you built that up in your ivory tower and didn't really get the buy-in for the rest of the team they're going to ignore you and build the room anyway right so again that's that purple person that can not only set the vision but get everyone to come along with you I know often people say when they say who's a good data governance lead I say well that type of person that can tell everyone what to do and people still like you and those people exist that can kind of generally shepherd people along and kind of get people to change their ways so hopefully that was helpful as well so back to the data management and measures which is really I think more of that data architecture part of it sorry I've got a glass of water I've been babbling away here to me some of these artifacts are some of those things that are in that purple middle right there's a lot of architecture artifacts but when we're trying to say well how do we get to that intersection of business and tech and architecture I've had a huge success with a lot of these good old fashioned business data model business process model near high level data architecture diagram what are your core business rules what's your glossary what are your policies the data quality dashboard we can talk about data quality but unless we can see it and manage it and track it over time so some of these core artifacts they don't go away again maybe they're not in the top of the hype cycle but they're part of business as usual which is more important still really really helpful where I have had a lot of success in our practice is do them but do them in small bites I kind of the agile version of data architecture pick a business problem and then do the data model around that or hone in on one business process so this might be a hypothetical insurance company what data is going to support our customers or our brokers or maybe we can get better data to price our policies better and should we use external data or then you can kind of build through the the customer journey map or the business process model around that build the data model around that show the data architecture diagram again these can be so helpful especially for people who aren't technical we can't do this because there's no line between system A and system B it just simplifies that in a way or that line between system A system B doesn't have the same data standard so they can't talk or whatever simplifying the problem etc do we have the right data quality to make that decision so we'd love to use this credit information to price our policies but have the credit scores are empty or we don't trust the source of the credit scores or whatever whatever right so I'll show this in the case study but I would say please don't skip a data architecture if you're the type of company that wants to move fast you know break things and move ahead and do it more agile just do it in a smaller way don't do the I would say no matter what company you are don't build the we're going to build a huge enterprise data model it's going to take two years and then come up for air you know people have moved on by then who even knows what's going to happen two years from now right so build it in a way either high level and broad or more detailed and targeted so you can really get some value quickly and then do it again right rinse and repeat so metadata is a big part of that so I will when I rant about tools at the end you don't always need a tool for everything I mean you can data governance your tool could be a word document right or an HTML page to say this is the policy or PII but even better is when you can take those policies and make it an and condition right then add the technical part either the lineage a lot of these data catalogs or a lot of the security tools can do automated lineage AI and machine learning can detect a whole lot now that we used to do by hand in the old days that wasn't that one so again things like metadata management or lineage really are super powerful and again working together right you don't want to have your audit trail your lineage not tied with your core policies and again seems to be a trend I've just noticed in the past maybe 18 months here of things like PII or security a lot of companies now have the fancy tools and they can do the lineage and they get but the question is I don't understand what those rules are what are the policies how are we defining what PII really is some of the basic ones we know you know social insurance number social security number but you know beyond that is age PII is a gender PII and so that's where the governance side if that happens so this is a great example of you need the peopley side in the business needs of what PII is and all that nuance and the technical audit and lineage and if you only had one of them it wouldn't be very successful you don't want people in the day to governance committee you know setting a PII rule and walking around asking people do you have PII that would be one extreme and you want to automate that but the other stream you don't want to just automate all the PII detection but not have a good definition of what PII or personally identifiable information is right so maybe that's obvious but I thought it was a helpful example okay here's my tool rant so tools are great I built them I use them love them but don't start with a tool so one of my favorite stories so one of my customers either start or become friends and we joke about one guy I'll leave him Frank just for a minute but I ran a big insurance company in North America and I met him at a conference and someone said you should talk to Donna I say she can help you with your data governance and he said so what I want to buy this tool that we're made on I like what they call them Frank Frank you can't don't start with the tool like you need to do everything else you need to understand do you have a data governance committee no do you have roles no do you have a you know charter no and so we'll get all that stuff in place before you go look at the tool I saw that demo it's really cool like you know Frank stop so we did we get a whole data governance strategy we did a whole data strategy they ended up committees they did actually everything right and then at the end he said can I buy that tool like please don't if you're just playing with me but one of the things we did as part of that is what what tool do you need even though you need a tool these tools could be so different and data governance and data architecture have so much nuance to them that I hope you're maybe pick up on a few things you hadn't thought of you know from your kind of viewpoint is it some tools are really good at you know helping you create that data governance organization and the workflows how do you validate a business definition there could be workflows that go to the stewards some are really good at that so here you know they did a kind of a matrix what what's is there a business need and then do we need a tool for it so yes it's a business need but you know just create the organization and this company maybe I don't need a tool for that it could be PowerPoint you know it could be a whiteboard or it could be we have such a complex organization we need one of these tools that can help us with the workflow neither answer is right you need to tell that right or it logging issues you could do raise your hand in the meeting that would be one extreme you could do a SharePoint workflow or you could buy a big fancy data catalog or you could use JIRA or you could again a lot of different things business glossary is a classic one you might just want to start even with an Excel spreadsheet just to get you know and I often recommend folks to say do do everything kind of like when you were in math when you were a kid and they'd make I don't know how they touch it now but we have to do it all by hand before you use the kind of calculator we're like why don't we need to do this one of those calculators well because you need to know what the calculator is doing so I kind of yes math teacher and when I was 10 you were right right so same thing with a glossary a lot of the part of a glossary is getting those definitions getting people together to agree and in that process do that first without a tool is what I'd say and then you can say you know do we need a tool that helps us with the workflow how do we need to publish it do we have hierarchies of glossaries do we need something fancy or can we do it with a SharePoint list you don't know that answer until you've kind of maybe gone through it in a pilot or a trial again so you know one of the customers who work with did something like this so based on their the importance of each functionality and who is using it another aspect of it is it needed by the tech team or the business team and then what features do you need you know a lot of companies by a great tool but it's a techy tool that they put in front of business people or something that the business really liked that they you know it's just not robust enough for the tech to really give that some thought tools can be super powerful but there's so much on the market today and there's a lot of overlap and do you need a glossary or could you do enough with your data modeling tool and publish the attribute definitions out for now right I mean and a lot of those tools are now yeah every tool has a catalog it seems now right I was on a I was on an analyst briefing this morning and we kind of you know we're joking about the catalog of catalogs because you know each each vendor has his own catalog right so anyway my small rant about tools yes they're good please don't start there and again the the tool that Frank wanted actually was completely not fit for their business use case that ended up with a very technical lineage tool because PII was very important to them and the one he was looking at was beautiful and it demoed well and it would have been great for a different use case but it really wasn't what they needed and he's still disappointed because it looked nice but it didn't do really what they needed to do okay so here's the case study and then we'll I promise we'll wrap it up for questions and then let you go in your merry way this was a good example I thought this was it kind of puts a lot of the pieces together that we had talked about with how governance and architecture can work together so this was a major retail company growing rapidly they're based in the U.S. sold a really high-end product that was IOT enabled and they could kind of track customer use and they were really growing rapidly and really and they had a very loyal customer base because these were high-end products so maybe you bought four or five in your lifetime and your friends bought them kind of thing so a lot of good things going for them but their data was a bit of a mess they had had a couple things both on the business side and the technical side and unnamed company loved them but let me the first to admit this they had two master data management systems for customer you all see the irony in that single version of the truth and we have two of them we like it so much even on the technical side they had a big major outage that lost they could calculate the revenue they lost because the data engineer database administrator decided to change the length of the product code on an operational platform well that's that's technical data governance everyone should be cringing right now that you don't do that they lost a day and a half of sales because their systems were down so they had it on both sides from the business and the tech and they're trying to grow rapidly selling stuff so how do you convince management that's growing rapidly to selling stuff a terrible way to do that would be like you know we need to automate the data types for our product code probably wouldn't get it right so you needed to kind of tell that story so what we did is we did something very similar to this different use case but we picked one area one of it was they were they were not able to track their customers for when they went into the showroom and looked at this product they said what's your email they said go away at stupid.com because who wants the email from the sales rep and then when they actually bought the product and they wanted to have it delivered in the wrong email and they had to you know they did their best they called the people and tried to explain it but it looked really bad so they picked one piece of the architecture just email address did a customer journey map business process model data architecture diagram saw where the disconnect was between these did data quality saw that half the emails were wrong or missing and then created some rules and policy around that really successful sales was part of it marketing was part of it may have heard me tell the story before but it's just it was such an extreme example of how this working we did it in a month and a half of again you can do a lot of these architecture diagrams in the small piece the head of sales sales not usually your purse person that wants to be governed said oh I need to have my folks actually put in the right email address I'll start and sending them on that because I didn't realize how important it was to marketing and everything else huge right if we had just come in and told the head of sales to say make your make your folks put in the right email address that wouldn't have worked he had to see through an architecture diagram like these how it flowed and how it affected things and then the head of marketing she was this far basically said I never thought I'd be using the word data flow diagram but no one no one else explained to me why my marketing campaigns didn't work again it was all email driven but they didn't see how things fit together so this was a good example they stood up a little mini data governance council with all the right people in the room picked one piece of data architecture used all the good old fashion tools and really made it business decision and then moved on to something else some of the bigger challenges but picked one thing so that light went off so ending with a happy story in summary data governance is both both business and technical when they work together right you have a lot of success and it really does take that vision the village to you know it's both process and workflow and tools and all of that that need to fit together to make that magic happen but but it can so as share get that questions together just a shameless plug if you want to join us next month it is all about data literacy around data architecture another shameless plug we do this for a living at global data strategy if you need help come to us we're happy to help and now I will open up the questions from Shannon Donna thank you so much as always so many great questions coming in and just answer the most commonly asked questions just a reminder I will send a follow-up email for this webinar by end of day Monday Pacific time with links to the slides and the recording and to past webinars as Donna mentioned so diving in here Donna what are the realistic deliverables of data of a data architect in a data governance program um I think some of the ones that we touched on see if I can move my own slide probably not I think some of this picture give some of those so I think data models are a big part of it data catalog data dictionary again there's generally an overlap between a data architect and the business side data flow diagrams you know your your overall data architecture diagram data quality dashboards maybe you again you depending your level if you're the only architect or you lead some architects you know sometimes there's a data quality analyst that does that but I would start with some of the basics your data architecture at high level data or you know system architecture diagram business process model if you can and kind of show those data and you may work with a business process analysts but kind of show those data touch points in your good old fashion data model is always a pretty long spot I love it so Gartner says in 2022 many data governance programs will fail due to the challenges faced in implementing it using traditional approaches can you tell us if this is true or what your opinion is on that well I Gartner likes to generate headlines with something like they're all going to fail and then I would pull my definition hat on what do you mean by a traditional approach right so having said that and been a bit snarky to poor Gartner who I actually respect I mean I think what do we mean by traditional approach I mean I think something we've found is that more kind of business led collaborative approach you know rather than let's just set a bunch of rules and policies and force people to do stuff and we don't know why I think if that's what they mean by traditional absolutely agree I think it has to be a little more agile a little more dynamic a lot of the even data catalog tools are much more collaborative driven and letting people you know it is and it may be another thing they might need but I didn't read that article I should have but about traditional is like and sometimes they still work if you're talking about master data you create the definition and the committee approves that it is validated it is vetted from the top down but if we're talking about measures and metrics you know maybe that needs a little more discussion and you know collaborative chatting and that kind of thing so I think there's a lot more tool some of the traditional approaches need to stay I think I have that in a previous webinar like depending on your data again master data probably should be pretty traditional and structured we're doing some data science and exploration maybe it is better to have a more collaborative approach to kind of coming up with metrics and definitions so I think it's a bit of a mix but yeah you don't want to be too rigid with anything with governance that's a great way to to alienate people and have them feel like they're not part of the conversation perfect and I'm going to try and fit in as many questions as I can hear we've just got three minutes left what does a data governance program takes or why does a data governance program take so much time to show value why value is not shown to consumers immediately or in the short term good point I mean I I were a big fan of I've tried to do it and in quick way I mean the reason it takes a long time is because of a lot of big decisions that need to be made but back to email address example that was one that they came to a decision in a month and a half and then we're able to execute something pretty sometimes those things to change right and now now make sure that all emails are right across the whole organization that that took some time right but what we try to do in that magic sauce is what is something small thing you can pick that's going to show success sort in the short term so that people can have the patience to do the things that take longer you don't always have success like this but we did one we did a data address clean up right before a big campaign for a non-profit they tracked the addresses they cleaned up and then they may you know not huge for another organization but this was a smaller company they were able to show $75,000 in additional donations based on those clean addresses right so that one was like in a month they showed ROI you don't always get something like that but is there something like that where you can solve one problem and then show the ROI and build so you can't wait because people are they're busy right and they're going to go on to the next thing so I would say try to build your data governance with a bunch of small quick wins as you do those other ones that are going to take some things just take a long time but you have to show and keep marketing marketing marketing so people understand that all right Donna and we could probably do a whole webinar on this next one but we've got two minutes so I mean we need your elevator pitch so even even the best data cataloging metadata repository tools have major deficiencies in implementing data architecture artifacts so I'm not sure how a data architect can be successful in this program well I say data catalog is not the only tool in the toolbox so again and I'll blame the vendors there is now we have catalogs you don't need anything else I mean you still need a data model you still need a data architecture diagram I mean we've often though taken something like a conceptual data model and put it as a link in the data catalog so that because a lot of business people like that it shows not just the glossary definition but how those things fit together so you know definitely own your own artifacts and there's a whole place for that but some some of those can't be published and kind of highlighted in the data catalog even if it's just a PDF picture that tool doesn't support it very well and that's often a nice one that gets people's attention oh you did it I love it perfect timing Donna thank you so much and thanks to all of our attendees for being so engaged in everything we do but I'm afraid that is all the time we have slotted for this webinar again just a reminder I will send a follow-up email by end of day Monday with links to the slides and links to the recording of this session thanks everybody Donna thank you so much thank you you'll have a great day good luck everyone bye-bye