 Hello and welcome. My name is Shannon Kevin. I'm the Chief Digital Officer for Data Diversity. We'd like to thank you for joining today's Data Diversity Webinar, Data Strategy Best Practices, sponsored today by Cambridge Semantics. This is the latest installment in a monthly series called Data Ed Online with Dr. Peter Akin. 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. If you have any other questions, we'll be collecting them by the Q&A section or if you'd like to tweet, we encourage you to share highlights by a LinkedIn or other social using hashtag data Ed. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And to open and access either the Q&A or the chat panels, you may find those icons in the bottom middle of your screen for those features. And just to note the Zoom chat default to send to just the panelists, but you may absolutely change that to network with everyone. And to answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days containing links to the slides. And yes, we are recording and we'll likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now, let me turn it over to Sean for a brief word from our sponsor, Cambridge Semantics. Sean, hello and welcome. Hello there, Shannon, and thank you for having me and happy new year to everybody from a very sunny and unseasonably warm Boston. So we're very pleased to be sponsoring this first webinar and I thought I'd spend my time with a couple of remarks, really, to help people understand where we think we fit into the data landscape. Cambridge Semantics is a knowledge graph company, but we're rather peculiar on the knowledge graph front because we're, we're really about OLAP data integration using knowledge graphs. So as I prepared a couple of slides for this talk, I thought I would just kind of compare and contrast what these emerging architectures of people are starting to talk a lot about are and the ones you hear about a lot that these days are data mesh and data fabric. And what I was surprised to find as I read a lot of different definitions all over the web and is that the data mesh concepts I think is much better, better defined that the people writing about the data mesh don't have such a good idea as to what really the data mesh people are thinking about and doing so it's, it's quite interesting the data mesh approach. And so what I really did was collect together a list of snippets of things from different papers and different particles, which sort of highlighted what people are thinking about each of these two things data mesh would appear to be a sort of a human centric approach where where the production of data is devolved down to the domain of people who really have own that data and are ready to clean it up and look after it. And they are prepared to sort of offer the service to other parts of the business. And it seems to me that that really sort of is a kind of architecture even maybe a philosophy that fits pretty well with where most businesses are because you know it's really not particularly product centric and it's, and it allows people to build on more or less what they've got so it's kind of business as usual but with a spin around, you know, how are we going to devolve the ownership of data out, you know, away from maybe very central approaches down to to where, where it's best, best done, you know, according to philosophy at the at the place where from the point of view of definitions. One is that it's really able to automate everything using metadata and and instead it's a it's an approach that doesn't use humans at all and and those of you who I'm sure probably all of you have data experts. There's nothing at all at the moment that allows you to simply automate the process of data integration and delivery. So that seems like a little bit of a cannot but but it certainly is an approach where, where people try to take a wider look at the data in the organization from an approach where they want to create data products that's that essentially come from multiple and and graph technology is is being seen as a technology that really sits in the middle of that. So, so from my perspective, we're really seeing and I agree with the, you know, what what most of the people write in these papers that these two approaches aren't really antagonistic or exclusive in any way in fact I when I when we we deliver our software often as a data fabric, I'm seeing the same sort of devolved ownership also showing up which the data mesh people talk about in the same projects. So, I don't think it really matters. You know whether you're a data mesh or data fabric person I suspect you're going to pick the best things that make sense out of both sort of approaches and do what you need to do to get to get the business happy. So, talking about knowledge graphs, really where do they fit in for both of these types of approaches. The way I think about it isn't as an overlay. So it's an overlay technology that could be over a single domain and and help a business group deliver data out of that domain data mesh, or it could be people taking a wider view where it's a data fabric which really has to blend data from across an enterprise and even data from outside the enterprise and the product that we have that does this is an OLAP graph system. It's massively parallel so it can scale to a large amount of data you should think about it as a kind of a snowflake for for graph data, and it allows you to amalgamate or virtualize large amounts of data and connect it all up. So it doesn't overlay to existing technology so there's no, no, no need to throw anything out. Now why knowledge graphs. The reason is that we, we like them so much is because they're able to really give you a very true representation of an underlying reality that you're trying to model in a way that is just awfully difficult to do with with and structures like XML and JSON which tend to not be very good at the relationships between things and are kind of forced when you're trying to do that and end up being a bit impractical. Knowledge graphs allow you to really represent much more complex realities that that thing on the right hand side there with the thousands of circles and arrows and so on the lines connecting them up the edges. And that's a model, and every circle represents what in a relational world would be a table or even a couple of tables. Can you imagine trying to manage that in a, in a, in a data warehouse, not really, but knowledge drafts gives you the tools to be able to deal with something like that so it allows you to essentially in an evolutionary way. You can put data into a graph at a sort of logical level described at a logical level often described using the business vocabulary of the consumers of the data. And then when you have additional data you want to bring into this, this picture you simply have to find a place where, where the new data coming in, you can create a line between that and anything else on the graph and now that data becomes part of the graph to and thereby you can start a fabric of connectedness, which you can query across and ask very complex questions. And, and that's what we allow customers to do which is to create views into these complex data structures, which end up being the data products that they deliver. And as I said it's very easy to, to bring new data into the system by simply finding a logical place that it attaches. Well, this is one of our customers actually we sit on top of the Cedar data lake at the FDA, where they've built a 360 view of every drug submission ever delivered so far so in this case it's a moderate. Yeah, fairly modest knowledge graph it's it's 14 underlying data sources some of them with very complex schema. 300,000 drugs 73 years of historical data and millions of documents and you can see in the sort of really dumbed down view, how we build the graph out of those different underlying sources on the left you've got a table and the, the product information is pulled out and, and then you've got a second table in the middle and some documents on the right which you'd use NLP to extract data. And what you're essentially doing is is casting that into a graph, and we use ontologies to define if you like the template for the types of things or the model of things that we're storing. And so this is what a graph looks like but obviously you're seeing here you know a few dozen facts that we've stored but but a real graph like this one would be in the, the multiple billions of facts that we'd be storing in the graph engine. Let's have a look and the way we do this is is in a system that allows us to essentially bring in the data sources wherever they are sometimes we don't bring them in sometimes we virtualize them and queries that part of the graph are pushed down as push down queries. So it can be unstructured data so you can if you've got an LP that works that can extract facts from documents or tweets or, or really slides or emails or anything. Those facts can be brought out and each of them is stored separately in as sub graphs in the overall graph, and then we can use graph transformations to essentially coerce that data into consumable models that different domain users that and, and those would be data products. And then of course the data products are consumable through API is through dashboards, whether it be existing bi tools or our own codeless graph that dashboarding tool. So that's more or less how we assemble these graphs. Now, some customers are building out huge fabrics, and they're doing dozens and dozens of graph solutions, each of which leaves more and more of the underlying data exposed for reuse by other customers in combination with other data sets for other parts of the business. And here we have a large manufacturer that has is looking at over over years, building many many solutions that that readers data products across a wider, a wider graph that they're across their entire sort of as designed with the products are designed as as they make them monitoring production lines and what happened historically and then as the products are used in the field where they're generating data. And sometimes you're going to want to connect the data that's generated with the, the data that was in the design data to help you improve materials and so on and improve the designs. So this is an example of, of an active fabric sort of emerging somewhere in Europe. I'm going to finish there by just pointing you to resources. One is something I was involved in writing a year ago which is how to get started with knowledge graphs and the underlying technologies the triples the ontologies and just how to kind of bootstrap this and that's free and you can just download it we write it with a Riley. And the second one is a great book that I've recently become aware of and been talking to the gentleman who's the author which is data management at scale. There's about to be a second edition on my see from Amazon there's a first edition already. And I would highly recommend that book it's, it's the gentleman who wrote it is enormously experienced and, and I've really enjoyed reading it and please say we've got a few pages in it where we're describing how we fit it. But, but it isn't a really excellent book. So with that, welcome to the webinar and I'm going to hand it back to to Shannon and Peter. Thanks. Thank you so much and thanks to Cambridge semantics for sponsoring today's webinar and help kicking off the year with our webinars season. I appreciate and help making these webinars happen. And if you have questions for Sean, he will be joining us for the q amp a portion at the end of the webinar so feel free to submit your submit your questions in the q amp a portion of your screen for that. So now let me introduce to our speaker for the webinar series Dr Peter Akin. Peter is an acknowledged data management authority and associate professor at Virginia Commonwealth University president of Damon International and associate director, director of the MIT International Society of chief data officers for more than 35 years Peter has learned from working with hundreds of data management practices and 30 countries, including some of the world's most important. All books are many first starting before Google before data was big and before data science Peter has founded several organizations that have helped more than 200 organizations leverage data specific savings, which have been measured at more than 1.5 billion US dollars. His latest endeavor is anything awesome. And with that, let me turn everything over to Peter to get his presentation started hello and welcome. And happy new year to you Shannon and Sean thanks for a great little tutorial on the knowledge graphs will look forward to joining us back at the top of the hour as we finish up this particular presentation as some questions already in the chat for you so that's a great generates of interest around all of this. Lots of material today folks, and we're just going to dive right in I want to draw your attention to the Malcolm Gladwell quote here practice isn't the thing you do once you're good. You do that makes you good and I love that particular statement I'm a musician so I understand practice practice all the time. Bottom line up front is that in looking at more than 20 years of multi page data strategies they just aren't terribly useful as the first one. So when you spend time trying to perfect something at the beginning of your journey. You lose the opportunity to invest equally into the process component of that so cycling through improvements is a better way to think about using data strategically than a grand plan a little bit of context your strategy is a repetitive process that can be improved. There is dependency in the sense that the data strategy exists solely to support the organizational strategy that that evolution of the strategy should be looked at in context of providing additional capabilities or improving the existing capabilities that you have, and that the actual outputs the plans are limited value just go back a couple of years and look at everybody's strategic plan that didn't include being locked down for a couple of years. Well we waited out a pandemic on this. Lots of plans also over emphasize technology and I think one of the things that Sean said, in particular, is that there's a lot of things that we can do that will knit together many other things and we'll come back and revisit and the last one is a musician's question how does one get to Carnegie Hall or Nirvana or wherever one is trying to get to and the answer is practice practice practice. So diving right in we're going to talk about what is a strategy how does that relate to data and how did the two work together we're going to look at data strategy in relation to data governance we're going to look at some very challenging research which seems to be the part that most people leave out of their plan on this and there's a then repeating process that we can put in place that will help all of us get better and as I said we'll swing back around about 45 minutes and do some Q&A on all of that so let's dive right in. And first of all, many people think that strategy is complicated it turns out it can be made complicated particularly as the price of the consultants go up higher and higher. But what strategy is really all about is doing the same thing for most of what we do and changing some aspects of it. That point of changing some aspects of it. We really have a very good opportunity then to move forward. The way to look at this is a wonderful talk from Simac if you still go back and do Ted talks. He starts out his by saying people are pretty good at describing what they do we're less good at describing how we do it and we're not very good at all about describing why strategy is what must provide that why in order to do it and this is sort of self evident at this point. What motivates people isn't what you do people don't look at what I do and say hey I want to be a data evangelist which is by the way a great job on this but it's that we can use data to help people out and the why is the important part. Again to pick a particular quote here Martin Luther King had said I have a plan. Instead of I have a dream. It wouldn't have been quite as moving a speech around that or as effective as speech as well. So what is strategy while we start out. First of all by understanding that it came from the military and that only about 1950 or so did the business group start picking this up business consultants and things. And they've moved it into this idea that it's a master plan or a game plan and in all of these things are good but it's really not the way to think about it and it's not how it was originally used. See in the business world a strategy is much more of a thing. Whereas, if we go back to the military origins of it and the definition from the military is a pattern in a stream of decisions. Well how does that actually work out turns out pretty well and more importantly you'll see that the second definition is a process oriented decision, which says when we're making decisions we ought to be looking for certain types of things I give you a couple of quick examples on this. But at Walmart, the business strategy if you do anything with them or understand anything about the company is every day low price. That's not anything super secret in fact they've done such a good job of making sure that everybody who works with surrounds is in contact with Walmart understands every day low price and more importantly, when a technology or business person within Walmart is making decisions if they err on the side that supports the business strategy, there is no discipline that occurs around that. Second example of strategy here is Wayne Gretzky. We're not necessarily in Canada right at the moment but if you know anything about him he's got a great strategy where he says he skates to where he thinks the puck will be. And of course if you're chasing a hard plastic object around the ice you will never catch up with it. In that context, a lot of really good stuff on the Wikipedia page that expands on his idea around here let's take a third example of strategy just very briefly how do I beat the competition when their forces are bigger than mine and the answer of course is divide and conquer. That is again our pattern in a stream of decisions. So I'm showing you here, lines of supply that in this case the British are shown in red and they are supplied out of Austin that I've circled in the upper left hand corner of your screen, and also facing blue Napoleon and blue is the Prussian troops and they are supplied out of Austin which now Napoleon being a master strategist said great. The process of divide and conquer is literally perfect for this if I hit them in exactly the right place I'll do it here one more time just to make sure that you can see that I can get the two of these armies to fall backwards. If an army is falling backwards they are much more likely to fall towards their food rather than away from their food. So this is a brilliant bit of strategy we're not done yet however we still have to go and continue. Again that the smaller force remember Napoleon's and blue has to turn around and defeat in this case the Prussians first, and then go out and defeat the British. So again, great example of strategy this is still taught in us DoD schools that we have it turned out it wasn't successful that's a different issue but we understand it as a strategy and let's take that third strategy apart for just a minute so let me get this straight this is the people who are receiving the strategy and they're saying, they hit both of the opposing armies at us at once at just the right spot, and then we're all going to turn right and defeat the Prussians and then we're all going to turn left and defeat the British. And oh by the way, will you please do this, while somebody is shooting furiously at you. Well that's probably not a recipe for success it certainly wasn't in this particular instance in here. Think about strategy again if you've got a book and says well here's we are the good guys and here's the bad guys, and here's how we proceed that's great, but you're going to need a different plan if the good guys us are up here, and the bad guys are down here, or vice versa if the bad guys are up here, and we are down there where each of these is going to require a different kind of planning. Remember again, a pattern in a stream of decisions and more importantly for what we're talking about in the business world because we're not actually out there trying to conquer France or anything like that strategy guides work group activities, whether they know what the strategy is not they all work towards what they think they know is the correct strategy around this. And strategy of course that winds up on a shelf is just absolutely useless. And so we have to be able to pull something off in order to do this. Again, you saw this if you saw the adverts for this particular webinar in preparing for battle I've always found that plans are useless but the planning is indispensable thank you Dwight Eisenhower. One of our former presidents around this or Mike Tyson if you prefer to go with him, everybody has a plan until they get punched in the face. So how about a data strategy here it's the highest level of guidance that's available focuses on data activity, excuse me I said it wrong focuses data activities on business goal achievement and that really is key so I'm glad I caught myself and didn't say it wrong provides a question based with a stream of decisions or uncertainty again, your data strategy most usually articulates how data can be best used to support the organizational strategy, but it almost always involves a matter of remediation and proactive measures there's a lot of data debt in our organizations that we need to work within when you're measuring the effectiveness of the data strategy we should be able to determine it's effective as over time. We should also be able to observe that his length should be shorter than the organizational strategy if that's the case and the organization is quite good at there should be versions of the strategy, so that when you hand people version one of the strategy and then you achieve it, and then you hand them version to they're not confused. So hopefully there's a way of measuring common understanding among all of these pieces. And if you really did want to put it all on one page here's a good way to do it this is courtesy my good friend Chris Bradley over there but I don't recommend this because it's not going to be language that people can understand that said it doesn't hurt at all to put what you're trying to do on an infographic so let's look at our two planning options that we have here. There's an entire process at the beginning where you can use iterative strategy cycles, and those strategy cycles give us the opportunity to incorporate corrective feedback in here, and use this in a way that helps your data program over time increase its capacity and performance while changing the focus from reactive to proactive all the way around. In order to do this and yet what I've seen over over over again from organizations is that they'll go in and I said well, our strategy is data science right well that's not a strategy. And I'm pretty sure that Sean will agree with me on that when we get back up in here as well. So let's just do a quick recap. So what is a strategy and again it's not a thing it's a process, and a data strategy then is the idea of supporting the organization's process with data, and that's the best way we can get them to work together, looking at this pattern and a stream of decisions. So I'm looking at a context here and say I have a particular strategic focus and we're going to call it space again physical space for example, we might, you know, hit that one first, and then come back and focus on a strategy that we're calling cost in order to do this. The data strategy is absolutely necessary for effective data governance in here now I'm going to put up seven data governance definitions please don't read them because I'm going to tear them all down here in just a second. Just imagine, in this case, trying to talk to somebody about it or better still getting on an elevator with a top executive who looks over and says hey Peter you work for me. It explains me a little bit about what this data governance stuff is. And of course as soon as I try to say hey it's about a decision decision rights and that you know I'm not going to have a good conversation. So I like to keep definitions short enough that executives can focus on them and understand them usefully data governance then is managing data with guidance. So if we look at it from this perspective. First thing you might ask is it also for not managing data with guidance. We're managing data without guidance. That's probably not a good idea around that. Similarly, I also as we go higher in the organization more towards the strategic level. I changed the definition slightly as you can see there, not just managing data but managing data decisions with guidance and that is really critical because most people don't know they're making data decisions, and that's something we have to work on is making them understand this because data is the only resource that we have that doesn't deplete doesn't degrade it's a durable resource at the strategic level. And when we compare that to other assets that we have it really compares very favorably winning in many cases and some people's ideas. The asset of course is that data is not the new oil. Everybody says this if you Google the term you'll see 5 million hits on it. I like to say let's just put a word I mean a letter out in front of that oil part and call it soil. There's two things that are important from that perspective the first one is that you don't just randomly garden by flinging seeds about the yard and hoping good things happen you carefully prepare the bed. You put things in it carefully and you nurture them as they're growing. The other part of it that's important is that you don't plant things on Monday and expect to eat on Friday. It takes time to nurture in this case. On the other hand we do need some sizzle in order to sell this stuff so whatever we can do to make sure that people are paying attention to it. So that is fabulous but as an asset then what we really have is the idea that data deserves its own strategy it has attention on par to similar other organizational assets and it requires some professional administration to make up for past neglect. Now just very briefly here. An example in 2020 American Airlines was valued by the marketplace value of the stock at $6 billion. And yet their data in their frequent flyer program was valued at tens of billions of dollars more than that. The same thing was true here for United. I contend that this is the data debt that most organizations both organizations are facing, which is the idea that you can't start off in a straight fashion and simply apply new stuff. You've got to get back to zero and it involves undoing a bunch of things. And now you get to go out and try to do even better with all of this so data debt slows progress decreases quality and increases cost and it's a major barrier to using data strategically in your organization. When you look at it from that perspective you're really talking about also separating the wheat from the chaff around this and that much of your data is not as useful as people seem to think it is. First place to start off with is is well organized data worth more. And I think the answer to that can be proven. Yes, just going back to our pre information age metadata. In the old days, of course, if I just handed a series of pages to you without putting them in order and giving a table of contents and things like that, it wouldn't be useful. In fact, if you want to make it a very graphic, just grab somebody's book, take the tap off it. Again, remove the spine and pretty soon the knowledge starts disappearing very, very quickly. Well, of course now we've proven that better organized data increases in value. And now I'm going to give you a very disappointing statistic that 80% minimally of your data is rot, rot as an acronym that stands for data that is redundant, obsolete or trivial. And when you think that most enterprise data is never analyzed this does represent some very nice savings opportunities and ability to pare down the general problem, problem space and all this. So who would be more uniquely qualified to accomplish this but your own folks who really do understand the data. Now, strategy and governance has to work together I mentioned before the support for the organizational strategies the only purpose of a data strategy and data strategy is what focuses the efforts around data governance. So what are the data assets doing that could better support strategy and how well is that data strategy working. Similarly, however, in Peter's world at least Peter likes to have data governance have an impact on it and it projects as well that's not currently the case in many organizations but it is getting closer to that I wouldn't show everybody that picture I'd instead show this one which is a little bit simpler and adds in our real worker bees in this context are data stewards. Now, our goal here from a data strategy is make sure that it's expressed in terms of business goals, and that the language of data governance is in the data because only by including those two components in here can we really make the efforts that are doing in data governance and data stewards, really tangible to management so that they understand why we're doing things and how it's going. Key for this obviously is to improve your organization's data improve the way people use their data and improve how people use data to support strategy that's a three part process which is a lot more than just making data of better quality. Next chunk here we're going to dive into prerequisites and these are the things that we need to do in order to work with us starting from a neutral position whereas most organizations are starting with a deficit. When somebody is approached from a strategy perspective the typical approach for most consultancies is to come in and say business needs. Great. Here's our solution. Again. This is wrong. Thank you for allowing me to sample Morgan Freeman there and say that is wrong. Why is that wrong. Well, it leaves out the most important component of it which is what is the current maturity or state of the organization that does exist. Again, imagine having the hand in the keys to your brand new Tesla to a 16 year old driver, and it's just snowed and, you know, atmospheric hurricane or whatever it is and telling them to go out and practice right well, you wouldn't expect good results on that. Similarly, if we don't find strategic data imperatives that are matching our capabilities and our business needs, we will not be able to implement this data strategy then is implemented in two phases. The first one is a series of prerequisites. The second one is once we have gotten off the ground and are flying we want to develop a repeatable process. We're going to get through three sub phases in that phase one, prepare for dramatic change and determine how to do the work to recruit a qualified data executive in order to do this another talent that we're going to need and then three eliminating the seven data. So we're going to start off with a dramatic change piece on this and this is really not at all surprising when we talk about CIOs are really not the chief information officer. In fact, when I wrote one of the first books on it the case for the chief data officer, and they translated into Chinese, the title came back chief data officer combat, which I thought was wonderful, because now we're asking in this case a CIO who has the title information in their title and chief data officer. Well, they're both kind of fighting over the same thing are they not now I contend that most CIOs are really chief integration officers or chief information technology officers around that but whenever we bring these two individuals together there is confusion uncertainty and doubt. So there are a couple of really good examples of how to do this I don't have time to get into them here, but what it really evolves around is change management and leadership and there are a group of dedicated professionals who do a great job helping organizations think about change. Now, this is something we're going to have to explain to our younger generations this is a physical lock that you're looking at obviously it's the way it keys on this but turns out that organizational change from a strategy perspective is about the same kind of a process. When I look at an organization, and I see, I'll just pick the middle line there vision skills incentive and an action plan but I see frustration. I know they're missing resources, and this is a wonderful model here done by Mary lipid, who did a great job and the point of the diagram just like the key is that unless you have all of these things lining up at once you will not change the organization. So it's great to do this and culture is the biggest impediment to shifting organizational thinking about data you can't just say we're going to do data better and not have an actual plan in order to do this. I have a absolutely free of charge case study that you're welcome to download. If you want to learn more about that particular piece. So, prepare for dramatic change because it is a different type of a world that we're working to recruit knowledgeable enterprise data because if you want to call it a CDO that's okay as well. And I'm going to talk about Enron and you may go wait a minute how did we get there sorry to give you a little bit of whiplash but unfortunately most people don't get the lessons that came out of Enron now first of all I'm going to talk about the book being a great book to take to the beach it's a really wonderful description of the whole story, but Enron in 2001 suffered the largest chapter 11 in history. In August, their stock was down to 26 cents a share from a high of $90. And from having been listed as the most innovative company for six years in a row, turns out they were the trickiest criminals that were out there in a row. And as they were circling the drain and about to go under, they got married to a company called Diner G which brought seven, excuse me several billion dollars in dowry to them they just said we'll get we think you're a great company we want you to keep going because there's a bunch of money and Enron spent the entire amount of billions of dollars in a week and this is the time you know when you're getting together with somebody and getting married or learning about relationships and all that sort of stuff, probably a good time to have a conversation about how you manage money before you do anything serious about it. Enron and Diner G didn't and Diner G found out that any person that Enron could write a check for any amount of money for any purchase at any point in time and they went back to Diner G for more money at the end of the week and Diner G said what happened to the several billion dollars that I gave you last weekend and Ron said, I don't know. Now, everybody, I believe, agrees that that is not good fiscal management it is in fact bad fiscal management. And that we know this because we have objective qualifications for leadership in the finance area CPA masters of account and see other types of things. But what's going on with people who work with data that would be the definition of a knowledge worker I believe we teach them generally and have taught them generally nothing about it and yet 100% of them use it. Every single day and it professionals even less we teach them one course and how to build a new database, which means that smart managers who believe in the curriculum that we've been pushing for the last couple years and I'm saying this as a university we haven't done as good a job in that area as we could because they think we don't need people in this because we're not building a new database we're merging two databases I have literally had those conversations with business leaders around that. And of course, if we've taught them nothing but how to build a new database for the last 30 years. Is it any surprise that one of our biggest problems from a societal perspective is that there are too many during databases out there. I think Abraham Maslow that is absolutely correct. This leads a lot of organizations into something called a bad data decisions spiral. The idea is that most business decision makers are not data knowledgeable and consequently, the technical decision makers are not either that leads to a falling down of the creek. It just goes further and further and further. And if the technical decision makers aren't any good about this we get what we're called bad data decisions. And if we have bad data decisions that results in poor treatment of data assets and poor quality of data, which leads to poor organizational outcomes. Yes, lather rinse and repeat how do we get out of this well. Thank you again Morgan Freeman yes it is wrong. Consider an example, implementing salesforce.com a decision that might be made that wouldn't be recognized as a data decision might be that we want to have Salesforce installed by let's just say January 1 of the year but if you put Salesforce out there with poor quality data in it I guarantee you that the customers of Salesforce will not be able to tell the difference between Salesforce and Salesforce having bad data in it. The lack of focus around data has been really problematic again, we have CIOs that are up there, but they're not doing the same kinds of things that our chief financial officers are doing and the chief financial officer doesn't balance the books the risk officer doesn't test the software, the medical officer doesn't perform surgery, and our hiring panels are even less likely to acquire good data help. So how are you going to get access to good quality people. Talk to some specific headhunters who specialize in it but do not assume that people in your organization have the ability to go in and select a good data leader in there unless they've had some specified training. So we need a top job in this area. Again, I like to call it the top data job enterprise data executive chief data officer whatever we're going to call it. They're going to run a data governance organization and other things. And they should be dedicated solely to data asset leveraging unconstrained by an IT project mindset and reporting directly to the business. Now the challenge that we've had around this is that most of them get that process started and they kind of make people upset. So it's nice to have the ability to say, you know, maybe you should rent that first strategy data leader and do something along those lines without having to dive into it just that far. Let somebody else take the grunt, the brunt that has to occur as somebody is going through this and really upsetting things. The last component of this real quickly are the seven deadly data sins. Again, they are not pride and envy and greed and hatred on this but there are seven of them there I'm going to start with number two which isn't most organizations don't have qualified data leadership. They are not able to implement a robust programmatic means of sharing data. They're not aligning the data program to the it projects failing to adequately manage expectations, not sequencing data strategy implementation. Again, I'm going to give you just an example on that one here just so that you see they're not just empty words. Most organizations when they're doing data strategy have a choice of two outcomes. These will be faster better cheaper, as in our internal processes will be better, or we'll do something innovative, and the innovative stuff may or may not be profitable so it's really critical to start out with the save some money so that people don't have any question as to what it is that you're doing today. 7th one, of course we're counting six is here, failing to address the cultural and the change management challenges is a sure way of failing this but the number one piece there is not really understanding data centric thinking. Collected words over the years people like to use these different ones to say hey data driven data centric focus first provocateur whatever it is all great sentiments and wonderful things to do but what does any of this actually mean and I don't think anybody has anything concrete on it. So once again, I'm trying to put a little bit of meat on the bones here and I went back to the agile manifesto for software development just to see if I could get some inspiration from it and it turns out. We've absolutely agreed as a society that the fastest way to develop higher quality software faster. All right, is to follow agile practices. But here's the source of agile. It's literally those words on the left hand side of your screen there. So I thought maybe we could do something similar here and look at something I'm calling the data doctrine here and it starts out exactly the same way that everyone does we're uncovering better ways of developing it systems by doing it and by helping others do it through this work, we have come to value. And again you'll notice there are four things down below and just like the agile manifesto. Absolutely while there is value to the items on the right, we value the items on the left more. So that's an important component let's walk through a couple of. Sorry, each of the four of these things what this really means is that an IT program is often seen as developing capabilities to an organization, certainly implementing mobile in a group that doesn't have access to mobile. Makes perfectly good sense. On the other hand, if we don't put anything on those mobile devices that is useful to the business, having that technical capability is not important. So the data program must drive what's happening in the IT programs. That's one measure. We at the second one look often at oh we've got to get everybody off of Windows NT now just a little quick side note here but the US Navy for several years has paid Microsoft millions and tens of millions of dollars to keep NT platforms running on some systems that they had for a while there. Those systems were very good, but they couldn't actually port them over to Windows 11 so what is the business value of getting Windows 11. Well, if Windows 11 locks your security down and prevents your organization from having a data breach that's really great but generally you're not going to get a really good bang out of that particular buck so informed information investing on the left hand side of that equation. There's shared organizational data that has some stability over it components that are evaluated in there. Once again if I've got an opportunity to do something cool with technology which is great or I've got the ability to develop and make maybe a pile of data that's good in one part of our organization, accessible and useful to another part of our organization. It might be a very, very, very much appreciated investment in that context here and finally the last one is that we have data reuse over the acquisition of new data sources I've already given you the statistic that 80% of the data in your organizations is redundant obsolete or trivial. And at the same time if we can reuse data that would work. Now I've worked for many, many different organizations over my 40 years in the business here, and one of the first questions I always get asked when I come into organizations is, Peter, can you go out and find out if we're buying our own data from somebody else and the answer has always been yes, I've always found that that organizations are actually paying for their own data to come back to them through some sort of advisory service or something. Absolutely hilarious to look at that. So let's think about these things and this may not be right for your organization but I think it puts a little bit more on the bone and saying, hey, we're going to be data driven. Well, this is what it means to be data driven in this particular context. So let's go back to strategy here again we've talked about the lack of organizational readiness which is why most of these again just imagine. You know, you're at the top of a ski slope and somebody says well you've never skied before but don't worry we've got the trail all smooth and here's some great technology that'll help you. It's probably not going to be a good outcome on that. It's going to not compensate for these lack of competencies here that we really do need to have from a data strategy also people that can implement that strategy in support of the organization, and look at those seven deadly data sins to see how problematic they are for your specific environment in here so the last component here then is what I like to call lather rinse and repeat. Now of course, if you were reading the shower, excuse me reading the shampoo bottle in the shower, you would never get out of the shower because of course it's an infinite loop and it's not going to be helpful with this but it is a shorthand for iterative and more importantly, iterative improvement around these things. So again, we are right here now at this we've gone through phase one we've prepared for dramatic change we've recorded a qualified knowledgeable team to do this or identified it from within the organization, and starting to eliminate the various data sins that we have out there. Now we're ready to start practicing, and there turns out to be a five step process that hopefully will break you all is not anything terribly original because I don't believe in reinventing the wheel on this but let's just look at the iteration here identify the primary constraint keeping data from fully supporting strategy in this particular environment, which means you have to not just look at volume of data but you have to look at how much the volume of that data is in that context, exploit organizational efforts to remove that constraint subordinate everything else to this and elevate the data constraint. If that doesn't work. Start over again so there you have it lather rinse and repeat let's look at it in a little bit more detail first of all let's go back to the data strategy framework here remember again, not the best thing to do by simply going out as a business need but only going forward when I have a match between a business need and an existing capability at the organizational level, then I can start to plan out the execution which means we get a roadmap and from this roadmap perspective it's really really important to balance your activities. Now I've had a CEO one time, tell me that they had given the data group I'm sorry CIO one point tell me they did gave the data group five years to come up with some value, they know it was going to take some time to get running, but the problem is most CIOs are still only lasting two to four years according to Gartner on this. Now, the balance part of this is that if I'm showing only business value on the left hand side, I'm likely airing so far on that business side that once I finish getting value I won't have the ability to go back and find another trove if you will another place to go in and do some data work. So we also have to look at the right hand side of the diagram here and balance the business value from new capabilities, because we do need to have things that we in the academic community haven't taught it people to do business people don't understand how to do this stuff so we're going to have to learn some new capabilities in order to come up with the way these things work and this is what I mean by a balanced framework here where you have some business value and some other ways to do this. And there's a couple other books out there on data strategy it'd be foolish to pretend that there weren't and when you read them they they kind of say that well data strategy really needs to be the sum of your data governance strategy and your metadata strategy and your data quality strategy. I'm not going to read the rest of these but you get the picture. My first question is and I wish we had insta polls here is you know how many of you have even one of these nine things and I didn't even list all the things I could list. So, trying to say that your data strategy is the summation of all that is not really a good way to do it. Again our third sample of Morgan Freeman there right. Yeah, it doesn't work that way so what does work. Well again, if I attack this with a particular method I'm going to call it strategy cycle one in this case. So follow this process that I just described for you very briefly through there and if I erase it at that point, then I've saw that particular strategic objective if I haven't, I need to go around the wheel again, and rethink the process. Hopefully this is putting some of your minds in memory of some things that will become obvious in just a couple slides on this to take a look. This is a strategy cycle to. Okay, remember we said we're going to have versions, and that idea would be a version to we're going to work on cost in order to do this. So, this allows us to focus on data debt in particular, finding the highest value constraint and practicing valuing things as well, if the constraint is not addressed start over again in order to do it. If you haven't already seen through here, yes, this is the book that I'm drawing from inspiration on this and it's called the goal if you haven't read it as a famous business text. And what it talks about is something called the theory of constraints, any system is going to be limited in achieving goals by a small number of constraints. There's always one constraint, and this focusing process, find the constraint, restructure the rest of the organization to address it, find that weak link in the chain. Because if we haven't gotten rid of the weak link in the chain we're more at risk than other parts of the organization in order to do this. And this whole process here is not new, it's a 30 year piece and the wonderful thing about it is that many people on the business side will also recognize this as a very appropriate way to put strategy in place in organizations. Each cycle therefore, as a specific focus, we're going to do something to achieve some goal in the theory of constraints generic plan. It kind of looks like this. We can start out here by identifying the constraint that's just very simply stating the problem. Then we exploit the constraint, we make decisions about how we're going to take that constraint if you recall the book the goal at all they had a new piece of equipment that came in. So the first exploit the constraint question was, how are we going to use the new piece of equipment. Now, really, you all may be buying a wonderful product from Sean. And so your first question is how are we going to use that particular constraint to do that. Now, if that doesn't immediately fix things, your next step is to subordinate all of the non constraints the key there is to work effectively, not efficiently in that because most often the cases when we find things and add a new variable into our system. It changes the way things work around. Then our process overall is throughput. So this is now looking at alleviating the constraint attempting to increase capacity in light of new system demands and non constraint surplus that we have in there. Again, you'll see different organizations treat these in different ways but it's a very, very sane and repeatable process know by the way if we haven't fixed it, we need to go around and rethink our specifics that we were looking at and gosh golly in a data strategy cycle it's the same thing. What can data do to best support the organizational strategy. How can I use this new constraint to most effectively gain more out of my existing system. How can I get things out of the way so that this constraint can really shine. How can I now use the value that has come in that organization to further improve the productivity of whatever constraint. I'm attempting to relieve the capacity of and again leather rinse and repeat. Again, though, if you think about this, this should look an awful lot to you like plan, do, check, act the famous Deming quality cycle. And once again, I think that's a really good way to do it. If they haven't heard of the goal. They will absolutely her have heard of Deming and quality cycles and plan, do, check, act. So a very good way of picking up and leveraging existing things rather than having to come up with a brand new methodology which isn't going to do anything other than what you're dealing with already here. We've got a few more minutes here as we get back to the top of the hour but I want to particularly draw your attention to the way in which most people go about this and if you haven't seen this wheel here before it's literally my fault. So we produced this first version in 2009, and now the second edition 2017. It's called the data management body of knowledge the dimbock wheel. Now, by the way, I'm looking for people to help us with all of these things because this is when you take a bunch of data geeks together and this is a very clear strategy. We end up saying well pimbok called there's the pimbok. So we'll call ours the dimbock right now. We might be able to do better on that but that's a separate area as well. The goal of course is to look at this diagram and see data management 11 separate practice areas centered around data governance one of the 11 in order to do that. There's a couple of things wrong with this diagram here and I think it's okay to critique ourselves and try to challenge it to do better so I'm challenging you all. One of two things this diagram doesn't show as data people dependencies and sequencing around this optionality. So, one of the things that happens here is that people look at this wheel and they say oh my God as a data strategy I have to do something for document and content management. So you don't. What we were trying to say here is that this wheel has these 11 practice areas in it, and that if you're doing things with document and content management, they should be considered from a data management perspective. But I do understand how people could look at this and say oh my goodness. You know, I must do all these things. No, these are optional activities that you can do. And the other part I mentioned before was the dependency as well. It's probably a good idea to start with governance and then work out from there. But depending on where your organization is in its journey. Any of these maybe good starting places to get started. Let's take a look at sort of three iterations around a relatively common set of activities which is that the organization is saying I'm going to pull some things and I want to do more with my data. Well, rather than think of this as I need to have something that goes on in all 11 areas. I like to think of structural dependency. Think of it as a three legged stool if I had a stool that was two legs, it wouldn't work it was one leg it wouldn't work if I had for it would work. But three is a good number. Three is a really good number and what you want to think of from a strategy perspective here is that my characteristic the business problem that I'm attempting to solve is going to be going into a different sort of a category here. We're going to do this for once. We'll look at it from warehousing and quality management and governance, but then the next time we go through it we may discover that we should have been looking at metadata in addition to data quality. Now I get two pluses for the data warehousing and data governance pieces but one X each for data quality and metadata. Finally, perhaps our third time says maybe we really should look at this as a formal reference and master data type of activity here. So this is how you can pull these things into play and get them to start working in a fashion that will work in a much more concrete way than it will if you're trying to do all of it or just one of it three is a really good number on that. So again remember strategy helps your data program over time increase capacity and improve operations and change our focus from reactive to proactive around this. And once you've gotten good with one group of people who are doing this well. You can now start to look at improving that process and spinning off other cycles that you can implement in order to gain some multitasking around the whole activity. We spent some time here we're just about at the top here data strategy specifies how data assets are to be used to support the organizational strategy. You now know that strategy is much better implemented as a process than a product. You know that data strategy is the thing that you do to make data more useful for the strategy of the organization that's how they work together, and that if you want to improve your organization's data, you need also to improve the way people use that data in order to support strategy So second two steps in that process you will not have good success. Finally, lack of organizational readiness failure to compensate for data competencies and eliminating the barriers to leveraging data are three things that people have to do in order to do more with your data. And then finally we get to the iterations part lather rinse and repeat. This is again Malcolm Gladwell's quote practice isn't the thing that you do. Once you're good practices the thing you do to get good in order to do that. So, again, bottom line up front, large amounts of investments in a physical strategy that's a written document are generally less useful than the process of instead trying to get better about working your data to all of these activities in here. And again finally cycling through cycling through these series of improvements in order to do that. And we are right back at the top of the hour and if you want to know what Bruce Springsteen is you'll have to ask that because that's a completely different question. So again, we're back to you and invite Sean back in. Peter, thank you so much and Sean thank you so much for these great presentations and for kicking off the webinar new year with this amazing talk. Just answer the most commonly asked questions just reminder I will send a follow up email to all registrants by end of day Thursday for this webinar with links to the slides links to the recording along with anything else requested throughout. So please come in starting with Sean's presentation. Um, so, which you need data mesh first in order to ensure the business meaning of the data is understood and documented before data fabric can use that metadata and deliver quality data. The short answer is, no, I don't think so. I don't think it's a question of going for one, you know, whether you think about data measures or data fabrics. I really see them as methods to achieve, helping you understand your, your metadata. I think, you know, putting together actually this has been a wonderful talk and I've really enjoyed listening to it given the given my own experience of customers and where they are on these and what a dramatic difference it makes. And bringing this back to metadata I think putting in place a strategy for for understanding your metadata is is paramount and it's orthogonal to whether you're choosing to use a data mesh approach or a data fabric approach or some kind of hybrid of both which is actually closer in my opinion to the reality. So other kind of more tactical approaches that are within those wider approaches to dealing with metadata but having good metadata is one of the most important things you can do to sort of set yourself up to, to, to be able to lead further down the line with things that build on the metadata, but I don't think you should rush out to say I've got to do a data mesh therefore, before I can fix my metadata. I think you can, you can look at metadata discreetly and and look at the practices around that specifically. So that's, that's where I stand on that. Can we add a piece on to that as well is there anything in what I'm showing on the screen here now where the graphs wouldn't be useful. Probably not, you know, you know, the thing about a graph is it really mirrors the way we think I think that's why people like them they like to see the pictures. There's a certain practical element where it's just too much overkill and it's more than you need. There's a lot of issues with the general as humans and this things connected to that thing and everything in the end is connected through through relations to everything else so graph is a very natural way of expressing things from a technical point of view only makes sense to really go to the trouble of putting that into software for for problems where where it makes sense but so I wouldn't necessarily maybe document a strategy as a graph but some people do if they if they have a complex enough strategy where it actually merits the effort. So there's a little bit of we're naturally attracted to graphs and sometimes the right actual technology to use and sometimes they're overkill or this is more practical solutions or maybe more historical solutions that are better proven and so on. I want to emphasize also the first book that Sean talked about at the end of his introduction there is a free download, and it is such a useful book we've used it in class here at the university, and I know several other data professionals that swear by it as well so just reemphasize if you do do not get a chance. Do anything else go download that look that book there because it's a really great overview. When it comes to metadata that book does tend to start with the metadata and how graph technology can really help you with a better strategy not just graph technology but the the knowledge and semantic technologies that often parking parcel of knowledge graphs. So there's a fair amount in that book which describes how to get started with a, a metadata strategy. How does one actually get an organization going to to repair repair usually the chaos within them and and come up with something coherent so we which we me and my co-authors really tried hard to come up with some ideas but how you know what what you're aiming for and how you get started with that. Because it does tend to start whatever you whichever kind of part of this journey you're you're you're attempting to go on it metadata will inevitably be a some some part of that which will could could be the difference between success and failure. Is data fabric similar to semantic layer. They're often used synonymously yes and also knowledge layer. So the answer that yes we see customers calling them all of those things. Data fabric is sometimes less than a semantic layer as well when when often from competitive vendors who have have less of a semantic bent to their products. And by semantic I tend to mean semantics based on standards from the W3C so standards that allow you to really describe data in a way that makes it abstracted from the systems that created it. You know, today, systems that generate data are tend to be generating it in a fairly idiosyncratic manner based on however the people who developed that system decided was the best model internally for that application or wherever the whatever's generating the data. The standards from the W3C allow you to describe the data in a way that is neutral to applications and abstracts it and therefore. Future proofs it so when I talk about semantics I really mean knowledge representations that are based on standards that we can, which where the data will be understandable 20 years from now long after the software that generated it is gone. So, and other people have a lesser definition of semantic usually around enterprise dictionaries and taxonomies and more informal organized but within their businesses but but but organized. But that don't translate as easily directly to to a standard representation for meaning that can be shared with other organizations very easily. So the plenty of semantic layers out there but not all of them are equal. I did put a link to the books in the chat for everybody so you have that again and it's also in the slides which I'll send out as well. So, could data graphs be used for project portfolio management to show interconnection between different projects and programs. I have certainly seen that in the engagements we've been in and I've seen people modeling. Many people are very interested in modeling carbon footprints and sort of representations of dependencies and things so. You know, it can definitely be done but I would also say that you need the, the amount the volume of that to be worth the trouble, you know everybody starts usually with Excel, and it's good to go for a while, but some point it becomes a bit of a black box but to brittle at that point you start looking for tools to help you. Maybe then it's time to start thinking about a, a, a knowledge graph way of representing it but often domains have very excellent applications that you know project management tools have ways of interlinking projects and dependencies and so on, sometimes you better off sticking with a custom application. I can guess the messages yes it can be done. I have seen it being done but I wouldn't do it until you feel like it's worth the investment. Okay, so. So how do we validate the cost of data and American, if for example your American airline example Peter, you know, how do you come up with the cost of data as well to justify investment in data programs. I'm absolutely certain that the President of American Airlines and United are trying to figure that out because of course they are renumerated based on the value of the company. So anything they can do to push the value of the company up higher, and you know wouldn't you think in the last two years they would have done that at this point if they knew how to, but they don't. The question comes back to it, saying that there's lots and lots of data in our organizations but the value of this data has not been well understood and I think this one will play right into Sean's example that he was talking about a minute ago. I'm new of an instance where I have two individuals were working for a chemical company kind of thing, and they would have lunch every day and just you know good friends and things like that but they never talked about work at lunch, until they both went off to the same conference and one of the friends went up and said hey I've invented chocolate, and the friend down in the audience is going wait a minute I've got peanut butter here we should have had this conversation 10 years ago. This is something that will help people to start thinking about what those cross pot project data selections collections whatever you're pulling together can be so it's showing out more ideas around it similarly to everybody knows the adage that a blank screen is the hardest thing for anybody to face right oh my god I've got to write a paper in the morning or whatever it is. So what you do with the knowledge graph is put things out there and say look, sometimes these are correct sometimes they're incorrect but we want you to use this type of thinking and everybody likes to be an editor. So they'll come in and look at this and oh like this tells a story right data models are some of the most boring things in the world to look at. Because they don't do anything Russian knowledge graph actually shows something getting done around that john when I add anything to that. I actually couldn't agree more quite a number of the projects we're involved in our variations on what you just said, you know, maybe it's a manufacturer of you know some complex instruments wanting to provide an experience for the engineers in the world who who are going out to repair this thing or services and they need all the different aspects related to this particular instance of this particular machine at this particular customer at their fingertips and that's a whole wide variety of things that comes from lots of different parts of the business. It's going to be the manuals machine is going to be the service history of that particular machine. There's going to be maybe some, some backwards and forwards between the customer having called the customer service line and maybe some, you know, some conversations you want to understand what the sentiment is the content. You know, that's just one example like another where the connected connectivity allows that individual to deliver a really much better experience to the customer a similar kind of backbone in terms of things want to remember to retrieve things through their connections. This could be mining, mining, you know, conference papers and speeches to understand who experts in a particular field or who or who's influencing who one of our customers uses that kind of information to send the right kind of information to doctors at the right time to to help them, you know, understand why a particular drug might be what they should be describing moral. Again, it's this notion of building these structures that link everything together to be able to ask questions that then drive action and deliver value to the business. So these are just variations on exactly what you've said Peter. All right, next question, Jenna. Awesome. So, what is a good maturity model to use for understanding the current state of the organization's data maturity, this allows an organization objectively determine where they are today, and where they want to be and develop an achievable plan to get there with people process and technology with in a allowable budget. So I'm even though I have to say that I started I think the field of measuring data management maturity with a paper in the scientific journal back in the odds around this I'm so tired of people putting over emphasis on maturity. An assessment for your organization particularly if you know your organization isn't stellar is kind of, you know, well I guess the question would be, is it worth a lot of money for somebody to tell you that you're not very good. And I don't think the answer to that is yes. What I would use assessment for is to try and find instances of common shared data or shareable data, and also to find best practices in your organization that you can leverage. I'm actually responding, literally these days to an RFP for a company that says hey we're going to go digital blah blah blah blah Sean I'm sure you've seen it as well. I have not even spoken to their data people to say what is it that we already have that we should build on I happen to know their data environment, really, really well. And it turns out we're probably going to win this particular, you know, RFP because of our knowledge in this, but it's sad when we have to as an external consultant come in and show the organization that they're actually doing some of this pretty way that the organization wouldn't be in in good shape so there's lots of literature on maturity models and things like that. I would keep your maturity assessment focused on two things. One, what do you have that can be shareable or shared data that you can emphasize and start to do things towards. And two, what are the areas in your organization that are already working well, and that should be further exploited and how much if this sounds an awful lot like the theory of constraints. It actually works out to be there Sean you may have a completely different take on on maturity assessments which are that my thoughts and we see it further further downstream you know we're at the point where someone's actually trying to do something. And, and candidly, a great many of these things fail because they do not have the data they think they do what's not obtainable in a way that you know that is, is actually achieve whatever is the combination that they want to put together to add some business value. So, often the businesses really are are unaware of their, of their, the state of their data in many cases or at least parts that we sometimes engage with and then the other place that these things fail is where, where the business, the sort of technical people are not really don't really have a good understanding of what would drive business value to the business side, and often will deliver a solution and then it will disappoint not because it doesn't do what what we were asked to do that but because nobody cares it doesn't deliver the business value that they were expecting because they didn't understand what would have, you know, what the what would have driven business value which of course for us is very disappointing. So we're kind of further, you know, we're on the receiving end of these issues. And, and often it ends up being really a disappointment for us because we love to see our software being useful and delivering value. And if you, if you end up sort of three quarts of the way into a project and realize we're just never going to get the data needed then to deliver what their vision the customers vision is then it's deeply disappointing. And time to pull a plug to right. Unfortunately. Yeah. Now sometimes you can do a customer a big favor by saying the thing kind of work. Yes, and it's, it's far better to do that earlier if you can and we try I mean, you know, you know, we're Cambridge semantics was a startup and you have to learn in a startup you learn everything the hard way. And it took quite a few years for us to really make sure that the people we're engaged with who had the whatever the idea was, or often they don't have an idea right for the new technology they're just kicking in tires to see what it might be able to do for them. There's nothing wrong with that because that's how you find out but, but they often don't have a any Velcro in the business. And even though there may be some budget to do those experiments that they they never figure out how to connect back to business so we've got much better at sort of uncovering that and qualifying. We've learned now that we, we think that there's a, they're there before we get to to engage in projects because you know where we can only do so many projects and really want them all to succeed and be a success for everybody. There's a super description of an organizational capability, we've got the ability to look at an organization and say you know that projects probably not going to work so as much as we'd love to sell you some software. You know, we're going to tell you now you need to go I can do some more homework before it's time to go invest in technology at this point you need some internal capabilities. Yeah we tend to say it more gently than that I mean the ideal is if you help the customer realize that themselves by asking for you know we need this kind of data or that kind of data or how are you going to do this and as they, as they work on it themselves that's where the deficiencies are. But it's, it's, it's data is still in many ways the great hand solve problem in nearly every business that we've, we've come in contact with. So, should a data strategy be part of a digital strategy to put it in another way should those people developing a data strategy wait for the digital strategy first. Absolutely not. I would do it the other way around so one of the things that was really kind of interesting to learn was that you know we're all locked away while during the recession. And yet I managed to have a hallway or a water cooler conversation with a good friend of mine at one point on one of these events, the guys named Mark Johnson he's out of Ohio and he, he wrote down two things he wrote down data, and then underneath it he wrote down digital, and then he wrote down digital, and underneath it wrote down data, and he said, if you take digital away from data, you still have data, but if you take data away from digital, I'm not sure what that leaves you with. It's his sort of shorthand way of saying, you cannot do digital, literally, unless you have the data in the right shape. And, as John was saying, he's seen lots and lots of organizations that struggle with this because it is a hard thing to do. The number one cause I have seen is people starting digital first, and then getting into it and then discovering oh I've got a data problem, and there's no budget to fix the data. So that's where things sort of run out of steam but again, everybody has different experience Sean what's yours. Exactly that. I mean, I couldn't agree with more with you more. I really couldn't. It's, you know, people in the business have a vision they they see something. I don't know something in Sparks, an idea of something that they think could be, could be very valuable to their business and then, and then it often flounders simply because there is not a digital strategy, sorry data strategy that that can actually do that. And in the end individual projects are usually not enough to fix it a data strategy. You can, you know, start small and use that as a way to teach people data strategy but it doesn't fix the overall organization status data strategy so unless unless it's coming down from a very high level maybe through a CDO from a board level. It tends to be tends to be kind of a little bit ignored and and it's an individual projects aren't usually enough to be valuable enough to fix it. And if I can, I'm sorry, go ahead. What I was going to say is that sometimes you can sort of get lucky and patch things up and you know put user technology like ours to kind of pull data from every which way but invariably there are gaps that end up being, you know, conceptually missing lines on that graph. And, and if you don't have those those lines and you can't use no data to fill them in then then you really you, you that's where your project creators. And to build on your point there too this gets to one of the things that I tried to emphasize in the talk as well. If your organization does not have a programmatic effort to support data and a programmatic effort means you have a leader that's in charge they have an annual budget, it may not be increasing you know the CIO's budgets are always decreasing going forward that's just a fact of life in today's it world around this, but to throw money at other things makes no sense whatsoever make sure that data exists at the programmatic level and that same focus there programmatic means is going to be made up of multiple projects and then you're not trying to make a program out of a bunch of projects you're instead creating a program, and then creating your projects from that as well so again Sean I think that just absolutely reinforces that point here these things have to be done at a, an organizational level. And I'm old and cranky so it's kind of nice. I can, you know, choose what customers and friends and projects and things I get to work on. And oftentimes I'll see an organization and they'll say well we're just going to do data as a project but you know you can still help us out. You know, I'm going to put my time and effort into something that I think is going to be actually something that will move the needle somewhere somewhere for somebody as opposed to just wasting your money on a bunch of spend. I'm really, really frustrated with that one but you've probably been there too Sean. Absolutely. Yeah. So, do you think we should bring in data contracts and data observability as part of this framework. Well now are they asking about the dim box framework sure that's the most frequent question I get a dama if I let everybody who put a pie wedge in our pie wedge would have we'd have 100 pie wedges at this point. And that's a different effort we're going to talk about that and dama to go forward here but as far as strategy goes, I think it's important to look at this as saying, I've got an organizational strategy and most organizations then filter that strategy through the IT organization so then they have an IT strategy and then the data strategy is the third piece of it. And that's got to change. Again, if we are trying to do data, based on a lens that is looking at the world through an IT perspective. That is not a programmatic perspective and will not result in good activities. Instead, we have to break that strategy out and make it directly supportive of that just the same way as we need to break data leadership out and not report through a CIO in most cases, and in fact go directly to the, the board or the executive level, whatever it is. In fact, just a quick little note for those of you that aren't in the federal government is now against the law and the federal government to have a CDO reporting to a CIO. Most people don't think that Congress passes those kind of laws but I think they let this one go through for just us data dinks. A little while ago that's another topic we can get into that later on I know we're getting close to the end here. Yeah, time for more questions Shannon. We do actually. Yes, I said I hit the mute button there. Just, we have just a couple more questions and I think we have time to fit one or two more in. So you know at the beginning we you know got the question about data fabric and semantic later, but is a semantic layer also the same as a data mesh. Well, I would say that they're, they're somewhat orthogonal having done a little bit of reading now. I think the people who implemented data mesh probably will end up would like to end up eventually with the data fabric. I think data mesh is more philosophical it's about the process for it's essentially decentralizing the process of delivering quality data to the organization to lots of different places. And those different places are individually responsible for their, their domain of data and making it available for the rest organization. And that is, whereas the data fabric is about consuming those. So I'm starting to see them as two sides of the coin that people would like to get to an ideal state. You want to make the data reusable, and generally the people who most able to do that or where the data is being made they understand it best they will describe it best. A data fabric simply draws together blends of that data from different sources. And if those sources are there and available and there's a laser that's a great thing so I, you know, I see these two, two ideas, not as really distinct architectures but the complementary parts of an overall process where you end up with sort of data Nirvana in an enterprise. I think we're a long way from that but I really don't see them as antagonistic at all. Sean, I don't mean to contradict anything just a word of note that Gardner in its hype cycle for 2022 last year actually declared data mesh obsolete. I'm not sure what they're basing that on. But it is something you should at least know about as they go forward here and of course we all know that Gardner isn't always right. The more reading I do I see data mesh more as a philosophy and, and I'm seeing people who are, you know, practitioners in data doing these assemblages that we're we're I mean we're neutral we don't really care what the underlying sources of data are we just glad to have it. But I'm seeing a lot of the same practices that I've been reading about as data mesh practices being being being done by people who are building knowledge graphs and some of those people are absolutely building their knowledge graphs with an eye to make you part of a wider fabric so I'm just not seeing. I'm not seeing the. I don't think it's dead particularly I don't think it's, it's just a way of describing. You know it's a model for describing a set of activities around good data practices and, and that's about it. What you're describing is exactly what Gardner did with big data to remember that was a big thing on here and all of a sudden they just went poof it's no longer part of this. You know, it is a philosophy. Well big data itself is still with us obviously I mean people and customers are doing whatever they do and if the data is bigger than there, then it's, you know, it's big and you have to have technology to handle it's. But I don't think it's quite the sort of center of attention that it has been or was sort of 10 years ago. Again gardeners not always right so please don't take this as gospel this is just what they're pushing out. Okay so we have time for, we have just two minutes left so a brief, very brief question and answer so and because I'd love to hear the answer to this so and since this is my title. And now we have Chief Digital Officers. Is that a combo of CID and CDO. I would like it to be Sean. I don't know actually have no idea. So I'm not a good person to answer that one. Well, there's no question, just as if we go back and I can remember stuff I was teaching back in the 70s where I was saying things like, well computers and communication and entertainment are all drawing together. And you're like, what are you talking about and of course nowadays you have a phone and it plays movies for you so those things have happened there's absolutely every possibility that that what Sean is describing will mature in this way and not in the way that Gartner sees it, not that there's anything wrong with one one version or the other but it is a matter of confusion in the marketplace and that's I think one of the things we all want to try to avoid around that. So if we can get, you know, sort of standardization like you said if you're if you're looking at the WC three thing that sort of bulletproof your data going forward from other types of activities or other foibles that will happen in there other things maybe exactly the same same way and we'll see how they have they shake out over time. I love it. So I'm afraid that is all the time that we have for this webinar. Thank you both so much for kicking off the new year with such a great topic and presentation really appreciate it. Thanks to Cambridge semantics for sponsoring today's webinar I hope making these webinars happen. Thanks for having us so Shannon. Oh, absolutely. And, and thanks to all our attendees for joining and just reminder I will send a follow up email by end of day Thursday with links to the slides links to the recording. And I'll call out those additional resource rings links as well for the books and everything else that was requested throughout. Sean and Peter thank you so much. Thank you Shannon thank you Sean pleasure to work with you. Likewise, bye everybody have a good rest of your day.