Why Bother with Data Governance?
Framework for Nimble Data Governance
In this on-demand webinar, we discuss the components of successful data governance. You’ll learn why governance efforts fall short and what foundational elements organizations often overlook or undervalue. You’ll come away understanding why good governance is so important to the success of BI in your organization.
Depending on whom you ask in the data world, the concept of governance may get called different things: an empty buzzword. A nasty four-letter word. A cornerstone element of a solid business intelligence implementation.
Love it or hate it, companies generally acknowledge the importance of having some degree of data governance. Despite its importance, many companies grapple with how to institute the “right” amount of governance for their organization.
Filtering the topic through the lens of his many years of experience with the Microsoft business intelligence stack, senior architect Shawn Alpay tackles these and other critical questions around instituting a manageable data governance program:
Why bother with data governance?
- What are the warning signs that might suggest I need better data governance?
- How do we implement data governance?
- Data - seems obvious, but often taken too much for granted
- Definitions, calculations, descriptions, tags, etc.
- Process - far more important than the technology
- Assess readiness, define principles, establish groups, etc.
- People - so is this
- Teams, roles, responsibilities, etc.
- Platform - yes, of course the technology is important too
- Architecture, development, security, documentation, etc.
- Microsoft tools: Power BI, SQL Server, Azure, etc.
- Data - seems obvious, but often taken too much for granted
- How can we implement data governance while staying nimble?
We know, governance has always seemed like a huge pain that takes too long. After all, you have projects to deliver. You'll learn the key components of good governance and how to make it (relatively) painless.
Microsoft BI Senior Architect
Shawn is well-versed across the entire Microsoft BI stack and its wide range of offerings, having built ETL, data warehouse, reporting and analysis solutions from the ground up. In his various development and architecture roles, he often serves as the client’s project manager and business analyst, partnering directly with their team to gather requirements and deliver insight.
Love it or hate it, companies generally acknowledge the importance of having some degree of data governance to support their business analytics. Despite its importance, data governance is approached with a bit of complacency. Companies shy away from it because it’s labeled as too expensive to implement. Or too high of a hurdle to achieve. Or someone lived through a past attempt that went sideways, and it left a bad taste.
Whatever the reason, data governance gets the short end of the analytics stick. But the truth of the matter is that data governance is a cornerstone element of a solid business analytics implementation. In addition to mitigating compliance risks, good data governance supports decisions and internal processes, it also helps improve customer experience and create new products and business models.
It’s true that achieving good governance is not easy. It requires consideration, collaboration and commitment. It’s an intricate dance between people, process and technology. Even the best companies struggle to institute a viable governance program and are constantly fine tuning their efforts. But as the saying goes, nothing worth doing is easy.
In this webinar recording, we summarize the critical considerations around instituting a manageable data governance program.
What data governance does
- Establishes one version of the truth
- Increases trust across the organization
- Establishes the business as data owners – not IT
- Positions data issues as cross-functional
- Treats data as an entity separate from its container(s)
- Prioritizes measurements to define success/failure
- Curtails security control issues (either too much access or not enough)
- Reduces rework time and money (really!)
The components of data governance
Data governance requires thought leadership, it is a process, it is not a tool. There are four main components that all must be addressed to ensure success.
People. Data governance fails without personal ownership. It starts with an executive sponsorship team that endorses the mission statement, sets the culture and reviews decisions. A set of decision-making teams, with clear roles and responsibilities, must be determined at the onset.
Process. Process is far more important than the technology! Define the principles, determine a clear scope, create a roadmap with prioritized phases and schedule, and set clear roles and responsibilities.
Data. It seems obvious, but often the data is taken too much for granted. You cannot govern your data if you cannot define your data. After you determine which domains are to be governed, develop a data dictionary that details every datapoint.
Platform. The tasks must define the tools and technologies, not the other way around. All the other components listed above must be figured out first. This is the easy part if you are really committed to the people and process.
Nimble data governance
Data governance projects require iterations—they are never 100% done on the first pass. To be nimble, roll out the project in phases using an agile methodology. We often find it useful to roll out Phase 1 and show off the data quality issues. To save time on the execution, invest the time upfront to define and document.
According to advisory firm Gartner, enterprises are increasingly pushing for growth through digital transformation, which puts more pressure on increasingly antiquated existing technical frameworks. Gartner believes that “through 2022, only 20% of organizations investing in information governance will succeed in scaling governance for digital business.”
Data governance takes hard work to achieve, but it is well worth the investment. So, if you are going to do it, do it right. No consultant can do it all for you—pulling together the key governance components of people and process is a bit of a “family affair” and no one knows your organization like you do. But knowledgeable consultants can serve as arbiters, help facilitate communications between stakeholders, help set up a solid framework and get you started on the right path in this most worthwhile journey.
Greetings everyone and welcome to this latest installment of the Senturus knowledge series. Today, we will be presenting on the topic of why bother with data governance?
Before we get into the core of the presentation, some housekeeping items.
Please feel free to use the GoToWebinar control panel to help make this session interactive, and we have all the microphones muted out of courtesy to our speakers, but we do strongly encourage you to submit your questions in the available question panel. And while we’re generally able to respond to those questions while the webinars and progress, we usually wait till the end. If we are unable to reply to those questions during the webinar, we’ll cover it in a written response document that we’ll post on our website at senturus.com. Which brings us to the inevitable next question of can I get a copy of today’s presentation. And the answer is absolutely.
It is already available on senturus.com, at the URL. You can see senturus.com/resources, you can go to the resources tab, or go straight to that URL, or you can click the link that we’ve just posted in the chat control panel.
And while you’re there, be sure to bookmark the resource library, as it has tons of valuable content addressing a wide variety of business analytics topics.
So our agenda today, after some quick introductions, we’ll talk about why you want to do data governance, governance, and one. Then we’ll cover some warning signs of complacency. We’ll talk about what does data governance do? Discuss the data governance process, and then stick around through the quick, but informative Senturus overview, for those of you who may not be familiar with our organization.
Some almost entirely always free additional resources, and stick around through that for the Q and A quick introductions here.
So joining us today, I’m pleased to be joined by my colleague, my esteemed colleague, Sean LP, who is a Microsoft PI Senior Architect Skirts Senturus.
Sean is well versed across the entire Microsoft BI stack and its wide range of offerings.
Having built ETL, data warehouse reporting, and analytics solutions from the ground up, in its various development, and architecture roles.
Sean often serves as the client’s Product Manager, Project Manager, sorry, and business analysts partnering directly with their team together requirements and deliver insights. My name is Mike Winehouse. I’m a director here at Senturus and have the pleasure of being the emcee for these presentations. So with that, I’m going to hand the microphone over to Sean for the core of the presentation. John Floor is yours.
Thank you, Mike. Alright, Welcome everyone and thank you for attending.
I’m going to start with the adage here. That data governance is hard. You’re here, because it’s hard. This is a difficult topic. We have seen folks struggle with this initiative. I have been directly involved many times in having it be established at various organizations. And I just want to honor upfront the fact that it is a difficult topic. So thank you for attending.
According to Gartner, you may be familiar with them. They are a technology research firm.
They, they claim that enterprises are increasingly pushing for growth through digital transformation, and this puts more pressure on the existing technical frameworks. The organization’s carry. We definitely see an increasing gap between the frameworks that organizations have been leveraging for a while and the needs. The business units are placing on those. This manifests itself in many different aspects, but definitely data governance is, is a pain point for many organizations. Even talk to your organizations, we see struggling to implement good data governance, but I really want to underscore the fact that they’re doing it because it’s worth doing. There, you may not be completely done or successful in the first phase of a governance project. But we definitely see that organizations of every size are attempting, or at least attempting to implement data governance for the organization. Because, because of the need for digital transformation.
So here’s how we’re going to be, approach and governance, will talk about the warning signs of what I call data complacency, AKA risks to an organization when folks start accepting data quality issues, or access security issues, et cetera. Well defined data governance, and will detail its purpose and value, will breakdown implementation of the consumable chunks, because I want to recognize, again, this is difficult. We really need to break it down into something we can understand. But we will be focused on the high level. This is not a Tips and Tricks Webinar, will definitely be approaching this more from a thought leadership place. This will be filtered through my lens, I’m a Business Intelligence architects. I’m not a security guru, I’m not an admin person, and I’m not an executive. I’ll try to be inclusive of those perspectives, but definitely know that my lens is that of someone in implementing business intelligence initiatives for an organization, so that’s the slants I’m taking when it comes to data governance.
I want you to filter this talk through your lens. What did I say applies to you and your org? And most importantly, how do you disagree with me? Your mileage may vary, I really don’t think that you’ll agree with everything that I say because this is such a tough and ephemeral topic. I want you to be thinking critically about what I say that you agree with and what you disagree with. And come away from this feeling like you engaged with the topic.
Alright. So with that said, let’s jump to data complacency. AKA this is fine. You may be familiar with these two panels of a little dog sitting in the fire and he’s, he says, this is fine. This is actually the first two panels of a really great web comic called Gun Show. I just want to step through the rest of the panels real quick. The dog says, I’m OK with the events that are unfolding currently takes, a sip of coffee puts it down. It says, that’s OK. Things are going to be OK. And then, of course, his face melt off.
This is a great allegory, I suppose, for what I see in various organizations when it comes to how they approach their data. They’re just, they see the issues all around them. But they accept them because they don’t think that they can actually change the situation. And I feel so strongly about this that actually have a Plus Xi of this dog. This is a picture of me, fleshy of this dog sitting on my desk to remind me at all times to not become complacent with data, but with everything in my life, but definitely, data governance as well.
Alright. Some warning signs of data complacency. These are some, some, some phrases I have heard at various organizations. For example, why won’t IT fix these? Data inaccuracies? I’ve heard business units say this all the time, they tell me how frustrated they are with the folks who own the various tools and technologies at the organization, not having skin in the game for fixing their data quality issues. But often this is illustrative of the fact that the very folks who were saying this don’t feel ownership over the inaccuracy of the data themselves.
It’s fine that the data doesn’t agree across systems, as long as it’s quote unquote directionally accurate. I love this phrase so much, I’ve heard it so many times. As long as, it doesn’t matter that we’re off by a few hundred basis points or a few percentage points, as long as we’re all, as long as all the data is larger or smaller than what we expect across the board, then it’s fine.
It’s what we might call directionally accurate. We could still make decisions on it because it’s all wrong in the same direction. It’s not find the data quality is kind of bad, but its Ben decided it’s too hard or expensive to solve. This, it’s been decided, is a very interesting passive voice, where there’s really no one who said it’s too hard or expensive to solve, but somehow people have cognitive dissonance. They don’t like that the data is bad, but the only way that they can come to terms with it is it that they feel that some ephemeral power that be decided that it’s unfixable placing the blame or displacing onto some party that doesn’t actually exist.
Is this net sales number, the finance version, or the operations one?
Oh, wait, it’s probably the marketing one.
So, often, we see measures different measures with the same name. Living in an organization across the various business units, this usually is illustrative of the fact that an organization has become somewhat siloed. And in this example here, finance ops and marketing all have different definitions for net sales. They might be all similar, but they’re there. They’re just different enough, where if you just put the word net sales on a report, without calling out whose definition it is. It could actually be very confusing and actually lead to bad decision making.
Finally, someone deleted the entire main reporting folder, again, this is an example of bad access controls, Bad security, where we’ve given someone too much access to something, and they deleted a production artifact. I’ve seen this happen many times, and the again, it applies that well. It happened once, and we didn’t fix it, and then it occurred a second time, or maybe a 10th time.
These are all risks to an organization when we become complacent and accept data quality being the way it is, Data governance, being the way it is. Then we start, we continue to foster a non-data driven culture, and we continue to foster an acceptance of things that we know in our heart, don’t work.
I want to challenge that.
So, what does data governance do? It pushes back on all of those things, all those themes we just talked about. First and foremost, it establishes the business, as data owners, not IT, IT should be framed as stewards of data. They are the ones who own the tools and technologies that may how’s. Data there, therefore, the stewards of the data that flows to those systems. They are not the owners of the information. The owners should be the folks who are generating and consuming the information. The business units of an organization should be the data owners, finance, ops, accounting, and marketing. These are folks who may be actually generating the data points, and their ownership is critical.
Just sassed of a data governance initiative, the accuracy of data, et cetera.
Data governance positions, data issues as cross functional. If a particular business unit might be generating data, for instance, operations may own net sales. But if everyone across the organization is consuming it, then everyone’s impacted if that data point is wrong, data governance helps frame a data point as something we’re all holding hands to own and consume. And if the business unit is generating faulty data, it really is the problem to be solved by the entire organization.
Data governance treats data as an entity separate from its containers. I often see, we often see folks refer to datasets by the source system. They come out of, but that’s certainly one place the data might live in a business intelligence initiative. We may see Dataflow across many systems. Before it gets to the eyeballs of consumers and data governance definitely treats data separately from the things that lives. And we’ll be talking more about this topic as we go.
Data governance prioritizes measurements to define success and failure, data governance is hard enough without.
If you’re lacking the ability to say, OK, this is how we succeeded. This defines that we met our goals and this defines what we will do if we don’t meet our goals without that, data governance just becomes that much harder. So it definitely prioritizes, saying, OK, we’re going to become this much more secure. We’re going to become this much more available with our data, et cetera. And be able to go back to that and say, we met our goals, or we did not meet our goals.
Data governance reduces cost of time and money. Really, I feel strongly about this. Feel often, that people think of data governance as a four letter word. And if you spend the time to do data governance properly, the thinking goes, it’s going to cost a lot of time, and it’s going to cost a lot of money. But I really feel strongly that to be proactive with data governance.
Allows us to save these precious resources in a way that being reactive without it would cost us. I feel strongly that, if you put the time in upfront, it will absolutely save you. Three X, five X ted-x, of these resources, down the road.
And finally, data governance, I believe, increases trust across the organization. This, this is a bit of an intangible, but data governance is an opportunity to take cold heart data and make it better. And with that evidence at hand, that we were able to be cross functional, work together to solve this problem. It helps foster cross functional culture, a data driven culture, which therefore, then leads to trust across business units, which will lead to benefits that are hard to describe or perhaps tangential to data governance, but definitely increase the potential success of an organization.
So, what is data governance? I’m going to give you my definition of data governance. If you ask 10 different people, they may give you 10 different definitions. I encourage you to disagree with aspects of this, but this is how I think of it, All right?
Data governance is a framework for ensuring the availability, accuracy, and security of data across an organization, OK? Great. But you might immediately be thinking, well, what does that mean?
Breaking this down into pieces. There’s a lot of nouns terms in here that we have to more fully define before we can fully understand this definition. You might first ask, well, what’s a framework? This is a collection of ideas that is not a technology, necessarily, that might be a piece of the puzzle, but it is people, and, and thoughts, and processes, and technology is all coming together to solve this issue. And there’s a bunch of other words. We’re not going to go into all of them, but, for instance, what does availability mean? What does accuracy me, what does security mean? What does data mean, et cetera, et cetera. There’s a lot of terms in here that we have to define in our organization. So the first point I’ll make after I show you this definition is that data governance is a long series of definitions and discussions. Putting on your detective hat, talking to people, understanding where they’re coming from, resolving issues, come into compromises, making sure you’ve made a black and white out of the gray of data.
This is a very important thing to do, and there’s no substitute for it.
Getting down to the brass tacks of what each thing means in your organization is, is absolutely critical to the success of a data governance initiative, and you’ll be seeing me repeat that many other times as we go through this talk, Therefore, data governance requires thought, leadership You can’t buy ideas off the shelf. If you could, you wouldn’t be here. I know you’re here because this is difficult, and because data governance cannot be purchased as a technology. It requires having people, including you. Invest in how to lead an organization, through ideas, how to bring a organization to this initiative. And it’s, it’s, it’s not just the technology you can buy. Which brings me to my next point.
Data governance is not just a tool, our process defines our platform, not the other way around. I feel so strongly about that. As a business intelligence architect, of course, I need to understand my tools cold. But I choose my tools, and I use my tools based on ideas, organization, that happens independent of the tools.
Yes, data governance needs, technology in order to be successful. But, it, is, it is, it flows out from the organization we install in the organization, in order to then leverage those things for success.
All right, so, you might be wondering, how do we, you know, do this? I’ll answer that question with a question. How do you eat a huge, rice crispy square? If you’re Bart Simpson you just go for it and you do it one bite at a time it’s super important to break down data governance into components. So we’ll be framing the rest of our talk by distilling the concept down into four major pieces. First of all, there’s process. How do you organize your organization and take the how of this into where, the, what the when, et cetera.
There are the people. How do you organize your folks into teams with roles and responsibilities? That can execute data governance?
Your platform? What is your technology? What are your tools? It’s the wear of where things will land. Where things will live. Your ideas are going to exist somewhere.
So that’s super important. The fourth piece, which almost sometimes goes over overlooked with data governance, is the data itself. What is the definition of your data? Who owns it? How is it maintained? Et cetera.
And of course, because all of these things are inter-connected, I won’t be able to really talk about one without kind of referring to the rest of them. So I’ll be starting with process. I’ll be touching on the rest of them as I talk about process and then I’ll move to people. I’ll be touching on the others and, you know, by the time that we circle through all of these, I’ll be talking less and less about each because I love.
It’s all inter-connected.
All right. So let’s start with process.
Got, we have to break out how down into W by W is. I mean, why, what, when, who, and where. So we’ll stepping through each of these. But it’s super important that as we move through these, you’d be thinking about how each of these sections, results and documentation.
And a point I want to make before we go any farther, super important is that I am extremely tired of documentation being undervalued. When I said documentation, your eyes may or may not have rolled into the back of your head. Because documentation often in the organization is a four letter word. That a document is like a 400 page monolithic thing. That doesn’t actually tell you what’s going on or how to do something.
High level, good, Concise documentation can definitely exist, It’s so critical to a good data governance initiative. I would encourage you to be thinking about how to do that as part of data governance.
Alright, let’s start with the Why.
Guiding principles, a mission statement: Endorsed by Your Organization’s Leaders. This is the high level document, talking about what’s going to foster a data driven culture in your organization. This is going to be endorsed and sponsored by the folks who are your data champions, and we’ll talk more about that when we get to a people section.
Here’s some examples of what you might find in the mission statement. We recognize data to be a valued and Strategic Enterprise asset.
Our data shall have clearly defined accountability. Our data shall be well managed. These are high level ideas. This is not exactly how you’re going to do it. This is why you’re doing it, and these are the values the organization wants to encourage across all levels.
Moving it to the what?
This flows from that, these, your requirements. This is your clear scope of how the, what you wish to accomplish. What shall we accomplish? What data domain shall be included, like sales or labor or inventory, and more specifically, the data points in there, et cetera.
What persona shall be included? These are the groups of people who, who touch the data, the executives, managers, individual contributors, admins, analysts, etcetera, will be talking about personas more on the people section, but who will be considered as part of the data governance initiative?
What shall define success and failure? We talked about that earlier. We’re going to need measurements to say, this is how much more available we wish the data to be, how much more secure? And what shall we do if we don’t meet those, those goals?
How shall we fund this? Obviously, a very important piece of the puzzle.
And what are the priority levels for all of these things? We can’t just say this all priority one. We cannot boil the ocean, we’re going to leverage priority levels in the next section when we decide what our roadmap is. This is a roadmap for the execution of the what.
We’re going to leverage the prioritization in that what section to determine our phases and our schedule. We might or might not be deciding an exact timeline, depending on what kind of methodology we’re using for execution, like, if we’re using, perhaps, an Agile methodology, where we’re working in in two week buckets, We may not say, we’re going to try to do this by June first, 2021, but it’s important to bucket what we’re trying to do in the phases and have a rough kind of flow, in terms of: We’re going to do this first, and then this, and then this, et cetera.
What must be accomplished in phase one? Must, is very important. Some things I know when you’re thinking about how to improve data governance in your organization can be postponed. It’s not that they should be postponed everything’s important, but what are the most important pieces that you want to absolutely rally around and say, look, look at the good work that we did? We can continue to carry this good work forward into future phases.
Phases can be small, I believe, strongly that five small phases will be faster than 1 big 1. I see folks often say, well, we don’t want to necessarily have to digest the overhead. It might cost us to turn the key on five different phases, why don’t we just push it all into 1 or 2 phases, and then deployment and testing and, you know, u.a.t., all of these things would only have to be done once or twice. I fully believe that, that kind of meta process is very important to step through and, and hone and I feel strongly that by the time you get to the end of the fifth phase, it will have been faster than if you tried to bucket of all together.
That’s my opinion, the decision making bodies and roles and responsibilities, these teams are going to organize will devise the why, and the what, and they’re going to make it happen.
You’re going to need crystal clear roles and responsibilities defined for each person, and each role each group will talk about this more later.
You also need personas for all the categories that people that touch the data. We’ve mentioned that a little while ago, we’ll get more into that when we get into the people section.
Finally, that leads us into the where, your tools, or technologies, or repositories, or diagrams in architecture, for all the tools that are going to be necessary to turn the key on these ideas that you have established in the preceding documents. This is your source systems, your code repositories, your document repositories, databases and data lakes, reporting interfaces, data management tools, security admin. The list goes on and on. Obviously, you need to have a host, a smattering of tools, and technologies to do data governance well. But again, it’s at the end of the chain. All these things are prerequisites to deciding these things. You cannot let your tools define your tasks. And I’m going to say it like, 3 or 4 more times by the end of this, this talk.
All right, turning our attention over to people, I want to bring up a book that I think is one of the most important reads of the last 10 years. For me, it’s called The Secrets of Consulting. It’s written by a guy named Jerald Weinberg, Even though it was written in the eighties. It’s still super applicable to organizations today. He makes a ton of great points.
But the point I want to bring up right now is that no matter how it looks at first, it’s always a people problem. Technology issues, organization issues. Everything under the sun when it comes to what I’ve seen as a consultant, helping organizations comes down to, are people understanding each other? Is there a communication problem, is or an organization issue? This is where to look to solve issues in an organization, super important to figure out, in a data governance initiative.
And an important piece of that puzzle is ownership. I really feel strongly that data governance will fall on its face if there’s not personal ownership across every level of an org that is implementing this initiative.
So, with that, I want to introduce to you some various teams that I have implemented in terms of data governance. The example I will step you through is an organization of revenue of maybe a couple of billion dollars per year. Your organization might be larger than that. It might be much smaller than that your business, you know, maybe very small. This can be tailored for any size. I’ve done it with smaller groups to much smaller groups. But the ideas are the same.
You’re going to have four major sets of teams that are going to help turn the key on this.
The first is an executive steering committee, that’s that high level driving culture change data governance committee, which will be focused on strategy.
Your business user advisory teams of individual contributors, who will be operating tactics, and your project development team, who’s going to be facilitating. This will be doing execution, we’ll talk about all four of these a little bit a bit more.
They’re all going to be working together super important, that there is regular and recurring interaction between these groups.
First, the Executive Steering Committee, the, the focus is going to be on culture, changing your organization to be data driven, and to really prioritize using data to make good decisions.
In this example, there were five executives. Perhaps if you’re a group of smaller, it might be a lower level, like director or manager. But the idea is that you don’t have too many people here, that you have perhaps roughly a half dozen folks really setting the tone for the org and able to provide true leadership.
Meeting Cadence quarterly. It might be a little bit, more often than that to start, But I find that these folks, often, their calendars are very hard to get on, and getting them to commit to quarterly is perhaps the most you might be able to get out of them.
The tasks that they’re going to have on their plate, really driving awareness across the organization. That data is important and that we’re doing this. Provide leadership and act as a final decision making authority when issues arise.
They’re going to be reviewing decisions of progress made by the other teams and they’re going to help resolve policy issues and or conflicts. The buck stops with these people.
If there’s any issues that run up the flagpole, this is where you’re going to see them resolved, turning over to the data governance committee.
The focus here is on strategy. They’re going to be perhaps 12 folks across the organization, a marketing person, an ops person, a finance person, et cetera, who are going to have skin in the game to really want this to go well, because it will positively impact their piece of the organization.
They meeting Cadence as perhaps monthly. I think whatever you agree on, it’s super important that everyone is there every time. When people start checking out mentally and deciding this isn’t that important, it can really rub off on everyone else.
And so if these folks who have been assigned to this committee aren’t taking it seriously, run out of the flagpole, and get the executive steering committee involved and make sure everyone’s attending, the tasks are driving awareness within their teams.
With a smaller group of people into the organization, they’re helping drive awareness of data driven culture.
They’re going to be discussing and approving requests and initiatives, like the requirements and the roadmap, and all that. This is the team that’s doing that. They’re providing the major chunk of strategy.
They’re going to be monitoring progress, removing roadblocks, and they’re going to be naming personnel to the business user advisory teams in our next section.
This is not actually one group. It’s actually a collection of groups who will be focusing on tactics. This, in my experience, and this example, was about 30 people in groups of 2 or 3, who will be meeting on an ad hoc basis to actually turn the key on this. These are the people who are worth their weight in gold, in your organization, your subject matter experts, or people who understand a particular business process better than anyone else.
We’re going to help you understand and execute data governance problems, they’re going to help implement own solutions. They’re going to identify new governance issues. They’re going to develop and deploy that data definitions and business rules. And they’re almost most importantly, going to be recommended courses of action through their deep and intricate knowledge of the subject matter at hand.
Finally, we turn it over to the product development team. This is the team that’s helping facilitate all this. This is a team that, in this example, I was on, we’re helping focused on execution, In this example, it’s about 15 people in IT with me, and the project manager, and architects Developer, et, cetera, like lots of folks who are helping from a data perspective make this happen.
Meeting Cadence, weekly, or ad hoc, we were having a daily stand-up, your mileage may vary in that regard, but definitely regular meetings to make sure we’re staying on top of this.
This team is coordinating the execution of the other team, providing technical data expertise to other teams, executing technical governance tasks and generally stewarding the data, again, as owned by the business. But they are stewarding it, helping facilitate, provide data to the other teams to help solve these issues.
Roles and responsibilities with those teams set up we then have to be very clear about what they’re doing and not doing.
Here’s an example of what we call a racy matrix. Racy stands for Responsible, Accountable, Consulted, and Informed. This is we have folks across the columns here, and we have tasks along the rows here. Right.
So we have an intersection of, and is responsible for task one, and Brian’s accountable for task one, et cetera, responsible as who will do the task, accountable as who will facilitate the task and vouch for its completion.
Keep in mind, there will only ever be one party who’s actually accountable for something being done. There may be multiple people responsible for it, for doing it, or being consulted or informed that it was completed, but only 1 1 person or group will be really accountable for it. Consulted is who will provide assistance and insight for doing the task?
And folks who are informed, who’s going to be notified that this was worked on or is now done?
I really highly recommend you never, ever, ever skip the step of assigning roles and responsibilities. How often, have you been a part of an initiative data governance? Or otherwise where it wasn’t clear what you’re doing, or not doing what someone else is doing or not doing? And you could probably chalk the main reason for it, not working up to the fact that this was not clearly defined upfront as I’ve seen this happen time and time again. And so I absolutely advocate for doing this at the top of, and it’s a really important initiative like this very strongly, never, ever, ever, ever skip this step.
I hope I have made myself clear personas, what kinds of roles are going to be doing with the data? These are folks who are going to be touching it in some way generating it, administrating it, consuming it, et cetera. Governance is much easier. In my experience, if you think of data in terms of how it’s touched, data, governance is hard enough as it is. But if you can empathize, you can kind of put yourself into the role of someone who’s going to be leveraging that data like an administrator or, or an analyst. Then it’s kind of easier to think about it. OK, OK, am I getting what I need? How am I getting at it, Where are my pain points? Et cetera.
What kind of access does each role need to do his job, is super important when it comes to setting up security and access.
If you, if you frame a security conversation around, OK, well, an administrator needs this, and analyst needs as developer needs this, it just makes it easier to execute, we fine.
Here’s a very high level example of a pipeline of a sale from creation to consumption.
We’ve got our customer, who might need one kind of access or service rep, who needs another kind of access system, admin, database, admin, account, and analysts, developer.
And then the executive whose consuming reports, managers, individual contributors, think about, all these people are touching similar kinds of data. But they need different slices of it. They need different levels of access to it.
And in a proper data governance initiative, we’re right sizing for all of these roles, and so if we kind of think about our personas upfront, then executing on proper security and access will just become so much easier.
Alright, moving on to data.
What data domains are actually going to be governed in your data governance initiative, sales, labor, et cetera? Is it’s super important to actually define what it is we’re going to cover, right?
And then once we’ve done that, we build a data dictionary, that details for every data point, both the things you’re measuring and the attributes you’re going to use to categorize those measurements with a solve, a bunch of question and answer a bunch of questions. First of all, what’s its definition? How is it calculated, right? That might be the first thing you think of, but there’s so many other things like, what does this description in plain English? How would you explain this data point, or this attribute, to anyone? Who’s not a subject matter expert? How would you communicate this to the total layperson?
The most important thing, I think, when it comes to this data dictionary, is what its name is, and does everyone agree on the name? Remember the net sales example, we brought up earlier, where we had three different business units using the same name? Well, when we’re working cross functionally, it exposes that problem, and then we need to rectify it. And all three of those groups might say, well, I’m going to call my thing that sales, and we’re going to call your thing, operating that sales, or marketing that, sales, No, we’re not going to do that.
They’re all going to have distinct names, and that part of the data governance initiative will help resolve that.
What tags or categories as a carry? Is this data points sensitive? Like, for example, are we going to carry social security number in the system?
Are we going to carry personally identifiable information or offeror from a data warehouse perspective, some more mundane categories like product category or sales, territory, or fiscal calendar for this data point or for this attribute? What are the ways we might categorize it?
How is it generated? How does it maintain? You don’t have to write a novel about this, but it’s pretty important to know, OK, this is how we actually generate our raw data that gets into this data point.
How is it corrected? If something takes three weeks to fix, that’s a problem. Understanding, exposing how something gets corrected when it’s wrong, is super important to good data governance and to high data quality.
Who is its owner? Which business unit actually owns this thing? And remember, it’s not IT. It’s going to be a business unit.
Who can access it? This is going to be very important when it comes to setting up security policies.
You can’t govern data if you can’t define the data, and, and, and so I’ll just make the point again. I think, I think defining data gets skipped often, The data governance initiative, with the implication it’s already been done, and often we need to go back and do some of this work that you may expect would have already been done when it comes to getting down to implementing data governance.
Alright, finally, platform, again, this is like this horrible, will last component, and, again, I wouldn’t say it’s our least important component, but it absolutely has to follow and flow from our previous components. This is where the rubber meets the road, but everything we’ve discussed so far needs to be figured out first.
I encourage you to think of technology more as the where, than the how. It is where our ideas will live, where, where we will, we will provide a house to those policies. It isn’t how we’re going to execute.
There may be some, some specific things to a particular technology may have to work around.
But it absolutely should not be wholesale defining how you’re going to do something.
If you have really committed to the other components, process people, end data. This is the easy part.
I believe that strongly, your tasks to find your tools, not the other way around. This is the fifth time saying it. It’s worth saying again, and I hope you agree with me.
A really important artifact that would come out of platform exercise would be an architecture diagram.
This is a high level document that describes logical Dataflow of data in your organization.
I would say, arguably, if it doesn’t already exist, and you’re creating it wholesale out of a governance initiative, it might be the most important document governance may produce, because then you can kind of just look at a concise one pager and say, Oh, this is what’s going on, this is how data gets to my eyeballs from the source system, it’s coming out of any data governance participant should be able to understand this document.
I’ll give you just a really high level example. You might get more specific than this, but this is just to illustrate what I’m talking about. Perhaps a customer kiosk is leveraged by customers, and it’s interacting with an Oracle sales database. And perhaps there’s an employee interface where you input labor data into a SQL data warehouse. And that’s living in Azure in this example. And there’s another interface that goes and does another SQL database for inventory. And then there’s some pipelines in Azure Data Factory that might land into a SQL data warehouse. And then, that might flow into an analysis services, tabular model, Israel, Microsoft technologies, by the way.
Which may then flow into Excel and Power BI, reports and dashboards to be able to just explain to the high level, this is our kind of, North Star. This is the thing that we’re trying to turn the Qian for doing better for, for securing, better, making data quality better, et cetera, just so important to kind of Align Everyone across the organization on kind of where the rubber meets the road.
One other point I’ll make is that, I think every arrow, and icon on here should have supporting documentation. Like who, the what, the where, the when, but it’s all under this umbrella, right? Like, how exactly, sales gets into the main data warehouse, how it’s transformed the actual data points. All of that stuff needs to live somewhere, in a document that can be consumed. It’s kind of a follow on piece of supporting document to this, this umbrella piece.
So how did we do all this nimbly, right? I know this is all this is kind of overwhelming, and you might be thinking that it’s going to take forever, to do. I do. I do believe that this: these kinds of initiatives can be done in bite size chunks.
I encourage you, again, to limit your scope one bite at a time. What has to be done right away? What can wait until later?
Garbage, in, garbage out. I think this is an important phrase. An important way to frame data, it can be extremely helpful to go to market in Phase one, and show off your data quality issues, as long as you can speak to them. Of course. And they’re not masquerading invisibly. If you can show people, hey, look, we have implemented a flow. And we have our first stap at data governance. And here’s our business to Business Intelligence Initiative, which is bringing data to you. Here’s our data quality issues, because our access issues highlight the problem right, then, in future phases. It kind of fosters an interest across the organization, in, in, in moving forward, on the second phase. Whereas, if you had taken all of this time waited until it was fully fixed, you may not may not have had full buy in from the organization to move quickly on this initiative.
So, something to think about, an agile methodology, I really think it worked with Business Intelligence hand in hand. I find often that people think, well, if it’s a BI Initiative, we can’t use Agile, and data governance initiative is diametrically opposed to the idea of working in two week chunks. But I really think that that flows from the idea that we set up a timeline where we have to work in a waterfall kind of way, where, by this particular date, we have to do this. If you think of tasks more in phases and sub phases and sub phases down into sprints of 2 or 3 weeks or what have you, and you focus on what you’ve got done and then roll things you didn’t get down into the next sprint and just work like that. It can be a very healthy and successful way of moving forward on data governance.
I will say though, there’s no shortcut for defining and documenting upfront. But I promise you, it will save you time when executing.
This is just true across any initiative, but if you are willing to be proactive upfront, it will save you so much time being reactive after the fact. And that is absolutely true, perhaps, doubly true when it comes to data governance.
All right, so let’s: Let’s summarize everything we talked about and frame it as a checklist. Just be thinking about everything that we’ve talked about so far, and we’ll step through simple Yes, No questions as to Do you think your organization is doing this well, or is there an opportunity?
Is your org struggling with data quality and access issues? I can almost say yes, of course it is in some way, but you know, your definition of that may vary.
Is your org ready to revisit its approach to governance?
Often, organizations don’t have the appetite to tackle the issue at hand, and, and, and some sort of conversation, advocacy needs to occur first, if those things have occurred, Has your org generated governance documents for, here’s a list, the guiding principles we talked about, the mission statement: The requirements are clear scope, the roadmap, what is our, our phases, and our prioritization, governance teams, our data governance committee. Our business user advisory teams, have thus been set up.
Our roles and responsibilities. What are folks responsible for, whether they’re not responsible for our personas? What are the groups of people who are going to be touching the data, or data dictionary, what are the definition of all of our data points, Architecture diagram? How does our data flow, right?
Finally, is your, or open, to letting the process to find the platform. You know, I had to sneak this in one more time. Our tasks to find our tools, can we let our process defined the platform? Are folks open to that? Often I find people are very excited about data governance. But they are framing the conversation through the lens of, this is the technology we’re going to use. How are we going to do data governance with it? And I just encourage you to flip that idea on its head.
Some closing thoughts. Governance will never be 100% done on the first pass. You will get to the end of your first phase, and it won’t be everything you just hoped and dreamed for. But if you’re ready to jump back in the saddle and try again for a second phase, then that is where governance is, quote, unquote, successful.
Here’s another quote from Gartner Through 2022. It’s really interesting. Only 20% of organizations, investing and information governance will succeed and scaling governance for digital business. I don’t want that to feel like it. It’s defeating you. I want to frame this by saying, you know, 20, only 20% of organizations are really going to hit what fully what their goals are, and, and I would say 80% of organizations will still have gaps that they need, that they are going to need to focus on closing in subsequent phases.
So, I would highly encourage you to judge your success, quote unquote, on a spectrum, and be ready to iterate.
Become comfortable with the gray of data and data governance, both with the topics at hand, and, of course, the gray on your head that it will introduce inevitably, so with that, I will leave you with a good luck. I’m really passionate about this topic, as, as it might as might seem clear, and I love hearing about people’s stories. Feel free to reach out and tell me what your experience with data governance is your frustrations with it: I really want to wish you the best of luck with turning that key on this in your organization.
With that, I’m going to turn it back to Mike.
Great, thanks, Sean, for some excellent content. Stick around every one and get your questions into the question pane. In just a few minutes. After we cover a few slides, we’ll get to that Q and A and, again, if we can’t answer the question, we’ll put it in a response document.
As discussed, data governance takes a lot of hard work to achieve, and you may be feeling a little overwhelmed right now. You’ve heard terms like Touse, Ephemeral, cultural change, but it’s well worth the investment implemented properly. So, if you’re going to do it, do it right?
Pulling together the key governance components of people and process at all levels of the organization, is key to your success, and having knowledgeable consultants, who can serve as arbiters, facilitate communication between stakeholders and help you set up a solid framework to get you started on the right path. Can be a real help to help you, evangelize them build support within your organization. Senturus is offering this executive summary on our site, you can download it from the resource section there, where the deck and soon the recording will be.
Few quick slides about Senturus. We are the authority in business intelligence. We concentrate our expertise solely on business intelligence with a depth of knowledge across the entire BI stack.
At …, our clients know us for providing clarity from the chaos of complex business requirements, disparate data sources, and constantly moving targets. We’ve made a name for ourselves because of our strength at Bridging the Gap between IT and business users.
We deliver solutions that give you access to reliable analysis, ready data across the organization, so you can quickly and easily get answers at the point of impact, the decisions you make, and the actions you take.
Our consultants are leading experts in the field of analytics with years of Pragmatic, real-world experience, and experience advancing the state-of-the-art.
We’re so confident in our team, and our methodology that we back our projects with a 100% money back guarantee that is unique in the industry.
And we’ve been doing this for a while. We’ve been at this for nearly two decades. And we have worked across the spectrum, ranging from Fortune 500 down to the mid-market, solving business problems across many industries and functional areas, including the Office of Finance, Sales and Marketing, Manufacturing, Operations, HR, and IT.
The team at … is both large enough to meet all your business analytics needs, yet small enough to provide personalized attention.
We invite you to expand your knowledge.
We have hundreds of free resources available on our website there @.com/send-tourist-resources. And go visit that book market. While you’re there, check out our events page. On the next slide, Shawn will be adding and October that we have an event coming up on September 24th, How to Successfully Implement self-service Analytics.
And that’ll be at the, and we always do these on Thursdays, 11 to 12 Pacific, 2.00 PM Eastern. So, you can go register for that there, and we’ll be adding an October eighth webinar on Data Architecture with a focus on Microsoft. So, look for that e-mail if you’re on our mailing list in about a week.
We’d be remiss if we didn’t discuss our complete BI training offerings across the top three BI platforms, Cognos Tableau and Power BI or, particularly ideal for organizations that run multiple platforms or, are moving from one to the other. We can provide training in many different modes. Whether it’s tailored group sessions, 1 to 1 1 too few mentoring, instructor led online courses, or virtual self-paced learning. And we can mix and match those to meet the needs of your user community.
Then, finally, before we get to the Q and A, some great additional resources.
We literally have hundreds of these on our website, and we’ve been committed to sharing our BI expertise with all of you for over a decade now.
I will jump over the Q and A Again, if you have questions, please feel free to put them into the questions pane, and we will get to them. We have about 10 minutes left here. So, Shawn, if you had a chance to take a look at those. But we had a question about the racy matrix that you put up there and is one person can they have more than one role such as responsible and accountable.
I, it’s funny, I love this question because if we’ve gotten down to the point where we’re looking at it like this than, I think we’ve, we’ve done some good work, right? I would encourage folks to, to not assign more than one role to someone. But if a team is small enough, it may be necessary. If, if perhaps a manager is a heavy individual contributor as well, they may be both the person responsible and accountable.
But I would encourage folks to start from the default of not doing that, and accepting that if that’s the way it has to be.
Great. What would you recommend for smaller organizations? That’s kind of a nice segue, Um, if you have 50 employees or less, how would you sort of scale that down so they can manage it?
Totally, So the idea of those four groups, still absolutely as applicable, it’s just, who’s going to sit on them, will be different. And just like the previous question, where are we? One person may have more than one role. Person may sit on more than one of those groups, but it’s important to think of that that person wears a separate, right? So if a group with a group of 50 employees, or less, let’s say, 50 people, then you may have only 1 or 2 people on the Executive Steering Committee, you may only have 3 or 4 people on the Data Governance Committee. You may have, let’s say, 10 people on the in the Business User Advisory Teams. And maybe even just 1 or 2 people on the project Dev team. It just at all scales down, perhaps in the numbers. But the tasks, the roles, the need, that’s all still exactly the same.
Sounds good. Can you talk about challenges in convincing executives to start with data governance and how you overcame those blockages?
How much time you got?
It’s, it’s absolutely different from organization to organization and that’s where, uh, the kind of role that I serve often transcends just being a data jockey and becoming a therapist, or, or an advocate, or a project manager. It starts with being able to show an organization, an executive, and their own issues.
It can’t just start with, perhaps a, uh, more Hattie conversation that’s kind of abstract. It has to be grounded in the issues at hand. And if we turn that to the definition of data governance we gave earlier.
How can we show an executive not only the issues surrounding accessibility, or, or security, or availability, but what are the problems it’s causing in the organization?
How do we draw a line from that issue, over to, and it’s costing you X, N, time, X and money, because, ultimately, executives spend a lot of the time thinking about roadmap, and budget, and what have you.
And if you can draw the pain point over to, it’s costing us something now, or it could be costing us something in the future, then that’s where their eyes will light up.
And that’s where they will be more excited in being a data champion.
I would also say, finding someone at a higher level of the organization who understands data, who is savvy with data, who is passionate about data? Because then, they’re already speaking, your language at this person may not exist in your work. But I have often found that if you look across the leadership, you will find someone who cut their teeth on really heavy Excel spreadsheets, or they themselves are a technology person, and, and they understand the language, and they understand the pain points. They understand what it takes to solve it.
And they’re passionate about helping you execute on solving that.
So, I wish I had a more concise answer than that.
It really will depend across organizations, but that is, um, at a high level, how I would start with that kind of conversation.
I think that’s a great answer. I mean, you have to find the pain, right? Where is it affecting the company in terms of revenue, customer satisfaction? Whatever the things are that keep your executives up at night. This one, this gentleman was trying to challenge us I think by stretching this question across five different panes. But I think what they’re suggesting is that data governance could be compared to the same process that you go through in developing business intelligence assets.
And you’re sort of saying that the governance that you need for good reporting is the same as it is for, for data governance, and is there overlap there, and what’s your view on that.
They’re so joined at the hip. I would say that so, much of what I’ve helped implement with clients for data governance was happening part and parcel, with an existing or starting business intelligence initiative.
And I often, as a consultant, helping an organization am coming in with certain questions, trying to define OK, are my prerequisites there to be able to move forward with good reporting and analytics?
And that the huge plank there is data governance, and is the data of high quality? Can people get to it? Can I, as an architect, get to it? Can I, can I help you show off that data? And often, there are certain prerequisites, certain documents that don’t exist.
So, going back and, and helping craft those things, can only occur if a data governance organization is established, and sometimes we can slot into an existing data governance framework.
Often, it’s had, I’ve had to create a greenfield and, and, in either case, in most of my, in most of my engagements, there has been at least a little bit, if not often, a lot of helping craft the organization’s data governance and having to put the PI initiative, not necessarily on the back burner.
You need to move forward with that, but it, it helps highlight the data governance problem, and then that’s solved, and then you can move forward fully with a high quality BI solution.
Yeah, it seems, to me that the data governance is a, is a broader topic, of which the governance for a specific reporting initiative is a subset of that.
And so, thinking about it more systematically, probably requires more research, more planning, but the, you know, the re-use and the potential benefits, I think are greater than.
How about, there were, can you speak to reconciliation processes that give confidence in your datasets?
So, to be able to say this is, this number is correct.
Absolutely, It’s like going all the way back to a source system, and seeing what it says there, and then following it all the way through your data flows down to the last piece of the puzzle, Perhaps the reports and dashboards that are being put in front of auditors, to be able to tie that, tie those numbers out.
And if they’re being changed, which they almost certainly are being transformed in some way, to be weighing that against documented policies, that describe why and how data’s being transformed, is of critical importance. To be able to, to, in the architecture diagram, that I showed earlier. To be able to put your finger down on the piece of paper, and follow the line all the way through, and say, this is happening here, this is happening here, that’s happening here. And that’s why there’s $200 number became, 185 dollars and 54%.
Uh, that starts with documentation.
It starts with having access to that source system.
I often find, I’m not, as, as an architect, involved in these kinds of initiatives. Not necessarily, at first, given access to the, the, where the data is being generated. It’s only it’s an intermediary spot that some transformations have already occurred, that I’m being given access. And so, I often ask, well, OK, you have concerns about this number, not matching.
Let’s get access to the, let’s get under the hood, in that original spot where it’s being made and, I want you to show me what’s going on and, I often will highlight the problem.
But, it comes down to Tieing the discrepancies to what should be occurring.
And almost, certainly, in my almost always, my experience, that just that, that is sufficient to getting to why the numbers might disagree.
Good stuff, well, we’re at the top of the hour here, so I want to be mindful of everybody’s time here. So with that, I think we’ll wrap it up. So Shawn, if you want to advance to the last slide. First of all, a huge thank you to you, Sean, for a fabulous presentation. Again, this presentation and a recording of the presentation will be available on .com. And we hope that for you. Thank you in the audience for joining us today. As always, if you have any business intelligence needs, we hope you’ll reach out to us either at our website or old school and still use a phone, we have an AAA number. Or you can always e-mail us at firstname.lastname@example.org. So, thank you for your time today and we look forward to seeing you on the next installment of the Senturus of Knowledge Series. Thanks. And have a great rest of your day.