 So hello everyone, I welcome you all to the session of data technical depth looking beyond code by Scott Ammler. So Scott, we are glad that you join us for the session and it will be great to have the insights on the session. Thank you. Over to you Scott. Okay, so thank you very much. Thanks for taking time out of your busy day to either attend this talk live or to view it. Either recording at another time. So anyways, yes, so what I'd like to talk about is technical debt in data and databases. This is a topic that's not covered very well, unfortunately, so but we'll share some industry stats and some strategies for you today. So, as you heard my name is Scott Ammler I'm one of the co creators of the dispensable toolkit along with mark lines I'll talk about that and share some information from that in a bit. I'm also the person behind the agile data method, as well as the agile modeling methods so I'm also going to talk about a few techniques that are, you know close to 20 years old now, and you know for addressing data quality problems. So anyway, so be some interesting, perhaps new to you, but old to old to me I guess. So anyways, I'd like to explore the concept of data or database technical debt depending on what you want to call it. And then we're going to talk about some strategies for you know how do we address it how do we avoid it how do we how do we actually accept, sometimes that we're just going to have to learn to live with some of this debt. And then I'm going to end off with a discussion of you know why is this hard, and why are we still struggling with data quality problems, or you just technical that in general, but certainly data technical debt. You know why we're still struggling with this it's, you think we'd be able to do better, but apparently not. So anyways, what's what is data technical debt. So as we know a technical debt is, it's basically the accumulation of poor product poor quality and challenges and defects data technical debt is well, you know poor quality in in our legacy data sources or existing databases and files and good stuff like that so it's just a you know a subset of overall technical debt, and one of the challenges is that there's many types of technical debt many categories. And unfortunately, due to cultural challenges in the data community. There's not a lot of discussion of data technical debt, and even though the, you know the stats are horrendous. We have some you know many organizations have some pretty significant challenges when it comes to data technical debt, and like I said I'll share some stats on that. So there's different types of data technical debt and this is from article I wrote a while ago now on this topic. You know we have some obvious ones like the structures of our tables and columns aren't quite right. You know the needs have evolved over time and we haven't updated them. Just basic data quality problems there's a whole slew of things that can go wrong with data. The implementation you know the method and function like a lot of the coding code oriented technical debt issues are applicable databases because there's you know stored procedures and stored functions and triggers and other types of functionality implemented in the database and it's code is just a you know it's coded in different language but it's still code. And so there's all the opportunities that the technical debt in in the code that's operating the database so this is a why you know there's a wide range of challenges here. So why does technical debt in general occur you know in particularly data technical debt well business pressures you know we're got to be on time and on budget I'll share some in front me I'll share some research stats on that a bit. Lack of testing the level of testing in the data world is much lower than what we see when it comes to unit testing or code, you know developer level testing. Yeah I'm sure many of you work in organizations where you don't even have a regression test suite for your databases. You might and you might even work in organizations where they haven't even considered the concept. So, there's some cultural challenges there that we need to overcome. We might not be refactoring, we might not even know how to refactor databases. I'll talk about that a bit. We, you know, just a lack of knowledge lack of lack of skills lack of, you know upfront thinking. There's many many reasons lack of proper collaboration between application teams and your data professionals in organization. So there's a lot of reasons why this technical debt occurs. So why should we care. Why is this important. Well, you know Gartner. You know, they've estimated that on average the average organization loses $15 million per year. Now this is an average so you know smaller organizations have probably have less of a loss. Larger organizations probably have significantly greater loss right so you know, but anyways, on average $15 million per year per organization is lost due to poor quality data. It might be worth your while. So if you're an average organization you're losing $15 million a year. I spend a couple bucks trying to fix those problems it was me. So what is the impact of poor quality data. Well, we have lost revenue right so the big, the big challenge is we, we are making ineffective decisions if we have the wrong data, or we don't have access to the right data and timing manner. We're not making good decisions at all. So our leadership is, is, is harmed. We might have, we might damage your reputation we're making mistakes in the marketplace where we might have data loss, you know we have security breaches and stuff like that. We might even be getting fined. For those of you working in organizations where, you know, regulations such as GDPR are applicable. You know, if you have some data problems, the fines for from GDPR are quite substantial, let alone if you're operating in California or many other, many other parts of the world that have similar laws to GDPR. So there's a lot of opportunity for to be impacted by poor quality data, poor quality data sources. This is another estimate this the the actual true source of this is an IBM study but this was first surfaced publicly, or at least promoted in a big way by Harvard Business Review, a few years ago now, but bad data is estimated to cost the United States $3 trillion a year. In fact, this number is bigger now I can't find better stats in this but actually if you know about better stats please email me, but $3 trillion a year. So that is a reasonably big problem that we might want to address and that's just the United States that's not an international issue. So, you know, we could be talking, you know, 10 $15 trillion a year internationally, or more. So, data technical debt, it impedes your, your ability to make decisions and to just to know what the heck is going on. It increases your operational costs. I'm sure many of you, you know, for at least the developers among us, you probably have to write code to do to do data to convert data coming in from a database into whatever it is that you want, and maybe to convert it back again to, you know, whatever the database is expecting. That's an overhead. That's not only we have data technical debt that you're covering up basically with a Band-Aid, you now have, you know, you now have code technical debt because you've got all this, you know, extra data cleansing code. Or, you know, look at the effort that goes in, you know, in the data warehousing world to cleanse data coming in and to fix it and make it, you know, better quality. And frankly, it impedes your ability to react to change. You know, many people work in organizations where, you know, the developers have adopted agile techniques and, you know, they're quite flexible and they can, you know, evolve their systems pretty quickly, except the data. And then the data, you know, changing a production database is perceived as risky and difficult. This is a problem. And I'll show you techniques to deal with that. But this is the reality on the ground that the databases are very often an anchor around our necks. And it doesn't have to be that way. So I want to give you a brief introduction to Dispin Agiles that way you can understand what I'm talking about when I start talking about when I describe how to actually fix and address these data technical debt issues in your organization. So Dispin Agiles is a toolkit. It's not a framework. And this is absolutely important. So where frameworks and methods tell you what to do, Dispin Agile tells you what to think about, what to be concerned about, and then gives you options. And this is one of the reasons why we have comprehensive data techniques in the toolkit is because, well, we, you know, we care, but we know it's important. So we put these techniques in a context for use that way you can choose to use them when they make sense to be used. I'll give some examples of this in a minute. So Dispin Agile is a tool is in a way an umbrella over hundreds of techniques. Actually, the toolkit right now has had puts about 1600 different techniques into context. So the idea is that there's always one of the techniques out there. Well, actually, if you look at what's going on at this conference. I bet you if you if somebody were to do account of the strategies and techniques that were that are being described at this event happening right now. Easily there's hundreds easily. And that's great. Right. This is one of the reasons why you attend an event like this is to learn, you know, techniques that are new to you and and hopefully learn how to apply them. Well, this is the reality in the ground. There's many, many, many techniques out there that you might choose to use because what you want to do is you want to choose the right techniques for the situation that you face to put together your way of working. This is why you attend training and conferences and stuff like that to learn about these techniques. Well, the toolkit has codified them. We've captured them, and we put them into context and we provide a means for you to learn quickly and to choose the right ones for you. We also have a more robust mindset, I guess you would call it. So, a few years ago we moved beyond the agile manifesto and don't get me wrong, the agile manifesto is great, but it's 20 years old. The agile manifesto or actually more accurately the manifesto for agile software development focused on solving the problems faced by software developers 20 years ago. Many of those problems are now solved in, you know, most part because of the manifesto, but we have new sets of issues. We have learned something. We've learned more than a few things in the last 20 years. And the scope has evolved. We're not just talking about software development anymore. We really are hopefully looking at enterprise agility. So a couple of years ago now at PMI, we stepped back and we said, you know what, if we were to rewrite the manifesto today, given what we know, how would we rework it? And this is what we came up with. So we believe in the collection of principles. And because we believe in them, we make promises both to ourselves and to the people that we work with. This is how we're going to behave. In order to fulfill these promises, we follow a collection of guidelines. Now, if you take a look at this, these are mostly lean ideas. There's some agile ideas in there as well, of course. And although there's a lot of people are in it stuff, as you'd expect. So we've gone beyond what was in the original manifesto. So anyways, and we're going to see, so why is this important? Well, first, I want to make you aware that things have moved on. But also for addressing and dealing with data technical network and technical debt in general, you know, some of the principles, promises and guidelines are directly applicable. And I'm going to be focusing on these sorts of philosophies or these sorts of ways of thinking throughout the rest of this talk. The scope of this financial is the enterprise. So you'll see that each of these hexes, it represents what we call a process later process area. All of these are, you know, all these areas can have the opportunity to improve so we can do better at software development. What we call this financial delivery, we can do better at DevOps, we can do better at portfolio management, finance and so on. So when you start wanting to be an agile business and truly be an agile enterprise, you need to look at the bigger picture you need to look far beyond it. And so the DA toolkit covers that gives you solutions or potential solutions for that. So, another thing about the DA toolkit and I think it was clear in the mindset is that it's a hybrid. So we adopt ideas from a wide range of sources, you know, agile, certainly agile sources, but also lean sources and even traditional sources because there's a lot of great ideas out there. And our goal is to put them into context to describe when you would want to use them when you would not want to use them and how they fit together. And we do this for all aspects of your of your organizational process, not just software development. So, in this talk today, I'll be adopting ideas from enterprise architecture or working through some ideas from enterprise architecture and governance strategies and of course data management strategies as well as software development and you know agile delivery strategies as well. So I just wanted to point that out to you. So how do we avoid data technical how can we apply the DA toolkit to, you know, hopefully avoid the debt debt to begin with, because the easiest debt to pay down is the debt that you never that you never took on to begin with. So this is the slight reworking of the technical debt quadrant from Martin Fowler, basically the only reworking is, I put the questions into the context for data technical debt. So we have different four different quadrants here. And the main lesson to be learned, we're going to see this over and over and over again in this talk is that there's good reasons to take on the technical debt like if you're, if you're thinking through and you're doing it deliberately and prudently. So you're being smart about the technical that you're taking on, and you actually explicitly accept it you understand the implications of yes we know we're taking on this debt. And it's a good strategy for us this is a trade off we're willing to make and we understand what we're doing. That's the green quadrant. The two yellow quadrants are sort of iffy, you know you're taking a technical debt, but you're basically stumbling into it. And then the red quadrant is you just don't know what you're doing. And sadly, it's mostly the red quadrant I think, or a lot of technical debt, at least the bad tech, they're really bad technical debt gets injected. So we need to understand why this occurs so that's why I'm talking with us and we're going to we're going to map the techniques to the quadrants over time. So one of the ways that we can avoid technical debt to begin with is we need to understand the requirements. Why are we building what it is that we're building or why are we evolving what we're evolving. So and this is a functional requirements issue and a non functional requirements issue to if we build the wrong thing. Well, we've just injected technical debt we've injected functional. We've even injected new functionality including data that we just didn't need. If we miss important non functional requirements, while we're injecting technical quality challenges into what we're doing, also didn't need to do that. So, sometimes the our approach to requirements and understanding the scope of what we're supposed to be doing can have a huge impact. So this diagram here I guess I should explain it because we're going to see these sorts of diagrams several times. This is the Explorer scope process goal diagram. So we describe team agility as a collection of I believe 26 process goals of exploring scoping one of them. So, the, in the middle, we have what we call decision points, these are issues or considerations that you need to address, and you'll be doing it either implicitly, excuse me. You'll do it either implicitly or explicitly. So when we go to the score scope, we're going to be thinking about what's the purpose of what it is that we're doing. How are people going to use our solution. How do we need to collect about it. What business process to be support what quality requirements, not functional requirements and so on. So we're going to be we need we need to think through these issues. Now, the methodologies and frameworks will often prescribe ways of working they'll prescribe you know that shell right user stores, for example they're not quite that explicit but they're basically, you know they've only got one or two techniques and they hammer on. Okay, whatever, but we know we need more. Right. So, anyway, so we have options, and then on the right hand side, or options, you know potential techniques that you can use to address the issues in the middle. So, there's two types of lists. There's an ordered list, the list with arrows. And what that indicates is that the strategy source the top of the list are generally more effective practice and the strategies towards the bottom list. And then there's an order lists, no arrows. So, in those lists we can't say that this technique is generally better than this technique all we can tell you is here's the trade offs of these techniques. Here's the context in which you would use them so you need to choose the right technique for you in the situation that you face. Because I don't I can't tell you what the best practices are there are there is no such thing as a best practice. All practices are contextual in nature. You need to choose what's right for you what can you what can your team do, what do you need to do in your situation. So choose the right, you know, the best or the most appropriate strategy for you in a situation that you face. So these methods when they prescribe here's a certain way of working here's what we declared to be a best practice. It may or may not work for you. It may or may not be the best thing for you to do in your situation. So I would rather give you choice. Let you choose you know what your situation is you're the one that's best suited to choose for you. So that way you can have a fit for purpose approach. So there's strategies in there that enable you to explore requirements better. We also explicitly include strategies to build quality and from the very beginning. How do you, how do you explore the non functional the quality of service requirements for your, you know, for what it is that you're doing and you know well first of all what issues should you know this chart here is showing the types of issues that you might, you know the views and concerns that you might want to address some of which are oriented towards data or data aspects, and other many other aspects as well. And then of course how do you actually capture them and then act on them later on. So this is an important issue. So the DA toolkit, we give you strategies for doing exactly that. So, by improving your approach to requirements. You reduce the chance of being in that bottom right corner is what we're getting at, because if you have misunderstood or missed requirements, then it often leads to, you know, you built something but you built the wrong thing. Or you built it wrong. And now you got to fix it right so you got to, you know, build a new version, you know, or, you know, fix whatever problems we injected because we didn't understand what we needed to build begin with. So, a little bit smarter about your requirements approach. Similarly, you want to be a little bit smarter about your approach to architecture. You want to identify architecture process goal. There's many techniques in there for for addressing data architecture and other aspects of architecture. I should also mention that I've uploaded a PDF of these slides to the website so you, you don't need to be madly writing these things down. And of course, all the stuff is really only of these charts and the details behind them are freely available in PMI.org. A bit of architecture modeling up front and followed by, you know, evolutionary design and evolution architecture strategies throughout the rest of construction can avoid a lot of future rework, do a little bit of thinking, and you'll avoid a lot of problems. In DA, we also suggest you have an architecture owner. So just like you have a, you might have a product owner on your team that's responsible for representing the, you know, the stakeholders and the customers and what they want and be responsible for the, you know, what needs to be built. The architecture owner leads the team in how to build it and helps you, you know, they tend to be a senior person, you know, architecture skills, of course, that can lead the team through important architecture decisions. So because of that, because of because we promote the idea that you really do want to have explicit architecture efforts within your teams. This leads to avoiding technical debt and you'll have less, you know, you'll have less debt to remove because you injected less debt to begin with. So having somebody on the team with architecture skills is probably a very good thing. So when you improve your approach to architecture, that addresses challenges that you would have had that would have landed you in the first, the, the, the two left quadrants as we see here. Building better solutions to begin with higher quality, you know, we're starting by building better quality things to begin with. So we're, we avoid the technical debt. One of the principles of this agile is to be enterprise aware to look at the bigger picture. It's not just about your team. So one of the great things about agile is that it made clear that software development is a team sport. And what it doesn't make clear is that your teams are not autonomous. This is a fantasy. This is one of the great mess of the agile community. At best your teams are semi autonomous. And the fact is that you need to collaborate with others to get the job done. But also, you need to recognize that whatever it is that your team is doing. It's part of your overall organizational ecosystem and the overall ecosystem of the world. And you really need to be aware of how your stuff fits in with the rest of the organization. You want to be following common conventions. You want to be working to common roadmaps. So that way you're not building something that somebody else has already built or is in the process of building. So one of the reasons why, you know, one of the sources of technical debt is that you keep building the same thing over and over and over again. Or like, you know, your team builds it some other team builds it some other team builds a version of it and so on. That's just wasteful. So we can be a little bit smarter about this if we choose to, or you'll build something in a different way. But your stuff might be really high quality. And but the team down the hall they're building something really high quality too, but they're following different standards and different conventions so together. It's a math, it's a mess. And for those of you who have ever had to maintain an update the code written by multiple people over time, you've seen this. This is a source of technical debt. You know, this person had really good style at some point, this other person another really good style and so on, but to in individually was great stuff, but together, no good. Right. We have to choose be a little more mature in the way that we were. And part of that is to become enterprise aware. We should also work closely with their enterprise architecture team, if we have one in our organization, if not, we should probably consider getting one or building one. So we have a collaborative lightweight approach to this so the architecture owners on my team will work will be part of the, the enterprise architecture team, or the divisional or the values team architecture team depending on, you know, how you're and about the thing is, is that the architecture owners are collaborating with either with each other, probably with some leadership, of course, to facilitate these conversations to share ideas to develop common standards and common roadmaps and common artifacts that they can share. So, with their teams so that way, they work more effectively together, and they avoid technically. So we have a, a one of the process plates, which we saw earlier is enterprise architecture, we have explicit support for agile and lean enterprise architecture within our organization. This is absolutely critical to your success. If you don't have a decent enterprise architecture strategy, you're, you will always have technical debt problems in your organization. You need some sort of commonality, some sort of mechanism to deal with common technical issues and once again to avoid technical debt. We want to, we want to follow organizational guidelines like common coding conventions, data conventions, security conventions, UI conventions and so on. This is, this is, you know, probably one of the easier ways to avoid technical debt is just to grow up and have some and I use this term on purpose grow up, have some common conventions. It's actually interesting for those of you have been around for a while, extreme programming, one of the few practices in extreme programming was to have coding standards. They realized even back then in the mid 90s, they realized that they needed the only way they could be successful and avoid at least code level technical debt was to follow a common set of conventions makes life a heck of a lot easier for everybody. So go for it. So by following common conventions, we can avoid problems that would have landed us in the bottom right corner. So, and we need to end and be enterprise aware, we really do want to, you know, understand and appreciate the big picture. And yeah, it's, it can be inconvenient, following coding conventions and data conventions, security conventions. But we need to do it. And, you know, if your problem is well I don't agree with the coding conventions, or the data conventions will work with the people who are responsible for them to improve them. So step up, and you know pay down that that's a form of technical debt, you know, inappropriate conventions or form of technical debt. So pay that down. And then of course we have reuse. So how are we managing the assets within organization. The more that we can reuse the less technical debt will inject. Things that are reused, excuse me, things that are reused tend to be higher quality, and they tend to be invested it, because if something's being used over and over and over again, and there's a technical issue with it, you're highly motivated to fix that debt, because you know, been used in 10 different systems, and you've got a quality problem with it. You have a huge impact but you know by focusing on that quality problem, you have a huge impact on you know multiple systems all at once. So things that are reused tend to be higher quality, things that are higher quality tend to get reused. So it's a virtuous cycle. So, great levels of reuse address challenges in the top left quadrant. So this is some stats from six or seven years ago now I guess about six years ago. That's still pretty valid. So, I suspect I should actually rerun this study again but I suspect things haven't changed much. So, you know we do see team agile teams doing like, you know lightweight up front architecture. We do see teams working with enterprise actually I hope things improve but I suspect not. You know we because I haven't seen movement in other similar things. You know some teams are including architects or some sort of architecture owner so you know we're seeing you know we're seeing progress but there's significant room for improvement. Like I said, maybe soon I'll rework this study. So, how do we go about fixing data technical that so many people think that evolving a database like production database right you know I get your, your production Oracle database is difficult. And the reason why is one of is because of coupling. You know so a given database could be accessed by hundreds of systems within your organization and maybe even thousands, you know the corporate customer database could be accessed by hundreds of things. So, they're highly coupled. And because of that coupling, if you make a change in the database, you could break 100 applications so for example, if you had to change the name of a column, you know in your customer table in your in your, your primary database. And if I was to ask most of you to, I want to change the name of the column in your customer in your customer table in your production database and I want to roll that change today. All I want to do is rename a column. Absolutely trivial. That is a trivial thing, or it should be. Is your organization, organization capable of achieving a trivial task. Most organizations can't do it. They'd be afraid because they know well if we rename the column, we'd break 100 applications. That's false. Here's how you do it. So there's a technique called database refactoring the, and what you do is so it's basically just like the code refactor. How do you safely evolve code while you refactor the code. How do you safely evolve the database you refactor it, you make small simple changes one at a time. Safe changes. The challenge is because is the data, you can't break the data, right. You can't do it, or you could do it but people don't like it if you break 100 applications. So you have to safely make these changes. So here's how you do it. So earlier, I talked about the absolutely trivial task of renaming a column in a customer database. So here we have currently we have customer first names is stored in the F name column. And that's just a bad name, right. It's not clear what the name is, and for some reason this is a serious problem for us, and we want to fix it. So the idea here is that if you can't accomplish trivial things, you have no hope of accomplishing things that are actually valuable. So yes, here's how you would rename the column. We add the new column name first name, and then we put a trigger in place to keep them synchronized. And we deploy that to production. So now we have this interim schema running where with the F name column first name column so if F name is updated and first name gets this update and vice versa. Then we tell the application teams that stop using F name start using first name. You work your code. That might take the months or even years. But at the point in time where we have the first name column in place, it's effectively renamed. Now yes we have this overhead of having the old cruft F name and the synchronized first name trigger in place. At the time, once the code was the application teams have refactored their stuff, and they're no longer accessing F name, then we can remove the old cruft. And refactoring is finalized. Now, as your teams get better as they become more agile, you'll your deprecation period that interim schema will be in place. At the beginning, maybe for years in large organizations, but you'll be able to get it down to months or even weeks as teams get better at evolution of development and being able to put develop changes and put them in place and roll them up the door. So this is how you refine out and this is obviously a trivial thing, but all the other refactoring so that in the book refactoring databases, written by myself and from one satellite, we provide 60 I think it's 65 database refactoring and show how to implement them so this is not theoretical at all. We show you how to code the changes. Now there's refactoring tools, it's better than coding, but absolutely worst case if you can type in code from a book, you can do database refactoring it really is that trivial. And of course to support this, just like you have to support code refactoring, you need to have regression test suite place for your database because I need to be able to make a change, and then run a test suite to make sure I haven't broken anything and or to identify what I did break, so that way I can go and fix it. So we need to adopt regression testing techniques in the data world as well. If your data if you consider data and act an asset. Shouldn't you test it shouldn't you do what you need to do to make sure it's a quality asset, which includes testing. Right, so we should have automated regression test suites for databases just like we have them for our applications. Pretty basic, right. Well, sometimes easier said than done. We also the issue, finally know just about to wrap up of sometimes we choose to accept technical that that's the real message of the technical debt quadrant when does it make sense to explicitly and intelligently accept technical that and that's what the green part, the top right corner is all about must be smart about this, because sometimes it makes sense to have technical that for various reasons. This is from a recent survey that we did at PMI. And in the study, we explored a bunch of things including a bunch of aspects of what technical that including data, technical that. And, interestingly enough, one of the questions that we asked was, you know, is is technical that being taking on intentionally intentionally are you are you operating in that top right corner, like Martin Fowler suggests you do. This is only about a quarter seem to be everybody else is either iffy or very clearly no. So, we have some opportunity in our organizations to improve the way that we deal with technical that. To explicitly accept technical that you need to understand the implications of it you need to understand the impact. You need to have a coherent reason to take on that those future costs, and you need to, you know, you need to be willing to actually address it at some point in the future. Because the debt will build up and the debt will eventually choke you out and kill you. You really want to be smart about taking on new technical that so do it for good reasons. And there are good reasons to do so. Time to market, for example, can be one. But you need to be smart about it. So why is this hard, why is all this technical that so hard and why, you know, after, you know, 25 years, why are we still talking about why are very clearly have we not solved this problem. Unfortunately, the business often doesn't understand technical that I'm going to share some stats on this from that that study I just shared. Because business wants new functionality. They don't, they don't understand technical that they often don't understand sometimes they do but they often don't. And they often don't understand the trade offs that they're making because they're focused on on time and on budget. So there's a lot of short term tactical thinking and not a lot of long term strategic thinking and technical debt is a long term strategic issue. You need to think strategically and act strategically. And this is also from that, that recent study. So, what may want to set one of the sets of questions we asked was we gave for for concerns, you know, delivering on time adding new functionality being on or under budget, and addressing technical And then we asked people, you know, tell us what your number one priority is your number two priority number three and number four. So, as you can see here, addressing technical debt was the number one priority of only 3% of the respondents to the survey and we had managers responding we had executives responding so very wide range of people. So in their organization was perceived addressing technical debt was only 3% of organizations had that as a number one issue, delivering on time was number one. For the majority, as you can see. Now, the, for number, the least important priority in organizations, we're seeing that two thirds of organizations had addressing technical debt as their lowest priority. So I think this provides pretty good insight into why we still have technical debt challenges after all of these years. It's because in practice for all the, you know, for all the yapping and all the rhetoric that the technical people including myself, talk about the evil's technical debt. We're not being listened to the organizations are not behaving properly. They're not behaving in a mature manner. So this is so we need this is a cultural challenge we need to address this. We need to do better. As we all know what gets measured gets improved, hopefully usually. So 78% of organizations measure code related technical debt. So that's not not bad, but only 30% or 36% I should say, are measuring data or database technical debt. So, we have a bit of blind spot here on the data side of things, as usual, as usual. And it's just because we haven't surfaced these challenges even though it's a three, three trillion dollar a year problem for the United States. Only a third of organizations are measuring this stuff. That's a bit problematic in my mind. So addressing technical debt requires a culture change, we need, you know, we need to make a part of our culture, we need to educate people we need to communicate this over and over and over again. This will be a generational it has been a generation. We didn't get it done. It's going to take at least another generation, maybe even two or three in order to address to actually build, you know, a culture that appreciates technical debt and hopefully avoids it. So, in part, just wrap things up before we go to Q&A. PMI is a, if you don't know who we are, we're a not for profit organization. Our goal is to help people to learn to enable people to learn and to improve and get better. And to become change makers to actually do better at what they do and to be successful in our careers. It's one of the reasons why we joined with PMI. So in DA we have four certifications for our training programs and you know we feel like it's sort of, you know, there's training and their certification you might not want to get certified. That's your business. But we have, you know, a DA Scrum Master, and it goes far beyond Scrum this is going to get renamed this is not the right name for it. But it teaches you how to improve at the team level and at the, at the individual level. The Senior Scrum Master cert is really about all but being a team coach. It's all about, you know, how do we lead improvement at the team level. And yesterday Mark Lines and I had a great talk on continuous improvement and how to do it properly and how to do it effectively so moving beyond failing fast. Failing fast is a fail, by the way. This is a fad that is not treating the agile community well. Anyways, my prediction two or three years from now will, you know, many of the speakers will be presenting their version of how to how to avoid failing fast. It's still failure. DA coach is all about leading improvement across disparate teams. This is more of a senior coaching cert. So how do we coach beyond IT? You know, how do we, how do we help multiple teams that are collaborating together improve. And of course, here's the value stream consultant. How do we improve across the organization across our value streams? How do we become more effective at bringing products and services to market. So anyways, we've got a minute or two, a bit of time for questions. Yeah, thanks Scott for those wonderful insights. So we have a question that to when we have the speed to market need to minimize the time. So any suggestion on how can we manage all these. Well, yeah, you're making choices, right? So that's the, that's the entire issue is that you're making trade offs. And do you are you making intelligent trade offs do you understand the implications what you're doing. So when you are aiming for time to market, or, you know, being on time being on budget type stuff, you almost always sacrifice quality you take shortcuts. And sometimes that makes sense. That's what the top rate quadrant is all about in Martin Feller's technical debt quadrant. The, so if you're making intelligent decisions that understand the implications of what you're doing, then that's fine, right. But if you're not, like if quality is being short changed in order to hit date. And you don't understand that, then you're not doing a good job and you're in one of the other quadrants, and you're taking you're recklessly taking on or imprudently taking on technical debt. And then that that just harm that just harms you. So, yeah, that's it so making intelligent trade offs that's the entire message. And if you don't understand the trade offs you're making, you might not, you might want to stop making decisions until you do, but you know, easier said than done. Scott, we have one more minute and I think I'll just take this last question. So what are some of the tools to measure data technical depth in SQL databases. Yeah, you'd have to do a Google search on that it depends on the platform, of course, there's some great stuff from red gate, but I'm not going to, I'm not going to name tools because it changes constantly. A lot of people actually hand jam the tools, the data world, the data community is not well served by tool vendors like there's great tools, but nowhere near as many great tools per capita, as what you see for software developers. For many reasons, you know cultural reasons and lack of skill reasons and stuff like that but but there are there are great tools but you would need to go and search that for whatever your platform is. Because there's many different database platforms as we know. Yeah, and just to share Scott, we are getting a couple of comments regarding thanks for your appreciating the highlighting that technical depths needs a cultural change. Thanks Scott. Thank you.