 Hello and welcome, my name is Shannon Camp and I'm the Executive Editor of DataVersity. We would like to thank you for joining the current 2015 installment of the Monthly DataVersity Webinar Series, Real World Data Governance with Bob Siner. Today Bob will be discussing data governance best practice criteria along with special guest speaker Craig Mullins. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights of questions by Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now let me introduce to you our speakers for today, Bob Siner and special guest Craig Mullins. Craig is President and Principal Consultant of Mullins Consulting Incorporated and the publisher editor of the database site, which is URL is thedatabaseite.com. His working experience spans three decades of multiple industries. Craig is the author of two best-selling books including Database Administration, The Complete Guide to DBA Practices and Procedures, second edition. Bob is the President and Principal of KIK Consulting and Educational Services and is the publisher of the Data Administration newsletter, tdan.com. Bob has been a recipient of the Damon Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Thank you very much, Shannon. Thank you everybody for joining us today. Thank you always. I appreciate you're taking some of your valuable time to attend this webinar. I'm very glad to be doing this webinar with a good friend of mine, Craig Mullins. As you might know or might not know, I'm a Pittsburgh guy by the fact that I live here still. But a good friend of mine who went to the University of Pittsburgh, Craig Mullins, is joining us today. And he'll be talking to us about data governance best practice criteria from more of a database administration perspective. And we'll talk a little bit more about that in one second. But welcome to the webinar today. I hope you'll find some information here that's valuable to take some good takeaways with it. Real quickly before we get started, I just want to remind you of a few things. One is the book of non-invasive data governance that was published back in September. The second is please visit kikconsulting.com for more information about a lot of the things that I talk about non-invasive data governance specifically. And also, I am so pleased to be able to speak at many diversity events. I just wanted to highlight a couple of those for you too before we get started. Coming up at the end of the month and into the beginning of next month is Enterprise Data World. The topic that I get to speak on is one that I'm very excited about. It's actually progressive topics in data governance. We'll talk about big data and data governance. We'll talk about agile and data governance. And we'll talk about the Internet of Things and data governance. So please join us there. And if you can or can't make it to D.C., please join us in San Diego for the annual Data Governance and Information Quality Conference. And I'll list the presentations that I'll be giving there. So I'm looking forward to meeting some of you, any of you, all of you out there at those events. So please, I'm looking forward to having you there. Just also to let you know about some of the upcoming webinars next month. And as you know, it's always the third Thursday of the month at 2 p.m. We'll be talking about data governance framework components. We'll be talking about building your own data governance tools and the fact that everybody is a steward and how we can get people to deal with that. We'll be talking about those three topics in the coming up three months. So I hope that you will join me for that as well. Here's the abstract that I used to attract you to the webinar today. The fact is that best practices are often the first step that organizations address when they're building new types of programs. So best practices define the target behaviors. This month I'm working with Craig, where Craig will also share with us some of the best practices around database administration as well. So I'm looking forward to getting that perspective as well. We're going to talk about the criteria first and foremost to what determines something to be best practice around data governance, around data management. And Craig will talk about database administration. We'll talk about how to evaluate your organization against the best practice and how to maximize the value of the thing that everybody calls an assessment or a critical analysis of the organization, steps that must be taken after completing the analysis and then how do we measure whether or not we're successful in achieving some of the best practices that we've defined for ourselves. So here's our agenda for today. I'm going to give Craig a moment to introduce himself further, but pretty much everything that I'm going to share on the next slide is already shared with you. I'm going to ask Craig for a couple minutes of conversation about database administration best practices, specifically around governance. And then we're going to talk about those topics and leave some time for questions and answers. So sit back. I hope it's enjoyable. I hope to get some good questions and look forward to sharing the information with you. Well, first thing I want to tell you about Craig before I let him talk is that Craig is one of my oldest industry friends. I've known Craig since we went to college together at the University of Pittsburgh. We interned at the same company together. And Craig and I took distinct paths in the data field. Craig specifically focusing on database administration and my more focusing on data administration, everything that Shannon had mentioned about him being the president and principal consultant of this consulting company. And he also has a publication around databases, which is the database site. In fact, Craig was the person who helped me to name the name of my website. He also has authored a few books. He speaks a lot at conferences. Craig, welcome aboard. Good to have you here. Thanks. Good to be here, Bob. Yeah, as you mentioned, we go back a long ways. And I think this is the first time we've ever really delivered a presentation together. We've been at the same places and delivered presentations separately, but first time as a tag team, I guess. Well, it's kind of interesting. So we just got to keep it interesting for people. That's all. But it's good. I know you've got a lot of opinions and a lot of things. And neither of us are lacking an opinion, so let's get to the point where we can share some of those. Anything else you want to add? Let's dig into it. Okay, very cool. Yeah, he sent me a very long bio, and we kind of cut it to what was on the slide. I figured he could tell us about all of that. But please contact Craig if you want more information about database administration. DB2, he's the guy to go to. So the first thing that we're going to do is we're going to talk about best practices in general. And are they necessary? We're going to define the practice of data administration, database administration, and then talk about what's the value of doing those things. Just real quickly, I'll kind of start is that this is where I start with most of the organizations that I work with. We define best practices, and you can do that relatively quickly around data governance, around data administration. And data governance. And my suggestion is, if everybody has read the book, or knows of the book by Stephen Covey, the seven habits of highly effective people, well, one of those is begin with the end in mind. So I always suggest that we start with the end in mind. We define the best practices, which really kind of define the behavior of the organization. Data administration includes everything associated with the definition, production, and usage of data. So I'm certain that in database administration, there's data modeling, and there's physical database modeling and things like that. And there's some crossover between the two, but really data administration encompasses everything that has to do with the management of data as an asset in our organization. And as I mentioned before, the value of a best practice assessment is that you at least set a target. Instead of doing the ready fire aim approach, we take a ready aim fire approach, and we know what it is that we're trying to address, at least as far as best practice is concerned. Craig, do you agree with those perspectives, or what are your thoughts about that? Yeah, yeah, a lot of good points there, Bob. I think the term best practices is always one that I think is one of those industry buzzwords. And what it means is great, but the actual term, I've always cringed a bit at, like best practices or best of greed tools. I mean, they seem to be a bit boastful. How can you ever really prove that something is best? But that's just niggling at a term. As IT professionals, we're practitioners in the discipline of information technology, and if we're going to engage in any practices, they might as well be the best, right? But getting down to exactly what that means, that can be the fly in the ointment. So what I guess what I'm trying to say is that DBAs need to have good, repeatable processes, and that they can deliver the needs that the business has in terms of administering and managing databases and systems. So yeah, best practices, obviously, they're necessary. And then you're defying database administration. That's something that I took a whole book to do, so I'm not going to read my book to you. But basically, every organization that manages data using a DBMS is going to have to have some kind of an administration group to make sure that the database system itself is used effectively and deploying databases effectively, and that you're writing applications against it appropriately, efficiently, and effectively. So the DBA is basically oftentimes treated as some kind of a technical guru, and they have all these tricks to make databases and systems operate efficiently. But really, those tricks, you go back to it, they're kind of the best practices laid out in terms of processes and scripts that the DBA uses when issues arise. So it kind of goes back to best practices. So what is database administration? I developed kind of an elevator pitch. Someone asked, hey, what's a DBA? I use a simple mnemonic device to help. And I say a database administrator practices keeping the company's databases up to par, where par is an acronym for performance, administration, and recoverability. So the performance of the SQL, the performance of the database structures, the performance of the system software. Then there's the administration, which I guess kind of is in the word database administration, and you're defining the term by another word in the term, and I know you hate that, Bob, but it works for my acronym, so we'll leave it to you. And that's things like design, modeling, change management, data integrity, data movement, and the like. And then finally, there's recoverability. And that makes sure that the database is properly backed up so that it can be available in case you have issues and that you meet your recovery time objectives. I'm guessing that we're just real quickly, just to interject real quickly, as I usually do. I would expect that you would require governance around the performance, around the administration, and especially around the recoverability. Absolutely. And I guess that kind of leads into the next slide, right? Okay, yeah. Let's just go there. Good question, right? Really, that's great. It does. And so when we're talking about best practice, we want to talk about what would be a criteria for best practice. And you know what? I didn't really mean to shut you off or cut you off, but you mentioned that the term best practice makes you cringe or makes you at least think about what is truly best practice. And so maybe it's just that we need to define practices that we can then compare against. Because again, the whole idea, the way that I use best practices is to define that behavior that we want to assess. Would you agree to that? Yeah, absolutely. I mean, when you're talking about, I guess the previous slide, we were talking about how you assess best practices, I kind of have three parts of it. I think the second one, you'll like the best. It has to be goal directed. You can match up with your organization's goal. It has to be minimally invasive. I don't go so far as to say noninvasive. But minimally invasive. And it has to be capable of being evaluated. So you have to be able to have some kind of measurement around to make sure that the practice is actually achieving the goal that is the first part of the three. So goal directed minimally invasive and evaluation capable. Yeah, you know that I would love the minimally invasive part of it because I've heard noninvasive, nonobtrusive, nonintrusive, I've heard it call it everything and another thing as well. The goal directed, those are the things that I really want to get to when we're talking about the criteria of determining whether or not something is best practice. So you said that it needs to have a goal directed. It has to be minimally invasive. And it has to be able to be evaluated. And I think that makes a lot of sense. That really kind of compares to the smart acronym. I don't remember exactly what all the letters of the word smart is. It's a good way to remember things the far way as well. You know, when I go and I try to determine something, if something is best practice around data governance, I use two criteria. And so you use three and I think even the combination of the two would be something that would be valuable to somebody. But the first best practice criteria that I use is that it has to be practical and doable because if we can't achieve it, and I mean maybe that's something that's just understood. But I asked the question, I said, you know, if it's practical and doable, and is it going to add value to the organization? You know, we've got to be able to answer the question. You've got to be able to answer the question, yes. That's the best practice statement. It has to be practical. It has to be doable. It has to add value. But then I also say that if we don't achieve practice, are we putting our program at risk? And the answer again needs to be yes. So we want to make certain that we're not labeling everything a best practice because everything is a practice. But the things that are really best practice or whatever adjective you want to use to describe the best practice, whether it's best or it's corporate practice or whatever it is, in order to limit it to the ones that are most important to the organization, I say that we're going to be at risk if we don't achieve the best practice. Is the same thing true for database practices? Yeah, I think so. I think you make a lot of good points there. I want to back up a little bit to the term governance here. And I understand data governance is an important criteria for organizations. And data governance is required in order for DBAs to do their job appropriately. But then on the slide you kind of couch it in database administration governance. And that term governance is not something that's going to readily register with a DBA. That doesn't mean it isn't applicable and doesn't make sense. It's just that that's not a term the DBAs use. I mean, I looked up the term governance to try to make this point. And Miriam Webster says it's to control, direct, or strongly influence the actions and conduct of. And that makes sense. And so, you know, DBA governance, I guess, if you're going to create it, is the formal control and the exertion of practices that surround the maintenance and health of database systems. So, yeah, DBA governance makes sense. But getting back to what I said right at the beginning here of this slide, excuse me, in order for database administration to be done appropriately, data governance is required. Because for the DBA to be able to do that job appropriately, the output of data governance has to become the input to the service level agreements and recovery time objectives on which the DBAs have to base their decisions for best practices. In other words, if I don't know what this data is, how am I going to be able to accurately determine what the performance should be to it, what its availability should be, and when it goes down, how rapidly the organization needs it to be recovered. So, there's an interplay between data governance and, I guess, what we're calling database administration governance, if you will. Yeah, okay, so you know what, I'd like to kind of switch that around a little bit. So, I understand completely, and I think that's a really good point that you made about database administration and then adding governance to it. I think the same thing is true, that in order for database administration to be successful, that you have to have the governance. But I would say that the opposite holds true as well, that in order for governance to be successful, we have to have darned good database administration. And when you said that the definition I use for governance is the execution and enforcement of authority over the management of data, well, you don't really necessarily need to execute and enforce authority over the DBAs if they do their job. So, the governance of a DBA would be the governance of pretty much any other position as well. I mean, I would think that in that way, that would apply that way. Interesting. Yeah, and the way I always look at it, I guess, is coming from data governance down to DBA, but it can, I guess, make its way the other direction as you're saying. One of the things that DBAs do, I think, is institute policies around physical data implementations that match the organization's data governance policies on the data stored in those databases. So, if you have regulatory issues around the data and that requires auditing, the DBAs have to implement that audit infrastructure in the database system or with third-party tools. And the DBAs are going to be the experts at how that happens, but they can't figure out which tables in which databases require which level of auditing. That has to come from the business. That has to come from the data governance area. And it's kind of that way across the board. There are strong things that DBAs need to do to exert control over the database infrastructure, security policies, that BDA and PAR, part of the administration aspect. The security of who can access what data and how. Sure, the DBAs need to be able to know how to do that and implement it appropriately so that intrusion doesn't happen into the data and you don't have data breaches. But in order to put the right levels of control on the data and make sure the right people are seeing it and not the wrong ones, you have to have that business perspective that only data governance can give to you. Yeah, you know what? They're very tightly related. They're different disciplines, typically, by professional, I would think. And I see it that way in most organizations, but they're so tightly connected. I know that an organization I'm working with now has said, well, we're not going to let people go directly to the DBAs, or we're going to instruct the DBAs to return a request to the data administrators, again, just to kind of govern the relationship between the DBAs and the DAs. Yeah, I think that's probably a good process to instate. You know, one of the things that I see as I go into shops and do DBA health checks and database administration-type things is many times there is no formal DA, and the DBA winds up having to do some part of this and they do it half-assed because they already have a full-time job. They need someone who has more of that business perspective. So, yeah, the DBA needs this input, but you can't rely on the DBA to be the person who is the data architect of the data and the meaning of the data itself. They need to understand it, but they're not necessarily the ones who are going to be able to solicit that information from the business. So, a strong DA is needed, and if you have that, then DBA is going to be better. Right, I agree. I think it's good. I think we can talk about the criteria and about the best practices easily for the hour. I want to get to the additional subjects. I just wanted to hear before we jumped into those, and we've still got a bunch of time left, I'll talk about some specific best practice in the data governance. And so, when I get to asking you to speak about the database administration governance best practices, let's just drop the governance right now, and maybe you can share or think about what would be some database administration best practice examples to share. But the data governance best practice examples that I want to share, and I use these repeatedly in organizations, and they are more around just the management of data as an asset rather than the actual physical management of the database asset. But the first one, and remember the two criteria that I used, and we'll also use the performance administration and recoverability against these, but I don't know if it makes as much sense against the data governance best practices. Maybe it makes more sense against the database administration best practices. But the first one is, there's a high level of senior management support, sponsorship, and understanding. And oftentimes I'll even underline the word understanding because that to me seems to be the most important out of that best practice. You need to have their support. You need to have their sponsorship. They can't really even give you the word sponsorship unless they understand the activities of the governance program. And so, is it practical and doable? Well, I guess that's up to you, the listener out there in webinar land. I mean, do you have a high level of senior management support and sponsorship? And do they understand what the heck it is you're doing, how you're going to go about it, what it's going to take in order to do it? Are you going to be at risk if you don't have that support, sponsorship, and understanding? I would say without a doubt you're going to be at risk at some point because somebody's going to be asked to do something that they don't understand where the request is coming from. They don't understand why they should prioritize their time that way. So that's a best practice. And to be honest with you, that's the one that I seem to be used 100% of the time. The second one is written in different ways with a team of cross-departmental resources. Basically, the second best practice is that somebody has to have the responsibility for data governance. So if somebody doesn't have the responsibility, first of all, is it practical and doable? Well, sure. If you can have somebody that's given the responsibility for the program. But the question is, how much time do they really have? And you need to have somebody in the organization that has the responsibility, has the time to manage the program. Without it, you're going to be at risk because nothing's going to get done. It just seems to be common sense. The third one kind of aligns up with when you talked about being able to evaluate, Craig, you talked about the measurements. And I say that it's best practice that we define the measurements of success of the program that we define those and we communicate those with people. Is it practical and doable to do that? Yes, it's practical. Are we going to be at risk if we're not going to be able to measure success? And I would say, without a doubt, we would be at risk if we don't define how we're going to measure the program in the last one. I mean, it's a laundry list of items, the goals, scopes, objectives, roles, metrics, rules of engagement, you know, the team, those things are well-defined and communicated. I mean, to me, is it easy to do that? Well, you can do it by reading a book. You can do it by reading my book. You can do it by reading Craig's book. You can do it by reading somebody else's book. But the fact is that you need to do it. Somebody has to have the responsibility for doing that. And if you don't do that, are you going to be at risk? Yes, because somebody at some point in time is going to want to know what the goals of your governance program are, or what the objectives or what the scope are. So when we talk about data-based administration, Craig, what would you consider to be best practice around data-based administration? You know, kind of like, you can even leave the governance word out of it if you'd like. Sure, okay. And thanks. And I just want to say that I agree with everything you just said, except that you can get it by reading someone else's book. Just kidding, just kidding. Thank you, Ray. You're talking about somebody else's other than mine, right? Go ahead. I'm sorry. Yeah. What happened? The understanding part, yeah, that is definitely part of it. And I'm always, there's like this old story that DBA is like to tell where someone, they hired a consultant and went to the CIO and was reporting the results of what the consultant's job was there. And the CIO said, well, yeah, I know we have Oracle here and that we need a DBA, but please don't tell me I need another one. I don't know what they do and they cost too much already. Unfortunately, yeah, that's kind of like the standard out there. Now, when you talk about responsibility, that's understood. So that's good with database administration. Most organizations realize, I've got this enterprise DBMS. I need a DBA or a DBA group to make sure this thing runs appropriately. Now, it's not across the board. There's this thing known as the accidental DBA. And that's mostly in a SQL server world where someone rolls in a SQL server. They didn't plan for a DBA. The person who used SQL server the most becomes the accidental DBA. And that's not a good thing to have happen because then you have to go back and get the understanding and take the responsibility and that becomes an issue. But in terms of best practices, and there's all kinds of different things that you can do, and I don't want to dive down into the weeds and talk about, well, you reorg this database when this happens and there's all kinds of that stuff. But at a high level, it all comes down to service level agreements. Now, depending on the practice at hand, that service level agreement, it can focus on availability. It can focus on performance. Or it can focus on both. And it's vitally important for service level agreements to be created between the DBA group and the business unit that's going to pay for it. And in order to be successful, a service level agreement has to have certain things around it. There's got to be agreement between business and the technicians that what you're trying to do can be accomplished. So you don't want the business users to say, every transaction has to run in microsecond response time. I don't care what I'm requesting. That's ridiculous. You've got to sit down, transaction by transaction in some cases, or groups of transactions. Groups of programs, groups of applications, and figure out what the response time is for that application, group, or transaction. The second part of it is you've got to have cost. You have to say, this is what I'm willing to pay as the business unit to get that service level. And if after researching the technology and the requirement, that's not possible at that price negotiation begins, compromise happens, and that's where you have to go back to, I think, what you have on this slide, senior level management. And hopefully you have reasonable senior level management who understands that you can't give 24x7 round the clock sub-second response time to every application at a cost of pennies, right? So the service level agreements need to be in place. Something like 99.5% of the service level agreements 99.9% uptime during the hours of 9 a.m. to 10 p.m. on weekdays at a price of X or availability. Average response time for transactions will be two seconds or less for workloads of 500 or fewer users. However you write it, whatever the requirements are for the business, then there has to be that cost perspective to it as well. It basically, if you have service levels written appropriately, I also use the term recovery time objectives, which is basically a service level for recovery. If you have these things written and agreed to and practical and well thought out, then performance management and availability becomes predictable, and you'd be able to manage the expectations of everybody involved. If you don't have predefined and agreed upon service level agreements, there's no way the DBA or the end users could know whether or not any of your applications are performing adequately. So whoever calls up and complains the loudest gets the attention instead of being able to look at the service level agreement and look at the statistics in your measurement tool, your performance monitors, what have you, and say we're servicing to the service level, and maybe you're not happy and you need to change the service level, but there's nothing I'm going to spend my time on now to fix a problem that isn't there other than in your mind, go back and renegotiate the service level agreement. Unfortunately, a lot of organizations don't have service level agreements. Well, and you know what, I mean, and so I wish this webinar could go on a lot longer than an hour, and it can't, so we need to really move into the next subjects, but one question I would have, and I guess we really don't have time to answer it, is how could we apply SLA to the field of data governance, and can we create, so we're not really performing the same type of service as data governance as we are DVAs, but if somebody wants to throw a question in there, that'll be great. We'll try to address that a little bit later on. We've got a couple more questions that we want to get to, and we want to leave time for some questions. It looks like there are some questions coming in, but certainly that's the thought is I really like the idea of the service level agreement, and if there's a way to be able to add that to data governance, you know, can we provide a service that is going to be measurable and that there's a cost associated with, it's just a good thought, and it sounds like that's really a very important database administration best practice. There's a cost associated with a certain level of performance, and it's creating information, Craig, so thanks for about that. The second thing I wanted, or next thing I wanted to talk about is, well, all right, so let's say we've defined these best practices, and I think we've come to an agreement, kind of, that the data administration best practices or data governance best practices may be different than database best practices. But one of the things that I typically suggest to organizations is once you have the best practice defined for data governance, we take these six steps, and these six steps are pretty common sense if you think about it. First thing you need to do is you need to be able to define the best practice. The next thing you need to be able to do is compare your present situation to that best practice. And, you know, some organizations can do that themselves. Some organizations need to reach to the outside. I heavily suggest that you reach to the outside. In fact, if you need a name of somebody, we could have to give that to you. But really, you need to do that in comparison of your present practices to these best practices. And then, during that comparison, there's really a couple things that you need to do. You need to identify what exists in your organization that we can leverage and that we can take advantage of to support that best practice. And let's articulate that to the organization that we're already doing these things. And again, the idea, and I talk about non-invasive data governance quite a bit, is to stay as non-invasive as you can. Let's find things that we're already doing and let's maybe not take credit for them, but let's say we can leverage those types of things to achieve the best practice. And then there's going to be some things that you're doing that you're just not happy with that you need to change. And I call them, instead of calling them the negative, things that I said, they're opportunities to improve. So again, it's the way that you articulate them to your organization. So you've compared yourself to this thing that you call the best practice. You've said that we can take advantage of these things. We need to address these things in order for the program to really start in earnest and start moving forward. It's a good idea to articulate the gap between where your present practice is and the best practice. And if you can associate risk to that gap even better. And then I would suggest that those two are kind of connected at the hip. When you have found a gap between what you're doing and what you say you want to be doing from a best practice perspective, identify the risk associated with that, and then use all of that information to deliver your plan. So you really, I said without that, without having the best practice to find and without assessing yourself to that best practice, you're not going to do this even coming thing. You're not going to do the begin with the end in mind. You're going to do the ready fire aim. And your likelihood of delivering a successful program becomes very difficult. So Craig, if you could in a couple of minutes share with me what would, once you've defined your database administration practices, what do you do with those? Are there ways to, how do you make certain that those practices are being followed? Interesting. Yeah, I think that once you're defining best practices, if we dig down into the weeds, DBAs have their whole bags of tricks. It's like, I do this when the database is exhibiting signs that I need to reorganization. I've got a query. I add an index. So there's all these things that DBAs do when there are problems. The issue I think more for DBAs becomes the lack of planning of the organization in terms of being proactive. So there's all these things we do reactively. Someone calls up, there's a problem. And that's when the DBA goes into best practice mode. How do I resolve this problem? How did I do it in the past? Take this script off the shelf, move it and do it. And this is why I go back again to the service level agreements. If you're in proactive mode, you've got the service level agreements and you know what you need to be doing from a best practice perspective. Now, as I mentioned, a lot of organizations don't do this. And I talk to a lot of different companies as part of my consulting practice. A lot of times they ask me, come in and do a health check of our environment. First thing I always ask them is show me your SLAs. And maybe it would shock you, maybe it wouldn't. I don't know. Usually I get a blank look. What? And then I talk about why service level agreements are required and how I really can't come in and say, what's your health like? Other than at a generic level, I can look at system parameters and things. Not why you did that wrong. You did that wrong. Kind of look at that. But not, are you meeting your objectives? Because you don't have any. So a lot of times it's like whoever is calling you, that's who you spend attention on. And I call that the YBWJ methodology. And that stands for, you bitch, we jump. And that's not the way to run a DBA group. Unfortunately, most of them run that way. So if there was one thing that I could really instill to the attendees here who work with DBAs, are DBAs, manage DBA groups, is to put the focus on service level management, create service level agreements, create recovery time objectives, and have your DBAs manage to that. And then you will be goal-oriented, minimally invasive, and I guess we'll talk about measurement on the next slide, right? Yeah, you know what? I've never had the problem of having an R-rated webinar before, but it's good. I like your acronym of YBWJ, because it seems as though that's repeated within organizations, that that's the way the DBAs are in responsive mode all the time. And again, if there's a way to be able to bring SLAs into the data governance world, because I've seen organizations from a data governance perspective that kind of act the same way, the only time that they think data governance needs to get involved is when there's a problem that we need to address. So the DAs jump into the YBWJ mode, and they help to resolve the issue. And if we can take a more proactive stance, that's not thinking that SLAs may be something to consider to add to the data governance best practices that I mentioned earlier, because we want to improve things in general. And you're improving your performance, improving people's ability to analyze the data, improving people's ability to be able to make decisions. But I think that's really great. I think the things that you said, and again, taking it back to the SLAs are important. And yeah, I would think that if you ask questions, that there are some organizations that have SLAs, but not all. So it's something that organizations should consider. So we're going to address one more issue here, and then we're going to open the door for some questions. There's a bunch of questions that have come, and I'd like them to be directed to you as well. So once we've defined these best practices around data administration, around data-based administration, we've got to find a way of being able to measure, I guess the SLAs would be a great example of something that you could measure against. In fact, you're measuring against it 100% of the time. So that would be, I'm guessing that you're going to kind of jump back to that in your response. You know, what I suggest, and I'm talking to you, Craig, the ways to measure the results of governance is, there's a couple different ways. One is through strict business value. Another one is through the acceptance of data governance into the organization. So a lot of times it's a change of culture. I talked to an organization today where they're talking about going through a major cultural shift because they want to manage data as a valuable asset of the organization. Well, we need to be able to demonstrate some measurable sign of value to us doing that. But we also want to be able to say, okay, we've educated 10% of the people in the organization, 20%, 30%. We want to be able to recognize that we haven't gotten to everybody yet, and we want to make sure that we do get to everybody. You know, I talked earlier about a future webinar being that everybody is a data steward and that people need to deal with it. Well, the fact is that everybody in the organization that has a relationship to the data should be held accountable for that relationship to the data. To me, that's the basis of non-invasive data governance. So if we're going to expect to hold them to being accountable for their relationship to the data, we need to educate them on the impact that they have on that information across the organization. So it's not just the business value. That's very important. We need to be able to measure what governance is doing for us. But we also need to be able to define for our organizations what the acceptance of governance in the organization. I added to these ways to measure. I added the quality of the data, the protection of the data. Those are certainly things that you need to be able to measure. I mean, you need to be able to be able to measure the quality of your data. You need to define a standard for your data. Have something to compare it to. So if you're going to compare what's right to what's wrong, you've got to know a clear definition of what's right. And that's really creating a standard around the quality of the data. And again, in the fact I spoke to these folks earlier today, that they want to focus on protecting the data. There's not a choice. The government's not coming to you and saying that you, you know, protect the data if you want. Or they're not putting regulatory and compliance controls and classification rules and things like that. He is saying, you know, comply if you want. They're telling you that you have to. So being able to measure your level of compliance, measure your level of protection. Hey, if you've all, if you've never been breached and you're reporting 100% all the time, then you can just make sure that you're measuring it accurately and continue to report 100%. But if you've had breaches in the past, you can measure against that now. You can say, well, you know, we've had these, you know, we've had these occurrences. We can, you know, protect our data a little bit better. So from a data governance perspective, in my opinion, it seems very important that we, you know, define these ways of measuring the results, but don't just limit it to business value. Take it beyond business value because that's difficult to define. I'm not meaning to steer away from it because it's difficult, but it's difficult to be able to articulate in dollars and cents. I've seen clients try to do that where they say, you know, we or return to mail cost our organization X number of dollars. So if we govern the data around the addresses, we can save X number of dollars. Well, that's great, but I think you also need to measure the acceptance of data governance. I would think that would be somewhat different when it comes to database administration, though, right? So how do you measure the performance of a DBA, I guess, or maybe just database administration in general? Yeah, that's a loaded question. And I think you can talk about measuring the performance of the database environment. And again, you were spot on. I'm going to go back to SLAs a bit. You know, when you have them, then DBAs can adjust resources and apply them to the most important critical applications and costs get controlled. Capital is expended on the pieces of the business that are going to be the most important to the business, and that can be measured at a business level. There are several other ways you can measure it, you know, with service level agreements, recovery time objectives that match business goals, then there's less of this hair on fire problem solving mess and more of DBAs and management discipline. So the phone should ring less. There should be fewer tickets raised in the help desk system. And these are things that can be measured. Now, how do you measure against the SLAs? Well, then you either need to use the components of the DBMS that allow you to do that if they're there. And if not, you need to augment your environment with performance monitoring and management solutions. And there are a slew of companies out there that will help you do that with recovery tools that can speed up your backup, speed up your recovery, perform different types of recovery. So these tools are there that can, number one, help you to meet the goals. Number two, measure that the goals are being met so that when you get the person following YBWJ complaining, you have the measurement in your monitor that says, no, we are actually managing to the service level and if it's a problem, the service level has to change. So basically, if you get the tools in place, the service level agreements and the recovery time objectives instituted appropriately and correctly, then you've got to better manage database infrastructure. There are fewer problems. It's going to cost less. And these are things that reflect on the bottom line. And in general, a less stressful environment. And who wouldn't want that? My people have told me my hair is on fire all the time. So I got used to that growing up. That acronym that you shared earlier really made a lot of sense. I mean, to me, you want to be able to measure your environment. It could almost, in a large organization, at least from what you're saying, it sounds like it could almost be turnover and DBAs. It could be an indication of the fact that they don't want to live in this YBWJ environment, hair on fire environment where they're always running after the fire truck. So to me, it seems to make sense that there's things around the database administrator's performance, but then also even just keeping them around, because DBAs are really hard to find. And they're very valuable to organizations. If you don't create an environment where there's improvement and there's really best practice around data and data management and they're always chasing their tails, you're going to lose your DBAs. Would you agree with that? Yeah, yeah, I would. It's funny. Sometimes people who've known me for a long time ask me, what are you doing for a living now? And they say, remember what I used to do? Now I talk about it. And that's basically... The phone doesn't ring at 2 o'clock in the morning when you're talking about it. So that is one of the things that made me not want to be a 50-plus-year-old DBA waking up at 2 in the morning to solve problems. Hey, if you're telling people you're age, and I already told them earlier that we graduated at the same year, then you're giving my age away too. Please don't do that. All right, so we're at 2.47. You're not fooling anyone. And we've only got... Go ahead. What did you say? I just said, you're not fooling anyone. So we're coming to the end of the webinar. We've got 13 minutes left and Shin and I... I'm getting ready to turn it over to you as far as the Q&A is concerned. I see that there's been a lot of good questions. Just real quickly, I wanted to wrap up, and thank you for taking the time to attend the webinar. I mean, it's been really interesting. I've enjoyed the kind of conversational perspective. If you like that, please let us know that that's cool too, because it's always interesting to throw a curveball at these real-world data governance webinars and keep them interesting for you. So we talked about the criteria for determining what's best practice. Craig shared the par. I shared the... I don't think I have an acronym for it, but it has to be practical and doable, and it has to follow best practice. Or it has to be... You'll be at risk if you don't achieve it. We talked about evaluating your organization against the best practice and the process for that, how to maximize the value of an assessment, steps to take after completing the best practice, and then finally, really, the measuring the results of your best practice approach. So with that, besides for thanking Craig again, I'd like to turn it over to Shannon and see if we have any questions. We certainly do, and you know one of the most common questions that we receive is people asking if they're going to get a copy of the slides in a recording. And just a reminder, I will send a follow-up email by end of day Monday for this particular webinar with links to the slides, the recording, and any good other information requested throughout the webinar. So let me get to the questions here. So go ahead and feed the slides back to the criteria outline. Should all three criteria be answered yes before considering something as a best practice? Is that a question? That's a question for Craig, because I listed two criteria. So Craig, why don't you take a swing at that from a database perspective? Sure. Yeah, I think the three criteria he's talking about is that it should be goal-directed, it should be minimally invasive, and it should be capable of being evaluated. I think for the best best practice, all three should be yes. I think number one and number three are almost have to be yes, and number two, I think depends on, as a consultant, you have to say it depends, right? It's going to depend on how much you're willing to change your organization, because if it's not minimally invasive, that means it's somewhat invasive or very invasive. So in order to institute the best practice, you have to be willing to break down the organization and institute the new best practice, and you have to be willing to spend money, because when something is invasive, it necessarily is going to involve work in order to get it implemented. So if number two of those three is not a resounding yes, then there's more work to be done, but that doesn't mean that it's not potential to implement as a best practice. I'm really glad you say that, because the minimally invasive, I mean, when I talk about noninvasive, the idea is to stay as noninvasive as you can, but if there's a period where it has to be invasive, then you've got to be invasive, because some of the things just have to be done, and I would think that would hold true from the DVA perspective as well. Absolutely. All right, Shannon. Are there any of you familiar with the CMMI data maturity model framework, and if so, how does that fit into all of this? I'm sorry, can you say that again real quickly? I'm sorry. Are there any of you familiar with the data maturity model framework, and if so, how does that fit into all of this? All right, so I'll touch on it, Craig, real quickly. Yeah, I'm familiar with it if you're talking about the CMMI, the capability maturity model institutes, DMM that they just produced. How does that fit into all of this? Well, database administration is certainly a part of managing your data assets, so when it comes to data management maturity, if you don't have strong DVA, then you're not going to achieve well in the data management maturity model. It's related, and I think that if you don't have strong data administration, it's going to be very hard to have successful database administration, so it's all tied together. I think that the framework is not just taking kind of one step backward, but it's taking, I don't mean backward, but taking one step higher. It's even actually a couple steps higher where you're looking at the overall framework of the maturity of an organization to be able to manage its data. Craig, you haven't thought on that? Yeah, I mean, I'm familiar with capability maturity models. I haven't seen the data one, I think way back in the 90s, when I was a gardener, I took a short stab at trying to come up with something that would be data focused, but the problem I've always had with what I saw, and again, I'm commenting on something I haven't seen. So I think that, as you said, it's several layers up, so I think it's kind of subjective, and you wind up with things like, is this an organization that's very mature and not very mature? What are all of the criteria that go into that so that you can grade it appropriately? And I haven't seen any of these capability maturity models that really dive down into the weeds to give what then could be a mark that gets translated into, are we mature or immature? But then maybe that's just my DBA perspective, where I really want everything laid out in zeros and bits and bytes. Hey, I remember seeing your data management maturity model back in the old TDAN days. Or TDAN, I actually had published it on TDAN, but it's great. So it's the same people that created the CMM, who created the DMM around Carnegie Mellon and the Software Engineering Institute, but it's now its own institute. And it's good. If people want to take a look at it, it's a comparable framework to things like the demo one and the EDM model, Enterprise Data Model or Enterprise Data Management Model. They all have frameworks, but I think they all include database administration and they all include data administration as well. I love it. I love that you guys are familiar with that. And we certainly have some webinars on the DMM. So for more information there, so the next question is should data governance be an independent department group of its own or should it be part of the IT departments such as with DBA groups? That's one of the age-old questions and I get that question often at different organizations. And my answer to the question is usually yes. It needs to exist somewhere. It doesn't necessarily have to exist in... I mean, a lot of people will tell you that it should reside in the business area and there are some people that don't even go as far as saying that if you have it in IT, it will not be successful. I'm not one of the people that say that. I say that as long as there is an alignment and there's a relationship, a strong working relationship, a partnership, so to speak, between IT and business, your data governance needs to reside somewhere. Oftentimes it may fall under the chief data officer, the chief risk officer, the chief information officer if they're really playing the role of a chief data officer. Craig, do you have any opinion as to where data governance should reside in an organization? Yeah, I guess. I think that my bias would be that if it is in the business, there is generally a greater chance for it really to have authority. If it's just in... And again, it depends on organizations and I'm sure you've seen organizations where it's in IT and it's work. And I'm not saying you can't, but I just think that the business which controls the purse strings, usually IT is a cost center, whereas businesses earn money for the organization and contribute to the bottom line. And if those organizations that contribute to the bottom line buy off, the data governance is important in something you're going to do as an organization, I think that gives it a little bit more cloud than if it's in IT. And I've worked at organizations and this was before the term data governance was anything, but there was data administration and the first time they needed to lay people off, it was the poor DA's that got it and I think that was a backward decision and that they were in IT. And I think the agreement is that it needs to exist somewhere. Yeah. And it really depends on the organization and IT. I just won't rule out IT as a possible place to have it. It really depends on the relationship with the business folks. So far as no outside evaluation or validation has been mentioned, when is that necessary to properly scrutinize the effectiveness of the program? Well, what I've heard is that oftentimes people within the organization are wrong in certain areas, but they're not listened to. And so there are some organizations that they require going to the outside and having an outside consultant tell them that they're not good at this because an inside person telling them that they're not good at this is not enough. So if you pay, we pay good money to hire a consultant to tell us that we're not good at this and then that's going to resonate with people and so be it. But if you have the strength and you can articulate it and you have somebody who has the responsibility for this and they're being listened to, then it's not necessarily absolutely necessary to go to the outside. It's good to maybe validate that against somebody from the outside, but the fact is that if you're able to do it yourself, more power to you. It makes a lot of sense. But oftentimes the person from the outside has a lot of expectations that you may not be considering internally within your organization or that you may have not experienced with other organizations. Craig, you agree that is the same hold true from the database administration that the consultants come in? Is there a need for outside evaluation or is internal evaluation necessary? That's always necessary. Yeah, I agree that it depends. The first thing I do after I've asked where the SLAs is I will take DVAs aside and interview them one by one asking them what do you think is wrong? What are your biggest problems? Generally that's the biggest information that I get on the consulting engagement. And a lot of times they'll tell me what they think should be done to fix it. So me, it's not always that simple, but sometimes it's sit down, listen, evaluate what they're saying if it makes sense, write it up and tell the organization do this and the DBA will be happy someone's telling them to do what they've been trying to get done anyway. So there's that to it. The other aspect of it is even when it's not that simple organizations can become very insular and do things a certain way just because they've been down a certain way from that outside perspective that a consultant can bring to the task. We've worked at multiple organizations seen things done multiple different ways seen things right, seen things long and a lot of times you don't get all of that exposure when you work only at a single company or even a couple of companies as you draw the line. Tom, I'm going to turn it back to Shannon and to wrap up. But thanks Craig. I appreciate your being a lot. I think people found this to be interesting to find it to offer the different perspective. I really appreciate your participation in this. Happy to have been here. It was enjoyable, had a lot of fun. All right. And thanks to both of you. It was a great discussion and really appreciated. And thanks as always to our attendees who are so engaged in everything we do. We love the questions coming in for the webinar. And just a reminder, you can see Bob at Enterprise Data World and in June at Data Governance and Information Quality in San Diego. If you're not registered for EDW yet, it is actually sold out. But you can order the... we'll be presenting 50 of the top videos that are available for purchase. And again, Bob and Craig, thank you so much for this great presentation and I hope everyone has a great day. All right. Thanks, Shannon.