 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining the latest installment of the Monthly DataVercity Webinar Series, Advanced Analytics with William McKnight, sponsored today by Matillion. Today, William will be discussing modern analytic data architecture maturity modeling. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via 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. Just click the chat icon in the bottom middle of your screen for that feature. And if you'd like to continue the conversation after the webinar, you can follow William and each other at community.datevercity.net. As always, we will send a follow-up email within two business days, containing links to the slides, to the recording of the session, and additional information requested throughout the webinar. Now, let me turn it over to Sean for a brief word from our sponsor, Matillion. Sean, hello and welcome. Thank you so much. Looks great. Good. Everybody see my screen? Yeah, looks great. Great. Hi, my name is Sean. I'm a solution architect at Matillion. As a solution architect, I'm exposed to a variety of implementation patterns the companies are using in the cloud today. I've also had the opportunity to work in the rapidly changing field of on-prem data warehousing for about 20 years. And I've seen a lot of best practices of data modeling changes techniques come and go. So let's take a quick look at Matillion. Matillion does as a tool. Matillion is an international cloud software company with offices in Seattle, Denver, New York, and Manchester United Kingdom. Our products are purpose-built for migrating data and transforming data in the cloud. Matillion runs on a virtual machine hosted in your own virtual network on one of the major cloud providers, AWS, Azure, Google Cloud. Our load and transformation software targets the four major cloud data warehouses, Amazon Redshift, Snowflake, Google BigQuery, and Azure Synapse Analytics. The main benefits that Matillion offers as shown on this slide are simplicity. We've got a drag-and-drop point-and-click interface that's fast and easy to build workflows with. This interface dynamically validates your work. It prevents mistakes and speeds up the development process, while also allowing you to preview data at every step. So you as a developer understand the shape of the data you're working with and how you've manipulated it, which really leads to speed. Our simple and powerful interface provides developers the opportunity to get a lot of work done. It shortens the time to value for your organization as you get your investment out of the cloud data warehouse. It provides a lot of scalability. The cloud data warehouse is our load and transformation engine. Matillion is just a orchestration tool and allows your data warehouse to leverage the massively parallel processing compute power. And then finally, savings. We offer a free trial that's really easy to spin up. After that, we have a pay-as-you-go pricing model so that you're really only paying for what you use. There's no large upfront expenditures for infrastructure or anything like that. So we know a little bit about Matillion. Let's take a look at what Matillion thinks the modern data architecture analytics ecosystem looks like today. What we see on the left side of this diagram is really standard stuff. We're always going to see multiple types of sources flowing into a data warehouse, flat files, APIs, on-prem databases, and then of course no SQL. This isn't really going to change. Businesses are always going to need to be able to leverage this data. The right-hand side is not going to pull out either. We have really powerful BI and analytics solutions. And while they're really powerful, they don't handle the previews of big data very well, volume, variety, and velocity. Where companies really need to focus to meet these challenges in this middle section here where you see Matillion in the cloud data warehouse. This area is the key enabler of analytics for businesses. Yeah, we do need to move data from all the different sources into the CDW, but that's not quite enough. We need to be able to transform it, apply business rules, and aggregate that data so that it becomes meaningful to businesses that like to make decisions based off of data-driven data. And then finally, the cloud data warehouse is built on this concept of massive parallelism. And this is really what allows us to attack the three of these big data. So what we want to be able to do is leverage this cloud data warehouse environment. If we can get this milky's right, businesses gain advantage over others. They'll handle today's business challenges, and we'll start to unlock a lot more insights into the tools that our data provides for us. So that kind of gives you an idea of the modern analytics ecosystem as Matillion views it. Once again, we do offer a free trial on all three of our cloud platforms. If you're interested, you can take a look. Our product is supported by a team of 15 Solution Architects. We have YouTube channels where we post all of our solutions. We've got online documentation. Coming in the near term, we have an idea portal where all of our users will be able to interact with our product development team so that you can promote and enhance features that make sense to your organization. Go ahead and check us out on Matillion.com. And I wanted to take a moment to thank you guys for your time. I hope you enjoyed this kind of quick look at what Matillion thinks the modern ecosystem looks like. I hope you enjoy the rest of your talk. Have a great day. Back to you, Shannon. Sean, thank you so much for kicking us off and thanks to Matillion for sponsoring. If you have questions for Sean, feel free to just submit them in the Q&A section in the bottom right hand corner of your screen, as he will be joining us in the Q&A at the end of the webinar today. Now let me introduce to you our speaker for this series, William McKnight. William is the President of McKnight Consulting Group. McKnight Consulting Group focuses on delivering business value and solving business problems, utilizing proven streamlined approaches and information management. His teams have won several best practice competitions for their implementations and he's been helping companies adopt big data solutions. And with that, I will give the floor to William to get his presentation started. Hello and welcome. Hello. Thank you, Shannon. And thank you, Sean, for that introduction to Matillion. Very agile data integration product there. And I hope that you all are staying safe and well during this time and sane as well as these things play out around us and hopefully we can accelerate the things that we enjoy doing in one way, shape, or form here. But anyway, today I have a very hot topic for you. This might be actually the most requested topic that I get for speaking. And it's about maturity and companies love to know how they're doing in comparison to other companies. I often engage this conversation and I like to push back a little bit because that's not the important thing. There's some interesting things about what other people are doing and other companies are doing that may be important to what your roadmap is. But you just want to maximize your capabilities at the end of the day. But I think it is a strong data point. And so I like to say, no matter where you are, beyond the mountain is another mountain. And this goes on and on. And unlike these mountains here which move at a very slow pace, our mountains today in tech and specifically around data tech and analytic tech are moving very rapidly. And things are being put in front of us at a pace much more rapid than any time that I've been consulting. And that's been over 20 years. So we need to keep up and we need to pick our battles and pick the things that we think are going to be not only important to us, but going to be keepers and going to be investment areas for the future in terms of technology. And so in regards to data, what does that mean? That means it used to be, give me some data and give it to me fast. And that was when I started this. And yeah, that was good. We could be successful in doing that back then. And then it got to be give me good data, but do it efficiently. And that was really the data warehouse approach to things. And that was fantastic for a while. And if you did that great, you were doing well. But now it's give me all data fast and effectively. And the data warehouse may or may not be the be all end all of that conversation when it comes to analytic data. Probably isn't. There's a lot more going on in an organization today in terms of analytics. And that's some of what I want to share with you. So one last point before I leave this slide, if you're still thinking that if you can just give up some data and do it fast and respond to requests and make sure the data is good, you're doing well. But you're not doing enough to keep the company competitive for the very competitive future in which the technological base of competition is changing rapidly. So we're in the business of data. Everybody on this call is probably a data professional, and I hope you are proud of that and are appropriately assertive within your organization about the importance of data because information is exploding. It's real time all the time. It differentiates us. The quality is certainly very important. Data gets used and reused in multiple venues throughout our organization and beyond. And information usage drives data value. And here I know we're here to talk about data maturity, but really data maturity is business maturity. Business maturity is data maturity. They are one in the same. We found a very high correlation between those that are at the highest levels of our maturity model and those that are at the lowest levels. And we're talking about business value and business growth and meeting your business objectives, not meeting your data objectives. They're less important, but they are definite conduits for that future. And so let me explain a little bit as we get into some of the details of the model. What we did is we looked back at our past about three years of clients, and that was clients that we did direct work for, that we were exposed to pretty heavily through our analyst work. And clients we just got to know a lot about for one reason or another through conversations or meetings or whatnot. And we were able to understand some 40-50 data points about their environment at that point in time. Well, we correlated that back to how's their business success doing? How are they doing from a business perspective, from a self-reported perspective, from a public company stock perspective? But how about their sentiment as they are expressing how they're doing? Is it good? Is it bad? Where is it? So we were able to plot a lot of these variables on a data maturity cycle. So what I present to you today is not William sitting back in his tower here thinking about it, but it's more or less, we found that companies out there fit into five different buckets of what they're doing in terms of analytic technology. And they're somewhat distinct, you might be surprised at that, but they're somewhat distinct and there are definite big steps to go from one to the next. And I'm going to talk about those steps as we go along here, but come back next month, because I'm going to be talking about organizational change management, which is another part of the requirement for making these moves, something that we often leave behind. Today we're focusing on the technology and so forth. But don't forget that as you move forward and you want to move forward. But most of you are behind what I would call standard today. And what I call standard is getting to level three, my level three, I'm going to share with you level three here and know that most of you aren't there, but you need to be sprinting there fast as you can to keep up and to keep competitive in the world today. Now, don't find comfort. Don't find comfort in the fact that you're with a lot of great neighbors if you're in a one or two situation. That's not comforting. You need to show a great leadership internally to the point where you're pushing forward to three and some of you really need to be at four, honestly. Some industries are going to have that level of competition. And kind of like back to the mountains example earlier, those mountains keep getting built up over time. And so I fully expect that this model will change as we do more surveys and learn more about companies in 2020, although it's probably slowed down a bit due to world events. And that's another topic of conversation. But still, things are moving forward and companies are moving forward and the analytic area is not the area that's getting gutted the most in terms of what's going on out there. As a matter of fact, it's probably flat. And that's what myself and colleagues are looking at right now in terms of the spend around this area, which relatively speaking is not bad, but I digress. Maturity modeling. The levels, as I mentioned, were defined through reverse engineering client environments in the past three years and based on business success. Capabilities emanate from the presence of the items shown in the environment. Well, you might say, well, why are you telling me we need graph databases? Isn't it more important that we have the capabilities the graph databases provide? Oh, yeah, of course, that is more important. But I found that the efficient way to things that you actually do need is graph database. And so I cut right to the chase in this. So I'm going to be sharing with you specific technologies that companies have in place at levels one, two, three, four and five. And they are very progressive, too, as you go up from one to the next. And I try to make it simple. There's a lot of details behind what I'm going to show you. But I got to put this in the slides, right? So you're going to see the slide. These should give you a sense of priority. These should tell you, first of all, I hope you're counting on your fingers as we go along here. And kind of you can figure out where you are. One, two, three, four and five. Some of you are now going, I know we're one. Okay, ones usually know it, but sometimes they don't. So do the quantifiable thing here as we go along and try to keep count of where you are. Take the average of the categories that I'm going to share with you. And that'll be where you are. And that's cold and hard. And that is the facts. And those are the facts. And that's what you should base your roadmap on. I want to help you with your roadmap. I want this to help you with your roadmap. I don't know that anybody's necessarily so far gone and behind the ball that there's just no way. You might as well shut the doors or kind of just ride it out. I haven't met that situation yet. But some of you out there are in a deep corner in this area. And you're going to need to have momentous progress forward, which is going to require a lot of leadership. Maturity levels tend to move in harmony. You can't be a one in one area and a four in another area, et cetera. Mid-sized and smaller companies, some of what I'm talking about may not apply to you because it's a lot. You can bump yourself up. I'll give you plus one. But everybody needs to be at level three. Momentum is paramount. So if you are moving in the right direction, that is the main thing. All right. So let's raise the foundation of your company. Here's my quirky slide here for you. Yeah. It's shaking about. Our foundation is shaking about upon us right now. But our job is to raise the foundation of our company. What is true today is not going to be good enough. What works today for you is not going to work for the future. Unless you're a five, and there's not too many fives out there, but you always need to be moving forward. As I mentioned, momentum is paramount. Raise the foundation. If you're an information professional, don't just be responding to requests. That's not good enough. We need to take the lead in situations and really have a seat at the table in terms of prioritizing what the company is doing. And hit those maturity efforts to arrive. I've been, like I say, been holding a long time. I've never gotten a budget for raising the maturity here. That's not something that gets a budget. I have to attach maturity efforts to an existing budget to an application. I look for opportunities to raise the maturity in organizations by looking at the roadmap. Maybe it's one I've built or they've built, but looking at opportunities that are coming up in the near future in that company. And maybe that's the time to insert the graph database. Maybe that's the time to take that big step into the cloud or to adopt cloud storage, data lakes, et cetera, et cetera. All the things I'll be sharing with you in the presentation. And you're going to be judged. Your success as a data professional is obviously largely measured based upon user satisfaction. Okay. That is sort of the lowest common denominator. We have to do that. And used by user, I mean internal application developers and obviously end users. End users that we brought our data warehouses to a highly cultivated point so that they can do exactly what they want to do with, I don't know, almost the push of a button. But today, your data success, your success as a data professional is really measured in different ways. And sometimes they're writing your performance plan. And sometimes they're not, but they're implied. Business return on investment and growth instigated. A lot of that needs to come out of the data professionals of an organization these days. And then data maturity, which translates into longer-term user satisfaction and business return on investment. And I leave a little slice of the pie there for things that are unique to your particular industry, your particular company. But I wanted to point out, I wanted to incent you a little bit as we go into the maturity items with the fact that we as data professionals need to be raising that maturity. So maturity level one. This is going to be pretty simple. I don't do a lot with this because it's a lot of things that, oh, if I wanted to be cynical, now would be the time because a lot of these things apply to a maturity level one organization, kind of across the board. disparate, heterogeneous, disjointed. I won't read them all, but I hear these things all the time. We have a lack of a consistent information management architecture. And really, sometimes the company has no connection to the word architecture. Architecture doesn't come up. It's just solving projects. And hopefully, you do them in a good way, but they're very disjointed in these environments. Lack of a true enterprise, BI and analytic tools, Excel tends to dominate. I put on here, it's the number one BI tool in use in these organizations. That's kind of a sign. It's not the only thing. But data modeling is, you know, something that's not really done, models that you're given or kind of locked and loaded into your production. Then you just live with them, usually very poorly. You have this one vendor mentality because you don't have a broad grasp of what all the possibilities are. If your favorite vendor or your enterprise vendor says, hey, this is what you need to do, we're doing it. And we're doing it with their tools. Sometimes that's good. Sometimes that's not so good. So I think you need to be a little bit broader than that. Think about getting into some different tools that might be more best to breed as we go along here and doing some different things. And the business IT divide is very, very high here. And when I say IT, by the way, I know some of you are in, not in central IT, but you're a technology professional, maybe out in a department. Okay. To me, that's still IT, as I refer to it. Now, as you accept different levels of maturity, the need to grow your levels of maturity, keep this paradigm in mind. And maybe some of you have seen something like this before. Many have by now, but it's the iceberg, right? And we like to work above the iceberg or many organizations, I'll say, when people who don't know that the iceberg actually looks like this, below the water line, tend to think they can do all the work above the water line on BI. And today, sometimes AI and AI will quickly crumble and fall by the wayside if that data layer is not in place. And it's not up to a high standard. But what we really need to be working on and thinking about is a data layer over and over again. And if you've been to my webinars and my seminars and so on, you know that I like to say that the data should be screaming out what you need to be doing with it so that you can put all kinds of BI tools and AI tools today, models and so forth, on top of that data, and it'll work for you. And you might say, well, I need to do an exhaustive study of the usage profile of this thing that I'm going to put in production. I think sometimes we overdo that. And we need to be more efficient about it. And the data profile to me speaks volumes. And yes, I want to understand how the data is going to be used, but many organizations don't have a complete grasp of that upfront. But the data we can spec out somewhat upfront in terms of its characteristics, its size, its data types and so on. And that tells me a lot about where that data belongs. Why am I saying this? Because the platforming of data is very important and is a very foundational element of this model. Getting data into the right platform so that it can succeed. If you get that wrong, then you're going to pay the price. And that price might be paid over the course of years. It might be buried for a while, but inevitably the inefficiencies are there in organizations that do that wrong. That put everything in blank database, you know. So we want to move on to maturity level two. Okay. Now, some more of you might be inclined here around maturity level two. I hope you are, at least compared to one. My strategy or excuse me, my maturity model is going to be broken up into four different quadrants, which you'll see over and over again for the two, three, four, and five. I'm going to show you. Let's start with data strategy in the upper left. And like I said before, there's more to it than this. But this is the slideware for it. So you've got data specialists now. You don't have application developers that are doing data on the side. And data is not just simply a drag along to the application. And you have people that do DBA, do modeling, do data integration. But you have some data standards, but they're incomplete. At least you've started. Okay. These are trying to be kind of forward-looking statements. Balance centralization. You're not fully centralized. Everything has to come to the central IT organization. Yet you don't have the lack of anything in the center that's supporting the entire organization through bulk purchasing and standards and architecture and things like that. So a nice balance is essential. And these are some of the things that maturity level two organizations have tended to step up to. These are some of the lower company denominators as you move up the maturity level. Compliance strategy. Now we have to have a compliance strategy. Now some of these things, I was kind of unsure where to put them in terms of the four areas. But this ended up here in data strategy. Compliance strategy. Stuff like HIPAA. Stuff like all the sort of privacy laws that are going into place all over the world. Data modeling. You do data modeling. It's not something you run away from. It's not something you've chased off. You've chased that skill off or you never give it any time. It's something that you actually do. Maybe not well, maybe not completely, but you do it. Now architecture. What about architecture for maturity level two? Well, your data warehouse, and hopefully everybody's okay with some of the words I'm using here, but your data warehouse has some slowly changing dimensions. It has some sharing going on inside of it at least. It's not just I locked and loaded some data. That doesn't even get you level two anymore. To be at level two with your data warehouse, you have to have some of these things slowly changing dimensions and data quality transformations. It's not just, again, data locked and loaded from source. It's data that you have looked at and decided I need to improve this data for its new purpose, or at least I need to have looked at it to make sure it's up to the standard of the new purposes in the analytic arena. You have platform selection. Platform selection actually happens. It's not a byproduct. It's not something that there's a default winner for everything and we just go with it. You actually understand that no one size fits all at maturity level two. You're not going to put everything into a blank database. Usually it's an OLTP style database. You're not just going to put everything in that and hope for the best. A database is not a database. It's not a database. And certainly a platform is not a platform. It's not a platform. I hope to develop that as we go along here. Even level two organizations are talking, thinking, and designing and doing some things around the data lake concept. Now the data lake, this is one of many things that you're going to look at and see that it's on the model many times progressively as we go forward up the numbers. And it appears to be a real winner for winning organizations. Now technology, MDM. There it is. MDM. You have a hub in place. Already, yes, at level two. Level two organizations have MDM hub in place. Now most likely it's a tool, a so-called master data management tool, but it doesn't have to be to meet the standard. But as you move up, you're going to get more interested in master data management tools. Third-party data is utilized. You're bringing in data from outside your four walls. And there's a strong cloud directional commitment. And you are utilizing the columnar arrangement for data in the analytic arena, especially. So we're talking here about analytics primarily. And in the analytic arena, you are definitely wanting to turn your data into a columnar direction. Organizationally, you have nominal data governance over your analytic area. You are using agile light or selective agile in the development of your analytic projects. And there are notions already in place of self-service business intelligence. It's already understood in level two organizations that central IT cannot be responsible for building out all the reports that are requested or building out all the dashboards or running down all the charts. It must be interactive from the user perspective. And that's what we call self-service BI. And that's a balance of responsibilities. So that's a level two organization. Now let's move to level three, data strategy. The data layer is finally acknowledged at level three. Now, what did I say about level three? You all need to be here. You need to be sprinting here. You need to have real plans in place to be at level three, to be a business competitor in the next five years or so. Data layer must be acknowledged. It's a separate discipline with specialists. We already had the specialists in place at level two. Most development is within architecture. Most development in the organizations within architecture. And you're all in on artificial intelligence. Wow. All in on artificial intelligence already at level three. I get some pushback on that. What? Yes. Level three organizations are thinking anytime that they have previously thought of business intelligence, they're now thinking of artificial intelligence. So definitely in the analytic arena, artificial intelligence is taking over and becoming very prominent as a way forward as a means of competitive advantage. Architecture. You have an enterprise data warehouse and it has data quality in it. It has the data quality that's above standard. Well, how do you know? How do you know if it's above standard or not? You're at least doing some measuring now at level three. And you have plans, three-year plans, five-year plans. Why are these important? Why are the plans important at this level? Well, the plans are important because they give you a true north that you can start gearing your architecture and everything really towards. So your analytic architecture starts moving in the direction that you want because you have that in place that you're thinking about it as you solution the various applications that you're going to need to do over the next few years. And so what you want to do is look at the roadmap. You want to influence the roadmap, but you want to look for opportunities to do some more mature things. So what this is, this model, I think, is very illustrative of is what's next for me? Well, what's been next in the journey for other organizations? So you can find yourself at a say architecture level two and look at level three and go, oh, there's some things that probably should be on our roadmap. And I would say this is definitely next six months type of planning here. You're using ELT more so than ETL. You're using the power of these cloud databases that Sean talked about that Matillion supports your Redshift, Snowflake, BQ, etc. And that's very prominent in more mature organizations. If there's one database that you should think about one type of database that you should think about for most of your analytics, it's definitely the cloud analytic database. And you're leveraging IP in your source target. You're not starting from scratch. I almost said ETL was automated here, but I found that that's something that pushed out a little bit. But at least at level three, organizations are not starting from scratch when it comes to source target mapping. So many others out there have done source target mapping. Matillion, for example, is exposed to a lot of source target mapping and data quality rules and so forth. And these are things that you want to be able to pick from and really jumpstart your activities in the data integration area. You're definitely using third party data here. Some organizations have more third party data than they do internal data anymore. That's partner data, that's syndicated data that they're buying, etc. And the EDW, here's a big one, and I actually have given whole webinars on this. The EDW accesses the data lake. And the data lake is in cloud storage at a separate point. It's not in Hadoop. It's actually there. It's not in a relational database. It's in cloud storage. It's in like an S3. And the EDW works together with the data lake so that it can do queries that reach into the data lake and join that data with data that's in the relational store. And that's the, you might have heard the data lake house concept. That's that. Yeah, at level three. And I would say, I didn't put the numbers in here, but I would say probably about, we've probably lost, oh, I don't know, at least three quarters of you by now in terms of where you are. Three, four, and five tend to be that the highest quartile of organizations. But I want you to be that too. All right. Technology-wise, the graph database is used for relationship data. Graph database is very powerful. I gave a whole talk on graph databases. For whenever you see relationship network passing things like this, that's an indicator that that workload probably is going to be best served with a graph database. You just simply can't be inefficient about this stuff. You can't say I'm going to force fit it into what I've always done, which is a relational database and not even use the graph capabilities of relational databases. And there are some. There are some. But if you don't use them, there are no value to you. Graph databases tend to be pretty important for these relationship type of workloads. You have specialized analytic stores for workloads with requirements not suited for the EDW. Okay, that's a lot of words. Hopefully you followed along there. But the EDW, like I said before, it's not one size fits all. It's not for everything. And there are many reasons for this. And hopefully you're not putting data in the EDW for the good reason, not the bad reasons, not the reasons because users don't want to use that warehouse because you're hard to work with or it's hard to work with or they just don't know anything about it. But there are reasons why you may want to go beyond the EDW. I work in organizations now that have had their EDW now for 15 years, 20 years. They were built to a high standard back then, but they simply can't keep up with modern demands. And so there are other analytic stores. Maybe there are other cloud analytic databases that you want to spin up in your environment. You've turned the EDW columnar. You've turned the EDW columnar. And that's a big deal. And that can be heavy lifting in an organization when you have so many stakeholders of the EDW and you certainly didn't start your journey. Well, most of you didn't start your journey in a columnar orientation. More and more new ones are starting as columnar. But that is definitely best for the analytic workload. You have minimized the use of cubes. We know about cubes. They're not quite as necessary anymore as so many things have come into place to be a better solution to performance. Now, MDM is across all applicable functions for major subject areas. I didn't say all. These organizations don't necessarily have MDM across their whole environment, but they probably have customer, whatever that means to them. They probably have product, whatever that means to them. And they probably have some other ones too. So they're definitely well on their path to MDM completeness across the organization. And they're using a tool at this point. They've decided that there's value in that cloud first. And we've heard that probably maybe you are cloud first, but you're actually doing it right there. You are cloud first. And you probably have a data catalog in place as well at maturity level three. I didn't say it was fully populated. I didn't say it was hitting all areas of the organization. But you realize that you're going to have many data stores, a lot of data at different levels of importance, and you're going to need to have a catalog to see your way into that more rash. Okay, the organization itself. And I am belaboring maturity level three here because this is where most of you need to get to. A lot of you are one or two. One's not very exciting, but you need to get to this level three. And there's a lot to say about level three, really. Data governance is now by subject area across most major subject areas of the organization. So data governance has taken a strong foothold in these organizations. Organizational change management, the topic of next month's webinar, is part of most projects now. You have a chief data officer in place. You have a data scientist in place. You have strong DevOps in place. And I know a lot of you are looking at this now going, wow, I would love to have all that. Well, you're going to have to be a part of change. You're going to have to instigate the change in your organization to move some selective things forward. Remember, momentum is paramount. Get things moving in the right direction. It doesn't take more time or budget to do it right. It takes knowledge and focus. That's right. That's right. It costs just as much to do it the wrong way. Because you're going to do a lot of rework. You're going to pay for it over time. And I think a lot of technology professionals know this. I just wanted to come out and state it as you look at this and go, wow, that's a mouthful. It's hard to get to. Yeah, it is. But I'm giving you a little piece of the knowledge here today. There's a lot more to learn, of course, but I can't give you the focus. You're going to have to take that focus back into your organization. And you might have to be a pariah for some of this in the short term until wiser heads prevail, you might say. Okay. Maturity level four. Now we're really stepping up here. Yes, there are organizations that are maturity level four. There are probably, I would say, at this point, we're down to the top 10% of organizations out there that are data maturity level four. And they're sitting pretty, but they're not sitting on their laurels because the effort it took to get to level four, they are just continuing that effort. And they're definitely going to be the big winners in this new economy. Data is an asset in financial statements and on all the communications of executives. All development is within architecture now. All, let's put that in quotes, but awfully close to all of the development in the organization is within architecture. I didn't say it was all in this rigid framework that everybody has to do. No, but it's within architecture. Architecture only goes so deep. It talks about the tools. It talks about the flow of data within your analytic environment. But at least all development is done within the architecture, in these organizations. You're doing predictive analytics, predictive analytics, not just analytics, where you're looking backwards, you're looking forward and you're doing a pretty good job at predicting the future. Now, you may or may not, even at level four, you may or may not be doing full-on prescriptive, which is you're actually tuning that future the way that you need it to be tuned. You're starting to do that here, but you're at least doing predictive analytics. And you're measuring analytic maturity. And that's, you know, we're starting that here today. You're counting on your fingers already where you are for each of these four categories, I hope. Measuring your analytic maturity. And you do that on a regular basis. And you have your own methodology for doing that. And you get, you get, you measure that on a regular basis. And you want to see that improved. When I do my check-ins with CIOs and CDOs and ITVPs and so on, I ask them, you know, are we measuring all the people's performance based upon how they're growing their area? Not in how just they're satisfying users, but in how they're making their area more mature. What's meant by more mature? Well, I'm sharing that with you today. Are they making their areas more mature? Architecture. The thing I wanted to call out here for level four is they have dynamic three-and-five-year architecture plans. Some of you will go and do those three-and-five year architecture plans. Remember, that was level three stuff, right? Some of you will do that, but you'll adhere to them so rigidly that they will eventually fall by the wayside. And we don't want that to happen. You understand the need to continually revisit your architecture and your plans there for three and five years. And you're continually tuning the projects in your roadmap towards that architecture, even though it's changing too. What else? Technology-wise, you have definitely minimized cubes at this point. You're not just not using them. You're starting to turn some off. Everybody's got it, right? But let's move on. MDM, all functions for all major subject areas. All functions for all major subject areas. Wow. Now you're looking at things that are coming in the future that some of you out there need to be thinking about, like GPU database. Data catalog is now populated, and you're almost all in the cloud. And if I've noticed anything from this COVID crisis the past few months in terms of what's happening, what projects are ticking up, and so on, definitely it's those projects that are pushing things to the cloud. Organizations are finding out the downside of having to work remotely as we're doing without things being in the cloud. So that's coming on strong here organizationally. This is fun. Now you have data governance across the board by subject area across all major subject areas. You might say, well, William, what's left? You still got a level five out there. Yeah, the top one, two percent are still doing even more with this. But some of these were at the end. Data governance, you know, we've done a lot here already with data governance by the time you get to four. But you can just hold that in place as the organization changes. You are doing very well. Organizational change management is part of all projects. You have not only a CDO, you have a cheap information architect. You have full data lineage. You know where it's come from, all the steps it's been through. It's diagramed. It's modeled. And you have strong not only DevOps, but now you have MLOps. Yes, you have DevOps applied to the machine learning environment, which is its own discipline. I wrote a big old white paper on that recently. But it's its own discipline. And it's a definite way to manage your machine learning, which is going to be the crux of your development as you go forward. Data strategy level five. Now we're way up there for some of you were kind of blue-skying at this point. But here's why you should pay attention, even though this is the top, basically, percentile of you. Because next year, when William gets this talk, or when somebody gets this talk, this might be four. It might be more moving mainstream. Because, like I said, things keep changing. I've changed this model. If you've seen me give this presentation before, there are changes in here from the last time you see me give it because we keep learning. In the data strategy area for level five, data is fully discoverable. You are an AI organization. AI underscores everything that you do in that organization. Now I'm not saying that you do everything in an AI way, but you are definitely considering it for everything, considering it strongly. And when you consider it, you really fully understand it so that you can adequately apply AI. Okay, you are into hyper personalization when it comes to your customers. You are doing prospective analytics at this point, and you are producing products that's based upon your information. Maybe you're selling your data, but maybe you're turning your data into information product. This is, again, where I say the information professional needs to be actively managing and actively contributing to the roadmap of the organization, not the data roadmap, not the data roadmap, only the real business roadmap. What is this business doing and what's the strategy of the business? Architecture. Data infrastructure as a platform with domain mastery. So, complete domain mastery across the board, wherever that subject is touched upon, it is built to quality. It is built to a place where people understand it and people believe in it as well performing microservices and containerization in your analytical architecture. And now your ETL or your ELT or your data integration is more or less fully automated at this point. There's a lot of automation happening in ETL data integration and so on. And a lot of it is because vendors are, they are learning so much from their community and from their own IP and their own thought processes and they are making it into the tool. So, a lot of what we have done in data integration, my goodness, data integration is at an all time high in terms of adaption and usage out there. But as we go forward, it will remain very high but it will become more automated. Technology-wise, yes, you're into GPUs now. You have them. You have complete enterprise MDM. You have self-describing data. You have an upper-litical database because you acknowledged at this point that it's not just transactions and analytics. It's, there's something in between there. There's operations that need tons of analytical data. So, it's an ecosystem and the data is flowing rapidly across the organization at this point. You have databases at the edge in your IoT. Yes, database. So, not just flat-filed data stores out there but you're taking advantage of not only, and I'll go beyond this a little bit, not only the power of databases at the edge but the power of AI at the edge, AI processing at the edge of your IoT architecture. And you have embedded databases in your applications. Invented databases are not just for external products anymore. It's for internal applications as well. And the really smarter shops out there understand that technology is a service to the organization and it's really an app-building kind of organization. And finally, there wasn't a lot more to say about data governance but it's all and it's pervasive across the organization. So, have you been holding up your fingers or somehow, otherwise, trying to see where you are? One, two, three, four, and five. I'm not going to take a poll but now at least you have some sort of idea if you didn't before. I'm sure you did. But kind of where you are and where some of the, what some of the next steps might be. Now, next year, when I talk about this, I don't know. I don't know. Like I say, things are changing so rapidly. I'm trying to keep up. You're trying to keep up. But the leading organizations are pulling away. They're pulling away in their data maturity. They're really pushing the bounds of what is possible. They're doing that level five stuff that I just talked about and they're level four stuff. And they're going to keep going, like I said, because I can just tell the momentum that got them there is going to keep them going. So, some overall comments on maturity. And I do welcome your questions if you have any questions. I saw a few pop through here while I was talking in a few minutes. I'll invite Shawn back and we will address your questions. But before we get to that quickly, there's more maturity level in it, moving imperfectly than in move, merely perfected. Let me try this again. There's more maturity level and in moving imperfectly than in merely perfect, perfectly defining the shortcomings. I almost got it right. So, it's one thing to step back and say, well, this is wrong, that's wrong. Yeah, we can kind of all do that. But let's lay down some plans that we'll actually do to move forward. I know it's hard. So many of you are in organizations that push back on this stuff and maybe you've felt an acceleration lately. And I know it's hard, but it's really important for the business. Like I said before, data professionals should be proud, should be appropriately assertive in the organization about the importance of data, because it's so important to the bottom line of your organization. And I think we all kind of believe that as data professionals, but it's not good enough for just us to believe it. We have to share it with the organization and to get some others to believe it as well. Build our credibility. That's what's going to carry the day. That's what's going to help us when we have conversations to be believed. Don't be afraid to fail. And really, it's not really, okay, I don't want to get all pedantic about it, but it's not really failing if you learn something from it and you move some balls forward and you can pick them up and move them forward at a later date. So it's definitely important. I don't have it on here. It's definitely important to move in an agile fashion so that you're not architecting yourself into a hole where you're never going to be able to get out of. You can always get the value out of what you're doing every step of the way. All right. Don't talk yourself out of starting your maturity level journey. Maybe you're excited right now, but then you get hit with a request and it's all gone tomorrow. Well, let's not let that happen. Be sure you touch base, touch base with your data maturity, your organization. Some of you are CDOs and so forth. You are definitely in position to make this happen. So, but I say everybody really touch base with the maturity of your organization, your analytical maturity of the organization and find ways to move it forward. Have an open mind. No plateaus are comfortable for long. That resistance is not about maturity level five. Wouldn't we all love that? Even in the business, if you just describe this to them, wouldn't they love it? Yeah, they would love it if they could wave a wand and have it, but it's the journey that they doubt. Maybe it's the people in place that they doubt will take them on that journey. Maybe they're just not interested. But anyway, make sure that the journey is palatable, that you outline the journey as well as vision as you go forward. And finally, my big comment here, information is the next natural resource. Our economy is entirely dependent on the natural resource of data. We will not run out of data, but we may be overwhelmed by it. So let's not be overwhelmed. You won't be overwhelmed if you get moving up the maturity cycles of this model. And that has been my part of the presentation. And we have a few minutes for questions. I'll turn it back to Shannon to host the questions. William, thank you so much for another great presentation. I have a feeling, especially on the fantastic conversation that's been going on throughout that we could probably turn this into a two-day event. A lot of information here and a lot of different ways we could go. Just a reminder to answer the most commonly asked questions, I will send a follow-up email to everybody by end of day Monday with links to the slides and links to the recording of the sessions. And we'll invite Sean to join back in as well in the Q&A here. So diving in, you know, what about distributed data mesh as an alternative to the data lake? Well, I'll go ahead and start on that one. I kind of touched on that, didn't I, in Maturity Level 5, if you go back and look at that. I was starting to bring in some of those concepts. I don't know that that would be a full-on concept, but when I said domain mastery across the enterprise, that's what I meant wherever the data was, and that the data was engaged in sort of a mesh type of fashion architecturally. So yeah, in larger organizations, I see that as something to start moving towards as a kind of a grand architectural model, whereas a lot of the things that I talked about here were more pieces of the model that would fit together. Sean, anything to add to that? Oh, no, I think that makes a lot of sense. I mean, you know, everything is so spread out today, you really have to be agile enough to leverage all of it in that mesh kind of format. Data catalogs play into the presentation. Can you provide your definition of a data catalog? Yeah, I mean, this is like your your colibras, you know, what they provide, and so on. And these, these are, well, I don't want to say the word catalog, but, you know, these are, you know, pointers and links and definitions of where data exists in the organization. They've been cultivated. Hopefully some of the data is self describing its way in here because it's a lot to do if it's manual, but there's definitely some manual components to it. Hopefully, it's able to get out there and somewhat reasonably understand your environment from an automated perspective. We like to bring in catalogs and turn them on and see what happens and cultivate a relationship with a business meet that can provide the business definitions and context of how data is used in absence of that. There's some definite technical things that are valued that we can put into a data catalog, such as relationships and lineage and so forth. And these are, these are just some of the things that a data catalog can take care of from a very organized fashion, whereas without it, we end up inevitably kind of self growing some Excel spreadsheets and putting them on the internet and stuff like this. And it's just not up to the task of a level three, four, five organization. And Sean, feel free to jump in if you have anything additional you want to add in there. No, I would just I would just support William on those comments. You know, I think he's I think he's right on point. Love it. So, can you have a successful data lake without an enterprise data warehouse? Well, how do I take that one? I actually gave a whole presentation on that a couple months ago. I believe it was go back and check that one out. But anyway, yeah, of course, your data lake can be successful, because you build it independent of your of your data warehouse. I would say the value grows exponentially, though, as you put them together and your data warehouse is able to reach into the lake and get some additional data into the queries in a we can call it a virtualized fashion. That's where the the exponential value comes from. But the data lake also supports the data warehouse and pulling off some older data, you know, and pulling off some insights that the data warehouse comes up with as well as different things in the organization like master data management, even that data belongs in the lake and so on. But really, I want a super set of data in the data lake. And I want a subset of that data pushed off into the warehouse from there. So I'm going to use it as a glorified staging ground as well. Now, now, maybe, maybe the question comes from the perspective of, can I do my data warehouse in cloud storage? Because many people conflate the idea of cloud storage and the data lake. And I do too sometimes, Frank. So the answer to that, I think, is really a no. I think you today, as you provision your data warehouse, as you think about your data warehouse, I think you've got to keep thinking about that in terms of its workload in a relational database. Yeah, you know, I would agree with that as well. William, one of the things that I see a lot of our clients doing today is expanding that cloud data warehouse and in increasing layers within it. Yeah. And the generation layers and so on and so forth. And I think that lines up perfectly. Yeah. All right. I'm going to try and slip in one more question here. The question I have is whether you make a distinction between data modeling versus domain modeling that is a different level above the physical modeling of the data? I certainly do. And I agree with that, that domain modeling would be at a higher level. I think that can be done kind of quickly for the whole organization. You can bring that to a pretty good level of specificity for what it needs to be. And that is also a fantastic thing to do, not just prior to data modeling, breaking that down, but also to identify your data stewards in the organization and also to identify your subject areas. And the subject areas are going to be the means by which you're going to build out your master data management. So it has a lot of value to an organization and certainly leading organizations have an active, updated domain model, as well as the build out of various subject area data models in the organization. Not on that one. No, I think we're good. All right. Well, thank you both for such great presentations and discussion and thanks to our attendees for being so engaged in everything we do. Just love the conversation that's been going on today. Lots of good opinions and lots of good levels of interest and information there. And just a reminder, I will send a follow up email by end of day Monday with links to the slides and links to the recording of this session to all registrants. So stay safe out there, everybody. I hope you all have a great, great. Thanks, guys. Thanks. Thank you. Bye. Bye.