 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer for Data Diversity. We want to thank you for joining the latest in the monthly data webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss how do data governance and data architecture support each other. 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 by the Q&A panel. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And just to note the chat defaults ascended just the panelists, but you may absolutely change that to network with everyone. 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 the session and additional information requested throughout the webinar. Now let me introduce the speaker of the monthly series, Donna Burbank. Donna is recognized industry expert in information management with over 20 years experience helping organizations enrich their business opportunities through data and information. She currently is the manager at G-Limited where she assists organizations around the globe in driving value from their data. And with that, I will give the floor to Donna to begin her presentation. Hello and welcome. Hello, thank you. Always good, good to join these and see a good turnout of familiar names and faces. So great for those of you who it might be your first time joining this webinar. It is a series. Dataversity does keep all of the previous series on demand. So that's a great resource. And then you'll see that there's a great lineup coming up the rest of the year too. So if this was a mid-term review and some of these other topics, please do join us with a lively bunch of data professionals. There's always some great chat and discussion during these as well, which is always nice to see. Yes, the topic of the hour is data governance and data architecture and are they the same thing? Are they different things? How do they work together? And we'll talk about that because I think there is a nice synergy between these two disciplines. I do clearly see them as separate things, but we'll kind of talk about that and how you can use both your advantage as you do the various data initiatives that you're working on in your organization. I do want to start by this idea of the importance of data governance and my association of data architecture. So a diversity and my company global data strategy each year publish a survey on trends and data management. And what's been really nice to see is that it's trends we do it each year. Year over year, the focus on data governance has been steadily increasing. And if you look at this year's survey about 88% of companies. And again, this is the data diversity survey. So not totally strange that people are doing data governance, but I still think that's a solid, solid number. Not everybody was in the same level out of folks were starting or planning. And I'm seeing a lot more of that too is more and more types of companies that maybe didn't focus on data as much, you know, if you're in finance or you're in government or, you know, those types of industries have been doing data from the beginning. And now what's exciting to see is so many different types of organizations and nonprofits and manufacturing and no matter, no matter what, so people are paying more data driven so that makes sense, but it's nice to see. You know, percentage there that I like to see as well is that people specifically mentioned that a benefit of using a defined data architecture was improved collaboration. And that may seem odd to you if that hasn't worked for you. With the global data strategy, we, we do this a lot and we see it all the time that using something like a conceptual or logical data model, or a data catalog or business roles related to data is a really key and very successful part of a successful data program. If you haven't seen that in action yet hopefully this, this webinar will give you some good ideas, because to me that's that sauce of having a really strong data architect and a really strong data governance lead. The same person company probably not ideal, but but you're having that that link and click together. It's really where you see a lot of success around data governance so hopefully we'll, if you're not doing that already and that idea is new to you maybe by the end of this webinar, you'll have some good ideas. We do leave time. And if I do this right, we'll have some generous time at the end, actually have some Q&A, if you have more ideas about that so don't be shy. This webinar is for you to learn so as a good data architecture data management professional I have to start with definitions, and where else to go but the dama dm Bach if you're not familiar with that body of knowledge. It's the data management body of knowledge that you know people who have been in the industry for a long time have kind of collectively shared their expertise and it is a really good asset if you haven't seen it before. So their definition of data governance. I like it's the authority control and shared decision making over the management of data assets and if you've seen some of my other presentations I really go deep into that definition I saw once again and Yang right of, if you have to have that authority and control, but also the shared decision making right you have to sometimes be very strict but also make sure you're having that conversation and that shared decision and it doesn't mean that you just have a big stick and tell people what to do. I'm not going to work around data governance so getting that balance right data architecture is kind of the sister or cousin of that right. It represents the organizational data at different levels of abstraction. I like that distinction in the definition we'll talk about that in the session of, you know, data. I'm a huge fan of data models if full disclosure there. I usually show a physical data model of a detailed CRM architecture to a business person, no way, but a conceptual model or a logical model right by the same token if you're a database administrator. You know, conceptual models helpful but it's not going to help you actually build the database right so tool right tool for the right job. It's also like you know the part of the bottom of you know that it is there's a series of architecture artifacts right that are the different state is this current state future state. Are you defining requirements is it a data integration diagram of high level data strategy schematic right so a lot of different pieces of an architecture will will cover pieces of it today not all the thing not everything you'll possibly ever do. I'll give you again some, some good ideas to start or continue of where you've already started. So, again, if you've joined these webinars you've probably seen this, our framework that we use for a data strategy, because that's in her name what we do a lot and a lot of more and more companies and I love to see it, are doing a more formal data strategy that differentiates from data government data governance or data management, and that really it's that aligning your business with, with data right so I'm trying to be a more successful organization. How could data support me and do that data governance is really that link between the tech and the business right so what are the people process policies and culture, and is also a technical aspect of governance and whenever. And when I asked someone with, we're talking about data governance for the first time, but what do you mean by data governance because in your probably both are right some people are thinking of the technical data governance right your data architecture standards your data types your naming standards your rules, that's data governance. Also, there's people and process and policies and culture building and all of that are data governance so that there's a differentiator, but I almost see architecture and some of those other things you see in that framework like quality management and things like that are really also a data governance, or pieces of it right now, the outfit together. It's a little more specific on that this is the data governance framework, we use that talks through that and I'll go through some of these boxes, you know, again, it's just a short webinar but you have vision and strategy that's super important to any data governance initiative. You know, why, why are we doing this and what are the benefits are we saving time are we saving money are we, you know, supporting a marketing campaign are we, you know, protecting patient data, you know, there's a lot of different reasons we might be doing this. We come in a lot in our practice after failed governance attempts and so often I see we go in and we'll do an assessment. Nothing is necessarily wrong, you know, people might have a great policy or they might have great, you know, technical artifacts. Often they're missing the why, you know what why would someone from the business want to do government as soon as you explain that and can can tie it directly to people's day jobs in the business. Governance can be super successful and you will have people say oh my gosh how do we live without this this is so helpful and more efficient happen just this week we were doing of all things we were doing a data modeling session with like a school for children and had to do with some of the classroom things and one of the people who was a nothing to do with data basically said I love this, this makes everything so much more efficient. I wasn't surprised to hear that anymore I used to be the first few times I heard that. But when you get governor's right a lot of that oh my gosh thank you this finally clarified this problem we've been having or gosh this used to take me all weekend to fix the stuff and now I don't have to write isn't a catalog or is more efficient process so that is why one of the big reasons you link it to the vision and strategy and then that also ties with the cultural communication. But the other the kind of the pillars of that framework are the people in the org you know how do we get the right people in the right roles processes and workflows we'll talk about that. It's twofold it's what processes we do to manage data, but also what are the business processes that support data and the use of data. Data management measures, we'll talk a lot about that that's the arcade that really is probably your pure architecture, your data models your data standards your catalogs your metadata, all of that. And then tools and platforms and I will wax poetic about this at the end, fan of tools I used to be a tool vendor way back in the day and but don't start there right, and I often see where people again, if video governance fails. It seems to me what to someone come to me say what tool do I buy for governance and like if that's your first question you're probably on the right track there are tools and I would say there is never one data governance tool. I know a lot of the vendors because you think back to that first slide of the 88% of folks are doing governance vendors are onto that right and you know a lot of folks want to have that data governance moniker as a positive thing and that took me for a while to realize as well as data governance is now sexy. We have our time in the sun. So a lot of tools will brand themselves as a data governance tool. And they may be right but there's just not just one tool business. So each of the boxes will talk a little bit about not so much the vision strategy culture and communication because I talked a lot about that other webinars but here I kind of want to talk about those middle pieces a bit more. So, you know, what do we mean, we're talking about architecture and governance and then how can they fit together and support each other, which is the topic of this webinar. So, I'm not going to read through each one of these boxes and bore you to death. But hopefully this gives you a little bit more detail that the types of questions these different buckets answer you know business strategy I talked a lot about that what is the goal is there a clear vision. And if you do not have that start there. See I said I wasn't going to talk too much about business strategy and here I go I can't not because I again, usually when a data governance program fails. It's not my data type was wrong in this particular fear this super important, it absolutely is, but more often I see a lot of folks that have the great artifacts, but it doesn't a time with a vision and can you sum that up in a quick, you know, 10 slide deck to and Shannon likes to demand that they always talk about the elevator pitch but you have to have it for your data governance program right. Again, I sometimes come in and someone will show us their data governance strategy or the data strategy and this, you know, 50 page document which may be correct, but no one's going to read it right where they're not going to read it unless they see that quick message first it's going to prompt them to read it right so really do spend time in that business strategy organization and people. You know, do you have the right committees if you need them the right roles and responsibilities both technical and business processes the workflow will talk about. Again, it's both business process and technical processes. Data management measures, this is just a tiny subset of them, you know data models, mappings between business process and data things like that. Data culture. Again, we won't go deep into here but super super important, and it's often forgotten with data governance programs as well we've we've launched it we built the glossary and this is all great. Did we remind everybody does, does everyone know about it to people continue to know about it. Do they, you know, is there a data literacy program, or people and sent it in their job roles to continue with governance and it's an ongoing thing it's a program, not a project right finance doesn't go away or HR doesn't go I did governance doesn't go away it's not a thing you do and then stop right to be ongoing. So therefore you need ongoing culture and communications. And then the tools and technology which we'll talk a bit about you know what do what what a what tools and technology are you governing that's part of it. And then what tools and technology do you use to govern the data right so all these things are kind of interrelated. And then the organization of people kind of going through this framework. Again, this is just indicative this is just an example. There's no one size fits all approach to governance and again I could do a whole webinar, just on this one slide, or this very topic. But this is fairly common and again if you go to the day and the day and box is these types of roles you might call these little different owner sometimes has a baggage around it you own the data or you supporting the data you know all of that but in general, you know some kind of sponsorship, you know who's going to be promoting this for you hopefully at the sea level to really help drive that program data owner tends to be and again these are all good but more on the management level that you know what are the key KPIs we need to look at and one of you know goals, the steward tends to be a little more rolling up your sleeves, they might help with some of the detailed technical, you know, business rules and things like that, but all of those first three are on the business side right because data governance should be driven and supported by the business that said you may have some technical data stewardship who handles the SAP system or the CRM or, or whatever right but they should be named thusly right it's nice shouldn't be it driving a data governance program, which kind of leads to those two roles at the bottom kind of the focus of this webinar right if the data governance lead so they're leading the data governance program. Often, you know their their best sidekick or co co partner and crime is is that data architect and I do think those roles should and do work closely together. Again, they may be the same person in a company. I think that should be a short lived thing if it's true I know if you're small you don't have 5000 people supporting this. But why are they different the data governance lead I often describe, they should be in the business side. They should be a champion, a good project manager sometimes is a good type of person for a data governance lead. If they're a little bit more extroverted they're really trying to drive the program and should then also be able to turn around understand and maybe help manage it for the loss area understand the need for some technical guidelines. They're not necessarily the one building the data models are building the state technical standards and things like that. That's sort of where the data architect comes in, and there's different levels of data architects there's technical architects business architects. I think the best forward facing you know business facing. The role of a data architect is going to be that type of data architect that loves to whiteboard and get up in front with people and, and maybe draw out against have a data modeling workshop with the business right I don't think the data governance lead should have to do that. But a good data architect is worth their weight and gold who can really describe these business roles and map them in a data aware way. This is going to really get to these and that's like that quote I mentioned earlier this week oh my gosh this is so helpful and so beneficial that's the data architect that's going to help with that of just, and I hear that so often you have clarified this problem of having just by mapping it out. And you will have business people starting to draw out data models themselves or draw out your business roles are asking for glossary definitions right because again this is their data or your data if you're a business person on the call right. You're using this every day in finance and HR manufacturing right you want to get the data right so that's where I think a good data architecture can bridge that gap. Often business people say to me of, you know, you've been trying to express this data problem, and this is a good language to do it through things like glossaries and data models and things. I'm kind of testing this but it's probably worth a slide itself again, just semantics what do we mean when we say data governance, you're probably both right of there's a touchy feely kind of people side, and there's a detailed dirty technical side. And there's something for everyone some people love to do both. I love to turn around and you know the market solicitor like that right I love to one day I'll be turn around right and SQL code and then I'll go present to people and but I think that's a bit rare. And there's purple people the unicorns. But I think with dead governance is one you know having a great data governance champion that loves working with people that wants to put together a change management program and a video series on data literacy and things like that absolutely embrace that kind of person, someone else who really loves data standards and databases and can't not look at a spreadsheet of the data types are wrong. Right, you're probably I'm one of those people. So, so you, you want to embrace that person right embrace your inner librarian your inner accountant that type of person that really loves that level of detail, both have a role in governance and there is a touch point between those so join the club if you're in either one or both of those categories right. So, on that note, kind of rare to find all of these great things in one person and even if you did just too much work for one person, and then just too much diversity so you know it takes a village to have a great day the governance program and a wide weight of roles are involved and maybe this picture kind of shows some of that so two aspects of that one and we like to kind of use these these colors of kind of the red is your technical and blue is business and one of the reasons I do that is because I like to put those two colors together purple people right and that's kind of a phrase in the end if you have heard elsewhere of, you know, for those people who can kind of do both or like to kind of live on both sides of that sense. But if you go kind of from left to right that data center I mentioned, you know, having the why right what are our kind of business requirements and things like that are super important what's the vision and why are we doing that is a really sorry wrong slide. Right multitasking it didn't work. Oh my gosh it's not going to work. Sorry. Having some system errors here. Gonna be one of those days. Let me try this again. Absolutely not working freezing the system. One moment one moment we've all been here. I can fix this. All right, don't use annotation mode on the slides I think that's what it taught me anyway I'll just verbally walk you through the slides. So on the left is kind of that business vision right of why are we doing this what are the goals. And so the business side, you might have your CEO or CMO or CFO, and they do more and more get involved and are motivated by getting a data governance program. At the top that might be your chief information officer and also be involved of why are we doing this. What is the business vision but at the CEO there they're responsible for driving the company. And it could be that my role as a CEO is to increase profitability that is their job right, but then when you get down to kind of that second level with the business requirements. You know the data owners or the data governance lead their job is to kind of help that CEO be more profitable through effective data governance and effective management of data which helps increase your business profitability and your efficiency through data and all of that so that's kind of that right between those. Similarly at the top with the red, kind of your data architect or your business analyst enterprise architect, you know all these kind of roles should be good at kind of explaining these business linkages or business requirements through things like models or capability diagrams or process models or data models, or to really kind of link those together so maybe that's a good example the data owners are going to say these are business needs around increasing profitability. The business analyst might be so well these are the capabilities that are affected and these are the data areas in the data systems and how we can manage that. So as we kind of go down the stack that how do we implement that into the third column there which is your data landscape. So what are we even talking about is that 1000 systems that 10 so things like a system architecture diagram or data flow diagrams, kind of at that level. As you get kind of in the middle of that stack that then how are we going to turn that into a database or a data store or whatever right that's where your data models, your glossaries your semantic layer for bi. Your data architect data model or maybe a data engineer some of these kind of morph, you know, good data engineer should be able to create a physical data model, but good data architect should be able to do conceptual logical physical physical things like that. And different roles have slightly different names as you go down well how do we execute that data landscape, your data engineer your data integration person your etl right so they're going to have their own performance and tumor requirements their data platform standards their data integration standards. As you move down even to the database itself you have a data engineer DBA, they're going to have their requirements for database creation and storing the database and then even the platform. You know how do we move. Are we going cloud over going on prem. How do we move from production to you know all of these columns really have some of their own requirements and touch points with governance so I think if you're missing any one of these. You probably don't have a fully governed environment right, you can have a great business vision. But if our systems are integrated and the platforms are a mess. You're not going to have success by the same token if all your system platforms are perfectly running but we don't know why or they're, they're showing our business problem. You're not going to have a success there either so you know a lot of folks have even I think one of the origins of the slide was you know what are these roles even mean what do they do. And I know there's some overlap and people use different terms, but kind of starting to go around some of the same terminology always helps as well. So hopefully that was helpful. So here's a slide you saw at the wrong time. Let's see it again. Process and workflow can all often be tricky but it's often one of the more important for a good successful program. And again words, right words mean things and people have different definitions and this one makes sense right so data governance and data operations have processes that make sense so how do we log an issue for data governance how do we have defined a data steward for a business area. Those are operations and processes around data governance itself. If we kind of go clockwise around that so data management processes might be you know how do we document a business rule, you know specific things around data that are processes you know how do I, you know configure a database, you know all of these, how do I manage data input validation with a code look up lists, when someone enters a state code or region code right all of those are kind of your data management processes, and then business operations. How does the data get in there to begin with right and we, Shannon I was talking about master data management right before this call and we're saying one of the challenges of master data is that because it does link so closely. It's like a business process or even operational data right, how are people putting the data in who owns that that's your pure data stewardship I'm, I'm entering a customer's address. How am I entering it do I have the right. Am I the right person being me updating it am I updating it but someone later down the road updates it but the systems don't talk to each other. Do we let the, the customer themselves update their own address right all that stuff. I have address standards isn't enough because you on the data side if you're a technical person can create those standards but if the business isn't following it, or it doesn't match their business process or way of working. It's not going to flow and I think with governance business processes so because at the end of the day we all have to be doing things in our day job that involves data and that's almost the core of governance and ideally with governance you're optimizing the people's day job right, could the address auto populate from the other system and I don't have to do anything and it's always right. I'm a business person and I'm happy because you've made my job easier and you've made the data quality better right when different was often frustrating about data governance is when it works well you don't notice. You know you have these business folks look of course I put in the address and it's just there and it does it ever not work that way. They say oh how lucky you are right. So, when these three things fit together really well, and it's a cycle right so that business person didn't have the address auto populate they have a problem because it's wrong address or they don't have a certain country listed or something making a long issue through data governance and then through a data management process and comes full circle right, so that's why these are sort of overlapping and they should fit together. These shouldn't all be done on a vacuum and that's why things like data governance committees and things should have representatives from all these areas should be heavily business focused, but also enough that the data folks that are can be sort of these technical advisors to say this might be a way to help support that process and vice versa. So hopefully that's a helpful way to think about things. This has been helpful to some folks and we think of you know some things are purely business centric governance. You know, again, what are our business goals why are we even doing this what do we prioritize of the myriad things we could be doing. Should we be focusing on customer data or suppliers more important right now to be managing or whatever right, how do we prioritize those. What is the ROI are we trying to be more efficient. Is it probably is it is it trying to increase profitability by understanding our customer like all of those things are super important. They should also be owning things like business glossaries they own the business terms right what do you mean by this KPI. How do you manage to define this metric things like that. The single side on the right, it could be your data architecture your data centric tools standards, you know what what Indian tool do we use or whatever you know physical data model standards, etc, etc, etc, right. And then the shared there's some tools. And when I mentioned earlier on the call this idea that architecture can promote collaboration. These are some of the tools we've had, you know, or artifacts we've had success with data models huge you know how do we even define a customer let's map it out on the whiteboard and we can see that there's a prospect that goes to a customer and a customer has a parent company and blah, blah, blah, right. Data catalogs and data dictionaries are really or data catalogs particular, you know put front and center some of these things like business definitions and calculation rules and things. You know, life cycle retention rules right generally legal has a voice on that nature has a voice on that you know, so a lot of these rules are business rules. But should be implemented in the tech right and that's hopefully those things fit together. This is on the data management side. Some of the tools that are often used in a data governance program. What I like about this approach that we're showing in the slide is what I think stops a lot of people with I can't do architecture just takes too long and I don't have a year to build a full enterprise logical data model like we don't have to write what can be really effective is build towards the bigger picture, but do it in small chunks around a business process so it could be a hypothetical insurance company right so we're trying to get some data to support our brokers to better price our policies right or or maybe to better support our customer journey, or etc, etc. Well let's just draw the data model for broker and customer interactions and do a business process model for how are the brokers and customers interact and how is that price created, and what data architecture supports that and are the certain business models around that any legal requirements we need to know, and then what's the data quality of the data we're looking at we even have good information around our customers if not maybe we need to do. Start again and do you know a different model and different, different approach so we've had a lot of success with this. A lot of these are at the high level you can see that business data model is just I want to say just but some simple boxes and lines that those simple boxes and lines can really answer a lot of questions and then go down. This is the business process how are people actually using the data. So here's some artifacts that we use successfully in a data architecture but tied with data governance to really get that business involvement right you can't do any of these or shouldn't do any of these in a vacuum. We've had some good success with that. Metadata is one of my favorite words and favorite terms and we'll talk a little bit about more than again all of these could be a full webinar and but won't be so I mean often there's policies and procedures in a data governance program those might be written and published on a web page or a document. But then there's a technical implementation that supports that and to me, things like a data model, or things like a catalog with lineage or metadata management really help kind of enforce some of those metadata rules so we could say you know you have to, I don't know, obfuscate PII or you know don't share personal information. Well, putting those as first order rules in your architecture and some of your business rules and your models and, and things like that are really affecting that so people don't even have the choice they cannot see credit card number right because it's been, it's been hidden. That's where some of these architecture diagrams and architecture models and data standards in your technical and physical environment really link those two together it's nice to have a policy don't fear people's credit card information. But if it's just passive and it's not implemented either visualizing through lineage to see where credit card is used and or implemented in some of your rules in models and architecture and things like that so those two fit really nicely together. So metadata if you haven't heard that term one of my favorite term stupid stupid name for a really helpful concept, or a complicated name. I like to just simplify it by is the who what where why, and when of data right so who created this data who's the owner steward of this data who's regulating it, etc, etc. What do you go into the what it's, you know, that's often where people are thinking of metadata I think, you know what's the definition of an elephant elephant element. What's the data type what's the security level all that that's very often what you see in like a good catalog or a data dictionary or data model, etc. So where you where is it stored where does what's the lineage where does data come from I'm looking at a metric on a report. I think I trust it but how do I know where it was populated from right so, you know why. It's always a good one to ask why we even doing this but why are we storing this data I mean more and more. So what I think for customer quotes was, you know, the personal data is like nuclear waste, if you don't need it don't store it it's just causes so many problems so you know more, you know, not just collect everything because we can. But if it's going to be expensive or complicated or risky store maybe we don't do we need to know customers social security number to sell them shoes, you know probably not. So let's not store it. So what's the usage and purpose as often you know I was, you know, how is this data used or why it's used could some of them help with the definition, etc. When that's a big one. If you use things like even just open data sets right I have the, the latest income data from, you know, Americans across the country from this year from 1960, you know, make a big difference. And so, or anything scientific data when was that published and why, how long should data be stored retention rules, etc. And then how that's kind of like the one we often think of meta you know what how are things formatted. How was your character, you know, numeric things like that so hopefully that's kind of a helpful way to kind of look at things like metadata. I think it's super simple and obvious when you see it and you see you need it but just trying to get seemingly academic but it really shouldn't be moving ahead, my slides will participate. Data models are kind of in that metadata catalog of wax, you know, love lovely things about them. It's important to remember the different levels of data model and an enterprise level that might just be a high level subject areas we're talking about supplier data customer data location data, etc. Conceptual is often where people start, which is, you know, what do I even mean by customer, what how's that different with supplier can an employee be a customer, all of those kind of high level rules or hierarchies as a customer the company is there holding company above a company is there a contact within the company just at a really high level that can be a conceptual your logical goes down one more layer where the business rules around that what are the data, you know, attributes of a customer first name surname things like that what are the data types and then at the physical level that's going to be your actual physical tables it's a pyramid because it should be a larger number when you get to the physical database conceptual really should be able to fit in a pay definitely an enterprise model can fit in the page, you know, mostly a conceptual model in the page even at the largest oil company in the planet because, or largest government or whatever, because it should be a simplified view. And when you look at the audience that kind of fits in with that slide of it takes a village to do data governance did architecture of you know at the high I think everyone can love a good conceptual model because it really sums up business, but really the audience there is are the business folks they should be enabled by an architect, and then even at the logical level that sort of your more of your business side. Again, the, the, the technical folks and understand that because that's where your business goals are, but now that physical data engineers or DBAs or developers things like that. And when those things get mixed, sometimes this will confusion happen so just a quick example this isn't a data modeling webinar. We do have those out there if you're interested. But yeah, the conceptualist just you know what do we even mean by an employee. And that's where you start to sound crazy to your, your family. Okay, so you, you know you work at this retail company you don't know what a customer is, but you know they usually the more core it is to your business the more core of the definition right at this particular model that I'm showing. I like this approach because it shows the definition it's almost like a glossary on steroids where you have the business definition but also the relationships between things. But even just that first definition and employees a full time or part time worker on the active payroll. Do we have part time people considered employees are we only talking about full time for this use case or should they have to be in the active payroll. We have one company that kept their considered employees for 10 years, even if they've retired right so that depends on every company so being explicit about those rules and discussing it as a big part of data governance and architecture. Logical you'll see, you know, kind of a similar type approach should be simple, but you'll see things there that there's data types there a product has a product ID and a name and the description and and things like that. Often this is where you get into these core business rules, you know, kind of customer place more than one order. I hope so. I support your customer thing. Do they have to have an order you'll see that there's an optionality there. Am I a customer if I've never ordered anything. Is that a prospect right or can more than one customer be on the order like even just those two boxes with some lines can generate so many questions that that isn't just always obvious you know sometimes I get well gosh can I just buy a manufacturing data model. Like well if your company is absolutely exactly like every other manufacturing company in the planet and I doubt it because that's your strategic advantage of how you manage your company so yes you can look at my law school or concepts or physical models from other examples, but it definitely has to be customized because your companies unique your unique and you want to just not take assumptions and often that's where I bought the ERP system and they walk work this way. It doesn't match how we do things. So a model can really something as simple as I don't know kind of company work for more than one department. The number of problems I've seen with that very one business rule from a data model. You know if I'm submitting an expense report connect, you know, different expenses go to different departments. I had that problem myself. Some systems just don't let you do that but that might be the reality in your company that I'm going in a business trip part of its sales and part of its customer support and part of it you know something else so. So that that's where these models can generally be helpful. I'm one of my very favorite success stories with a customer that had done their data model. And they were working with a vendor and they said we want to make sure you match our data and the way we use our data and they said of course of course of course they said but this is our data model. Can you match it. And the vendor was shocked but to the vendors credit. And they worked with them to kind of say well these are the areas we think you might want to customize in a product to match that and it was great to do that ahead of time they did that as part of the sales cycle where they still have some influence right. And it really helped them pick the tool they were using because they understood their data in their business and I wish more people did that they had a much better implementation because they had started with the data. And I think often when people do implementations of things like ERP systems and things like that. It's hard to fix the data afterwards right. And this gives the business folks and the people in that story where business people, I guess that was part of the story then that's why I think the sales rep didn't expect that your average, you know, business person is going to come showing a data model with their data, but it worked really well. And the physical data model, it really does describe your database, and it should have your data types and your, you know, your nobility and all of that can be interesting generally isn't part of a business type interaction of data governance, but absolutely is still data governance. So do we have the same data and matches with your metadata as well is the data type the same across all my systems, you know, is this a required field in the same way across system, you know anyone doing data warehousing, if I live and breeze this right or master data or any data integration efforts, this can really be a challenge and can affect the business I retail my stories I'm sorry if you've heard these ones before but I'm not surprised anymore although I am because you think it was a major major retail company with that will renamed on me named, and they saw a lot of their products online. I still don't understand this one but a data engineer at the time decided to change shorten shorten not lengthen or change shorten the product code of their product in the database and it brought down the website and as you can imagine everything crashed and they lost two days of revenue which was massive for this company, while they fixed it like that is something where technical data governance would have been into play. And even without governance I'm really still flabbergasted that someone thought that was a good idea to do. But again, that's any anything, because we're all human beings who knows that person could have been up all night doing right like good good regulation helps against human error or human mistakes right you know seatbelt in the car or anything that kind of protects you against your own bad day. And that's where data governance can be that person just shouldn't have been able to do that they should have been policies procedures and roadblocks in place for something like that to happen so we tend to talk especially or I do a lot on the business side of data governance because that is a big part of it, technical side, absolutely as important if not more so because that's really keeps all your system thinking thinking and also reduces a lot of redundancy right. So let's have a data standard and do it the same way or reuse tables that are already there and don't reinvent the wheel and so much of that can drive efficiency at the very core of application and database development so definitely important to manage as well. So tools and platforms I told you I'd rant about this one a little bit. Absolutely a fan of tools use the tools support the tools. I just say do not start there. I think I might have told this story before I had a customer at a big bank up in Canada and our big story insurance company up in Canada, and I met him at a Gartner conference and he said I need help with data governance what tools should I buy. I don't start that you're asking the wrong question, and I explained data governance they believe me we came and we did a whole data governance effort was very successful at the very hand he's like can I buy my tool now. Did you know, I think it's just pulling my chain, but that had nothing to do with a big part of what they needed for governance. They needed an organization and they needed roles and responsibilities and there are some tools that brand themselves data governance tools that can help with that. And what are your roles and what are the responsibilities and what are the workflows around those folks that's one type of tool. You might need a data glossary you might need a data lineage tool. One of the tools they ended up needing at this insurance company was a tool to help with their security classifications for their different, you know, documents, which probably wasn't the first thing that came to his mind when he said I need to have a data governance tool he was thinking of a more of a data catalog or data glossary right. They also needed some data standards and they needed some data quality tools that was a big part of what they needed. But we didn't know that we were learning through so one way to do this and we've kind of, you know what all all the things you need for functionality and every company a little different there's some. Some similarities and governance that's why we have a framework but maybe it's the process that the biggest part maybe new data. This is process, not modeling tool that might be your biggest problem right or your process is automated but your data quality is bad and you need to manage that right so kind of list all the functionality you're looking for. So we need a data governance org that's super important the number first one thing we need to start with. Is that a tool solution other than like PowerPoint and Word and whiteboarding like in documents probably not so you don't necessarily need to buy a tool to get your roles together. You might have a tool to support that later, whereas something like data lineage. I need to really understand, you know, the impact of a change in a technical system across all 1000 systems we have probably would recommend not doing that manually. That's a great place for a tool right both are important but that might not be the first thing of the important right so again, no right answer for every company but it's a nice framework to kind of think of that whether that we actually had a, you know, we had a tool that our own tool. So just a fancy spreadsheet that help kind of manage some of this but you can do this yourself or just do it kind of common sense wise right of what our priorities is that a technical solution. And if so, you know what tool might support that I know obvious but I know when you're doing a lot of things sometimes these simple frameworks can kind of help. Okay, here's one example, I thought of that we had done that actually was the company where they did the guy changed the product. Anyway, they knew they needed to be more data driven. And they had a lot of issues and they super technical company the product they had was technically enables they had like IOS T streaming data from the customer interactions and really they also had their own supply chain. And they did their own manufacturing so super complex a lot of it was data driven but it was not optimized and they had a lot of problems one of them was, you know, they was pretty high end problem product. And their customer loyalty was through the roof people bought, you know, one or two in their lifetime and told all their friends about it and all of that but the problem was, they couldn't track the email from when someone went into the store and pride it and people said, go away. I hate you dot com right. And then when they actually want to deliver they probably put in the right email right and they couldn't, they couldn't match those up. And to this company's credit they cared about their customers so much they would call them or they would find them and they would, they would try to fix this problem and some of the customers like seriously you don't even know my email for I spent this much money with you So we went through in the approach we did, they didn't have governance, they didn't really have a formal architecture. And they were super driven like fast paced and we need to sell more stuff and sell it fast and grow our revenue. So within that environment it was going to be really hard to say we're going to build a massive data governance framework and take six months and create roles and sometimes that is the best way to do things. But here we have to be more tactical. So our data governance was to get some data stewards without that name and data owners to kind of map out that process. And all of those diagrams we had in the previous slides we did a, all of the above in about a month and a half right. We did a simple data flow diagram. We did a process model we did a data data model, all of that and it helped really explain the process of why when my email one place, it didn't update the other sales people liked it the marketing team loved it they said we've we've known that this was a problem, but no one has ever explained this before I think my favorite quote was from the marketing head. She said I never thought I'd use the words data flow diagram in my life, but you're the first people to explain to me why my campaigns weren't working. And they actually printed out I know it seems old fashioned but they printed out the architecture on the wall and they said anyone changes that you need to go through governance first, and then we'll print out a new one but that was almost a way to say don't just change stuff. And sales was bought in and we started with that small effort and then built it out and did more from there but we started with a small tactical thing that was really great with collaboration and it was a combination of governance getting the right people in the room and architecture, getting that small set of artifacts that explain the problem and how to solve it through data so one little success story there. And hopefully you'll have your own. So in summary, data governance is both technical and business driven dark architecture and governance work really well together and should because there is a village of roles across the business and that getting that business process and business and technical workflow line is really important and tools are just a piece of that puzzle but don't start with a tool. Next month if this is an interest to you about data management and maybe getting executive buying this we will go into more about that, that vision part that we talked about just briefly today. If any of this is of interest and blatant plug we do this for living and consulting and can help you, and I will open it up to q amp a because folks usually not shy and I will pass it over to Shannon. Donna, thank you so much for another fantastic presentation. If you have questions for Donna it's helpful if you put them in the Q amp a panel for me so I can filter them out. There were some great questions I saw coming in the chat to which I'll try and get to but the Q amp the panel be great. I just reminder to answer the most commonly asked question I will be sending a follow up email by end of day Tuesday for this webinar because normally we send it out end of day Monday but Monday is a US holiday so occasionally we take a day off. It's, it's true. So, so diving in here, Donna, so how do you define models with multiple definitions for the same term customer can mean different things to different departments. So how do you mesh those models together. Absolutely great question, and I will extend this answer also this question often comes up with things like measures and KPIs, you know, total sales to one group that means something else to another. I think that's absolutely why data models are helpful. I would say the start, you know, put them both up there, right because that's going to help. Okay, we have customer that means something to one and to the other so a class, it could be it could be several things right and that's exactly what a data model helps the goal isn't always to just get one single view and that often scares people we're going to force you to use our term it's a clarified view right so it could be, you might have a what do we even mean by a customer often I think by putting attributes on that can help. If you put things like I don't know. If you name last name, then you, you're clearly a C to be to see right you're talking about a human being customer or someone be like, Oh, I was talking about the tax identifier I'm talking about the company that person works for right, that might be a great example. Okay, we're talking about the, the company or customer client, we're also talking about the contact right so that just might be a clarification in term or it could be HR comes and says oh our customers and employee. Well that employee could say internal customer, or could be I mean wholesale comes customer, and you mean retail customer right. So I would say to start to brainstorm put them all out there and then ask those clarifying questions. And normally it can be solved with a clarifier or a different term, because you shouldn't, you should not have to conflicting term for the same thing. Yet, you're not going to start is make a custom classic one. And actually a large multinational company made this mistake and I work for them so I won't use their name. They sent out marketing emails, you know, to actually renewal emails to people who didn't have the product right because someone said send it out to send out to all our customers. Well sales use the term come go visit a customer. They included the CRM system which was prospects right so you're not going to stop sales by saying I'm going to go visit a customer, but you could clarify your systems these are prospects. They're not a customer right so that was a great example of don't go being like the police of not letting a sales person use the word customer, but in your back end or in the glossary be super clear this is a prospect, and this is a customer or this is the lead or whatever I answered that one to death, but hopefully that was helpful because that one does come out with sorry just to finish my additional question I asked myself with a measure same thing. Total sales it says Europe in America have different definitions of total sales would be great to have them be one but if it's really absolutely different just call it European total sales in US total sales right at least you're clear right. Sorry, I'll shut up and let you ask the next question. No, it's great. Thank you. And this question came into the chat earlier, and I wanted to call it out because we get this question a lot. And so I'd love your take on it so how do I find the data owners doers in a systematic way in a large organization, and how do you get them to use the data catalog. Oh, great question. I do get that one a lot. And I'm not the only one that says this, but I'll use it because it's a great. Usually data owners and data stewards are found, not made like you probably already have them in the org. When we come in as consultants were kind of like who's do we do a lot of interviews, and we always find these champion your data steward might be saying things like, God, I'm sick of spending the weekend fixing this spreadsheet of data that needs to be cleaned every week. That's the data steward and they're probably thrilled to be part of your, your org, or that stewards like I don't agree with that definition in that report that might be getting them to use the catalog right data owners might be like I'm not getting the information I need or I, or something like that and then to use the catalog. I would say something I don't I don't know who asked this or what they're doing so it's not a judgment but I often see once they go wrong, and it's so tempting because the tools are really good. I'm going to scan everything and get all the lineage in for everything. And then from a business user it's, I can't even know where to look or but often a better way to start is something like let's pick sales and all of their terms for a particular report or something like I said, to use it. I mean my my best example of this I worked for a Wall Street trading company one of my first project way back when they were called metadata repositories, and I wanted to do what I just said not to do a super technical problem I want to get into all the cool stuff right. My boss said don't just put all the trading terms out there like what's it default credit swap. Like, so I remember storming home on wall feel like kicking your hand down so I can't believe I have to do something so stupid like that that could be done in a spreadsheet, which it but he was wise, because then all the traders who had all these different products in different terms like every week changing they went to this place to get the information and then they supported this thing and we got the buy in and they did all really super technical stuff and they're still using it. But we started with stuff people cared about or filter I think that's where I often see it go wrong like business people are dying for a catalog and it's just that you need to make it easy I find the business people super bought in you just because it's the questions they're trying to ask. I'll stop I could go all day on that stuff but I won't hopefully that was kind of helpful. Very helpful thank you. Yeah, and so don't how important is reference data management in data governance project. Super important. How's that. So, yes, so I talked about master data I think reference data you folks aren't familiar with it is stuff you use every day your code lists it's your hierarchies it's things like that. There's no way to get people bought in and then someone back to the first question can you can you get a simple. Do we all have to have the same definition so something like region is a big one. Oh my gosh how many times we've done region. So region means a thing like in geography. Sometimes there's sales regions that change, sometimes finance has different regions right, and that might be a great example just to clarify this is the sales reporting hierarchy. And this is the finance reporting hierarchy and just be really clear about that in your reference data. And then that's just you're not trying to fight those are just physically different things I might have a similar name, or for data quality. I still like, I think I even tweeted about this when I signed up for a data quality webinar, and they had a manually type in the state code. Ah, man, I'm going to be funny to anyone else but people on this webinar right but what can't you have a drop down list of all the US state codes with the two character field. That's going to improve your data quality and that's reference data, what is your list, or is it is it not just us states we all help Canada and the different provinces right, all of that is great. Maybe we not we had a one company in Detroit, and they didn't know they had to do we have people in Canada because it's right across the border or do we only use us that was a great data governance win for them, because it was a big discussion. Well, we only have us employees but some actually have an address in Canada and we actually had to go through it whole discovery through data governance to find that. And that's a great example of data reference data, having really big business impact and could be a win and sometimes it's a nice when I'll set up on this one question, because it's nicely contained. That's something the business can get their brain around we're just talking about who we're sending our mailings to is a Canada or just the US, and then you can do the reference data and it's kind of helps build some of those quick wins or do we do we agree with finance or sales for the hierarchy or do we have both right so nice really tactical thing people can relate to. All right, rant over. What's the next one. I love it. We do we have four minutes left and I love that these questions are getting you going. It's great. So, Donna, what's the relationship between data architect and data privacy or data security officer does their policy always trump the data architect or are they animated discussions. You can tell by my animation, we tend to get animated around data. Yes, that's a good call that flight I had if you have memorized all my slides. The one that I had if we have all the data governance roles and then the data architect and the data governance person I often have the security team or even legal on there as well. I just because this topic of the webinar with architecture I took that off, but absolutely they said I have a thing in the game steak in the game. I mean, I don't, I'm not going to be the one to answer sounds like a class in the organization. I mean, I guess back to the ownership maybe I'll use legal which wasn't your question, just so I don't cause any angst in your company, but like legal would be maybe the one to say can we track or it was kind of likes to privacy. Are we allowed to track people's social security number. Right, or their credit score or their social insurance number or wherever you live right. I think the the owners or the ownership might be in the privacy officer or legal to look at that but it should be a discussion we had a good actually was at a insurance company can we use those credit scores to rank. And it was, it was all of the voices that's where governance comes in someone probably has the accountability at the end of the day and I would say it was privacy. But I think it has to be a discussion because you don't always understand retention roles as another one, and then there often is a conflict will legal makes us keep it for 1010 years but we're supposed to get rid of it in HR after seven years and, and how do we handle that is it stored somewhere else right so I would answer it somebody has the accountability and I would think it's who has the business accountability, the architect probably should follow what the business says. I would also say it doesn't mean that that person just makes a final decision that's where governance comes in because that those types of things always have tons of nuance of can we or can we not and then or maybe it's a subset of people who can, and that's a really great use case for governance. Hopefully that helped. What's the next one do we have time for one more. One more and we have just under two minutes here so any idea what the success rate is for an in house initiative on aligning a startup between an organization's data architecture with data governance cross functionally and a portfolio of various product lines. Oh, that's a bad two minute one because I have to think through what the person. I know. Well, I don't in house. I mean, I would say it's hard to say a success rate I think that's going to be a hard one but I think trying to get all the right people in place aligning I would start with all of those kind of a quick win. I would make sure that we're all a lot I would say the biggest thing to success. If it sounds like there's a bunch of different products with different voices and and who owns what is really trying to align on on that vision thing that I said we're going to talk to it to all of those groups have a similar problem that we want to solve and then maybe going in and with that, you know, and how much overlap is there across those product lines and where you can separate them what what is truly owned by a certain group and then what needs to be shared and not overdoing each one might help as well just kind of brainstorming there but the person might have met. All right. You did it. Thank you. Thank you all so much for being so engaged in everything we do and love the chat that's been going on as always. And just a reminder again, I will send a follow up that email by entity Tuesday because Monday's a US holiday with for this webinar with links to the slides links to the recording as well so Donna thank you so much. All right, thank you. Enjoy your day. Thanks everyone. Thank you.