DataOps For Beginners

00:00:00 Welcome, housekeeping, and introducing Gil Benghiat

Chris Bergh: All right, everybody. I think we're going to begin. So my name is Christopher, I'll be hosting this and our topic leader today is Gil Benghiat, okay, if you go to the first slide,

Gil Benghiat: Hey folks. And Chris, are you recording?

Chris Bergh: Yep. Sorry been recording. so, The slides and recording will be shared this week. Probably today, if you have questions, put them in the chat window or in the Q&A I'll be perusing it. While Gil talks we may answer that or We're definitely will answer at the end. Our target is about 45 minutes and then we'll take questions at the end and, we reserve the option to answer questions during the meeting. so, next slide So, I've worked with Gil for part of Gil, 20 years, a long time. And so, I think Gil is a extremely technical person as well as a good sense of managing teams and people experienced deeply in software, engineering, and DataOps, and it's been kind of one of the thought leaders behind the cookbook. The manifesto and a speaker on DataOps. He's gone to some great schools and I'm really excited to have Give this presentation today. So Gil, if you could take it away,

Gil Benghiat: Good. Thanks. Chris.

00:01:19 Where DataOps came from: shipping bad data and getting yelled at

Gil Benghiat: And I think a question is where did DataOps come from? So Chris and I we've known each other a long time. this is the second company where we work with each other, and at the first company, we did a bit of everything related to data. So, we had a product that was an ETL tool that also displayed data. We did consulting. We produced data sets every week. So we really got a lot of exposure and I don't know if any of you've experienced this when things are just not going well at work, have you experienced kind of a pit in your stomach driving to work and the first part of this presentation is just some of our experiences at the previous company where things did not go. and we figured out, all right, we're not enjoying ourselves. How could we do better? And we didn't know it at the time, but that was the birth of DataOps is we talk about it. So, Is, I don't know if you've experienced this but driving to work, not looking forward to something, and especially when it hinges on after a data, refresh thinking, I might not go well and then getting kind of nasty letters or upset letters from your customers. And that's no fun. this one was actually Chris. So I remember this guy, who was one of our customers head of sales. he would call Chris and yell at him, if there was a small data issue in any of the reports, so Chris you remember, Think you might remember that?

Chris Bergh: Yeah, it's so much fun to produce wrong data and produce it, for, at least, a month to thousands of people and then realize it and have to go beg, forgiveness or worse. Have not realized it, and then have the customer, call you up and yell at you, and say, you're a moron. And so that feeling still resonates with me of shipping, bad data, being wrong and, as an organization, your business, customers always have choice. If you're an internal team that hire someone else. If you're a consulting team, they can fire you and so getting things wrong has real consequences.

00:03:39 Last-minute changes, the bathtub story, and never going fast enough

Gil Benghiat: Yeah, so that wasn't fun. this was another anecdote from there where somebody would put a last-minute change. It's like I'm gonna go do the 15-hour build, I'll put in a change and Yeah, I think it went okay, because cuz no one complained and it's like, how do you know, if you're gonna make a change that, is there a way to do that with confidence that the change is correct? And this isn't a story from our previous job, but until we've spoken to a lot of other companies and I think this is kind of the best story of having troubles. Come haunt. You one person said, I had this data issue and I had a hide in the bathtub during my kid's birthday party, to fix the data issue. And I don't know if you've experienced anything like that, Chris and I have experienced it on the soccer field. But I think this was kind of the worst. And at this company, we couldn't go fast enough. we work for physician who was very demanding, I would prepare estimates for projects for features, make three-point projections. But see what a 90% confidence level is and we'd be really proud. Okay, we got it down to two weeks and we get this disapproving. Look, it's like, Hey, I thought this should be two hours, not two weeks. So, we really just couldn't go fast enough and then our own constituents People just wanted to use their favorite tools, so with these issues, we've encountered of shipping, bad data, not going fast enough. that was the birth of DataOps because we said there has to be a better way. And that's really what this presentation is about how to do better.

00:05:37 Hope as a strategy, and the waste DataOps is meant to shrink

Gil Benghiat: and really, we weren't alone, we did a survey and we found that half the people use hope as a strategy. Yeah, I put it last minute change and I'm hoping it doesn't work and we could see that a lot of data engineers are just not happy, they're very stressed, they're thinking of changing jobs, even changing careers. So, is hard data is stressful and hopefully out of this presentation, you'll think of a way that it could be better. and we think of the benefits this way, is that there's really three main activities. there's kind of the good stuff in green. There's new data sets, available for customers, there's improvements to the system. But what eats away at that is operational, errors and non-automated tasks. And the idea of DataOps is to shrink this blue, so we could deliver more features and therefore faster. So the goal in a nutshell is to learn how to deliver faster. More frequently with higher quality, and it's using this idea and techniques from DataOps. So what I'd like everybody to do is pick out a piece of paper or electronic notepad and as we go through the presentation jot down what you might want to apply tomorrow. So don't just listen, make yourself a list and at the end of the webinar I'll ask you to look at that list and pick one or two to give a shot.

00:07:14 What DataOps is: Agile, DevOps, and lean manufacturing

Gil Benghiat: All So what is DataOps. It's really a combination of three things first. it's a technical environment that supports people processing organization and the people process an organization is agile and we'll be talking about that. And the technical environment is DevOps plus lean manufacturing and DevOps is been proven out successful and software so we want to take some of the techniques that were develop there, use them for data and also lean manufacturing. Not just the attitude of Agile but actually measurement using things like statistical process control and treating what you're doing like an assembly line. So that's the three main ideas of DataOps. And we'll start briefly on agile because it's been around longer than DataOps has

00:08:02 Agile as a mindset: focus on delivering value

Gil Benghiat: So agile we think of it A's a mindset. and it really is a focus if you want to boil it down to one phrase, Agile says, focus on delivering value. There are four values 12 principles and we could boil those down to collaborate with your customer. Build what's most important first? Deliver what you build. So get it in the bank and then get feedback on what you've built. and finally, adjust your process to become more effectively through retrospectives So to us, this is the essence of agile.

00:08:39 From the Agile Manifesto to the DataOps Manifesto

Gil Benghiat: I have a few references on here to the right, are the four principles, you could see that at agilemanifesto.org also on agilemanifesto.org or the 12 Principles. Those are worth reading offline but we were able to boil those down further. We like that so much. DataKitchen. we modified the Agile Manifesto into the DataOps Manifesto. These are the 18, High Level Bullets. There's more information on it. it's about a page and a half. So, I would say Read the DataOps Manifesto, and if you'd sign it as well,

00:09:22 Why frequent, smaller deliveries beat waterfall

Gil Benghiat: And I just want to focus on of a few parts. I'd like to highlight the idea of frequent deliveries and Agile was developed in the era of waterfall software. Development where, there's a series of steps between having an idea and deploying during that time. The project had some challenges that could happen. Namely requirements the technology could change. So by the time you deliver sometimes what you produced was out of date so the Agile idea is to chop your delivery And deliver more often. And what does that look like? Let's say you're trying to deliver four features, once you deliver them, you're getting value to your customer and you're learning about. are those features useful? Can I get some feedback on the features? the idea of agile is chop it up so you could get learning and value as you go. And as you can see up here on the deck was features one through four. And then Hey, we've learned let's swap in feature five instead. So figure out how to make your release smaller and deliver often.

00:10:46 Limit work in progress: the 20%-per-project context-switching tax

Gil Benghiat: Another idea from agile, more of a Kanban practice is limit, the amount of work in progress, there's less context switching, the idea is focus on something, get it out sooner, there's less chance to abandon the task which means less weights And I think that's followed up by this interesting study. The study is referenced in these two books and what they're doing is they're measuring the time loss to context switching for every additional project. So if you're working on one project, there's no time lost for context switching but as you add a project, this is suggesting you lose 20% of your time. for every project you add, and you kind of imagine with six projects are you really getting nothing done? But I think the takeaway here is really just try to focus on one thing. Get it done, get it in the bank and make it small.

00:11:55 Retrospectives, and turning every request into a ticket

Gil Benghiat: Another great technique from agile is retrospectives, don't just think about what you're delivering but how you're del think about your process. So retrospective is a meeting that's held at the end of an iteration or if you're more in a Kanban mode, periodically during that retrospective reflect on what went that you want to keep doing and what are opportunities for improvement. I really like this website here, which gives a whole list of different ways to do retrospectives But at encourage you to start them, and if you're not doing them start once a month and commit to getting one thing done, picking one action item from each retrospective and hey, at the end of the year, you would have made 12 improvements. Another thing this isn't so much agile is just a nice agile, project management, turn everything. You do into a ticket, data features, bugs requests emails, if it's bigger than a bread box, figure out what your threshold is, an app more more than a half hour, make it into a ticket if it's not a ticket, it doesn't exist. This is just good advice on keeping your team All right, So here's the question, I'm gonna come back to this. It was there anything you just heard in the agile section that you might want to try and apply tomorrow?

00:13:39 The two pipelines: value (production) and innovation (development)

Gil Benghiat: All right, so next on the agenda is looking at the technical environment, the combination of DevOps and Lean manufacturing. so the seven steps to implement DataOps are listed here, orchestrate to journeys and tests and monitoring using version control branching and merging. Multiple environments reuse and containerize and parameterize your process. That's what will spend the rest of the webinar on. So the first organizing two journeys, what's your first journey? It's really thinking about what you have running in production. So your production pipelines is your first pipeline. We call it the value pipeline because it takes data. Does some transformations or movement to the data and then outcomes value to the customer? And the idea is treat that, an assembly line, like a manufacturing plant or materials come in, they're modified, and you have outputs There's another journey or there's another pipeline, which is what we call the innovation pipeline. And this in DataOps, is your CI CD pipeline, where you have an idea, you do some development and then you get it in production. And that's another pipeline to think about.

00:15:09 Add tests to both pipelines, and why the same test often works in each

Gil Benghiat: So the first idea with DataOps is that you have these two pipelines, you want to automate them, and you also want to add quality steps to them as you go, quality steps in measurement. So the quality steps in your production pipeline would be, you don't want to learn about data quality issues from your customers. and the purpose that monitors or tests. in your innovation pipeline is You don't want to break production when you deploy your changes and I'm just wondering, What's the value of Okay, so you want to add tests to do both of those. in production, has anybody had just think to yourself a pipeline that runs green. Everything looks so okay from my execution standpoint but then really nothing comes out. The other end somehow it was a bad join in there and all your rows got absorbed. That's a great place for a test. I think about tests, those that run in production as a gift, you give to your future self. And if we think about the test adding that we add in quality monitoring or the test that we add to the innovation pipeline people, typically think of those is, as unit tests or functional tests or end-to-end tests. The difference is that in production, the code is not changing, but the data is And in development, it's the opposite, you're changing your code and you want to keep your data static so you can keep track of things. and there's actually something that we've learned is that these can often be the same tests. So that will result and stay savings as you add monitoring and test to your system. So this is really a big part of DataOps putting tests that run in production and using tests like software does to make sure that what you develop is what you expect and does not break production.

00:17:45 The three categories of production data tests

Gil Benghiat: So let's look at the test that you add in production. We could think of those as there's three main areas or three categories of tests to add one as your data arrives from your different suppliers is the data free from issues. I'll jump to the right. Once you produce your outputs, you want to make sure that those are what you expect. And then during the transformations are there, checks you can make along the way and as a developer are there assumptions you're making about the data. And if there are those assumptions, should really be a data test. So, these are the three broad categories of tests.

00:18:39 Stop the line, warn, or measure: statistical process control on data

Gil Benghiat: When you have your test running in production it's really not just past fail, Again think of it as an assembly line. So you what Toyota was famous for in the 80s versus American manufacturing? Is that if there's an error If it's really bad, stop the line. Fix the quality issue and some data issues that roll into your system are that bad. others you may want to warn or put into a release note and then there's another category which is Hey I just want to take some measurements because I'm trying to figure things out. But either way keep history and with that, you can actually create and this is from me statistical process control graphs. So here this is a percent of invalid us zip codes and some input file. And we can see there's a threshold at one when there's warnings issued. And when it's below 1%, that's deemed accessible. what are the thresholds, that really depends on your application. There's some places where a bad zip code is a fatal error. There are other places where you can really tolerate, a much higher threshold.

00:19:59 Innovation-pipeline tests and the row-count balance example

Gil Benghiat: for the innovation pipeline again think of it as is your testing what you're developing. You want to run all your tests before you deploy your feature. hopefully it's automated with the click of a button into production. There's a lot of different tests that you can write. Here's a list. I think this was a good area for other. Research, but I'll go into a couple examples. So one test and this one's in production is a location balance where let's say you get a source flat file with a million rows and you kind of break it down that kind of packed into those million rows or 700,000 facts and 300,000 dimensions. You could make sure that the sum works out. And then in the report you really don't care about the original million rows. But again, that this total is a million. So, this is kind of the idea of a simple row count can help you. And even though this is great in production, you want this rule and this behavior to be the This is an example of a test that can be reused in production as well as in the innovation pipeline.

00:21:22 Group-by comparisons that expose subtle errors a top-line total hides

Gil Benghiat: Here's another kind of example test that goes a bit beyond the row count. one thing one could do is time over to week to week development compared to production the total of something should be the same. So here we're looking at sales volume, units sold and we could see some in this version is 525 575 and also in the new version it's also 575 however grouping by Something that is meaningful to the business can help yield some hidden or subtle errors. So we see if we have our products, they're in product groups and then we sum up the volume group by product group. That when we make the comparison, we have 225 in group one and 255 in group two and likewise, I' group one. And in the comparison, likewise group two, it's number change. So here, the idea is that numbers contained by regrouping, or you can have something like if you're grouping by state and you can have something like, Rhode Island disappear, It doesn't really change the top line number very much, but it's something that you'd want to detect. So, A little bit of a summary. there's The value innovation pipeline, treat them assembly lines, like manufacturing, take measurements. So there's some other measurements that you could do to control your operations, and we'll do a quick review of those.

00:22:59 Tornado charts, counting production issues, and quality circles

Gil Benghiat: So the first we call tornado chart which is really looking at errors by supplier. It's a two-sided chart on the left, is a count of errors and on the right, is a impact from those issues, some type of impact assessment to get started. You can just do simple counts and we could see that, in this period, there was a lot of trouble and if you color code the suppliers you can see which ones giving you the most trouble. So this is one type of chart to keep track of your data operations. Another is just simply counting the number of issues that you have in production. So, by day or by week have account and sees that trend going up or down, You can then take that one step further and form a quality circle, around those issues. So the idea is meet periodically to talk about the issues, culturally look for opportunities for improvement. There's no blame or shame and then

00:24:09 Pareto root-cause analysis, delivery charts, and the DataOps maturity model

Gil Benghiat: You can either look at individual incidents or if there's a lot roof them in through a Pareto chart into root cause and then work on the loop root. so, on the Pareto chart, this is a diagram analyzing why customers refuse to accept delivery of pizza. And we could see delivery So if I'm trying to improve my delivery operations, I could look and dive into the reasons here. why is it taking too long? And then the next one is wrong food. Probably work on that one. Next, Another chart is looking at delivery times, this is looking at deliveries on the left by source. Just color code. Everything is it missing later on time and you could see by doing that it kind of pops that Source Three and five are great but source for could use some improvement. I'd probably focus my time over there. testing is very important. So, just start by adding your picking, an inventory of tests. You'll want that to go up over time, How many tests do I have running in production and how many tests do I have running in my innovation pipeline? so, This is from Agile, the burndown chart classic velocity chart. These are all things that are helpful for your operations and finally DataKitchen has a maturity model where we have these seven attributes of running a organization and kind of the classic five different levels, through surveys. You can see where they Take an average and this is another way to track your operations.

00:25:58 Summary of steps one and two, and where to get TestGen

Gil Benghiat: So, as a quick summary of Steps One and two because There are two pipelines, you want to automate those. The first is the value pipeline which is your production system. The second is your innovation pipeline, which is your development process. Add tests to both and treat them assembly lines use the measurements and data to improve your operations. And it makes me think of Deming who really started the whole idea of lean and total quality management, he would say in God we trust, everybody else must bring data. And as far as testing it's a great topic, here's a couple great resources. If you want to start some testing by generating, some automated tests, we have this free software TestGen, there's a link to it here. And if you just want to read about a little bit more about how to affect change in an organization and improve data quality. Here's a white paper, you can follow up on And Chris will follow these links are in the chat and Chris will put them in an email. Alright again, so we went through a couple steps. Is there anything that you related to that, resonates with you? If so, write them down on your notepad,

00:27:26 Version control, branching, and multiple environments

Gil Benghiat: Alright, we had seven steps to implement DataOps. here's the remaining steps. So this one, when we started the company was actually Not many people as you thought were doing it, People have gotten much better about using a version control system, but there's still lots of code that's either on desktops or sitting just in a tool. So the next step use version control, all of the transformations are really just code. Once you have things in a version control system, use that to branch and merge your code. And again your favorite version control system is very good at this many people do it. It's very easy to branch and merge code. What gets a little harder is to branch and merge data. That's where the next step comes in. Which is using multiple environments so it's not just code right? Your analytics work involves both code and hardware and data. So you want to have environments for each. And you want to have. An environment really for each branch. So here we see there's production we make a branch for each sprint. there's an environment for that and again there's a branch for each feature, There's an environment for that. So analysts need a place for experiments, do it on a branch with their own system engineers and me to place to do their development which is not on production. And there's a couple ways to think about environment One is a more classic or static. Version where there's a number of environments here there's three, but there could be more frequent, product prod development. QA Development, Sometimes you'll often see staging in there and those are around a long time. But if people are sharing a development environment and they're making changes in their encode, they have their own branch but it's hard to have a shared data environment that's in debt. So there's another strategy which is a more dynamic strategy where there is one production environment. But people are able to spin up sandboxes, for a sprint or for their own feature work, and there they're able to, have more complete isolation. And this is a very handy way to work. I think the challenge there is How do you create environments? And the answer is automate and some of the modern On a data tools. between either bucket storage or being able to copy on clone that will enable you to create data environments as well.

00:30:34 Reuse, containers, and parameterizing your pipeline

Gil Benghiat: The next steps are reuse and containerize. It's not a monolith like software. You want to have modules that can be reused, that can be shared. And then also, Docker is really a great way for deploying and managing your environments. And finally the last step is parameterized. What's going on? you could think of your pipeline like a big function. And if you have name sets of parameters that can help increase your development philosophy. And there's really a couple ways one is you could vary the inputs, you can say where the outputs go or you can use parameters to run, subsets of the data and therefore have subsets of the environment and it can even make a time machine based on parameters. So for example, if you have your data in let's say S3 buckets the font the file names or the paths have a date stamp on them, you can use that as a parameter, you can say which buckets you take your inputs from. It could be the production data and then parameterize, Where the outputs go, that could be a separate folder and S3 or a separate. Schema This gives you a lot of flexibility. So those are the seven steps.

00:32:12 What this looks like at a customer, and the seven-step summary

Gil Benghiat: a DataKitchen, we've been using these for quite some time and we've had some success in fact, our customers have a lot of success and then they're actually been bought and if we take Celgene as one of our customers, as an example, we've had, quite the operation going with hundreds of data sets, thousands of tests, lots of changes a week, all done with a small staff. No major data errors, and then it's cost effective. So, again, nothing's perfect. But, in contrast to driving to work with that pit in your stomach wondering, if the deploy is going to work, having tests having this environment can really work. So to summarize everything we've talked about is really, automate your pipelines, automate your environment, automate your tests, validate and those tests and then keep iterating. So finally, what did you jot down on your piece of paper? I hope you've been taking notes, you've been thinking about what you've heard, what you might want to try and I wish you success. as you go forward and apply some of these techniques.

00:33:39 Where do I start with DataOps?

Chris Bergh: Gil, thanks for That was great. And so, I'm just curious if anyone who had some thoughts on what they're gonna do next. If people want to share with the chat, While we do that, why don't we Go in the next slide.

Gil Benghiat: Yeah.

Chris Bergh: So the question always comes as DataOps is great but where do I start? And so, but over the years, I think, the best way to start DataOps is to start afresh and build Your system with DataOps principles in mind, with testing, with automated deployment. and so, That's the place but unfortunately not many people do that. They already have systems that are already built and they already have data that they want to focus first on kind of data quality and observability. And to do that, we've Open Source two products that I'd love to have people check out. So if you go to the next slide,

Gil Benghiat: Yeah.

00:34:38 The two open-source products: TestGen and DataOps Observability

Chris Bergh: So there are two products, one called DataOps TestGen, which is a data quality product that sort of snaps on your data. And it scans it and automatically build some of these data quality tests that Gil talked about and allows a nice UI for you to manage their configuration with your data governance or data quality people. And then we have another tool called DataOps Observability that really checks the tools. So really to have something that works great in production, you've got to check the tools acting upon data and the data itself and both of those are available under Apache 2.0 license for you to So please check them out.

00:35:22 The DataOps Cookbook, the certifications, and other resources

Chris Bergh: And then the last slide is, If you want more about DataOps, there's a bunch of stuff that we have. One is the free software start using it. The second one is, we have just more content. We have a book called The DataOps Cookbook. About, 250 pages, we have another book about how to transform your team with DataOps, and we have two certification programs. So the three-hour DataOps certification and a seven-hour Data Quality and TestGen certification, All available for you to use. And so it turns out you can't write in the chat but you can write in the Q&A. So we have some And so if you can go to the QA section by looking at the right, we're still seeing if anyone has any questions. And just to repeat, we will be sharing the slides and the stack in an email at the end of the day.

00:36:22 If someone asked one question: add tests, or start a quality circle

Chris Bergh: All right, there doesn't seem to be any questions. great. thank you so much Gil. you If there was a question that someone would ask? What do you think it would be?

Gil Benghiat: I think might be there's a lot here, what's the best place to start? there are seven steps. There's Agile. and I would say, do you have tests, it would be adding tests and think about should you add them in production or should you add them in development? And I guess, look for opportunities to do either but where would you get the most benefit? So I would say ad test first

Chris Bergh: Yeah, I agree, Gil, but I think a little differently. I think in my memory of the experience, the first thing I did was a quality circle. because there's a couple things, right. You have tests are a way to remove errors and errors. Could be in production data in raw data and integrated data or in the tools acting upon the data. And the best way to find those is, of course, tests or checks. But how do you find what tests to write? I think and also, how do you get over the psychological bump of not wanting to notice errors, hide your head in the sand. I think getting people together getting a list of all the problems you've had in the last week or two, prioritizing them finding out what it is. I think is the best thing for a team. Because I think from that perspective, they grow from kind of living in denial that they're having errors to a culture of kind of loving their errors and seeing them as an opportunity to improve.

Gil Benghiat: Yeah, yeah. that's a good point. It is about dialogue. It is about culture, test, quality circles are a great way to do it, especially if you're focusing on production issues and another one is you could do retrospectives, that's a way to improve your process. But that said, what, part of the process should you improve, having it driven on production errors and quality circle is a great idea too. I'm seeing,…

Chris Bergh: Yeah.

Gil Benghiat: I don't have access to the Q&A but I'm seeing things pop up and go away here.

00:38:45 Which industries need DataOps most, and how to test edge cases

Chris Bergh: Yeah, So one question was a Celgene examples. Interesting, what industries do you see the most need for your product or for DataOps? I think in general there's two characteristics. One is where you have very demanding customers who demand insight and two. Is that where you have? Because those customers have insight, you have a lot of data of different types that you're bringing together and so both of those things cause the problems that DataOps has one is that your customers? How do you How do you deal with unrelenting customer questions and customer need? And How do you deal with unrelenting data, either different types or qualities or updates? And there's a lot of industries like that that have that, it's the typical data intensive, industries like financial services or health care. Those are ones, small companies, BBC companies but it's all over the map for us. it's manufacturing companies. Other companies who really take teams that take data, seriously, have demanding customers and have complicated data that's causing problems. And then another question is, Do you have a demo? Yeah, we have a demo. if you go to datakitchen.io there, you can get to a demo from there and we'll share one in the email. And another question is, What are your suggestions for testing edge cases, and DataOps? I think, from an edge case is interesting because I think From a perspective is that there's two ways to think of it, the edge case is really what's unique to your business and something that your team doesn't know. I mean, how do you get your data team or your analytics team to know these edge cases? And I think the first step is to take care of the basics, to be able to go in and make sure that you have broad coverage across all your tables, where you understood the data and then are looking for variations, or anomalies from that. And that's really where we put our TestGen, it does that automatically. the edge cases are really unique to your business. and, you can't say a pharma company even at a pharma company commercials very different from manufacturing, different types of financial services companies, manufacturing, they all have different data and needs. You need to be able to test edge cases based on that specific need of your customer. And so you need to be able to do that, both off and manage that from a data engineering perspective and from a business User perspective and I think that's important and so you kind of got to get through the first part to get to the edge part because the edge cases the fun part and being able to do that fast and get it in productions important.

Gil Benghiat: And one other comment on that is, I think that if you do have testing and your users do, find something that you missed. You go. can you consider that an edge case? Yeah. Something we didn't do and didn't consider. It's important to develop the kind of organizational muscle that if you're your customers or someone else finds an error that find out what it is at a test and then you could be confident that won't happen again.

Chris Bergh: Yeah, never let it good error. Go to waste, Another phrase is Run towards your errors,…

Gil Benghiat: Right.

00:41:52 Quick wins and fundamentals: hero teams, fear teams, and an assessment

Chris Bergh: not away from your errors, and errors are away and opportunity for you to show how great you are. So gil, Here's a question for you. what would you consider quick wins or fundamentals? That allow for a successful journey to start implementing DataOps functionalities into a data platform.

Gil Benghiat: Quick wins and fundamentals I think that that's a very generic question. I think it's reflecting back on it. I think would take a little bit of an assessment Where are the bigger troubles in your organization where What is the low-hanging fruit and every organization is different, for some it may be adding tests for some it, it it's about development. So, I don't know to me that really depends on where you are in your organization. I don't know.

Chris Bergh: Yeah. Yeah,…

Gil Benghiat: What do you think Chris?

Chris Bergh: we have a Gil, brought up our sort of DataOps assessment, which you can actually take on our website go in and get an assessment and broadly, speaking kind of teams are in two buckets, right? There's hero teams, right, who are, and we're doing a consulting engagement with one now, or everyone's working hard. They're killing themselves and they have one and maybe it's a whole group of people but there's one or two heroes in here, So vitally important that the whole system will blow up if they leave and heroism is great. You just don't want to do it. And then, on the other hand, you have teams that are just living fear. So it takes so much to make a change and they have processes and SDLCs, and it can take months to get anything new done. And so to start is What kind of team Are you a hero team? Are you a fear team and I think from that you goes where you're quick wins are and I think start with an assessment start with kind of looking at you your

00:43:39 Start measuring with a spreadsheet: errors, deploys, and where time goes

Chris Bergh: And going for things and this is maybe boring to say. But that kind of quick wins that we said, We have seen having things like starting with the quality circle and starting with testing. The other part is just starting with your own measurement. How many errors do you have in production? Is it once a week twice a week, start with a spreadsheet. Honestly, count your errors count, how fast you deploy. and the other part is just ask your people what they're working up because oftentimes your teams are 80% of their time. They're not doing Good work that chart that Gil had at the beginning that showed the amount of waste that the detailed.

Gil Benghiat: Yeah. But not doing the work.

Chris Bergh: And so you can

Gil Benghiat: You expect that they're working.

Chris Bergh: Yeah, it just certainly them How much time this week? Did you actually code, or did you actually do work? and you can get a lot of data, just from spreadsheets, counting your errors counting. How often you deploy, seeing how many times that employees break asking your people? what they're doing? And even anecdotally, you can get a sense of sort of where your problems are just from that because I think, Another Problem with Data and Analytics Management. we're not very data-driven about how our teams run and that measurement section that Gil output on and tornado. Charts and DataOps allows you to build a layer of measurement automatically in your team. But you can also start kind of manually as well.

00:45:33 The five whys, and why teams avoid finding root causes

Chris Bergh: And someone brought up the five whys — Gil, you want to talk about the five whys and doing understanding a data issue and… we're causing analysis.

Gil Benghiat: that's actually really good. Yeah. so this gets into, if you're doing a root cause analysis, if you're in a quality circle and something goes wrong, there's this technique, they say, ask why five times and then you'll really get to the root so it could be my car didn't work. the battery died it was cold, and it drained overnight, and it's like, why? we're not maintaining the car. We didn't add the fluids, like we're so the car dies. but the root cause after five whys is that maintenance, it turns out it's a maintenance issue so it's a technique at getting at the root and it's a good one. Thanks whoever mentioned that. Thank you.

Chris Bergh: Yeah, yeah, and I think to me, I look at it from a team emotion standpoint, I think a lot of teams avoid finding root causes. They're always focused on building the next thing and not focused on Sort of the once you built it, How do you run it with low errors or How do you change it quickly or How do you measure it? So you can find these things and all these sort of day two and three activities of monitoring. testing it changing, It aren't as fun as building the new things but you have to build a system to do that because your day too and day three of building anything in analytics. Any kind of data transformation, any kind of visualization or predictive model really matters. And I think if anything DataOps is about a focusing on that second and third day,

00:47:44 Closing: resources and thanks

Chris Bergh: All right, one more question. So we gotta thank you. And again there's a lot of resources here to follow up on. We' had, about 30,000, people read our book, we've had about 3,000 people, go through our online trainings. These are really good resources for you, where we continue to update them. We updated the cookbook this year. And so feel free to reach out from a DataKitchen standpoint. We do management consulting and we also have software for you to use and check it out and I'll follow up with an email. So thank you so much for the questions and have a great rest of your day.

Gil Benghiat: Thanks folks, good And if you have a question, you could contact us.

Chris Bergh: Okay.