So welcome, everyone. Today, we're gonna be talking mastering data governance. This is with InterWorks. So we'll be going through, you know, how to how to properly define data governance, sort of what are the domains and the tenants of of data governance when it comes to, sort of the modern data stack and some of the, analytics applications and data frameworks that we're creating here. And we'll sort of step through how to help better contextualize that, put some guardrails around what we wanna focus on, and then jump through, an actual plan and a framework for success, to deploy a good and sound data governance strategy. So with that being said, let's jump into it. So we'll start with introductions here. As I said, help with that that, operational definition, then go through, a nice analogy to help contextualize, data governance in those tenants, step through that framework for for success. And whatever time we have left at the end, Justin and I would be happy to answer any questions that you good folks might have today. So, let's get started with some intros. Justin, would you like to start? I would like to start. Thank you. My name is Justin Lemon. How dare you? My name is Justin Lemon. I am the data practice lead for for the, US data practice here at Innerworks. I work at about out of our Portland office. I'm also one of our services leads here, so I run a team of folks from across, you know, several different practices. I've been at Innerworks almost fifteen years now. Long long enough I have to think about it. I hear I hear they give you a car at fifteen years, so I'm waiting to see if the rumors are true. Yeah. Excited to talk about data governance and, and a framework for success today. Go ahead, Brooks. Thanks, Justin. Yeah. So I have a very similar role here at InterWorks on the analytics side. So consider that everything from sort of analytics engineering all the way through a traditional BI and reporting up into UI and UX and and designing, data applications or analytical applications. I'm also a team lead here. I manage, some of our architects here. So our more tenured or technically, advanced, practitioners in the field delivering solutions to our clients. I've been here for about seven years, so I'm halfway to that car that Justin, alluded to there. Before that, I had a pretty deep, background in health care. So, I've passed around a few health care organizations for about eight years, out of college. I'm originally from New England. I saw a few accounts come across the board there, from that area. Went to school down in South Carolina. Moved to Texas for a bit, and now I am, stationed up in Portland, Oregon as well, about a mile and a half down the hill from where Justin lives. Yeah. So really excited to dig into data governance this morning. So quickly, a bit about us and really more about Innerworks. So we are a full data and analytics tech, stack consulting firm. We've been in business since nineteen ninety six. We are based out of Stillwater, Oklahoma with permanent locations in Oklahoma City and Tulsa as well as our headquarters in Stillwater. Justin and I will be joining here from Portland. We do have space here, but we also practice, the services across the world, so not just US. We also have other offices in the UK, Berlin, Australia, sort of across the board there. So, yeah, have a have a good and, nice, global footprint. So we'd like to really focus our services around strategy, solutions, and support, so helping customers to build a successful pathway, develop strong and elegant applications to help enable their customers, and then support them along the journey. So those are really the core tenants that we like to deliver services around. Few fancy logos here. All this is to say that we have a really broad reach when it comes to working at some of those the top Fortune fifty firms, as well, you know, all the way down to SMB and commercial size groups as well. And we also have a broad sort of industry agnostic, portfolio. So you'll see groups across retail, tech, health care, and education. But, you know, we work with many, many organizations across many industries. We also partner with top solutions within the analytics and data space. If I jump through here, we've got a few of our, and awards that we've won, across those services partners, but I would call out that we are Tableau's original service partner. We've been partner partnering with them. Justin, keep me honest, but it has to be going on fifteen years at this point. So very deeply intertwined in, customer success in building solutions when it comes to Tableau. We're also one of Snowflake's original partners, and work with a myriad of other technologies like Matillion, DBT, Fivetran, many of those solutions that you probably all have invested and are using to build products, within your space and your organization. So with that said, I wanted to jump into a poll here. So you should, see something pop here pop up here in a second. But we wanna start off, and I I did allude to starting off with with actually defining data governance. So wanted to get a quick, stress test. So if any of you folks had your manager walk up to you and ask you to define data governance, how confident would you be in being able to provide an answer? So give a few few folks, or give you folks a few minutes to answer that. Nice. We got good engagement here too. I appreciate everyone chiming in. Looks like we've got a quorum here. So I'm gonna end the poll and share results. Let's see. Justin, can you add us to am I am I displaying the results set here? I can see it, but I could see it a little bit of time. So I think I'll make someone from chat to confirm. Okay. Fair. I will take I will, take your word as truth here. So it looks like we've got seventy one percent, so really brought consensus around somewhat. Right? So, you know, we understand some of the core tenants. We understand what governance means. Probably means we need to build some policies, procedures, enforce those, probably disseminate those across the organization. But, you know, the actual what's, whens, and whys of it all, may still be pretty fussy there. So it's good to see, and that sort of aligns with a lot of the research that we've done in the field and, much of the feedback that we receive from our customers. So, yeah, that's great. I really appreciate the engagement there. Okay. With that said, let's sort of step through what that how we sort of think about defining data data governance. So, to us, really, data governance in within the context of the modern data stack. So, you know, cloud first type, data architecture where we're using BI reporting tools to enable a decision support within organizations. We sort of think about how we sort of like to put some garbles of definition around, how organ organizations manage, protect, and then go in and contextualize how their data assets across the entire data life cycle and technology ecosystem sort of interact, and provide solutions for their users. I think most of us really understand what it means to manage and protect. I mean, there's a lot of things that can go into that, but it's really important to also understand the context with how their data assets are used, how they're accessed, and then how people might think about the numbers and the attributes that are on the page when it comes to supporting their decisions, across the organization. Within that, we we sort of think that these these six core tenets and I know there may be some other on the periphery here, but I think these are these are important core tenets to call out when you think about what does it mean to own data. And even within that ownership, how do you steward that data across the organization? You know, considering data security with many, compliance measures that we have in place now across, different industries or across different, governments and and countries, things that we have to consider there, laws that are in place, data privacy as data becomes more personal and also used for different use cases, making sure we, are cognizant of of of securing and making that data private. And then data quality and data life cycle. How do we continuously improve that data? How do we continuously vet it to ensure that data is of a high quality, that it's consistent, that, it is precise, and it is accurate in the measures that it is reflecting? So, as a former or I guess still am a a graduated psychology major, but a reformed, bachelor of of psychology, I guess, I I would more put it. I'd like to sort of use some analogies from previous trainings to try and help, contextualize and help sort of ground the conversation around, themes in tech. So went for, an analogy here to help, drive the story around data governance. So not sure if users here are familiar. This is, Abraham, Abraham Meslow in the top left corner here. But, he developed he was a famous, humanist psychology psychologist in the forties, and he developed this hierarchy of needs, which is this theory that all humans, have different levels of needs that we could bin together that go from a base level all the way up to more complex. And those sort of lead to a higher, higher stasis of the human experience. Those go from all all the way from or they span all the way from things like the physiological needs that we have, food, water, the things that we need to sustain life, all the way through safety, connection, you know, the things that make us who we are up into self esteem and full potential. So what it really means to sort of thrive and, thrive within the human experience. So I know with trying to contextualize and better understand, data governance, put guardrails around things, bin, tenants, domains, all of all of the all of what might be all the things of data governance. I went through and sort of did a similar, activity for, like I said, all of those domains within data governance. So I think sort of this net analogy helps us to understand, what we really need to work on and achieve and be successful at when it comes to governing our data systems. And then from there, as we're building good base baselines, we can move up along the data governance journey, to fulfill some of these other domains to to build solutions, to build policies, to build communities, those types of things across the board. So I have the little blurb blurb in the in the corner there. But much like within Maslow's theory, data governance needs really need to be, accounted for at that most base level base level first, before we can move to each section here. So that sort of helps us to narrow our focus and also to continuously, approve and main improve and maintain, those lower levels as we aspire to, affecting change and building solutions at those higher levels. So, with that said, I'm going to step through each one of those sections here and sort of add a bit more context around, what are those things that we can focus within each section here. So I'll go back one slide real quick. Starting with base level, we would bin things like data acquisition, data accessibility, and data availability, within those core, like, core base level tenants, of data governance. So we need to be able to get data into our systems. We need to make sure that people can actually go and go and utilize that data. You know, we'll we'll think of sort of, like, RBAC and talk about those things, later in another section. But just from a from a basic perspective, people need to be able to get that data, and those systems need to be available. So we need to have, uptime when it's critical. We need to make sure that the systems that people are using to access that data, are up and that those folks are getting access to those things and and able to query or ask questions of our data. And I know we alluded to this a bit upfront, but also wanted to have some green flags and red flags, some really do's and don'ts when it comes to each one of these sections as well. So, really, things to focus on when it comes to base level needs. One, documentation. Obviously, documentation is tantamount to do across the board when it comes to governance, but we really want good hygiene when it comes to data to, data documentation, asset documentation, those types of things to be a focus of those base level, requirements. We wanna make sure, requirements are clear. So clearly defined, we have things like clearly defined data types, sort of within our atomic data sources that are coming in through different systems, and then making sure that wherever possible, everything is standard. So we don't want any sort of policies and procedures or pathways that are not within the frameworks that we set at this base level. And then something to avoid, really, and that's probably neatly aligns with standardization here, is fragmentation. Right? We want to make sure that as much as possible, we're being consistent, when it comes to building that base level competency within our data governance function. So then as we step up the ladder further, we get into things like safety. So compliance. Right? We had talked a bit about, industry, specific compliance measures like HIPAA within health care. We also have, you know, sort of geographic and government based, compliance laws, across the globe that we need to adhere to. We need to make sure those are being built in, because they are serving a function for, the people that we are collecting data from and the people that we are serving data to. As well, things like permissions and data data security. So controlling who has access to that data at what levels of of of of specificity, or aggregation, and then making sure that our data and our systems are secure so that so, really, we're adhering to those, controls and practices that make sure that, we are not exposing ourselves to theft or or data corruption or or unauthorized access. So some do's and don'ts there. I had allude to alluded to role based access control, but, you know, really focusing on access from sort of, like, the, personal competency and and role standpoint, making sure that the right folks within the right teams are getting access to data that is, approved within the roles that they hold at the organization. And then wherever possible, really leaning on automation. So, using things like SCIM and all that to make sure that, all of those measures are are automated so they're not beholden to manual processes, which can really open up for risks and failures there. And it's also great to, continuously audit those policies and procedures, making sure that security standards are adhered to. Oftentimes with different industries, we're also beholden to annual or around some cadence, monthly audits within, some compliance organizations. So we wanna make sure that we're always up to date on being in compliance and ready for those audits. Things to avoid, informality. Right? We don't want to have sort of fuzzy, governance policies when it comes to things like security and permissions. That is a that is definitely a no go. And then broad classification. So, sort of if we're if we're sort of fuzzy on, how we're defining, different levels of data sensitivity, across the board, that can lead to scope creep and really permissions creep within within our systems. Moving up the ladder further, we've got connection here. So, really, that's sort of establishing the community and the belonging within within our data groups here. So helping folks to better understand where data is, what is the inventory, what they may have access to, and what are the definitions of those data elements, whether they're at the atomic level or up through into a further aggregate level through data catalogs. We're also seeing more folks talk about data semantics. I mean, this is a this is a topic that's been around for a while, but, there is increased focus here, with some of the AI applications that are coming out. So, be more mindful and more clear around business definitions of KPIs, understanding business terminology, whether that's within an industry, a horizontal, or even unique to that organization, making sure those are widely understood and those are stored in appropriate systems. And then from there, building out things like COEs, where we have cross functional, groups and organizations or communities where they're doing a lot of the steering, when it comes to, governance policies and procedures, where data resides, what is best when it comes to cataloging data and defining those things, all good behaviors there. So what are the things to focus on? I would say centralizing your glossaries. So really centralizing, like, your semantics and your catalogs that we're talking about there, making sure that we don't have that, that fraction sense of what what these business, terms mean or, some of what the data elements might be within your organization. And then really focusing on data lineage, you know, having DAGs across, not just your orchestration layer, but also in your transformation layer, all the way up through KPIs and into reporting. So really understanding and communicating how, processes and objects within your stack are interrelated to each other. And then any things not to focus on, really be aware of data silos there. So building consensus, bringing folks in, helping them understand what their contribution is to to data governance there, and, again, making sure that your objects are interconnected as much as possible. Moving on to self-service. So this is now we're really getting into empowering those teams and end users to to really operate at a high level. For tenants there, I think of things like data mesh. So starting to actually think about the the sort of team organization, the sociotechnical that you might have within the broad spectrum or the broad lens of analytical functions, across your organization. So whether or not those are centralized, distributed, how you might optimize those things across the board, as well as making sure we've got strong and robust data prod products adhering to, soft software development, best practices, making sure they're of a high quality, that they're versioned, and that they are specific and serving a purpose across the different business needs that we have there. And I did allude to metadata a little bit upfront. Yeah. Becoming more aware of of of sort of how the data is being affected, how it's being used, consumed, access, all those things across the board so we can be more aware sort of at the central governance hub of of how effective our products are and how they're being used. Things to really push, within self-service, group ownership and accountability together, making sure that the business has a stake, when it comes with the business has a stake in the data applications that we're providing to them. And in turn, making sure that the governance, groups, or governance policies that's holding are holding those folks accountable to continue to ensure quality, when it comes to our data and our data applications. And then things to avoid, certainly bottlenecks. We don't want to introduce any more bureaucracy at the self-service level that makes, change become too difficult or too cumbersome, too slow to change. Those would all be things we would want to avoid. And then as much as possible, I know talk a little bit about data mesh here, but, we wanna make sure we still have domain level expertise, down to individual groups, organizations within our company, to make sure that, you know, there is some technical competency there and that that is providing back to the centrality of data governance. And last section here, this is sort of the reaching the full potential, sort of what might be sort of that very, very high level of operating here. I think when we think about sort of bleeding edge things like this, it's also important to acknowledge that many of these things may be aspirational or things that we continuously reach for, but never really achieve or move to a done status. So at the moment, I would say, you know, I we're always sort of focused on automation. So how can we inject automation into data governance to make sure that is, as low touch as as adverse for for failure points and things like that, and has the lowest level of manual, intervention and, upkeep required. So automation, good thing to focus on. Some of these concepts around data contracts to really encourage, both, participation and accountability down to the individual business units that that sort of express very well and very effectively through data contracts. And then, obviously, you know, talking more about AI and AI driven applications, for data governance or, or implications for AI driven solutions within data governance. Always something to, keep some research and be mindful of. But, you know, good things to focus on here. Still making sure we're we have a a good amount of formality here. I know we had talked about these these things being aspirational, but we wanna still be, intentional when we're when we're striving for these things. And then I would also call out, making sure we're preventing, any sort of lack of vision when it comes to evaluating, what might be our aspirational goals within data governance and making sure that we always maintain and have a consistent North Star when it comes to how we're enabling our customers and, investing in data governance so that it can be a benefit or of a benefit to our organization. So as we went through that whole broad landscape, I wanted to present a, another poll here. So, as I sort of talk through those things, I'm curious, where the folks here in the crowd are more are really most interested in focusing your data governance efforts. So, you should see a poll pop up there. And if you wouldn't mind responding, that'd be great. It looks like we got good engagement here. It looks like we hit about eighty respondents, which feels like a decent quorum, and I'm gonna share results here. So, interestingly, looks like we have a pretty even spread. So that is fascinating. That is not what I expected. So I really appreciate the feedback here. Appreciate the feedback, and, yeah, I'm gonna, I'm gonna take that away and, and, see if we could provide more resources across the board for y'all. But I really appreciate the participation there. Okay. With that said, Justin's gonna jump in here and pivot over to talking through, providing a framework, to build successful, governance policies and procedures. Yeah. I'll be walking through a framework for success here. You know, sort of going back to the base level needs, I feel like, a base level need for a lot of us is a bulleted and or numbered step set of things that we can just sort of step through as as, humans. So, that's what we're gonna go with here. I I will preface this by saying I have a a long and storied history of, breaking demos at Innerworks. So we're gonna have Brooks continue to control the slides here. Hopefully, there's there's sort of a natural point there so I don't have to Oh. Alright. That was a ask an answer. Joke I had to do. Hopefully, for the rest of these, there's a there's a good natural break there, so I don't have to just keep saying, like, next slide or or maybe I'll just be like, bong, and then and then then you can go. That's that's your cue if I give you a loud, bell ring there. So, in general, this framework, you know, it it looks like this. If you know, I would never do this personally, but if you were going to type something like, what is the framework for success in data governance into chat g p t, for example, it might give you something like this. Again, I would never do this, but, a lot of websites out there will say something along these lines. You know, define your goals, define your roles, define your policies, evaluate tools and implement those, monitor metrics for success, and then sort of, like, iterate on that on that loop for ongoing improvements and adaptations. So, in an effort to sort of, relate those to a, like, pseudo realistic, business use case, I have I have created this, fake company for us. Some of you, like, may be may be wondering, you know, is this just a reason for me to put an adorable photo of my dog into a slide, or, you know, a reason to show off my iPad doodling skills or to gather investors for my newest app idea. And you, you know, all three of those can be right, and I can use it for a specific purpose in this slide set or in this presentation. So this will serve as our fake company here. I will try and relate some of the boilerplate template type things into real world scenarios. So in this company, we have our chief marketing officer. You know, the real one you gotta worry about always asking for reports and updates and kibbles and and all that stuff. And, you know, if there's something he wants, he's gonna whine about it. Still a good boy, though. So, we keep him around. Next, we've got our HR director here, chief information officer, and director of analytics. We're gonna sort of bounce between, you know, the templatized version of of these steps, like I mentioned, and then sort of, like, relate those to to each of these, key stakeholders along the way. Starting off with the buying goals. Yeah, this is where we meet with all those key stakeholders that I just mentioned. We sort of want to foster, multi domain collaboration. You know, I was just talking internally. I didn't know it works the other day. How we've got, you know, a bunch of different practices, you know, IT platforms, data analytics, enablement, marketing, accounting, etcetera. You know, all of those have a role to play in data governance overall. So so everyone's got a part to play. You know, at your organization, each department will probably have a key stakeholder and or a data owner, that we can identify on this this path. And we use this this as our opportunity to gather requirements. Yeah, we're all we're we're all used to gathering requirements, in basically everything we do. So we're gonna do the same thing here and and, you know, ensure we have a good list of goals that we can build policies to to meet and achieve. This last point here, the goals should be outcome based and ideally follow the smart methodology. For those of you, maybe unfamiliar with with SMART, it is, you know, one of our favorite, acronym buzzwords in the business community. Stands for some approximation of specific, measurable, achievable, relevant time bound. Your mileage may vary on some of the lettering there, but for the most part, that's what it means. Sort of taking, nebulous goals and putting more measurable things around them turning into sort of, like, KPI type things, for example. Okay. So, you know, anytime you see this this logo on your screen, you know, don't turn off your console. This is this is sort of our tie back to the Lucky Lemon, company example we had earlier. So when that pops up, that's gonna be sort of, like, the queue that, you know, I am now shifting over into sort of what does this look like in the real world. Right? So or to the real world in this case. So, our examples here, chief marketing officer wants to increase outreach and efficacy of marketing campaigns. HR director wants to increase PII privacy. CIO wants to increase data security, and our director of analytics wants analysts to know when reports are gonna be delayed. So these are sort of the good start for goals, but we want to further define those to make them more measurable and and trackable and and achievable. So going on to the next slide, I will sort of increase the the specificity on these. So for CBO, we sort of changed that to twenty percent higher open rate and fifty percent increased conversion rate within the year. HR, we've got higher percent of PII fields private within the year. RBAC and encryption in place for every data object and day of notifications for data delays. You know, maybe there's another SLA there involved, that sort of defines, like, what the acceptable, gap is between a delay and a notification, things like that. Those are all good things to define here. And then these will sort of serve as our direction for policies, once we get a few more steps down the line here. So our next step here is to sort of define the roles across our organization. This this sort of helps clarify responsibilities and ensures accountability. You know, I think I think one of Brooks' points earlier was, like, there shouldn't be any, you know, confusion or or lack of parity around these things. So we really wanna make sure that across the company, people know who is responsible for each of these pieces and who to go to when when issues arise. Right? This doesn't it typically should not land on one person or department. It's it's supposed to be, you know as I said, involve everyone, involve all the practices, involve all of your departments. But within those departments, we will specify roles for various people. So shifting over into our real world examples, in a lot of cases, if you're looking up the roles for data governance, you're gonna see, I think a few of the ones we've talked about earlier were data owners and data stewards, and then governance committee is also gonna pop up. So data owners, typically, a definition is gonna be responsible for decisions around their data domain. What does that really mean? So for a chief marketing officer, and sorry. I'm just gonna keep rolling with this. Like, I'm I'm, like, in too deep on the marketing thing now, so you guys are just gonna have to sort of deal with it. I I've I've reached the the point of no return. So you're gonna work with, the governance committee to define those policies for campaign strategies, marketing outreach, and segmentation, for example, in the example of marketing. Right? So they will also work with the data stewards to ensure proper use of the, the above things I mentioned to make sure that they're meeting those goals. You know, data owners, you know, typically, these are the people we go to. You know, in this case, like, they will set the the North Star, the direction for our campaign strategy or marketing outreach strategy, for example. The governance committee, these are typically also going to be, you know, senior folks in the organization. You know, definition you'll generally see is that they create and maintain the data governance framework. That one's fairly self explanatory, but, you know, if we're breaking this down into examples of of specific tasks, You know, take our senior VP of marketing, for example, you know, you know, a little bit lower in the in the org chart there, but, they ensure that data governance policies are properly implemented across their department. You know, if anybody has has questions about access, you know, like, should should, this other group have access to this specific piece of our marketing data, for example, you know, these are these this is the group in the governance committee that is gonna resolve those conflicts. And then they should be regularly reviewing performance of the data governance program. We'll sort of talk about that later when we get to tracking metrics and iterating the process as well. Right. Lastly, but not leastly, data stewards. They are responsible for the day to day data management. These are typically people who are working with the data on a day to day basis. Right? Like, they they're your analysts. They're in here doing reporting. They may be data engineers. So in this case, our marketing analyst, they ensure the campaign data is accurate and consistent. If they notice that something's not lining up, like, these are these are the folks who we we would generally identify to sort of, like, run that back and and, make sure that somebody is notified that the data is not accurate and sort of, begin the the remediation process there. They also maintain data dictionaries, appropriate relationship definitions. You know, if someone's trying to figure out how to tie marketing data, some of the other data, tie all that together, you know, these people would would generally be responsible for that and and sort of, like, you know, defining the objects and and sort of making sure that those match across the different domains so we don't have, you know, different definitions of what a customer is, for example. They're also gonna be educating data consumers on proper data usage. You know, these are they're gonna be teaching people, like, this is how you access the these specific reports, for example. And and, again, like, going back to object definitions, like, this is how you use, a customer object, and this is how it relates to, you know, the campaign object, for example. Yeah. And then here, I put together sort of what an example org chart across these departments could look like for your organization. It won't always look like this. In fact, some of you may not even have marketing departments. But in general, you know, it tends to look like this as far as, like, you know, company hire hierarchies go. There's also a lot of overlap. You know, a lot of times, data owners will be in the governance committee. Data stewards might be as well. You know, this might be the same person across all three of these things. Right? You know, as as I'll mention later, this this is not like a one size fits all thing. These are just sort of examples of of how this might look in in a, semi realistic organization. So now we've got the goals and the roles defined. We move on to policies. You know, we wanna make sure that these these sort of match up to our goals. These are gonna be, you know, data quality policies, validation policies, etcetera, relating to all the data objects. Again, going back to the clarity, they should be well documented. Honestly, that's one of the most important things here. You know, roles, policies, metrics, you know, all of these things. In general, people, if they, you know, see some documentation about it, they should understand ideally, you know, everything they need to know there, whether that's, how the how the policy is enforced, or, you know, again, like, who to go to if a data issue arises, for example. Moving on here. Going back to our our real world example, bringing back the the goal of the chief marketing officer here. You know, they want the higher open rate. They want the increased conversion rate. So in this case, you know, we may set up policies, requiring data validation on ingestion to make sure that, you know, we're matching fields in our customer data platform, for example. We might set up data cleansing policies to make sure removing duplicates and fixing data types, things like that, and then data quality policies to make sure that our customer details are complete. And, you know, that could be something in our in our data platform. It could be something in, you know, further down the line in our, you know, ETL pipelines, for example. But use some example policies that could support that overall goal. Again, for HR, you know, they want a hundred percent of PII fields private. So, you know, some example policies here could be we catalog all of our data fields and make sure we're tagging PII, you know, classifying data as, you know, this is private. You know, this is confidential. This is public. All of those fun things. We might also set example or data data privacy policies, to ensure that any of those PII fields that are marked, are actually masked and and kept private. And and not to be forgotten here, we we wanna ensure that everyone is trained and aware of of the policies in place and, make sure that everyone knows about the PII fields and and, that they're keeping those private and masked. Okay. For our CIO, you know, their goal again is more security. So so maybe we're talking about RBAC and encryption so we could have security policies in place to make sure that quarterly, user access audits are in place, and another security policy to make sure that all data is encrypted at rest in transit. And is it just, you know, flowing around out there in plain text for anyone to grab and see? Finally, we get to our our analytics director here, who wanted those those notifications on data delays. So, example policies could be quality policy to make sure we've got standardized report delivery times. You know, if if we're supposed to get those reports at eight AM every morning, you know, that really helps us keep track of when those are not there at eight AM so we can track those delays and potentially set up more data quality policies to, to enforce automated alerts, and root cause analysis to figure out why those things are happening. Tools. Everyone loves tools. So we can use tools to to, enforce a bunch of different aspects of these policies. Tools are not always necessary. You know, a lot of times, you can sort of build this in with with some of the things that already exist. You know, there there's a build versus buy argument. You know, I'm I'm going to present some, some examples of tools that you could buy here, but that's this is not, like, a recommendation or anything. And and, you know, building these things out is perfectly fine. It's also also fine to do it, you know, other ways if if you've got different ways of enforcing your your security policies, for example. Really, the biggest point here is that last one that you want to really foster a culture of data governance across the organization. Make sure everybody's committed to it. Make sure everybody knows how it works and what they need to be doing to to follow these things to, to enforce the policies. Alright. Lucky limit time. We go back to our our examples here. So for the CBO, for data quality and accuracy, one example, they they could use DBT or Matillion to ensure those policies of data quality and make sure that they're properly cleansing and transforming the data. You know, go into the privacy policies, you know, maybe the the HR director selects elation for discovery tagging and compliance to make sure that all PII is is tagged and masked and, you know, following all of those things. For RBAC, you know, we might be deploying that automatically with Terraform. And then for analytics, you know, the group that was was concerned about report delays, you know, maybe they wanna add in some some data observability, and so they use Monte Carlo for downtime alerting, for example, there. Okay. Tracking metrics. This sort of ties back into defining our goals, but it also ties into the next step of iterating the process here. So, you know, we wanna implement our practices. We wanna keep track of how effective they are. Again, I I mentioned here, we wanna include the goals we set at the beginning of the process. So on the next slide, we'll kinda go back to those and see how we can track to make sure that we are properly enforcing our policies and that our data governance program is is actually working. So for data quality and accuracy, you know, obviously, we've got those top level metrics that we discussed about, you know, an x percent of extra customer outreach, for example. Additional metrics we could use here to track our success would be like, setting up data profiling to identify, like, a percentage of duplicates that we're seeing or, you know, the amount of data that's coming in incomplete from our from our, intake platforms. Similarly for for privacy, we could use audits to check percentage of unmasked PII fields. Hopefully, that ends up being zero, but, you know, if it's not, we've got some work to do. Going on to RBAC, you know, we could use monitoring for for any ad hoc permissions. You know, if we're deploying those role based access control policies via Terraform, what we don't really wanna see probably is is someone else going in and and adding in some manual permissions into our data platform, for example. And then for observability, you know, it's we we can pretty easily track down time percentages, incident response time, and things like that. Okay. So, potentially, the most important piece of this is the ongoing iterations and improvements. You know, it's not gonna be not gonna be perfect the first time, which is, you know, something I'll be discussing on a later slide as well. But we wanna make sure we are continuously refining this, you know, making tweaks along the way, and ensuring that that we are continuing to to foster that collaboration across teams. This one, pretty straightforward. No no need for lucky lemon here. I think we've got, you know, regular meetings to to review the current framework. We want a feedback loop. I'm bringing it back. You know, for chief marketing officer, he loves me and everyone. So we wanna keep the feedback loop going with him and the other stakeholders, state owners, state stewards, you know, everyone involved here. This is, I think, typically something we see as a pain point across across clients where, specifically when it comes to data governance policies is, you know, for example, we we've seen some where the governance policy may be, like, too rigid, and too complex. And, you know, for example, if if someone is trying to access some data that is otherwise, like, mostly public, but they have to go through, you know, several several channels and, you know, fill out a big form to you know, for every single table, that they want access to that is in a schema that they already have pretty broad access to and it is is broadly considered public public within the company knowledge and, you know, not private or anything like that, then maybe that's something where you can take this feedback from your users and analysts and and take it back, you know, to the data governance commit data governance committee and the stakeholders and say, like, hey. We need to revisit this thing, and maybe maybe loosen it up for for some of these pieces of data, for example. It also helps, you know, we find to to sort of create a road map and and sort of a data governance score of of how you currently sit, in your in your program. And then, obviously, continued training and awareness are are a huge deal here. Make sure that any changes, everyone's aware of those, updates, etcetera. You know, clarity is the biggest thing here. Okay. Moving on. We've got some common challenges here real quick. I know we've got eight minutes remaining, so I'll try and get through these real fast. So they're mostly mostly meme based, because, you know, I'm a I'm a millennial, and it's really the only way I know how to communicate. So, these should be pretty quick for me to get through and and leave a little time at the end if we need. So for our first challenge, generally, you know, the internal reluctance that we see, you know, this kinda ties into my example about, you know, people, you know, know, running into data governance policies that are too complex. But then, you know, partially, some people, you know, might just be curious why we're enforcing all of these things. Or, you know, if if you're building a new data governance framework, they they might need to know, or just might have questions like why, you know, why they're having to go through it and, and, why things are changing. So, you know, I listed here, you know, demonstrating benefits and proper training are are huge deals here. Thankfully, if you walk through the the data governance framework for success, we take care of a lot of these in the beginning. Right? So if you're having those conversations to define your goals and policies and documenting things really well, then you can pretty easily deliver that to your to your coworkers and say, like, yeah. Here's the reason we're doing these things. You know, here are the organizational goals that that we're aligning with, etcetera. Next challenge we see, clashes with current state. You know, a lot of times, if you're building in changes or perhaps you had old governance plans and you're trying to implement new ones, or even just, like, introducing new tools to the system, right, for for additional, meeting other policies, like adding in, you know, a new a new tool that takes care of, the PII, for example. You wanna make sure it works well with everything else. You wanna enable interoperability here. You know, a good example of that, I know I've I've got some some cube friends in the chat. So a good example of that might be might be using cube for, for semantic layer, for example, to make sure that that, everything is interoperable across your data ecosystem there. Other good options here are building proof proof of concept, identifying opportunities where you can sort of, like, merge those governance programs into each other. And then everyone's favorite everyone's favorite, buzzword from, I think, the last twelve to eighteen months, change management. I think that's that's a big help there too and and ensuring that everyone's on the same page as far as, like, what to do next, when we're building these things into into a system that already exists. Third challenge here, chasing perfection. You know, someone has said many times that perfection is the enemy of progress or good or done or however you wanna end that statement. So, really, what you wanna do is, you know, make sure you're meeting your requirements. Make sure you are, achieving your goals. And from there, you can sort of iterate along the way. Right? Like, you know, like my example earlier, if if you find that that your governance policies or your RBAC policies are too strict or too complex, you know, you can always set up that feedback loop, with your users and and make sure that that you're meeting their needs, along with the needs of the organization. Finally, we get to over engineering. Yes. Data governance is not one size fits all. I think we've we've mentioned that a couple times here. It's good to sort of self evaluate and and make sure you are meeting yourself where you are. It's good to also have a road map for the future so you can scale. Typically, we we like to see a phased approach, you know, like like Brooks walked through, like I walked through, but make sure you're keeping an eye on those base needs and those base goals. And I'll leave you on this on this last point here about rightsizing your path. I'll I'll leave leave you with an anecdote actually from Brooks. Brooks is a very talented runner, and, you know, we've we we did a half marathon a couple years ago, and the rest of our office, you know, we're sort of training. We we make jokes back and forth, about how fast Brooks is. He basically runs twice as fast as the rest of us. It's it's honestly insane. But, but to his credit, every time we ring it up, he will say, everyone's running path is different. And that's that's something I like to like to keep in my back pocket. And, you know, I'd like to leave you with that on this last point here. If if there's, like, a major thing you take away from this from from my point of view, it would be that everyone's data governance path is different. You just need to make sure you're right sizing your path for yourself. We hope we have provided sort of a a a reasonable framework to work within to help you along that path. Look at this. The path doesn't end here. I kept this slide in specifically for that transition. Okay. Well, we'll go on to the next one then. This is the important one you need. Brooks, you wanna hit the outro here? Yeah. Thanks, Justin. I appreciate everyone joining here. I know we have a short short couple of minutes here, and I see one, open question in the QA. And I think, Justin, I might actually pose it to you because you might have a more eloquent and measured answer than me. So, what kinds of questions would you ask, to help better and effectively define goals for data governance? Yeah. I mean, I I think, honestly, you know, we we ask these questions a lot in in gathering requirements for, for client projects, you know, our in our SVRs as well where we do sort of a a strategy vision and road mapping sessions with clients. Generally, I would just ask what the what the pain points are, honestly. If there if there isn't a good, you know, obvious example of some goals, then then asking pain points might be a a good start there and figuring out, like, where things maybe maybe aren't exactly how you want them, and then then you can sort of tighten those up. So, you know, again, going back to the example I I used earlier, if, you know, if a pain point is like, oh, I've always gotta fill out, you know, always gotta fill out these these these forms specifically to to get access to a table that I feel I should have access to, then maybe, maybe the goal for for data governance there is making sure that, you know, all of our access matches, how that data should be actually classified, for example. I don't know if that fits what you were thinking, Brooks, or or if you've got a different thought there. No. That's great. I would always make sure you're asking the right people too. Make sure when you're building consensus and you're you're setting up those sessions to gather requirements and and and make sure you're effectively structuring a data governance practice to make sure that that those folk that there's some intentionality in the folks that you select to interview and to bring into those, those sessions as well. So great. Well, looks like we are tying this all up right on time, and I think we've got all of the questions answered. So with that said, really appreciate everyone's time, today and and walking through the content with with us. Please feel free to scan the QR codes you see here to, follow-up at all with us as well, as get a bit more information and to sign up for our next session here, in the coming month. Thanks, everyone. Thanks, y'all.