 Hello, everyone. Welcome to one of our final conference sessions called the Data Leadership Framework Primer or Primer, depending on your preference there. This will be presented by Gene Boomer, Principal Consultant at DataThink. I can speak directly to this point. Gene was there at the very beginning of the conceptualization of this framework. He's an excellent source for us to be learning about it today. As a reminder, everyone is muted during these sessions, so please submit your questions in the Q&A window on the right of the screen, and we'll get to as many of those as possible at the end of the talk. Let's begin. Gene, thank you. Welcome. Take it away. Thank you, Tony, for the introduction. I welcome everybody who's attending the virtual version of EDW this week. I hope you've been taking advantage of the number of sessions and the great number of speakers out there. I've been sitting in on sessions throughout the week, and they've been very good. I know it's not the same as being in-person. I mean, personally, I like to be in-person. But this is better than nothing, and I think you still can gain a lot of benefits and education and things to ponder as you reflect on this week, and then go back into your organizations and try to make changes or try to move ahead or whatever it is that you're trying to do, whether it be big or small, that you're actually moving forward. Okay. As Tony mentioned, this session is on the data leadership primer. Before we get started on that, it's a little bit about me. I am a Principal Consultant at DataThink. I have plenty of years of experience, started at IT, migrated to data, been in that space for nearly 20 years, multiple disciplines, and worked in a number of different industries. I'm a founding member and current president of the Dama Indiana chapter of Dama International. That has been a very rewarding experience for me. I hold a CDMP certification at the master level, and I was a contributing author to the current release of the DIMBAC. I was contributing author to the reference semester data section. Okay. Topic of discussion. We're going to look at data management issues, data value, the actual daily framework. It's based on the book, as Tony mentioned, that data diversity put out by Anthony Elgram. I mean, here's the book. It's not a very big read, but it has a ton of information in it. We're going to go through the categories and this plans and then how you can make use of this. The first thing I'd like to focus on is the common data management issues. If you look within your own organizations or just listen to some of the speakers this week, none of this should really be news to you with regards to some of the issues that exist probably within your organization. You don't have the consistent view of X, whatever X may be. This basically has an effect on the growth and retention. You have sporadic and brittle data integration. This is pretty common. It causes what is affectionately referred to as the swivel chair integration. As multiple systems have to be accessed, basically the joke is that our unfortunate business users have to swap from system to system to get the information they need because they're actually integrating it real time by jumping from system to system. I'll say this has an effect on efficiency and productivity. Then the infamous authoritative trusted source, whatever that may look like within your organization. The idea is try to get to a trusted environment. However, what usually happens is that business users will resort to using whatever warehouse, smarts, bread mart exists and based on good feel as for where the best data resides. I have a lot of industry experience in insurance, and so the biggest area folks who do this are your actuaries. They're extremely smart folks, but a couple of problematic issues for data people is, one, for them current state is 100 years, and then two, they just want the data. They don't want you to refine it or do anything else. They want to do it and then they want to apply all the massaging. Of course, that could be problematic. You'd rather have them operate from a trusted source than allow them to apply their actuarial specific sauce to the data. Of course, this has an ultimate effect on risk and trust. Just people, process and technology. How many times have we heard of PPT? It's always about regarding people, fighting the right people at the right time, some type of delivery process. It's usually SDLC or some form of agile, and then using right technology, preferably the Cloud, that's where everything's moving now. But there's some issues with this. When you're just focused on PPT and you forget about data, and I have some quotes here, no names given of course, that I've actually heard in my career regarding data and how we need to handle that within the PPT environment. The funniest one, which I had to actually stop myself from laughing was, why haven't you stood up at Data Lake yet? Like Data Lake was the magic thing that was going to solve all of our data woes. When will, and this next one I've been asked by multiple leaders, usually all in IT. When will data governance be finished? I know some of you are snickering right now, because as we know, data governance will not ever be finished. Why does the logical data architecture not specify any technology? Usually, I get asked that by CIOs who are really CTOs, and they want to see the actual technology. You specify data virtualization, why don't you have Denoto? You're specifying integration, why don't you have Informatica? I mean, you're specifying visualization why don't you have Cognos? I mean, it's just on and on and on. That puts us in a particular awkward situation. One of the things we want to do is include it and have the PPT with the focus of data. You want to have the right data people, but the right data skills. You want to follow a data-centric development life cycle, not a SDLC or a waterfall or anything like that. Then you want to use the right technology in context of the use of the data, and that's the thing that we miss up on. I do like this quote by Steve Jobs, he's absolutely correct. Unfortunately, every organization will say they want to hire the smartest individuals. They'll get them hired, and then they won't really listen to what they have to say. I know a number of you probably have actually experienced that. But what does this mean for us moving forward? Well, we don't really want data coders, we want data provocateurs. You probably have heard that phrase quite often this week, is one of Tom Redman's phrases. He believes that we should be data provocateurs within our organizations to be able to help affect changes and provide better understanding what we need to do with data. Also, we don't deliver data, that's another misnomer, we drive outcome-based insights. I mean, that's where we need to look at this. We just don't use technology, we use for-purpose technology. The approach for technology is it could be polyglot, right? It could be I use one thing for a data stored, I use one thing for integration, I use a different thing for integrating. All depends with is the best fit that is needed for your organization. Data value. Now, you probably have heard some discussions about data value this week, and some things of what data is and what it is not. The phrase about data as the new oil is really a misnomer, and I know some of the speakers have said we should ban that kind of contentation moving forward. Because data value is actually a representation of the difference in business outcomes with the data versus without it. Now, I'm old and around for a long time, so when I started out, everything was 100% application centric, and data was just exhaust. It was just the output of the application. The application was the most important thing. We have worked very hard to kind of flip that. We're not there yet, but we are closer than we've ever been before. To get it understood that we need to be data centric, and then the apps just basically subscribe, or consume, or provide data, as opposed to be driving the use of data. And also note that it's a positive change of business, because we want to maximize, we want to have a positive change in business outcomes to maximize through leader data ship. So that's on us. We need to do that. And then, of course, if you could generate data value, it actually gives you a metric in how data leadership is actually doing within your organization. There are generally only three ways to measure data value. It's either increase of revenue, decrease cost, or manage risk. Those are the macro values, ways to measure. I know some other folks will say there's like four or five or six ways to measure data value, but at the macro level, it's really just those three. So we all have a different focus, right? We want to change the typical IT to business area relationship. This is a quote that's in the book, and I know if some of our BAs or data quality people are on the session here, they might not like that first bullet point. And I think that's to kind of to get a response. It's that business requirements are important, but they should be the end all to get all, right? Sprint and execution, obviously we wanted to iterate through a process, right? And even on the app side, Sprints, in a lot of cases, is like many versions of waterfalls or a kind of weird view of a waterfall. Weird view of a waterfall, but there is some still issues with that. Of course, we want to have elastic delivery dates. I've been asked numerous times when are we gonna be done with X? And it's always tough to say that I'm gonna be done with X exactly at this point in time. I got in the habit of doing like three or six months groupings where I said this is what was kind of imminent and what we'd be expected to deliver and then the next three or six months of what would be proposed to be delivered and then the next three or six months would be what we could predict to deliver, right? And so going through that actually helped manage the process going forward and helped our business folks understand some of that. So we want to actually look at it from the simple virtuous circle. We want to have a baseline that we measure from. We want to identify improvements and then actually implement those improvements and we just want to keep cycling through that, right? And the data center development lifecycle actually allows you to do that. So if you kind of are familiar with that particular framework, you can actually see how this kind of works with that. And we want to stop talking about working and start working, right? And we want to use the daily leadership framework as our guide. So here there's never really nothing really important on here except for a couple of Dilbert strips. The first strip here, believe it or not, of actually sat in meetings where that one has occurred. And maybe some of you have also sat in meetings where that has occurred. The one on the bottom is basically said, hey, we do all this work, now we just need to add a pinch of leadership. When a reality, we need to do all the work to help provide the understanding of what the data leadership is and how it could be effective within our organizations. Okay, so here is the data leadership framework. This prior presentation might get a little dry, so I'm gonna apologize for that now. But basically it's made up of categories and disciplines. So the items on the top are the categories and then the items on the side are basically the disciplines, right? So there's 25 disciplines across the five categories. And we'll go through each category and kind of just give a little discussion about each one of them and then kind of do a review at the end. So the first category is access, right? So enabling connection to data assets, right? And so that basically has five disciplines within that environment. Oh, one of the things I should mention too, it's a framework, right? So you don't need to have all 25 in your organization. You pick the ones that make sense for your organization because some of them just may not apply or you may not be at a right maturity level to implement them, but just know that they're there and you can make use of them. Okay, so if we're looking at access, we're basically looking at security, data architecture, data wrangling, development and support and operations, right? Data security, this is something that's kind of near and dear to me personally, the last few organizations I've worked at, I had a really good relationship with the privacy officer and the compliance officer if they are two different people, sometimes or not. And that has been a very good relationship so that we have an understand of this concept of permissible use. Data architecture, I think we all know the importance of that but it's more than just laying out the data architecture, we also have to ensure it's alignment with data governance and that the architecture based on business strategy and not IT deliverables, if that makes sense. Data wrangling, that's the naval data discovery, right? A lot of organizations and a lot of IT organizations look at data wrangling as a bad thing but really allowing data wrangling allows that initial discovery that actually helps refine the items that you actually want to make available to the whole organization. And they're gonna constantly iterate. This is where I usually had a good working relationship with the actuaries and we tried to help them understand this, that there are importance in it and how we can actually evolve this so then I'll have data assets that could be used throughout the organization. Development, basically ideas about extending data capabilities and restricting constraints and the concept of understanding for purpose technologies. Service and DevOps, although I think I might like the word data ops better here but basically is ongoing activity to measure and to handle issues, those types of things. And then also within your environment, whatever you stand up, you need to be able to eat your own dog food so you need to use what you're asking everybody else to use. I have seen in some organizations where that was not the case. And so that's kind of important from that aspect. Refine, we want to refine and optimize the data for use. Metadata, obviously very important but more so is the metadata that's, you gotta watch out what's called low data, low data value density, metadata. Technical metadata is very easy to get. There's many tools that provide that but an overwhelming amount of technical metadata is actually ends up providing low data value density. The more high value data value density, metadata is business metadata. So you need to engage your data storage in your business area, SMEs, to be able to tie their vernacular into your architecture, into your data environment. Master data goes without saying, if you can't master your data, I don't see how you could actually ever get to the point of having a trusted source, so master data will be your primary entities within your organization. Like for an insurance company, it would be customer and policy holder, and claim, and agent, producer, those types of things. Enrichment is being able to add data usually from external sources. Marketing folks usually really want to be able to make use of that and do an enrichment. And curation is the, you're trying to reduce noise and balance the weight of data asset. I've unfortunately worked for some organizations, they said, hey, we're gonna build this data hub or this data warehouse, whatever, and we'll put everything in it, right? In reality, you don't wanna do that. You only wanna put what's in there what's actually being consumed and could be used because then you spend too much time on things that might be used. It goes back to the whole philosophy. If you build it, they will come. Unfortunately, I worked at one organization where we spent five years and $25 million producing a data warehouse for a marketing area. And we ended up only having one subscriber after all that time and money. So the philosophy of building it ever come, it's just, it's a fallacy, right? So think of enrichment as adding value and think of curation as removing noise. So if you kind of keep it in that context, then I think overall you'll be better off. I think this particular area as far as setting up data value is the most important. If you don't have a handle on these particular items, it's going to be hard to produce the data value that you want to have for your organization. I've been fortunate enough to work for a number of organizations over the years, both as a employee and as a consultant. And I can tell you over time, I've come to realization that these five items here are extremely critical to be able to affect business outcomes with the data within your organization. Adopt, okay, now we want to start utilizing our data assets. So the first two categories basically kind of set you up to be able to get data value from your data assets. So these next categories are about how do we actually use that or realize that, right? So basically the disciplines in this category are data modeling and data warehousing, traditional reporting, dashboards, systems integration, and then emerging data technologies. I think most of us understand the importance of data modeling and warehousing. The impact of the cloud, quote unquote, the cloud kind of has kind of muddled to some degree some of this and I was amused by the leaders saying we need to get down to the cloud. And I know the benefits of that, right? Because the cloud basically is, a cloud is just a data center that's not on-prem, right? And because it's not on-prem, the organization doesn't have to worry about the actual underlying infrastructure. But the data architecture does not change, right? It should not change, right? You just wanna make use of the advantages that you have in the cloud to do data modeling and warehousing. Traditional reporting, right? That she's referred to as descriptive analytics. In most organizations, this really is the used the most and somewhat neglected the most, right? Because we're looking at the shiny objects, right? Which is the analytics, predictive analytics and AI and machine learning. And then we kind of forget that traditional reporting supports the data, today, operations of the organization. So, and if you don't have a good handle on this, this is what leads to the spread marks and other types of things, also leads to people getting into a meeting and they're all pointing out different numbers, whether it's different number of customers, revenue, whatever it is. So, this is an important discipline to kind of have an understanding of. Interactive dashboards and visualizations. The idea of self-service analysis, I'm very high on. Some organizations have actually done this pretty well. But the idea is that for that to work, you obviously have to have business involvement and you wanna have business partners actually as part of that effort to do that. Cause if you just try to push it out as an IT only thing, again, it's gonna, hey, I built this, will you calm? It's just like, nah, it's just gonna be problematic. If you're not keeping the, what the business does in your mind, what your organization does in your mind, when you're going through these categories of the DLF, that's gonna be problematic. I've heard some people mention, I think John Landly mentioned the fact that you should be looking at balance sheets. I've looked at balance sheets for my organizations. Go look at the K12s or K10 documents. I mean, go look at the documents that are actually put out by regulatory reason that your organization has to provide to their shareholders and to regulatory bodies. Have an understanding what that is. You also wanna speak in the nomenclature of the business, not in the nomenclature of IT. This is something I had to learn over the years. No one cared about my really fancy-dancey data model or the fact that I could actually kind of whip up this ETL workflow, snaggy workflow, whatever. Business partners don't care about that. They wanna know how's this affecting them and how does it help them affect the bottom line? So we need to speak into vernacular business. Scott Taylor has also talked about that. That's about the concept of telling stories. We need to be able to do that and effectively do that. And now some of us are not all made to be able to do that and that's okay. But within your organizations, there's gotta be someone who can speak, who can tell a good yarn as it were to be able to present to business leaders and even IT leaders, quite frankly, to be able to explain the kind of journey that we need to go on to provide the best use and value from our data assets. Systems integration, this one has done a lot. I'm sure that within your organization, especially if it's a large organization, you got literally hundreds or thousands of integration flows. The thing about system integration is you wanna be able to design and make use of that where it becomes second nature, right? So you want to, you have to monitor the integration, you have to, and those types of things, but you really wanna focus on automation. If you have to build out an integration or fix or address an issue with integration, having the abilities of automation is just gonna be so much better with regards to delivery and the actual end result. One of my things, and I say this even now with the client I'm working with, is I'm a big fan of consistency. I don't even care if you do it wrong as long as you're consistently doing wrong, but when you're doing it varied number of ways, which I've seen on the integration side, that's just a recipe for disaster. So you wanna be able to coalesce on a common approach to do that and automate as much as possible. And then you do wanna take advantage of emerging data technologies, right? Like I said, we should be looking at our data architecture as a polyglot environment. Maybe we use RDMS for an ODS, our operational data store, but then we use a graph database to actually manage networks or contacts and things like that. So the idea of just saying, well, I must do everything in this database or on this platform, we need to kind of look at that. And this was another area that took me some time to get my head wrapped around and to be able to effectively look at it. I am a big fan of graph databases to be able to handle relationships and then once to be able to quickly traverse a relationship, then once I have the node I'm looking for, then I could dive into a traditional data store sitting in our RDMS to get the kind of data that I want. But all this should be included and thought about with regards to your environment. But the point here is too, that technology represents really only a small part of the data value chain. Again, remember when we're trying to provide data, data asset value to our organization, we wanna focus on the impact of the data asset to business outcomes, not the technology we're using. And that is just so hard to kind of get your arms around sometimes, especially if you've been brought up in an environment where it's all about technology or if you're solely within an IT department because the focus is technology. Okay. I wanna let you know you've got about 10 minutes before the Q&A. Okay, thanks, Jim. Okay, impact. So now we wanna be able to measure, right? So let's say we prepared our data assets, we've been able to show value or we've been able to present them and allow consumption of them within the organization. How do we determine the impact, right? So within all your organizations, you have measurements metrics and KPIs, right? You have goals. KPIs are usually at, you'll have KPIs at the board level and then you'll have KPIs within your line of business or down to your department, et cetera, right? It's good to have KPIs. They should be distinct. There should not be many and they should be easy, quote unquote, easy to measure. But that's the only way you're gonna be able to find it if you're having an impact with the use of your data assets. Regression analysis, predictive modeling, in the past, we used to call that statistics, right? I mean, really, that's all that is, is statistics. And then, of course, you gotta be careful with that, with statistics in general, right? There's a lot of things that people will provide or stand behind that was based on faulty data. There's a quote from, I think it's Mark Twain that says there are lies, damn lies, and then there's statistics. And that is true everywhere. You can mangle a statistic to provide a narrative. And I'm not saying that could be necessarily a bad thing, but if it leads to a direct negative impact to your organization, that's not good. I've seen analysis done where the underlying foundational data was just bad. And it led to certain decisions that in the end provided no value to the organization. And in one instance, it exposed the organization to risk. So just saying, hey, we're just gonna jump in and do predictive modeling, all this nice stuff, it sounds great. But if you don't, if the data that's being used to feed that is not from a trusted source, you're not gonna be able to effectively, I think the biggest thing is manage risk in that regard. Business process automation, this is a lot of organizations are going through a cycle of trying to implement BPA. I think it's a good thing. It kind of can help with providing the decision-making processes that can be followed and have an impact. And it could actually remove some of the things that a lot of organizations use to do BPA, which is usually excess database and spreadsheets, which I've seen in the past. And then we want to be able to, we wanna be able to support these as data-driven processes. Data monetization, right? So some of the speakers, including the keynotes, I think Doug Laney talked to this, maybe even John Lively did, but to get values, like how you get value, how do you monetize your data, right? Now, some organizations actually make money author data because they sell it. Nielsen is one I can think of. And the insurance side, there's Verisk, which basically provides data to help us, data and processes to help insurers meet your obligations with state regulators. But you're not looking for just that. We wanna look for data monetization within your organization. Like again, how does it impact the bottom line? Eventually, somewhere down the road, a data asset will materialize on a balance sheet outside of it just being goodwill. Some organizations have been able to actually show data value, the data asset value on their balance sheets. And I think over time, we'll continue to see that organizations will be able to understand and provide some kind of number to that. So we need to keep that in mind as well. Okay, Align. Now, the Align category is kind of like, not like part of the virtual circle, but this is just like the ongoing care and feeding, right? You need to have standards and policies, right? We all know that. Proper PMO in project management, we need to have that. Marketing and communications, this is one that we need to work heavily on in our data community. Scott Taylor is an excellent resource regarding this particular area about telling data stories. We gotta get better at telling data stories so that we can effectively educate our organization and help understand what they need. One of the things that I used to hear is that, well, the business doesn't know what they need, so we have to give it to them. And it's like, no, my experience over the years just told me the business knows exactly what they need. They just have a very tough time communicating it, right? Because it's almost like we're talking two different languages, like we're talking German and French at the same time. I mean, that's really how it appears to me. And so we need to learn to talk in the vernacular of the business. And I think marketing can help with that so that we can actually provide what we're trying to do and then we can give feedback from them. Course training and building a operational excellence culture is important, right? And we need to, this is one of my things too, any organization where I actually had a team, I was really big on training and education because I had a boss who told me one time, he goes, if you ever get to the point, you leave the organization and one day you will. I wanna make sure you're the best prepared when you go to that organization because if you're not, then I failed at my job. So ever since that particular point of time in my career whenever I had the opportunity to lead a team, I was very, I stressed the importance of education and training, even if I know somebody was going to leave, right? It's just the right thing to do and it helps provide a atmosphere that helps move you on this journey. And of course, regulatory compliance, if you're into a regulated industry, you know the importance of that and how many issues you get. Now, like I said, my experience with insurance companies, once I started dealing with privacy officers and compliance officers, I had such a better understanding of the concerns of the organization and a better understanding of how to manage risk. Okay, so the recap. Remember, this is a framework. It's not a prescriptive tool. It's not something you take and you lay down in front of somebody and say, we must do these. No, you look at what makes sense for your organizations either from a skill set or maturity or kind of what you wanna do. And some of these things you can move, the disciplines could actually move around because remember, it's a framework. And remember, if you have a good understanding of what these disciplines are, that will provide you the most impact that you could potentially provide to your organization, which is what we wanna do at the end of the day, right? We wanna help our organizations go forth. Thoughts to ponder. Okay, again, remember, it's a framework. You need to understand your organization, your industry and you also need to understand the business strategy, right? There are some talks about that. You know, you can have a business strategy, data strategy and IT strategy. You need to start a business strategy that should feed both your IT strategy and data strategy, which are two separate things. You wanna balance the categories and disciplines based on your organization. You wanna continue to develop your leadership and drive data value. You wanna combine it with other frameworks, right? The DIMBOK wheel. The DIMBOK is another framework, basically the primary data disciplines. If you're not familiar with that, please get familiar with it. And another one of my things is, I truly tried to live to this Albert Einstein quote, is, I have seen people twist themselves in the pretzels. In the pretzels, they try to take care of a one in one million thing that will happen. And it's like, why? So you wanna make everything as simple as possible, but no simpler. So, but also gets an understanding of minimal viable product and things like that. And that, you know, you don't have to have it correct on the first try. This is something else I had to learn through my experience, right? Is I didn't have to be 100% correct out of the gate. I had to be the most correct I needed to be to help the organization move forward. And then I went to my next iteration. That's the way you need to kind of think of it, right? You want to cure technical debt or data debt, but the idea is you plan for that and then use that to move forward. In conclusion, all right, so we kind of touched on the management issues, the points of data value. What is the framework? Went through the categories and disciplines and hopefully I gave you some things to ponder. And one of the things that's in the book that Anthony kind of uses as his pet phrase throughout the book is go make an impact. So I'm asking you that within your organization, whether it be big or small, go make an impact. And with that, I'll turn it over for any questions. Thanks a lot, Gene. For those of you who may be interested, the book that Gene is referring to is available on Amazon and Kindle, pardon me, in Kindle form as well. And if we attend next year's enterprise data world, we'll be giving it away. We actually gave it away in 2019. And I'm pleased to say it was well received. I guess the question that I asked myself before we decided to publish the book, Gene, was do we really need another framework? But Anthony had a fairly compelling argument here. I mean, obviously this is not the same as a Zekman framework or a DIMBARC. But how do you see positioning this framework versus some of the others? Because that's a question that's gonna come up. Okay, I look at this framework as a template to follow, right? So if I was going to lay out a data management organization and I wanted to know kind of, you know, it's like, what disciplines would I need to focus on? This framework provides a guide that says, hey, I need to kind of focus these particular disciplines. And one of the things too is when I first saw the book when I went through and read the book, it's like, it was a-ha moments for me because we have talked about this stuff in the past, right? And but I've never seen it's put down in a concise enough way that was easy to kind of follow and look at and digest. Because usually we would, we would mash together a bunch of things. We would take the DIMBARC and the Zekman framework and the one used by the IBA and then the one over by the data maturity. And we would try to munch them all together and try to get something and say, hey, this is kind of how we're gonna inform our data strategy move forward. But if I use the DLF, that truly is my starting point for that to move forward. Yeah, I think, and I agree with you. I think the part about the justification for publishing this that really resonated with me when we were talking to Anthony was that, you know, what he was aiming for was a practical framework for sort of the data organization, which is what you mentioned. Not necessarily trying to define what the strategy is or what the architecture is, but the organization itself that's going to address those topics. And the thing that comes through time and time again, and for those of you who've not met Anthony, I mean, he's nothing direct and I think I've got more great one-miners from his talks than just about anybody else because he just calls it out. We're showing some goggles, we need to do that. He has such an irreverent style of writing, but it keeps hammering home the value message and it all comes back to value. And, you know, if you're doing something that adds no value, then you probably shouldn't be doing that. So anyway, there's a couple of questions here. So a question, can this framework be implemented at any level, I'm going to assume there, can this framework be implemented at any level? Or is this more of an upper level management framework? Yes, the point, that's a good point. Again, you have to look at your organization and maturity of it. It could move across two layers, right? You don't have to say, well, I need to start at the top and then work this way down or I need to start at the bottom and work your way up. It basically is where you are at the moment. Like remember, in your world, wherever you are in your organization, you may not realize it, but you have the opportunity to impact beyond your current realm of team or department. You just don't realize it yet. So you're looking at this framework that helps you provide the, an idea of how you can actually make that impact beyond your immediate team or group. And it doesn't have to be endorsed by up high or whatever like that. It'd be good if you had a data leader like a CDO in your organization who would basically endorse the framework and then you'd be able to just kind of use that as the guideline to move forward. But a lot of organizations don't have that. One of the things I've done, I've worked at organizations where I actually sat with the CEO in organizations where I never made it past an AVP, right? So, but the idea is that regardless, you need to have the same amount of impact, whether you're meeting with a CEO or an AVP to be able to get that message out. And so yeah, so it's in line to where you are. And then if you're fortunate to move up in your organization, take it with you up to that layer and then you'll have a more of the organization to impact. Gene, can you hold the book up again, please? Christian was just asking, what's the book title? It's called Data Leadership and the author's name is Anthony Alcomar. A-L-G-M-I-N. And Rex asked if you could put the alignment slide up again because he was out. Well, we're here to please. So there you go. And there's a couple of other questions here, which I'm afraid we probably are not going to have time to get into much. But one of the points here is that, as Irfan says, currently most CEOs have no idea about the power of data management if properly implemented. That is, that is, that is, that is, that is, unfortunately true in certain organizations, right? Like I said, my past experience with insurance companies, they are the laggards among the laggards. And so at the last organization, I actually did sit with the CEO and his leadership staff and try to, you know, go through this. And, you know, I don't know, and try to, you know, go through this. And some of it was breaking through. I could see some of it was breaking, breaking through. But there was this, just this thing about going to the shiny objects and immediately going to, you know, analytics and, you know, IA and everything, everything else without an understanding and you have that foundational piece. So I had to kind of, I still remember the CEO saying, hey, I'm thinking about doing this and this and this and this. He wanted to actually set aside some money to just focus on analytics and nothing else. And I said, I'm very intrigued by that particular suggestion, really intrigued. I said, one of the things we need to focus on before we can really move on that, though, is we have a lot of foundational issues we have to address first, right? And we were working through these. And, you know, then I could see the look on his face and I'm thinking, I probably shouldn't have said that to him. But at the end of the day, you know, I'm trying to be true to what I see and not just kiss, but just so I can get the CEO to, you know, like me. I didn't want him setting aside money that could potentially go down a hole and then expose us to risk. Yeah. All right. We're basically at our time here. So I'm going to have to wrap things up. But Jean, thanks very much. I appreciate you talking about the leadership framework with us. And let me see. We're going to be back in 10 minutes with the final presentation of the conference, our last keynote. Thank you everybody for joining us this morning. And we will hopefully see in a few more minutes at the top of the hour. Thanks again, Tony. Bye bye. Thanks, Jean. Bye bye.