 Here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the latest in the Salmon of the Monthly Data Diversity Webinar Series, Advanced Analytics with William McKnight. Sponsored today by CAS Search. Today, William will be discussing what is my enterprise data maturity 2021. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A section or if you'd like to tweet, we encourage you to share the questions by Twitter using hashtag ADV analytics. And if you'd like to chat with us or with each other, we certainly encourage you to do so. To open the Q&A panel or the chat panel, you'll find those icons in the bottom of your screen for those features. And just to note, the chat defaults to send to just the panelists, but you may absolutely change that chat with everyone to enable the chat and networking with each other. As always, we will send a follow-up email within two business days containing links, slides, the recording of the session and any additional information requested throughout the webinar. Now let me turn it over to Thomas Hazel from CAS Search for a brief word from our sponsor, Thomas. Hello and welcome. Shannon, thank you. Let me present to you. Let's go. So my name is Thomas Hazel, founder CTO of CAS Search, and I'm excited to be here with William to hear his presentation, the maturity of data in 2021. You know, at CAS Search, we help customers know better by activating now the mature data lake viewpoint for analytics. You know, CAS Search is a data platform where we index all the customers cloud storage and render it fully searchable, enabling analytics at scale with massive, this is key, massive time and cost complex reduction. Now we have created some innovative technology that really empowers the data lake philosophy. We're going after log analytics. We're going after BI analytics, as well as ML analytics. And what we've really enabled is this cost effective data lake viewpoint that, you know, in 2021, it's really the hot topic your terms like lake house, etc. We have a whole bunch of great clients that are using our platform today, Echo Facts and Armor, Blackboard, Caesar Key Names, Klarna, that you've maybe heard in the market. And again, the key thing is we're going after multiple markets, log analytics for your security use cases, for your platform application, as well as BI. And so, you know, at CAS Search, we really have adopted the data lake philosophy. And we know why data lakes are important. It's cost effective, it's scalable, secure. And the idea that you could stream data into that lake to derive insights, but insights are only achieved if you can get access to that data. And the wonderful thing about lakes, it's easy to store. It's elastic, scalable, cost effective. But here's the challenges, right? The data lake has gotten some ups and downs. Now, recently, the status quo is, you know, even Amazon is pushing it where you store everything into your data lake using, say, cloud, Amazon S3, and you move the data out to all these different services. And there's a term called Lakehouse these days. And, you know, this idea of moving data, physically transforming data into multiple silos is the status quo today. And, you know, that was some of the challenges that we've had in the past. And these are slides from Amazon, the idea that you move it out, you move it around those different services, you move it back in. And this is really problematic. Why? Because the complexity of it, the staying up of services, the solutions, it's really not where we want it to be. And not where the challenges of where the data is grown to be really problematic. What I see in the market, and we've seen this time and time again, is that people want no movement out of this lake, no more these silos of standing up solutions, they want direct access to their data, whether it's streaming of IOT data, app log data, BI data, et cetera, on all these clouds so that you can get access via Kibana, Grafana, Looker, Tableau, TensorFlow, and all these different personas want access to their data immediately, not waiting weeks and months to access this data, but now. And our viewpoint with a chaos or solution is you and now with your cloud storage, whether it's Amazon or Google is we transform your cloud storage into an analytical data platform, publishing elastic API for search, SQL APIs for BI, ML APIs for predictive analysis, where all you have to do is stream your data into your lake, connect our service to it, and we'll discover it, we'll management, and ultimately, you provide the analysis on your platform in one solution. And so with a chaos or solution, all that time cost complexity has been solved because of the ability of leveraging cloud storage, but with our unique innovation, with our unique architecture, we unlock we activate your lake for those use cases security application BI, as well as ML. But here's the thing, saving 80% of what you traditionally would do with unlimited retention and at scale with high performance. Thank you. Shannon back to you. Thomas thank you so much for this great presentation and for kicking us off. And thanks to chaos search for sponsoring today's webinar and helping make these webinars happen. If you have questions for Thomas feel free to submit the questions in the Q&A section of your screen as he'll be joining us in the Q&A at the end of the webinar. Now let me introduce to you our speaker for the series William McKnight. William has advised many of the world's best known organizations, his strategies from the form the information management plan for leading companies and numerous industries. And with that, I'll give the floor to William to get his presentation started. Hello, and welcome. Hello and thank you Shannon. Thank you Thomas for that introduction and that presentation I am very intrigued by chaos search I've often said that I think lakes have tremendous promise but a lot of the things that we've grown to enjoy. And the relational environment probably need to be there and this is a big step in that direction so be very I'll be very interested to watch the progress of chaos search over time. But today we're going to talk about where things are at the moment in terms of enterprise data maturity. Hopefully you have a sharpened pencil and a piece of paper because you're going to need it. And we're going to learn a little bit more about where you are in your data maturity as compared to your peers. I don't think that's the best question. I don't necessarily like to answer that question a lot because I think the key is just moving yourself forward as best as you can. However, I think the journey of others in their data maturity progress is instrumental in advising everybody as to what perhaps the next steps could be in your environment. And that's what this is all about. That's what all my presentations are about. Taking next steps. Actually taking action within your environment. Now today, this is a bit of a broad presentation as compared to say drilling in on data lakes or master data management or what have you. This is going to encompass that and much, much more. It's all the things that I think of in terms of data management. And I'll tell you a little bit more about the origins of the study that led to this maturity model in a bit here. But first, a little philosophy. Maybe you've heard me say this before, but I'd like to say this. Beyond the mountain is another mountain. This is an old Haitian proverb. And my encouragement here is for you to take one mountain at a time, but know that mountains, they keep getting built out in front of us. You know, literal mountains of course, but new technologies like a search, new things that we need to think about adopting in our environments and picking winners and so on. And this will be never ending for probably all of our careers, no matter what age you are if you're staying in data. Hopefully you feel like as I do that you chose well at getting into data. It keeps on giving. It keeps on innovating and for good reason because next slide is encapsulating that. We are in the business of data. Now I walked into a new, now I virtually walked in. I haven't walked into a client for a while, but I virtually walked into a client shop the, I think last week, a new client. They're in insurance and he said to me, first thing, we are a data company that happens to sell insurance. And I said, great, some of my work is done. You know this already because this is really where it's at today. We are where it's at today. We in data, we in analytics. We should feel proud. We should feel bold about the things that we need to do within our environment. And some of this is going to, I hope, empower you as to what the next steps might be within your shop. And again, we're looking broad today. We're not looking at a single application and what can we do to it. Somebody has to be thinking like this within the organization about data. And I hope that is you from whatever perch you're in within the organization. If you get the knowledge at webinars like these and otherwise, you're really empowering yourself and the organization to move forward. And that's what I want you to do. So information is exploding to real time all the time. It differentiates us. The quality is important. It's used and reused. And it's a key business asset. I hope you are treating it that way within your organization. So if you are going to provide a great service to your company, you actually anticipate the need, the voracious need for data. If the need does not seem to exist, you're not off the hook. That is where you need to start. You need to start by increasing the demand for the supply that you provide to the organization, which is data and analytics, right? So it's not simple enough. It's not good enough to be just responsive to urgent requests in the organization and be considered a leader. Yes, I know you're going to have days like that. You're going to have stretches like that. But please be sure you pull up. Your organization needs it. Now, what we did here at the consulting group, my consulting group is we look back over our clients. We've been looking at our clients for the past four years. And at some point in the engagement, we measured them in terms of their business performance. Oh, if they're a public company, those metrics are certainly helpful. But we really try to dig in and go with the insights that we get by being a part of that organization for a while, right? And so they naturally cluster into one or five groups from low success to high success. And at the same time, and what's important to us is we measure them against 40 metrics that have to do with the data environment. Some metrics about their data warehouse, their data lake, their data governance, all the things you're going to see in this presentation. And what we found, and probably no surprise to those of us in the data business, but what we found is that they are highly correlated. The data maturity, that is the mature, let's pick on something like a data lake, the more mature that is, the more mature the organization does appear to be. And this is true for a lot of the data artifacts in the organization, such as master data management, data warehousing and so on. We'll get to all that. So we plotted, again, we plotted business success on a continuum. We have clusters of data maturity and a progressive data profile. We can confidently say that data maturity is correlated to business maturity and vice versa. Now, occasionally just to put an asterisk on this, sometimes we, well, we frequently work in very large organizations, and we're not, we're not privy to everything going on within the organization from a data perspective. So it's not necessarily when we evaluate the business, quote unquote, it's not necessarily the entire business. If we're at PepsiCo or we're at GE, we're not grading out the whole business. We're grading out that department that we are visible, we have visibility too. So but anyway, I think the study has some tremendous merit and insights for us. That's what I'm here to share with you today. And these are some other things that we found. Okay, again, we define these levels through reverse engineering client environments in the past four years and we base it on business success. And as for the data maturity, as for all the data metrics that we choose, that's all let's let the chips fall where they may. And so we looked at where the chips fell, and they did turn out to be, you know, quite correlate to business success. The capabilities emanate from the presence of the items shown. So you may say, well, it's not about whether you have a data warehouse. It's not about whether you have a data lake and have anything just so it works and it does these things for the business, you know, improves your margins and adds customers makes them upsell more decreases fraud, all that stuff. Yeah, the stuff that's right at the bottom line stuff. I think we talked about ROI last month. But anyway, all that stuff. Yeah, of course, that's true. But all these artifacts that I'm going to be talking about they relate directly to those pieces. They really do. And there is such a thing as a great data architecture within an organization. It's not just the throwaways. It's not just a, well, let's, you know, let it let it fall into place how it falls into place from a total bottoms up perspective. And we'll take no headway on this. And we'll see what happens that is not going to correlate to those bottom line factors. And I agree with you, by the way, that the bottom line is what counts. And this is all about that. So so you can't. Okay, third bullet should give you a sense of priority. We want to emphasize some of these bullets here. And by the way, this presentation on like most of my others is not that slide intensive. So we'll be spending a little bit more time on some of the slides than usual. This should give you a sense of priority. Because again, what we did was we looked at the we looked at various businesses and we looked at how successful they were as a business first. And then then we dropped in all the data points. And so wherever you find yourself on the maturity model, you can look at the next level to see what a lot of companies. I'll put it that way. What a lot of companies did next and what moved them up and move their business up. Now, you can't skip levels in any category. This is just an observation from being with clients. And, you know, if you're a one, you can't say, well, I want to be a five by the end of the year. That's pretty aggressive. Actually, in my opinion, to move the entire data maturity up to the next level. And I'm going to say there's five levels. It's probably a good six months of concerted effort and progress. So we can't be skipping levels. We have to take it as it comes. Now, here's the good news. Momentum is paramount. That's the last bullet. Once you get going in the right direction, you start seeing results, start seeing business results. You are given more leeway to move things forward in the direction that you need to. And moving the data maturity up. Now, maturity levels tend to move in harmony. That's another observation. There's not too many organizations out there that are going to be a one in architecture, but a five in technology. You know, you tend to be within one, at least in all the categories. Now, you might surprise me and be a little bit more disparate than that, but I don't think so. I don't think so. Once you pull back the covers, I think that you're going to be around the same in my categories anyway. And you'll see my categories in a little bit here. And yeah, so you don't enjoy working on the business strategy side of things. Well, that's too bad. Somebody needs to because you can't move forward too far too fast with the other things that you might enjoy more of if you can't pull that along. So make sure that you're moving in harmony. And I am, I did notice, I guess that we have a lot in here that I may not recommend necessarily for a midsize or a smaller company. So if you consider yourself a midsize company or a small company, you can probably bump yourself up one on my maturity model just because I don't know that you would necessarily need to be held to the same standard as a big enterprise. A big enterprise is going to do the things that we are showing here today. And here's another thing. I think you all must be at level three. You'll see what that means in a bit. Some of you need to be at level four in order to be competitive this year. Now, as you may have noticed on the prior slide, let me just back it up. There's a lot of organizations that are in lower data maturity. I don't know if the slide conveys this correctly, but a lot of organizations are in low data maturity and not too many are in high data maturity. That's what I'm trying to say, no matter what the slide connotates. And the same is true for business success. And so it's hard. The momentum is paramount, but you have to stay focused and you have to keep on the plan and you have to keep iterating the plan. You've got to keep your ears open to the ground to what's going on out there and what might you want to pull in. And by the way, this maturity model, it keeps changing. I've never given this presentation the same twice. It's always being updated because things keep changing. Now, it's not radical change. You can feel pretty good about this presentation for quite a while, but you do have to keep your ear to the ground. Now, you might say, well, William, I'm measured on one of these puzzle pieces. User satisfaction, that's all that I seem to be measured on within my organization. I can guarantee you that's changing. For a data professional, an analytics professional, that is changing. We, as I said at the outset, we are sitting on the gold of the organization. We are the ones from which business strategy should emerge from. And so we need to be assertive about this and we will be measured on this, all of us. Are we driving data maturity? Because data maturity is correlated to business success and business ROI. Yeah, business ROI. That's not something that a traditional data person or traditional analytics person, especially one who sat in central IT, that's not even a concept that I can say personally. I used to necessarily relate to when I was in my IT roles. But it is a concept that we are starting to see becoming much more prevalent inside the data professional success metrics. Yes, we are responsible for business ROI. Not necessarily that we're coming up with all the applications, but we're a strong part of most of the apps that are developed within the organization and we are bringing apps to the table. Yes, that's right. Because only we know what some of those apps are that will really set the company apart. Again, you're empowered with all this data expertise we want to put to work. Now, if you would please get out that pen and paper, however you want to do it, and just kind of copy this, what you see here onto that pen and paper, onto that paper. And I want you to keep scores we go along here. That will make it a little bit fun too. And what I would really like you to do is if all your colleagues from your shop are not on this presentation right now, have them watch the replay. Yes, have them watch the replay and do the same thing. And don't tell them what you scored and see what they scored. And then have a meeting and compare your scores and just talk about it. It is great when organizations get together to not talk about the fire of the day, not talk about the deliverables of tomorrow, but to break out of that for a moment, for an hour, for a presentation, for a meeting. And look at the bigger picture of things. And this would be, I think, just a tremendous asset in having that conversation. Now you don't have to do any... Don't go into that meeting thinking, well, we've got to come out with action plans because that's what we're supposed to do with meetings, right? Just leave it open-ended. And all you're doing is seeding thoughts. There's your action plan. Seed some thoughts within everybody. It opens up opportunities down the road so that your eyes are open when somebody says, let's do it this way, you can say, well, hmm, actually there's an opportunity to utilize artificial intelligence in doing this and that would also raise our data maturity at the same time. Maybe we ought to do that. Maybe the users are trying to dictate architecture and you can say, hmm, well, if we actually did this with master data management, that would work a lot better. So again, empowerment and so score. By the way, for scoring here, as I go through one, two, three, four, five, when I get to the level that you can confidently say, we're not there. We are not level three on strategy. Well, then you're a level two, right down to as your score. However, when I'm talking about three for strategy, I'm going to give you some next steps. So you can list in next steps what they are at the next level and that's what you aspire to, right? So that's your ideas. That's where the ideas come from and then they get seated into the organization. So for your overall score, I say add up the four categories and then divide by four and that's your data maturity on a scale of one, two, five. Now let's start with maturity one. And I am not even breaking this out because it's all negative stuff. It's all we're not doing anything. We're not doing this. It's all negativity. I don't want to dwell on negativity. Although it's kind of fun to talk about it for a little bit here, but if this describes your organization, your maturity one. As a matter of fact, what I find is most organizations already kind of know if they're down low like this because they have that feeling. They know, but these are some of the factors that you might find in organizations with maturity level of one. These are organizations that haven't done much proactive action in the area of information, data, analytics, what have you. They are desperate, heterogeneous, disjointed. They're organizational silos. They lack KPIs. They lack metrics. They lack a consistent information management architecture. As a matter of fact, there's really no connection to the word architecture. What's that? It's all about applications and delivering applications and there's not a sense of architecture in the organization. Like I said, it's kind of fun to talk about level one like this. Lack of a true enterprise BI and analytic tools, maybe you're overusing Excel or some basic tools from yesteryear. I guess it's not fun if you're actually in there doing it, but be that as it may. Lack of consistent data management quality and governance practices. Cloud skepticism culture. Can't go to the cloud for this, that or the other reason. Deadlocks dictate in these organizations. And what I mean by that is, I've been a consultant now for I think 23 years, so seen a bit and I know a lot of organizations get this way where maybe you need 25 people to raise their hand and say yes to something before it can really happen. And if Joe over there may or may not not be on board with this, let's hold up and let's wait out until Joe comes aboard even though the rest of us seem to want to do it. So that is not a mature organization. Multiple overlapping data stores. You have the same data in multiple warehouses in multiple lakes, et cetera. Technology initiatives are behind schedule, consistently behind schedule. Lack of data modeling. Everybody's got their big fire hat on. Lack of data modeling. Lack of a consistent enterprise path to production. So when I ask a simple question, okay, we're going to develop this, you name it, Data Lake, blah, blah, blah. Okay, how do we move it into production? Well, maybe we'll have QA and we might have to do it ourselves and 10 questions emerge from that. Should be a consistent enterprise path to production or you're pretty inefficient. Excel's the number one BI tool in use there. High data skills turnover because frankly, these environments aren't providing the highly in demand data professional with the environment that's stimulating and that's moving them forward in their career and that's another factor. Frankly, it is. Especially these days, we're trying to hire and it's difficult. So just know that and be good to yourselves. Business doesn't contribute to technology progress. They go out of their way to stay out of it and there's resistance to change. Like I mentioned before, okay, that was it. Let's go positive now. We've been negative. Let's go positive. Now, on the next slide, I'm going to talk about one of the factors. Well, let me just switch. One of the realizations that organizations have in order to move to the next level of maturity and in this case, just to move from one to two, you have to understand as an organization that you raise data maturity as you accomplish business goals. That's right. That's right. They go hand in hand like peanut butter and jelly. So that is how you get to move forward. I do not get budgets for raising data maturity. Let's raise data maturity, William. No, it's not about that. It's about doing something for the business and oh, by the way, let's do it in a great way and you're not really slowing down progress by doing it in the great way. You're not. You're improving progress on this and future initiatives if you do it right. So it takes that knowledge and foresight, that leadership, if you will, to do that. And so some organizations are going to struggle just going from one to two. I get that. I get that. But if you can keep momentum going, you won't have that same struggle down the road. I'm getting kind of hungry after looking at that slide. Slide number 10 is about maturity level number two. Now I'm starting to break out the factors of the data organization into the four components. Strategy, architecture, technology, and organizational. Let's start with strategy. So again, hopefully you got your pencil out. In level two organizations, they have data specialists. It's not just a side skill of somebody to handle the data. You know, somebody who's maybe an application programmer. Oh, by the way, on the side, can you, you know, handle the data or maybe there's in back to level one. Sorry, but back to level one for a sec. Maybe there's no data professionals in that organization and there's no sense of sharing of data or doing data right. It's all about the application. So back to level two, you have emerging data standards. I say, you know, the word is emerging. That's the word I could put on it because there are some. They're just not comprehensive, but there are some and they're starting to be some enforcement behind that. You're starting some decentralization. It's not all about central IT in these shops anymore. There's some decentralization getting some of the, the tech specialist closer to the business areas. As long as there's, you know, that thread that connects everybody. I think that's a good thing. And we'll, we'll touch on that a little bit later. And there's some data modeling and, you know, I kind of struggled to, to, to even suggest that there was low data modeling anywhere, but there is many organizations run on pre-packaged data models. And that's about it. If you ask a level one organization to do some data modeling for something new, something particular to your shop, that company can go into traction and pass the buck and blah, blah, blah, and data modeling doesn't get done. So you got to have that skill for level two. Now let's move on to architecture. Okay. Now you have a data warehouse or data warehouses. Some of these organizations at level two have too many data warehouses in my opinion. But at least you have what somebody might call a data warehouse or two, and you have some slowly changing dimensions. You have some data quality transformations. So hopefully that doesn't sound uber mature to you. But there are data warehouses out there that are simply copies of data kind of shoveled over into a different data store. We don't want that or we want that as a start, but we also want to know that we can share the data there through slowly changing dimensions and we can change the data as it needs to be changed for its new purpose over there in the warehouse. Platform selection happens. Not everything goes into your, your favorite vendors database and it's always a new database. Everything is just assumed to be a new database in level one. So in level two, you actually think about it a little bit. Not enough in my opinion, but you think about it a little bit. There is a data lake in development. Yes, even amongst level two organizations. I didn't say it was in production yet. I didn't say it was fully developed, but it's in development at level two. And you're doing steps beyond ETL for your data integration. I wouldn't have said this a year ago, but there's been a lot of progress made around data integration beyond ETL and I'll get to some of that as we get more mature here. Now let's look at technology. And by the way, by the way, some of the, some of the ways I've categorized these things may not be what you would do and that's okay. I guess. So I'm thinking about master data management as technology here, but you know, some of you may say, well, that's really architecture or strategy or even organization. Okay. But I had to draw the line somewhere and balance things out. So data warehousing to me, that's architecture. That's not technology. You can have different kinds of technologies for your data warehouse, even an OLTP database in some cases. Excuse me. But let's go back to technology now that I put all that preamble out there. There is a sense of master data sharing. I didn't say master data management. I said master data sharing. That sharing concept grows as your data maturity grows. That's very important. That idea of having leverageable data stores. That idea of having data lakes, data warehouses, master data management environments, data hubs otherwise, not having all one off application data stores. Of course they're necessary, but that shouldn't be it. Third party data is now utilized at level two. Last year I think it was at level three. Now it's at level two where third party data is being utilized. That's certainly taking off. Cloud usage. Okay. Now we're in the cloud at least a little bit. We're utilizing columnar data structures. And hopefully you know what that means. If not check back in December, because that's going to be the topic of my December talk, columnar databases. And a lot of databases out there today give you that option if they're not fully columnar. Anyway, you are forming up machine learning. I didn't say you were doing any in production. I said you're forming it. You're thinking about it. So it's starting at level two these days. Organization, you have some nominal data governance. You are doing agile. You're not doing waterfalls anymore. And at least you're doing it in a light way or a selective way. Yeah, there's still some waterfall in level two, but you're moving on these data projects. It's moving towards agile. And you have notions of self-service BI. Technology professionals are starting to wean themselves off of running every report and doing every little thing that users can do in maturity level two. So those of you that you say, well, you know, you lost me a technology. We're not doing that. Okay. You're a level one then on technology. Sorry to say. But let's accept reality. That's number one at moving forward. Now what is that reality that sets in to help you move to maturity level three? And this is the big reality that must set in that too often we work on that part of the iceberg that's above the waterline when the real leverage is in the data foundation, which not everybody can see. Data professionals, we're down there with our scuba gear. We see the iceberg below the waterline. That's where we're working. And hopefully as we are presented problems within the organization, we dive in and put our scuba gear on and dive in just to expand that analogy to a ridiculous level. But anyway, we know that we have to work on the data platform, not just the BI platform. Okay. So matured level three, we want to get there. Let's see what that looks like. The data strategy, the data layer is acknowledged. It's actually, it's met the level of being considered a layer in the organization, in an application. It's not just one humongous blob layer. No sense of layers really in level two. But level three, yeah, there's a data layer. And so when there is a data layer, you start to take care of it in a particular way. Most development is within the architecture. It's not all rogue development happening at maturity level three anymore. And by the way, you're already all in on AI from a strategy perspective, maybe not implementation yet, but you're all in on strategy. Now architecture, you have your EDWs, your enterprise data warehouses, and they have different flavors, I guess is the best word I could come up with. I've expanded on this concept before, but there are data warehouses that focus on customer, that focus on finance, that focus on product, et cetera. And well as it turns out, that's actually a fairly mature thing to do. I'm not saying it's more mature than having one single enterprise data warehouse in the sky that has everything. It just doesn't seem like many organizations got there. But a good place level three, again, level three is where I want you all to be. You should be sprinting towards level three. And I kind of fear for your ability to move forward as an organization if you can't get here by approximately first quarter next year. So put in place those plans to get here. Where else do you need to be? Three and five year architecture plans. You're not just head down focused on today, but you're looking ahead at three and five years at what you want to be. You also know at some point anyway, you learn that these plans are flexible and may need to change. But at least at level three, you have in place some three and five year approximate architecture plans. Data lake. Now you have that data lake. Yes, the organizations at level three have the data lake. And by level three, I'm probably talking about, where's my notes? I'm probably talking about some, we're probably in the 30s, about 34% of organizations are going to be at level three. Yes, it's not for everybody today, but the winning organizations are going to be doing this. Moving on, they're using streaming. They're using ELT. They're leveraging IP, intellectual property, pre done work, I guess you might say, in doing source target mapping. Yeah, leveraging IP and source target mapping. So this is, this is acknowledging that others have done this pull before. This is acknowledging that AI can be done to help us move forward sensibly with our data integration. Third party data is really prevalent in these organizations. They have the lake house, not just a lake, but it's integrated at least to some degree with the data warehouse, maybe not where it needs to be, but to some degree. And they have diverse data under management like JSON, XML, Avro, Parquet, etc. So this streaming, by the way, I am talking there about Kafka, Pulsar, things of this nature. We have found that it's data integration is not all about ETL. There are much better ways to do, I want to say most of the data integration within your organization. Okay, I've got a lot to say here on about technology at level three. Graph databases, specialized analytic work stores, analytic stores for workloads with requirements not suited for EDW. Unfortunately, I had to make that a bit of a mouthful, but hopefully you get this. What this means is that you have sensible other analytic data stores that you didn't just spin up a copy of the data warehouse. You didn't just spin up a copy of the last analytic database that you had. You didn't just, because you needed to add a new column, you know, completely pull a new source, pull a source that you've already pulled many times before. So that's some architecture beginning to gel there. Your enterprise data warehouse itself is columnar. You are minimizing cubes. You have MDM across all the major subject areas now, not all subject areas, maybe not fully developed, but now master data management is in play in these level three organizations. You are cloud first. You have a data catalog. It may not be fully populated, but you have a data catalog, at least the technology in place, and maybe it's working for one application at this point. And you're open to open source, although you are light about it in your organizations. These maturity level three organizations are not all open source technology by any stretch. They have some though. Organization, you have data governance now by subject area across most major subject areas. I hope I'm describing you right now. You have organizational change management. In other words, you know that you affect people when you do these projects and you're doing things to bring people along, getting acceptance and getting buy-in and enhancing people's working career in life really in the process. Chief data officer. These organizations have the CDO. They have data scientists and they have strong DevOps. All right. So what's the big realization that you have to have when you go to level four? By the time you get here, you should begin to see and anticipate what the need is going to be for the data and how it's going to be used. So you don't obsessively worry about, well, let me list out all the users and what's their top ten queries going to be of this data. That's just not that important anymore. The data profile itself is pretty important. And the data profile today is going to help you get into the right platform. The data characteristics, excuse me, count for much more than the usage profile. So take advantage of the cloud scalability. Take advantage of enhanced performance and move forward with mature direction. So level four data strategy. Data is now an asset in financial statements and within executives. Now I'm not saying that you put a dollar figure on it. I am just saying it gets acknowledged as one of our assets. Executives know about it. They say it. All development is within architecture. Predictive analytics. You are predicting the future pretty accurately at this point. And pretty soon you're going to learn how to impact that future. And you're going to have to use AI to do that. And you do things like what you're doing today. You're measuring your analytic maturity. You do that on a regular basis if you're level four. Architecture, those three and five year plans I talked about. Now you are really realizing that they must be dynamic, that they must change. And you have the expertise to do it. And so you're doing that. Kubernetes and Kubernetes services like Azure Kubernetes services, Diamante, things like that are in place. Take advantage of those platforms for your Kubernetes work. API management is in place. Again, back on data integration, there's been a lot of change in data integration. A lot of it's gone the way of APIs. And you have a management platform like a con in these environments. You have identity management like IAM with like Azure Active Directory, one of these. Technology wise, I guess some of that could have been technology, but here we are. MDM, most major subject areas. Now you're looking at GPU databases. You're looking at, they're not in place very wide and far, but some are looking at it. The data catalog is now populated. It's not necessarily enterprise wide, but these organizations are populating their data catalog. And almost all cloud or hybrid cloud. Now you're not almost all on-prem. It just seems to be a correlate to business success to be more in the cloud than otherwise. And I'm not sitting here saying everything needs to be in the cloud. Not every workload, not every cost security profile is for the cloud, but you have the freedom to move the application, the data, the users, etc. between the data center and the public clouds. That is the option that you have at level four. And the organization, data governance. There it is again. Now it's much more developed by subject area. It's an acknowledgement at this level that you need special governance for each subject area. You need subject matter expertise for each major subject area. It's not like you hire a data governor. Not a great just straight up job. It's a side job, but it's an important side job of these people. And they bring their specific expertise to the table. All major subject areas. Chief information architect. Wow. Taking information all the way to the chief level. Yes. At level four, this is beginning to happen where you have the chief information architect or something else. Maybe it's the CDO. Maybe it's the CTO. But they're actually doing architecture type of work. But it's acknowledged at this level. You have full data lineage. You know where all pieces of data came from, what transformations they went through, where they sat for a while, etc. You have strong ML ops. Not just data ops at this point, but ML is so important that you want to repeat it. You can only repeat it if you have strong ML ops. And you have what I would call strong data leadership. That sense of we're a data organization that just happens to do insurance. That is set in. And that's set in at leadership levels. And it's not something that has to be, you know, discussed every time. Hey, William, just as you're switching to, I just want to give you a time check. We're at just 13 minutes left. 13 minutes. Yes, I'm almost done with the slides. And then I look forward to your Q&A. If you have questions, go ahead and lob them in now. And Thomas and I will get to them. It doesn't take more time or budget to do it right. It does take knowledge and focus. And this is what puts people at that self-actualization level, number five. All right. At number five, data is fully discoverable. It's an AI organization for sure. Hyper personalization in terms of your customers. They're not clustered anymore. They are individuals. Your analytics are prescriptive. They're not just predicting the future. They're getting in the way of that future. They're changing that future to what it needs to be for the organization. And you have information products at this point that you're actually selling. Architecture, data infrastructure as a platform with domain mastery. Now, data infrastructure as a platform with domain mastery is kind of how I call the data fabric. You may have heard that otherwise. I don't necessarily like that term, though. But anyway, this is how I interpret that. And this is what I see in some really mature organizations. They get that they're not going to have a single architecture, but they get ways to thread various architectures together. And kind of, if you squint your eyes, something you can call an enterprise architecture at that point. And domains get mastered at higher and higher levels in these organizations. You have microservices and containerization in your analytical architecture, not just your operational architecture, but in your analytical architecture. You're doing data extract, like with tools like Encorta that do direct data mapping. Again, you're finding ways to really short change or, shall I say, streamline your data integration cycles. And a lot of what I've shown you in data integration has been about that from one through two and now five. Multimodel, your databases are not strictly for just relational data anymore. They are for multiple. So you know how I've been on this kick even in this presentation about how, well, you have to have a specialized database for everything, right? Well, it's changing. That's changing. And the multimodel concept is really taking hold where databases, especially from the NoSQL arena, are able to handle multiple data types. And why not if that can be true without suffering anything? And so anyway, you're taking advantage of that at level five. You have policy management. This is security beyond the database. Database-only security is too cumbersome at this point. So with tools like Immuta, you can provide access to all data for central office employees, mass PII data, add to users to all PII data, for example, share data with particular class of people like managers and so on. And that tool becomes pretty necessary at maturity level five. Technology. Complete enterprise master data management at this point. You have self-describing data. You have translitical databases, not just databases that can handle multiple data objects or data types, but operational and analytical. Yeah, again, I'm seeing the beginnings of a simpler architecture for us in the future. Just the beginnings, but that's where we are and that's where this is going. Databases at your edge in IoT, in your IoT architectures, you have databases at the edge, not just data, and you're doing things with that data at the edge, including artificial intelligence, and you have your embedded databases inside of applications. The organization, finally, we can say you have complete data governance all the way pervasive throughout the organization. So that was it for 2021. Hopefully you've been keeping score. You know where you are across all of these categories, technology, organization, architecture, and data strategy. And hopefully you've taken down some action items to move forward to the next level. And keep in mind as you do get on your data maturity journey, there's more maturity moving in perfectly than it merely perfectly defines your problems. Yes, a lot of us can point our fingers at things and say that's subpar, but how about moving it forward? Build your credibility. Don't be afraid to fail. Don't talk yourself out of starting your maturity journey. Start it mindfully. Start it with action. Have an open mind. You may not have all the answers, but have an open mind to others who bring ideas that are still in conjunction with this idea of moving data maturity up. New plateaus are comfortable for long again. I don't know what things are going to look like next year on this chart. I have a feeling about a few things, but I will wait and see and see how my companies do and see how they are doing business-wise and data maturity-wise. And by the way, that resistance that you have in the organization, it's not about getting at maturity level five. Everybody would love to... It's not about being there. I should say everybody would love to be there. Even at the price that you would put in front of them, they would love to be there, but they are concerned about the journey. Will we be able to do it? Because it's worthwhile to get there. So that concludes my part of the presentation. I will turn it back to Shannon and see if you have any questions. William, thank you so much for this great presentation and to Thomas. If you have questions for William or Thomas, feel free to submit them in the Q&A portion of your screen. And just to answer the most commonly asked questions, I will be sending a follow-up email by end of day Monday with links to the slides, the recordings, as well as anything else requested throughout. We had a question come in the chat here. Data retention is usually an afterthought when data structures are architecture and it becomes very complex to anonymize or remove data that has complex retention rules, like not being a customer anymore plus seven years. What can you advise to move this to the front of the architecture designed to segregate the data at PII and PCI data? William, you want to take that? Yeah, you take that first. Yeah, I'll jump in on that one. That's a really good question, by the way. Another similar question that I have to prod organizations to answer is, where are we storing our history? Because it used to be the data warehouse and then we rolled things off to tape and now I'm going way back. But now we can do that pretty effectively within our data warehouse. But anyway, then you have this other thing thrown in there for a lot of us, which is that customers have a right to be removed or have their old data anonymized and so on. Just got to keep track of all that stuff about where all your data is and all the more reason to have great architecture because if every time that you have to do this, meaning of a new adventure or any time a new regulation comes in this area, it's a new project. That's not going to be good because we'll see a lot more of this stuff and this is why we have to have great architecture, well-documented. I think the thing that I would point out is the data catalog. And also the thing I would point out is having data governance. So you have a body of people with the knowledge to go to to help out with those sorts of things that have the cataloging where all the data is so all the places that you have to touch when these things come up. But yeah, definitely have a plan around where your historical data is going to be and how long you're going to keep it and then have a plan for your ability to supersede that plan with one-offs that are going to occur as a result of compliance regulations like this. Yeah, and actually I'll add to that. One thing that we want to do at KS-Search is not own the customer's data. Building data solutions, building databases. Once you own that data, you have a lot of responsibility. And so one thing that we took approach is that the customer owns their data. They give us rights to access that data. So when a KS-Search solution, the cloud storage is owned by the customer and they provide a policy for us to read that data as well as a location to write our unique indices into their account. So from a PCI and all that, from our viewpoint is we want the customer to own that data. Now what we've also done about data structures and changing over time, we've created some technology to allow schema change to support multi-model, customer owns the data, multi-model access, schema over time change. These are key things that I know we wanted to address because we see that the pain and problems at large scale in big IT organizations. I love it. Thank you both. And so I think we've got time for at least one more question here. So what happens if one part shows signs of one level of maturity and another part indicates different maturity? How do we measure an enterprise maturity in such cases? Did you say part, P-A-R-T? Correct. Okay. Well, okay. So this is always the big question. This is a question when organizations have had, you know, over the years in terms of, well, we're building an enterprise data warehouse. Okay. Well, if you're PepsiCo, if you're GE, that may or may not be for the entire enterprise, everything that rolls up to the stock ticker. That's very difficult to pull off. And so you can only bite off what you can choose. So you have to define what your enterprise is going to be. And I would say make it as expansive as you actually have any control over. So if that's a particular business department, that's your enterprise. If that's the domestic part of the company, that's your enterprise. If that's where you sit in the organization, if that's where you have influence, then that's your enterprise. And then proceed to grade out that enterprise and just stick to it. If circumstances change and your quote-unquote enterprise becomes bigger or smaller, redo it. But you got to go with something as your enterprise because you're not going to be improving it until you're able to measure. And you can't measure a vague enterprise. So you have to define what that enterprise is, make it your level of influence. Yeah, and I'll just add one more note. I mean, have that North Star. Know where you're headed and do things incrementally. Make sure that, you know, you prove the solution, the path you have selected and go on to the next. And so, you know, be incremental, but have that North Star. It's easy to me and it's easy to make different choices. So, you know, test out your philosophy as you go. All right. I'm going to sneak in one more question here. Think about the levels of maturity. You can recognize yourself in say level three, but also parts of four. But really it should be fully at each level. Say you've achieved that level of maturity. Also maturity can vary by types of data disciplines, et cetera, like MDM, security, quality, et cetera. Any additional comments on that? It's more a comment than a question, but yeah. No, I like the thinking because too many organizations, they're afraid to put in place hard rules about, you know, how mature we are. You know, there's always all disastrous, right? You know, oh yeah, but over here, we know we're doing this. We're, you know, we're really four over here. So, you know, but I think, you know, the way I laid it out is you don't move to that next level until you have all the things at that next level. And that keeps the motivation in place to do all the things at the next level. And I think it's a pretty sensible journey. So if you take one level at a time, again, I said before you can't skip levels. So now you know what's at that next level and you can go about trying to accomplish all that. If there's one thing missing, you know, to move you to the next level, well, all hands on deck. And let's do that one thing. I mean, I know that that's impossible in an organization, but you know what I mean? Really focus on getting that thing done and then moving on. And then the world opens up because I'm going to guess you probably don't have too much at the next level up other than maybe very small things. So anyway, that is it's directional in terms of how you lay out your your program over time. But I will never, never, never take your judgment out of the process. Okay. Your judgment has to still be there. This is just foundational and background for that judgment and keep that in place. I love it. Well, thank you both again for these great presentations. And if you all don't know at Thomas Hazel, you say, Thomas, you said it's blog with us and we were just talking about that before the webinar and they were really popular. He's been a fore-thinker of data lakes for quite some time. So I'll give you links to those old blogs too. You can see. Yeah, yeah, please do. Yeah, it looks, it looks, it looks, I think relatively relative, right? Yeah, I think they very much so. Yeah. So again, thank you both. Thanks to all of our attendees too for everything, for being so engaged and everything we do. We just love the comments and the questions that have come in, but that is all the time we have. Again, I will send a follow-up email by end of game Monday with links to the slides and the recording as well so you can share and go through this assessment with your teams. I love it. It's been great. Thank you both so much. Thanks everybody. I hope you all have a great day. Thank you. Thank you. Bye.