>>Hello and welcome today's cube presentation of eight of us startup showcase. I'm john for your host highlighting the hottest companies and devops data analytics and cloud management lisa martin and David want are here to kick it off. We've got a great program for you again. This is our, our new community event model where we're doing every quarter, we have every new episode, this is quarter three this year or episode three, season one of the hottest cloud startups and we're gonna be featured. Then we're gonna do a keynote package and then 15 countries will present their story, Go check them out and then have a closing keynote with a practitioner and we've got some great lineups, lisa Dave, great to see you. Thanks for joining me. >>Hey guys, >>great to be here. So David got to ask you, you know, back in events last night we're at the 14 it's event where they had the golf PGA championship with the cube Now we got the hybrid model, This is the new normal. We're in, we got these great companies were showcasing them. What's your take? >>Well, you're right. I mean, I think there's a combination of things. We're seeing some live shows. We saw what we did with at mobile world Congress. We did the show with AWS storage day where it was, we were at the spheres, there was no, there was a live audience, but they weren't there physically. It was just virtual and yeah, so, and I just got pained about reinvent. Hey Dave, you gotta make your flights. So I'm making my flights >>were gonna be at the amazon web services, public sector summit next week. At least a lot, a lot of cloud convergence going on here. We got many companies being featured here that we spoke with the Ceo and their top people cloud management, devops data, nelson security. Really cutting edge companies, >>yes, cutting edge companies who are all focused on acceleration. We've talked about the acceleration of digital transformation the last 18 months and we've seen a tremendous amount of acceleration in innovation with what these startups are doing. We've talked to like you said, there's, there's C suite, we've also talked to their customers about how they are innovating so quickly with this hybrid environment, this remote work and we've talked a lot about security in the last week or so. You mentioned that we were at Fortinet cybersecurity skills gap. What some of these companies are doing with automation for example, to help shorten that gap, which is a big opportunity >>for the job market. Great stuff. Dave so the format of this event, you're going to have a fireside chat with the practitioner, we'd like to end these programs with a great experienced practitioner cutting edge in data february. The beginning lisa are gonna be kicking off with of course Jeff bar to give us the update on what's going on AWS and then a special presentation from Emily Freeman who is the author of devops for dummies, she's introducing new content. The revolution in devops devops two point oh and of course jerry Chen from Greylock cube alumni is going to come on and talk about his new thesis castles in the cloud creating moats at cloud scale. We've got a great lineup of people and so the front ends can be great. Dave give us a little preview of what people can expect at the end of the fireside chat. >>Well at the highest level john I've always said we're entering that sort of third great wave of cloud. First wave was experimentation. The second big wave was migration. The third wave of integration, Deep business integration and what you're >>going to hear from >>Hello Fresh today is how they like many companies that started early last decade. They started with an on prem Hadoop system and then of course we all know what happened is S three essentially took the knees out from, from the on prem Hadoop market lowered costs, brought things into the cloud and what Hello Fresh is doing is they're transforming from that legacy Hadoop system into its running on AWS but into a data mess, you know, it's a passionate topic of mine. Hello Fresh was scaling they realized that they couldn't keep up so they had to rethink their entire data architecture and they built it around data mesh Clements key and christoph Soewandi gonna explain how they actually did that are on a journey or decentralized data >>measure it and your posts have been awesome on data measure. We get a lot of traction. Certainly you're breaking analysis for the folks watching check out David Landes, Breaking analysis every week, highlighting the cutting edge trends in tech Dave. We're gonna see you later, lisa and I are gonna be here in the morning talking about with Emily. We got Jeff Barr teed up. Dave. Thanks for coming on. Looking forward to fireside chat lisa. We'll see you when Emily comes back on. But we're gonna go to Jeff bar right now for Dave and I are gonna interview Jeff. Mm >>Hey Jeff, >>here he is. Hey, how are you? How's it going really well. So I gotta ask you, the reinvent is on, everyone wants to know that's happening right. We're good with Reinvent. >>Reinvent is happening. I've got my hotel and actually listening today, if I just remembered, I still need to actually book my flights. I've got my to do list on my desk and I do need to get my >>flights. Uh, >>really looking forward >>to it. I can't wait to see the all the announcements and blog posts. We're gonna, we're gonna hear from jerry Chen later. I love the after on our next event. Get your reaction to this castle and castles in the cloud where competitive advantages can be built in the cloud. We're seeing examples of that. But first I gotta ask you give us an update of what's going on. The ap and ecosystem has been an incredible uh, celebration these past couple weeks, >>so, so a lot of different things happening and the interesting thing to me is that as part of my job, I often think that I'm effectively living in the future because I get to see all this really cool stuff that we're building just a little bit before our customers get to, and so I'm always thinking okay, here I am now, and what's the world going to be like in a couple of weeks to a month or two when these launches? I'm working on actually get out the door and that, that's always really, really fun, just kind of getting that, that little edge into where we're going, but this year was a little interesting because we had to really significant birthdays, we had the 15 year anniversary of both EC two and S three and we're so focused on innovating and moving forward, that it's actually pretty rare for us at Aws to look back and say, wow, we've actually done all these amazing things in in the last 15 years, >>you know, it's kind of cool Jeff, if I may is is, you know, of course in the early days everybody said, well, a place for startup is a W. S and now the great thing about the startup showcases, we're seeing the startups that >>are >>very near, or some of them have even reached escape velocity, so they're not, they're not tiny little companies anymore, they're in their transforming their respective industries, >>they really are and I think that as they start ups grow, they really start to lean into the power of the cloud. They as they start to think, okay, we've we've got our basic infrastructure in place, we've got, we were serving data, we're serving up a few customers, everything is actually working pretty well for us. We've got our fundamental model proven out now, we can invest in publicity and marketing and scaling and but they don't have to think about what's happening behind the scenes. They just if they've got their auto scaling or if they're survivalists, the infrastructure simply grows to meet their demand and it's it's just a lot less things that they have to worry about. They can focus on the fun part of their business which is actually listening to customers and building up an awesome business >>Jeff as you guys are putting together all the big pre reinvented, knows a lot of stuff that goes on prior as well and they say all the big good stuff to reinvent. But you start to see some themes emerged this year. One of them is modernization of applications, the speed of application development in the cloud with the cloud scale devops personas, whatever persona you want to talk about but basically speed the speed of of the app developers where other departments have been slowing things down, I won't say name names, but security group and I t I mean I shouldn't have said that but only kidding but no but seriously people want in minutes and seconds now not days or weeks. You know whether it's policy. What are some of the trends that you're seeing around this this year as we get into some of the new stuff coming out >>So Dave customers really do want speed and for we've actually encapsulate this for a long time in amazon in what we call the bias for action leadership principle >>where >>we just need to jump in and move forward and and make things happen. A lot of customers look at that and they say yes this is great. We need to have the same bias fraction. Some do. Some are still trying to figure out exactly how to put it into play. And they absolutely for sure need to pay attention to security. They need to respect the past and make sure that whatever they're doing is in line with I. T. But they do want to move forward. And the interesting thing that I see time and time again is it's not simply about let's adopt a new technology. It's how do we >>how do we keep our workforce >>engaged? How do we make sure that they've got the right training? How do we bring our our I. T. Team along for this. Hopefully new and fun and exciting journey where they get to learn some interesting new technologies they've got all this very much accumulated business knowledge they still want to put to use, maybe they're a little bit apprehensive about something brand new and they hear about the cloud, but there by and large, they really want to move forward. They just need a little bit of >>help to make it happen >>real good guys. One of the things you're gonna hear today, we're talking about speed traditionally going fast. Oftentimes you meant you have to sacrifice some things on quality and what you're going to hear from some of the startups today is how they're addressing that to automation and modern devoPS technologies and sort of rethinking that whole application development approach. That's something I'm really excited to see organization is beginning to adopt so they don't have to make that tradeoff anymore. >>Yeah, I would >>never want to see someone >>sacrifice quality, >>but I do think that iterating very quickly and using the best of devoPS principles to be able to iterate incredibly quickly and get that first launch out there and then listen with both ears just >>as much >>as you can, Everything. You hear iterate really quickly to meet those needs in, in hours and days, not months, quarters or years. >>Great stuff. Chef and a lot of the companies were featuring here in the startup showcase represent that new kind of thinking, um, systems thinking as well as you know, the cloud scale and again and it's finally here, the revolution of deVOps is going to the next generation and uh, we're excited to have Emily Freeman who's going to come on and give a little preview for her new talk on this revolution. So Jeff, thank you for coming on, appreciate you sharing the update here on the cube. Happy >>to be. I'm actually really looking forward to hearing from Emily. >>Yeah, it's great. Great. Looking forward to the talk. Brand new Premier, Okay, uh, lisa martin, Emily Freeman is here. She's ready to come in and we're going to preview her lightning talk Emily. Um, thanks for coming on, we really appreciate you coming on really, this is about to talk around deVOPS next gen and I think lisa this is one of those things we've been, we've been discussing with all the companies. It's a new kind of thinking it's a revolution, it's a systems mindset, you're starting to see the connections there she is. Emily, Thanks for coming. I appreciate it. >>Thank you for having me. So your teaser video >>was amazing. Um, you know, that little secret radical idea, something completely different. Um, you gotta talk coming up, what's the premise behind this revolution, you know, these tying together architecture, development, automation deployment, operating altogether. >>Yes, well, we have traditionally always used the sclc, which is the software delivery life cycle. Um, and it is a straight linear process that has actually been around since the sixties, which is wild to me um, and really originated in manufacturing. Um, and as much as I love the Toyota production system and how much it has shown up in devops as a sort of inspiration on how to run things better. We are not making cars, we are making software and I think we have to use different approaches and create a sort of model that better reflects our modern software development process. >>It's a bold idea and looking forward to the talk and as motivation. I went into my basement and dusted off all my books from college in the 80s and the sea estimates it was waterfall. It was software development life cycle. They trained us to think this way and it came from the mainframe people. It was like, it's old school, like really, really old and it really hasn't been updated. Where's the motivation? I actually cloud is kind of converging everything together. We see that, but you kind of hit on this persona thing. Where did that come from this persona? Because you know, people want to put people in buckets release engineer. I mean, where's that motivation coming from? >>Yes, you're absolutely right that it came from the mainframes. I think, you know, waterfall is necessary when you're using a punch card or mag tape to load things onto a mainframe, but we don't exist in that world anymore. Thank goodness. And um, yes, so we, we use personas all the time in tech, you know, even to register, well not actually to register for this event, but a lot events. A lot of events, you have to click that drop down. Right. Are you a developer? Are you a manager, whatever? And the thing is personas are immutable in my opinion. I was a developer. I will always identify as a developer despite playing a lot of different roles and doing a lot of different jobs. Uh, and this can vary throughout the day. Right. You might have someone who has a title of software architect who ends up helping someone pair program or develop or test or deploy. Um, and so we wear a lot of hats day to day and I think our discussions around roles would be a better, um, certainly a better approach than personas >>lease. And I've been discussing with many of these companies around the roles and we're hearing from them directly and they're finding out that people have, they're mixing and matching on teams. So you're, you're an S R E on one team and you're doing something on another team where the workflows and the workloads defined the team formation. So this is a cultural discussion. >>It absolutely is. Yes. I think it is a cultural discussion and it really comes to the heart of devops, right? It's people process. And then tools deVOps has always been about culture and making sure that developers have all the tools they need to be productive and honestly happy. What good is all of this? If developing software isn't a joyful experience. Well, >>I got to ask you, I got you here obviously with server list and functions just starting to see this kind of this next gen. And we're gonna hear from jerry Chen, who's a Greylock VC who's going to talk about castles in the clouds, where he's discussing the moats that could be created with a competitive advantage in cloud scale. And I think he points to the snowflakes of the world. You're starting to see this new thing happening. This is devops 2.0, this is the revolution. Is this kind of where you see the same vision of your talk? >>Yes, so DeVOps created 2000 and 8, 2000 and nine, totally different ecosystem in the world we were living in, you know, we didn't have things like surveillance and containers, we didn't have this sort of default distributed nature, certainly not the cloud. Uh and so I'm very excited for jerry's talk. I'm curious to hear more about these moz. I think it's fascinating. Um but yeah, you're seeing different companies use different tools and processes to accelerate their delivery and that is the competitive advantage. How can we figure out how to utilize these tools in the most efficient way possible. >>Thank you for coming and giving us a preview. Let's now go to your lightning keynote talk. Fresh content. Premier of this revolution in Devops and the Freemans Talk, we'll go there now. >>Hi, I'm Emily Freeman, I'm the author of devops for dummies and the curator of 97 things every cloud engineer should know. I am thrilled to be here with you all today. I am really excited to share with you a kind of a wild idea, a complete re imagining of the S DLC and I want to be clear, I need your feedback. I want to know what you think of this. You can always find me on twitter at editing. Emily, most of my work centers around deVOps and I really can't overstate what an impact the concept of deVOPS has had on this industry in many ways it built on the foundation of Agile to become a default a standard we all reach for in our everyday work. When devops surfaced as an idea in 2008, the tech industry was in a vastly different space. AWS was an infancy offering only a handful of services. Azure and G C P didn't exist yet. The majority's majority of companies maintained their own infrastructure. Developers wrote code and relied on sys admins to deploy new code at scheduled intervals. Sometimes months apart, container technology hadn't been invented applications adhered to a monolithic architecture, databases were almost exclusively relational and serverless wasn't even a concept. Everything from the application to the engineers was centralized. Our current ecosystem couldn't be more different. Software is still hard, don't get me wrong, but we continue to find novel solutions to consistently difficult, persistent problems. Now, some of these end up being a sort of rebranding of old ideas, but others are a unique and clever take to abstracting complexity or automating toil or perhaps most important, rethinking challenging the very premises we have accepted as Cannon for years, if not decades. In the years since deVOps attempted to answer the critical conflict between developers and operations, engineers, deVOps has become a catch all term and there have been a number of derivative works. Devops has come to mean 5000 different things to 5000 different people. For some, it can be distilled to continuous integration and continuous delivery or C I C D. For others, it's simply deploying code more frequently, perhaps adding a smattering of tests for others. Still, its organizational, they've added a platform team, perhaps even a questionably named DEVOPS team or have created an engineering structure that focuses on a separation of concerns. Leaving feature teams to manage the development, deployment, security and maintenance of their siloed services, say, whatever the interpretation, what's important is that there isn't a universally accepted standard. Well, what deVOPS is or what it looks like an execution, it's a philosophy more than anything else. A framework people can utilize to configure and customize their specific circumstances to modern development practices. The characteristic of deVOPS that I think we can all agree on though, is that an attempted to capture the challenges of the entire software development process. It's that broad umbrella, that holistic view that I think we need to breathe life into again, The challenge we face is that DeVOps isn't increasingly outmoded solution to a previous problem developers now face. Cultural and technical challenge is far greater than how to more quickly deploy a monolithic application. Cloud native is the future the next collection of default development decisions and one the deVOPS story can't absorb in its current form. I believe the era of deVOPS is waning and in this moment as the sun sets on deVOPS, we have a unique opportunity to rethink rebuild free platform. Even now, I don't have a crystal ball. That would be very handy. I'm not completely certain with the next decade of tech looks like and I can't write this story alone. I need you but I have some ideas that can get the conversation started, I believe to build on what was we have to throw away assumptions that we've taken for granted all this time in order to move forward. We must first step back. Mhm. The software or systems development life cycle, what we call the S. D. L. C. has been in use since the 1960s and it's remained more or less the same since before color television and the touch tone phone. Over the last 60 or so odd years we've made tweaks, slight adjustments, massaged it. The stages or steps are always a little different with agile and deVOps we sort of looped it into a circle and then an infinity loop we've added pretty colors. But the sclc is more or less the same and it has become an assumption. We don't even think about it anymore, universally adopted constructs like the sclc have an unspoken permanence. They feel as if they have always been and always will be. I think the impact of that is even more potent. If you were born after a construct was popularized. Nearly everything around us is a construct, a model, an artifact of a human idea. The chair you're sitting in the desk, you work at the mug from which you drink coffee or sometimes wine, buildings, toilets, plumbing, roads, cars, art, computers, everything. The sclc is a remnant an artifact of a previous era and I think we should throw it away or perhaps more accurately replace it, replace it with something that better reflects the actual nature of our work. A linear, single threaded model designed for the manufacturer of material goods cannot possibly capture the distributed complexity of modern socio technical systems. It just can't. Mhm. And these two ideas aren't mutually exclusive that the sclc was industry changing, valuable and extraordinarily impactful and that it's time for something new. I believe we are strong enough to hold these two ideas at the same time, showing respect for the past while envisioning the future. Now, I don't know about you, I've never had a software project goes smoothly in one go. No matter how small. Even if I'm the only person working on it and committing directly to master software development is chaos. It's a study and entropy and it is not getting any more simple. The model with which we think and talk about software development must capture the multithreaded, non sequential nature of our work. It should embody the roles engineers take on and the considerations they make along the way. It should build on the foundations of agile and devops and represent the iterative nature of continuous innovation. Now, when I was thinking about this, I was inspired by ideas like extreme programming and the spiral model. I I wanted something that would have layers, threads, even a way of visually representing multiple processes happening in parallel. And what I settled on is the revolution model. I believe the visualization of revolution is capable of capturing the pivotal moments of any software scenario. And I'm going to dive into all the discrete elements. But I want to give you a moment to have a first impression, to absorb my idea. I call it revolution because well for one it revolves, it's circular shape reflects the continuous and iterative nature of our work, but also because it is revolutionary. I am challenging a 60 year old model that is embedded into our daily language. I don't expect Gartner to build a magic quadrant around this tomorrow, but that would be super cool. And you should call me my mission with. This is to challenge the status quo to create a model that I think more accurately reflects the complexity of modern cloud native software development. The revolution model is constructed of five concentric circles describing the critical roles of software development architect. Ng development, automating, deploying and operating intersecting each loop are six spokes that describe the production considerations every engineer has to consider throughout any engineering work and that's test, ability, secure ability, reliability, observe ability, flexibility and scalability. The considerations listed are not all encompassing. There are of course things not explicitly included. I figured if I put 20 spokes, some of us, including myself, might feel a little overwhelmed. So let's dive into each element in this model. We have long used personas as the default way to do divide audiences and tailor messages to group people. Every company in the world right now is repeating the mantra of developers, developers, developers but personas have always bugged me a bit because this approach typically either oversimplifies someone's career are needlessly complicated. Few people fit cleanly and completely into persona based buckets like developers and operations anymore. The lines have gotten fuzzy on the other hand, I don't think we need to specifically tailor messages as to call out the difference between a devops engineer and a release engineer or a security administrator versus a security engineer but perhaps most critically, I believe personas are immutable. A persona is wholly dependent on how someone identifies themselves. It's intrinsic not extrinsic. Their titles may change their jobs may differ, but they're probably still selecting the same persona on that ubiquitous drop down. We all have to choose from when registering for an event. Probably this one too. I I was a developer and I will always identify as a developer despite doing a ton of work in areas like devops and Ai Ops and Deverell in my heart. I'm a developer I think about problems from that perspective. First it influences my thinking and my approach roles are very different. Roles are temporary, inconsistent, constantly fluctuating. If I were an actress, the parts I would play would be lengthy and varied, but the persona I would identify as would remain an actress and artist lesbian. Your work isn't confined to a single set of skills. It may have been a decade ago, but it is not today in any given week or sprint, you may play the role of an architect. Thinking about how to design a feature or service, developer building out code or fixing a bug and on automation engineer, looking at how to improve manual processes. We often refer to as soil release engineer, deploying code to different environments or releasing it to customers or in operations. Engineer ensuring an application functions inconsistent expected ways and no matter what role we play. We have to consider a number of issues. The first is test ability. All software systems require testing to assure architects that designs work developers, the code works operators, that infrastructure is running as expected and engineers of all disciplines that code changes won't bring down the whole system testing in its many forms is what enables systems to be durable and have longevity. It's what reassures engineers that changes won't impact current functionality. A system without tests is a disaster waiting to happen, which is why test ability is first among equals at this particular roundtable. Security is everyone's responsibility. But if you understand how to design and execute secure systems, I struggle with this security incidents for the most part are high impact, low probability events. The really big disasters, the one that the ones that end up on the news and get us all free credit reporting for a year. They don't happen super frequently and then goodness because you know that there are endless small vulnerabilities lurking in our systems. Security is something we all know we should dedicate time to but often don't make time for. And let's be honest, it's hard and complicated and a little scary def sec apps. The first derivative of deVOPS asked engineers to move security left this approach. Mint security was a consideration early in the process, not something that would block release at the last moment. This is also the consideration under which I'm putting compliance and governance well not perfectly aligned. I figure all the things you have to call lawyers for should just live together. I'm kidding. But in all seriousness, these three concepts are really about risk management, identity, data, authorization. It doesn't really matter what specific issue you're speaking about, the question is who has access to what win and how and that is everyone's responsibility at every stage site reliability engineering or sorry, is a discipline job and approach for good reason. It is absolutely critical that applications and services work as expected. Most of the time. That said, availability is often mistakenly treated as a synonym for reliability. Instead, it's a single aspect of the concept if a system is available but customer data is inaccurate or out of sync. The system is not reliable, reliability has five key components, availability, latency, throughput. Fidelity and durability, reliability is the end result. But resiliency for me is the journey the action engineers can take to improve reliability, observe ability is the ability to have insight into an application or system. It's the combination of telemetry and monitoring and alerting available to engineers and leadership. There's an aspect of observe ability that overlaps with reliability, but the purpose of observe ability isn't just to maintain a reliable system though, that is of course important. It is the capacity for engineers working on a system to have visibility into the inner workings of that system. The concept of observe ability actually originates and linear dynamic systems. It's defined as how well internal states of a system can be understood based on information about its external outputs. If it is critical when companies move systems to the cloud or utilize managed services that they don't lose visibility and confidence in their systems. The shared responsibility model of cloud storage compute and managed services require that engineering teams be able to quickly be alerted to identify and remediate issues as they arise. Flexible systems are capable of adapting to meet the ever changing needs of the customer and the market segment, flexible code bases absorb new code smoothly. Embody a clean separation of concerns. Are partitioned into small components or classes and architected to enable the now as well as the next inflexible systems. Change dependencies are reduced or eliminated. Database schemas accommodate change well components, communicate via a standardized and well documented A. P. I. The only thing constant in our industry is change and every role we play, creating flexibility and solutions that can be flexible that will grow as the applications grow is absolutely critical. Finally, scalability scalability refers to more than a system's ability to scale for additional load. It implies growth scalability and the revolution model carries the continuous innovation of a team and the byproducts of that growth within a system. For me, scalability is the most human of the considerations. It requires each of us in our various roles to consider everyone around us, our customers who use the system or rely on its services, our colleagues current and future with whom we collaborate and even our future selves. Mhm. Software development isn't a straight line, nor is it a perfect loop. It is an ever changing complex dance. There are twirls and pivots and difficult spins forward and backward. Engineers move in parallel, creating truly magnificent pieces of art. We need a modern model for this modern era and I believe this is just the revolution to get us started. Thank you so much for having me. >>Hey, we're back here. Live in the keynote studio. I'm john for your host here with lisa martin. David lot is getting ready for the fireside chat ending keynote with the practitioner. Hello! Fresh without data mesh lisa Emily is amazing. The funky artwork there. She's amazing with the talk. I was mesmerized. It was impressive. >>The revolution of devops and the creative element was a really nice surprise there. But I love what she's doing. She's challenging the status quo. If we've learned nothing in the last year and a half, We need to challenge the status quo. A model from the 1960s that is no longer linear. What she's doing is revolutionary. >>And we hear this all the time. All the cube interviews we do is that you're seeing the leaders, the SVP's of engineering or these departments where there's new new people coming in that are engineering or developers, they're playing multiple roles. It's almost a multidisciplinary aspect where you know, it's like going into in and out burger in the fryer later and then you're doing the grill, you're doing the cashier, people are changing roles or an architect, their test release all in one no longer departmental, slow siloed groups. >>She brought up a great point about persona is that we no longer fit into these buckets. That the changing roles. It's really the driver of how we should be looking at this. >>I think I'm really impressed, really bold idea, no brainer as far as I'm concerned, I think one of the things and then the comments were off the charts in a lot of young people come from discord servers. We had a good traction over there but they're all like learning. Then you have the experience, people saying this is definitely has happened and happening. The dominoes are falling and they're falling in the direction of modernization. That's the key trend speed. >>Absolutely with speed. But the way that Emily is presenting it is not in a brash bold, but it's in a way that makes great sense. The way that she creatively visually lined out what she was talking about Is amenable to the folks that have been doing this for since the 60s and the new folks now to really look at this from a different >>lens and I think she's a great setup on that lightning top of the 15 companies we got because you think about sis dig harness. I white sourced flamingo hacker one send out, I oh, okay. Thought spot rock set Sarah Ops ramp and Ops Monte cloud apps, sani all are doing modern stuff and we talked to them and they're all on this new wave, this monster wave coming. What's your observation when you talk to these companies? >>They are, it was great. I got to talk with eight of the 15 and the amount of acceleration of innovation that they've done in the last 18 months is phenomenal obviously with the power and the fuel and the brand reputation of aws but really what they're all facilitating cultural shift when we think of devoPS and the security folks. Um, there's a lot of work going on with ai to an automation to really kind of enabled to develop the develops folks to be in control of the process and not have to be security experts but ensuring that the security is baked in shifting >>left. We saw that the chat room was really active on the security side and one of the things I noticed was not just shift left but the other groups, the security groups and the theme of cultural, I won't say war but collision cultural shift that's happening between the groups is interesting because you have this new devops persona has been around Emily put it out for a while. But now it's going to the next level. There's new revolutions about a mindset, a systems mindset. It's a thinking and you start to see the new young companies coming out being funded by the gray locks of the world who are now like not going to be given the we lost the top three clouds one, everything. there's new business models and new technical architecture in the cloud and that's gonna be jerry Chen talk coming up next is going to be castles in the clouds because jerry chant always talked about moats, competitive advantage and how moats are key to success to guard the castle. And then we always joke, there's no more moz because the cloud has killed all the boats. But now the motor in the cloud, the castles are in the cloud, not on the ground. So very interesting thought provoking. But he's got data and if you look at the successful companies like the snowflakes of the world, you're starting to see these new formations of this new layer of innovation where companies are growing rapidly, 98 unicorns now in the cloud. Unbelievable, >>wow, that's a lot. One of the things you mentioned, there's competitive advantage and these startups are all fueled by that they know that there are other companies in the rear view mirror right behind them. If they're not able to work as quickly and as flexibly as a competitor, they have to have that speed that time to market that time to value. It was absolutely critical. And that's one of the things I think thematically that I saw along the eighth sort of that I talked to is that time to value is absolutely table stakes. >>Well, I'm looking forward to talking to jerry chan because we've talked on the queue before about this whole idea of What happens when winner takes most would mean the top 3, 4 cloud players. What happens? And we were talking about that and saying, if you have a model where an ecosystem can develop, what does that look like and back in 2013, 2014, 2015, no one really had an answer. Jerry was the only BC. He really nailed it with this castles in the cloud. He nailed the idea that this is going to happen. And so I think, you know, we'll look back at the tape or the videos from the cube, we'll find those cuts. But we were talking about this then we were pontificating and riffing on the fact that there's going to be new winners and they're gonna look different as Andy Jassy always says in the cube you have to be misunderstood if you're really going to make something happen. Most of the most successful companies are misunderstood. Not anymore. The cloud scales there. And that's what's exciting about all this. >>It is exciting that the scale is there, the appetite is there the appetite to challenge the status quo, which is right now in this economic and dynamic market that we're living in is there's nothing better. >>One of the things that's come up and and that's just real quick before we bring jerry in is automation has been insecurity, absolutely security's been in every conversation, but automation is now so hot in the sense of it's real and it's becoming part of all the design decisions. How can we automate can we automate faster where the keys to automation? Is that having the right data, What data is available? So I think the idea of automation and Ai are driving all the change and that's to me is what these new companies represent this modern error where AI is built into the outcome and the apps and all that infrastructure. So it's super exciting. Um, let's check in, we got jerry Chen line at least a great. We're gonna come back after jerry and then kick off the day. Let's bring in jerry Chen from Greylock is he here? Let's bring him in there. He is. >>Hey john good to see you. >>Hey, congratulations on an amazing talk and thesis on the castles on the cloud. Thanks for coming on. >>All right, Well thanks for reading it. Um, always were being put a piece of workout out either. Not sure what the responses, but it seemed to resonate with a bunch of developers, founders, investors and folks like yourself. So smart people seem to gravitate to us. So thank you very much. >>Well, one of the benefits of doing the Cube for 11 years, Jerry's we have videotape of many, many people talking about what the future will hold. You kind of are on this early, it wasn't called castles in the cloud, but you were all I was, we had many conversations were kind of connecting the dots in real time. But you've been on this for a while. It's great to see the work. I really think you nailed this. I think you're absolutely on point here. So let's get into it. What is castles in the cloud? New research to come out from Greylock that you spearheaded? It's collaborative effort, but you've got data behind it. Give a quick overview of what is castle the cloud, the new modes of competitive advantage for companies. >>Yeah, it's as a group project that our team put together but basically john the question is, how do you win in the cloud? Remember the conversation we had eight years ago when amazon re event was holy cow, Like can you compete with them? Like is it a winner? Take all? Winner take most And if it is winner take most, where are the white spaces for Some starts to to emerge and clearly the past eight years in the cloud this journey, we've seen big companies, data breaks, snowflakes, elastic Mongo data robot. And so um they spotted the question is, you know, why are the castles in the cloud? The big three cloud providers, Amazon google and Azure winning. You know, what advantage do they have? And then given their modes of scale network effects, how can you as a startup win? And so look, there are 500 plus services between all three cloud vendors, but there are like 500 plus um startups competing gets a cloud vendors and there's like almost 100 unicorn of private companies competing successfully against the cloud vendors, including public companies. So like Alaska, Mongo Snowflake. No data breaks. Not public yet. Hashtag or not public yet. These are some examples of the names that I think are winning and watch this space because you see more of these guys storm the castle if you will. >>Yeah. And you know one of the things that's a funny metaphor because it has many different implications. One, as we talk about security, the perimeter of the gates, the moats being on land. But now you're in the cloud, you have also different security paradigm. You have a different um, new kinds of services that are coming on board faster than ever before. Not just from the cloud players but From companies contributing into the ecosystem. So the combination of the big three making the market the main markets you, I think you call 31 markets that we know of that probably maybe more. And then you have this notion of a sub market, which means that there's like we used to call it white space back in the day, remember how many whites? Where's the white space? I mean if you're in the cloud, there's like a zillion white spaces. So talk about this sub market dynamic between markets and that are being enabled by the cloud players and how these sub markets play into it. >>Sure. So first, the first problem was what we did. We downloaded all the services for the big three clowns. Right? And you know what as recalls a database or database service like a document DB and amazon is like Cosmo dB and Azure. So first thing first is we had to like look at all three cloud providers and you? Re categorize all the services almost 500 Apples, Apples, Apples # one number two is you look at all these markets or sub markets and said, okay, how can we cluster these services into things that you know you and I can rock right. That's what amazon Azure and google think about. It is very different and the beauty of the cloud is this kind of fat long tail of services for developers. So instead of like oracle is a single database for all your needs. They're like 20 or 30 different databases from time series um analytics, databases. We're talking rocks at later today. Right. Um uh, document databases like Mongo search database like elastic. And so what happens is there's not one giant market like databases, there's a database market And 30, 40 sub markets that serve the needs developers. So the Great News is cloud has reduced the cost and create something that new for developers. Um also the good news is for a start up you can find plenty of white speeds solving a pain point, very specific to a different type of problem >>and you can sequence up to power law to this. I love the power of a metaphor, you know, used to be a very thin neck note no torso and then a long tail. But now as you're pointing out this expansion of the fat tail of services, but also there's big tam's and markets available at the top of the power law where you see coming like snowflake essentially take on the data warehousing market by basically sitting on amazon re factoring with new services and then getting a flywheel completely changing the economic unit economics completely changing the consumption model completely changing the value proposition >>literally you >>get Snowflake has created like a storm, create a hole, that mode or that castle wall against red shift. Then companies like rock set do your real time analytics is Russian right behind snowflakes saying, hey snowflake is great for data warehouse but it's not fast enough for real time analytics. Let me give you something new to your, to your parallel argument. Even the big optic snowflake have created kind of a wake behind them that created even more white space for Gaza rock set. So that's exciting for guys like me and >>you. And then also as we were talking about our last episode two or quarter two of our showcase. Um, from a VC came on, it's like the old shelf where you didn't know if a company's successful until they had to return the inventory now with cloud you if you're not successful, you know it right away. It's like there's no debate. Like, I mean you're either winning or not. This is like that's so instrumented so a company can have a good better mousetrap and win and fill the white space and then move up. >>It goes both ways. The cloud vendor, the big three amazon google and Azure for sure. They instrument their own class. They know john which ecosystem partners doing well in which ecosystems doing poorly and they hear from the customers exactly what they want. So it goes both ways they can weaponize that. And just as well as you started to weaponize that info >>and that's the big argument of do that snowflake still pays the amazon bills. They're still there. So again, repatriation comes back, That's a big conversation that's come up. What's your quick take on that? Because if you're gonna have a castle in the cloud, then you're gonna bring it back to land. I mean, what's that dynamic? Where do you see that compete? Because on one hand is innovation. The other ones maybe cost efficiency. Is that a growth indicator slow down? What's your view on the movement from and to the cloud? >>I think there's probably three forces you're finding here. One is the cost advantage in the scale advantage of cloud so that I think has been going for the past eight years, there's a repatriation movement for a certain subset of customers, I think for cost purposes makes sense. I think that's a tiny handful that believe they can actually run things better than a cloud. The third thing we're seeing around repatriation is not necessary against cloud, but you're gonna see more decentralized clouds and things pushed to the edge. Right? So you look at companies like Cloudflare Fastly or a company that we're investing in Cato networks. All ideas focus on secure access at the edge. And so I think that's not the repatriation of my own data center, which is kind of a disaggregated of cloud from one giant monolithic cloud, like AWS east or like a google region in europe to multiple smaller clouds for governance purposes, security purposes or legacy purposes. >>So I'm looking at my notes here, looking down on the screen here for this to read this because it's uh to cut and paste from your thesis on the cloud. The excellent cloud. The of the $38 billion invested this quarter. Um Ai and ml number one, um analytics. Number two, security number three. Actually, security number one. But you can see the bubbles here. So all those are data problems I need to ask you. I see data is hot data as intellectual property. How do you look at that? Because we've been reporting on this and we just started the cube conversation around workflows as intellectual property. If you have scale and your motives in the cloud. You could argue that data and the workflows around those data streams is intellectual property. It's a protocol >>I believe both are. And they just kind of go hand in hand like peanut butter and jelly. Right? So data for sure. I. P. So if you know people talk about days in the oil, the new resource. That's largely true because of powers a bunch. But the workflow to your point john is sticky because every company is a unique snowflake right? Like the process used to run the cube and your business different how we run our business. So if you can build a workflow that leverages the data, that's super sticky. So in terms of switching costs, if my work is very bespoke to your business, then I think that's competitive advantage. >>Well certainly your workflow is a lot different than the cube. You guys just a lot of billions of dollars in capital. We're talking to all the people out here jerry. Great to have you on final thought on your thesis. Where does it go from here? What's been the reaction? Uh No, you put it out there. Great love the restart. Think you're on point on this one. Where did we go from here? >>We have to follow pieces um in the near term one around, you know, deep diver on open source. So look out for that pretty soon and how that's been a powerful strategy a second. Is this kind of just aggregation of the cloud be a Blockchain and you know, decentralized apps, be edge applications. So that's in the near term two more pieces of, of deep dive we're doing. And then the goal here is to update this on a quarterly and annual basis. So we're getting submissions from founders that wanted to say, hey, you missed us or he screwed up here. We got the big cloud vendors saying, Hey jerry, we just lost his new things. So our goal here is to update this every single year and then probably do look back saying, okay, uh, where were we wrong? We're right. And then let's say the castle clouds 2022. We'll see the difference were the more unicorns were there more services were the IPO's happening. So look for some short term work from us on analytics, like around open source and clouds. And then next year we hope that all of this forward saying, Hey, you have two year, what's happening? What's changing? >>Great stuff and, and congratulations on the southern news. You guys put another half a billion dollars into early, early stage, which is your roots. Are you still doing a lot of great investments in a lot of unicorns. Congratulations that. Great luck on the team. Thanks for coming on and congratulations you nailed this one. I think I'm gonna look back and say that this is a pretty seminal piece of work here. Thanks for sharing. >>Thanks john thanks for having us. >>Okay. Okay. This is the cube here and 81 startup showcase. We're about to get going in on all the hot companies closing out the kino lisa uh, see jerry Chen cube alumni. He was right from day one. We've been riffing on this, but he nails it here. I think Greylock is lucky to have him as a general partner. He's done great deals, but I think he's hitting the next wave big. This is, this is huge. >>I was listening to you guys talking thinking if if you had a crystal ball back in 2013, some of the things Jerry saying now his narrative now, what did he have a crystal >>ball? He did. I mean he could be a cuBA host and I could be a venture capital. We were both right. I think so. We could have been, you know, doing that together now and all serious now. He was right. I mean, we talked off camera about who's the next amazon who's going to challenge amazon and Andy Jassy was quoted many times in the queue by saying, you know, he was surprised that it took so long for people to figure out what they were doing. Okay, jerry was that VM where he had visibility into the cloud. He saw amazon right away like we did like this is a winning formula and so he was really out front on this one. >>Well in the investments that they're making in these unicorns is exciting. They have this, this lens that they're able to see the opportunities there almost before anybody else can. And finding more white space where we didn't even know there was any. >>Yeah. And what's interesting about the report I'm gonna dig into and I want to get to him while he's on camera because it's a great report, but He says it's like 500 services I think Amazon has 5000. So how you define services as an interesting thing and a lot of amazon services that they have as your doesn't have and vice versa, they do call that out. So I find the report interesting. It's gonna be a feature game in the future between clouds the big three. They're gonna say we do this, you're starting to see the formation, Google's much more developer oriented. Amazon is much more stronger in the governance area with data obviously as he pointed out, they have such experience Microsoft, not so much their developer cloud and more office, not so much on the government's side. So that that's an indicator of my, my opinion of kind of where they rank. So including the number one is still amazon web services as your long second place, way behind google, right behind Azure. So we'll see how the horses come in, >>right. And it's also kind of speaks to the hybrid world in which we're living the hybrid multi cloud world in which many companies are living as companies to not just survive in the last year and a half, but to thrive and really have to become data companies and leverage that data as a competitive advantage to be able to unlock the value of it. And a lot of these startups that we talked to in the showcase are talking about how they're helping organizations unlock that data value. As jerry said, it is the new oil, it's the new gold. Not unless you can unlock that value faster than your competition. >>Yeah, well, I'm just super excited. We got a great day ahead of us with with all the cots startups. And then at the end day, Volonte is gonna interview, hello, fresh practitioners, We're gonna close it out every episode now, we're going to do with the closing practitioner. We try to get jpmorgan chase data measures. The hottest area right now in the enterprise data is new competitive advantage. We know that data workflows are now intellectual property. You're starting to see data really factoring into these applications now as a key aspect of the competitive advantage and the value creation. So companies that are smart are investing heavily in that and the ones that are kind of slow on the uptake are lagging the market and just trying to figure it out. So you start to see that transition and you're starting to see people fall away now from the fact that they're not gonna make it right, You're starting to, you know, you can look at look at any happens saying how much ai is really in there. Real ai what's their data strategy and you almost squint through that and go, okay, that's gonna be losing application. >>Well the winners are making it a board level conversation >>And security isn't built in. Great to have you on this morning kicking it off. Thanks John Okay, we're going to go into the next set of the program at 10:00 we're going to move into the breakouts. Check out the companies is three tracks in there. We have an awesome track on devops pure devops. We've got the data and analytics and we got the cloud management and just to run down real quick check out the sis dig harness. Io system is doing great, securing devops harness. IO modern software delivery platform, White Source. They're preventing and remediating the rest of the internet for them for the company's that's a really interesting and lumbago, effortless acres land and monitoring functions, server list super hot. And of course hacker one is always great doing a lot of great missions and and bounties you see those success continue to send i O there in Palo alto changing the game on data engineering and data pipe lining. Okay. Data driven another new platform, horizontally scalable and of course thought spot ai driven kind of a search paradigm and of course rock set jerry Chen's companies here and press are all doing great in the analytics and then the cloud management cost side 80 operations day to operate. Ops ramps and ops multi cloud are all there and sunny, all all going to present. So check them out. This is the Cubes Adria's startup showcase episode three.

>>Hello and welcome today's cube presentation of eight of us startup showcase. I'm john for your host highlighting the hottest companies and devops data analytics and cloud management lisa martin and David want are here to kick it off. We've got a great program for you again. This is our, our new community event model where we're doing every quarter, we have every new episode, this is quarter three this year or episode three, season one of the hottest cloud startups and we're gonna be featured. Then we're gonna do a keynote package and then 15 countries will present their story, Go check them out and then have a closing keynote with a practitioner and we've got some great lineups, lisa Dave, great to see you. Thanks for joining me. Hey >>guys, great to be here. >>So David got to ask you, you know, back in events last night we're at the 14 it's event where they had the golf PGA championship with the cube Now we got the hybrid model, This is the new normal. We're in, we got these great companies were showcasing them. What's your take? >>Well, you're right. I mean, I think there's a combination of things. We're seeing some live shows. We saw what we did with at mobile world Congress. We did the show with AWS storage day where it was, we were at the spheres, there was no, there was a live audience, but they weren't there physically. It was just virtual and yeah, so, and I just got pained about reinvent. Hey Dave, you gotta make your flights. So I'm making my flights >>were gonna be at the amazon web services, public sector summit next week. At least a lot, a lot of cloud convergence going on here. We got many companies being featured here that we spoke with the Ceo and their top people cloud management, devops data, nelson security. Really cutting edge companies, >>yes, cutting edge companies who are all focused on acceleration. We've talked about the acceleration of digital transformation the last 18 months and we've seen a tremendous amount of acceleration in innovation with what these startups are doing. We've talked to like you said, there's, there's C suite, we've also talked to their customers about how they are innovating so quickly with this hybrid environment, this remote work and we've talked a lot about security in the last week or so. You mentioned that we were at Fortinet cybersecurity skills gap. What some of these companies are doing with automation for example, to help shorten that gap, which is a big opportunity for the >>job market. Great stuff. Dave so the format of this event, you're going to have a fireside chat with the practitioner, we'd like to end these programs with a great experienced practitioner cutting edge in data february. The beginning lisa are gonna be kicking off with of course Jeff bar to give us the update on what's going on AWS and then a special presentation from Emily Freeman who is the author of devops for dummies, she's introducing new content. The revolution in devops devops two point oh and of course jerry Chen from Greylock cube alumni is going to come on and talk about his new thesis castles in the cloud creating moats at cloud scale. We've got a great lineup of people and so the front ends can be great. Dave give us a little preview of what people can expect at the end of the fireside chat. >>Well at the highest level john I've always said we're entering that sort of third great wave of cloud. First wave was experimentation. The second big wave was migration. The third wave of integration, Deep business integration and what you're going to hear from Hello Fresh today is how they like many companies that started early last decade. They started with an on prem Hadoop system and then of course we all know what happened is S three essentially took the knees out from, from the on prem Hadoop market lowered costs, brought things into the cloud and what Hello Fresh is doing is they're transforming from that legacy Hadoop system into its running on AWS but into a data mess, you know, it's a passionate topic of mine. Hello Fresh was scaling they realized that they couldn't keep up so they had to rethink their entire data architecture and they built it around data mesh Clements key and christoph Soewandi gonna explain how they actually did that are on a journey or decentralized data measure >>it and your posts have been awesome on data measure. We get a lot of traction. Certainly you're breaking analysis for the folks watching check out David Landes, Breaking analysis every week, highlighting the cutting edge trends in tech Dave. We're gonna see you later, lisa and I are gonna be here in the morning talking about with Emily. We got Jeff Barr teed up. Dave. Thanks for coming on. Looking forward to fireside chat lisa. We'll see you when Emily comes back on. But we're gonna go to Jeff bar right now for Dave and I are gonna interview Jeff. Mm >>Hey Jeff, >>here he is. Hey, how are you? How's it >>going really well. >>So I gotta ask you, the reinvent is on, everyone wants to know that's happening right. We're good with Reinvent. >>Reinvent is happening. I've got my hotel and actually listening today, if I just remembered, I still need to actually book my flights. I've got my to do list on my desk and I do need to get my flights. Uh, really looking forward to it. >>I can't wait to see the all the announcements and blog posts. We're gonna, we're gonna hear from jerry Chen later. I love the after on our next event. Get your reaction to this castle and castles in the cloud where competitive advantages can be built in the cloud. We're seeing examples of that. But first I gotta ask you give us an update of what's going on. The ap and ecosystem has been an incredible uh, celebration these past couple weeks, >>so, so a lot of different things happening and the interesting thing to me is that as part of my job, I often think that I'm effectively living in the future because I get to see all this really cool stuff that we're building just a little bit before our customers get to, and so I'm always thinking okay, here I am now, and what's the world going to be like in a couple of weeks to a month or two when these launches? I'm working on actually get out the door and that, that's always really, really fun, just kind of getting that, that little edge into where we're going, but this year was a little interesting because we had to really significant birthdays, we had the 15 year anniversary of both EC two and S three and we're so focused on innovating and moving forward, that it's actually pretty rare for us at Aws to look back and say, wow, we've actually done all these amazing things in in the last 15 years, >>you know, it's kind of cool Jeff, if I may is is, you know, of course in the early days everybody said, well, a place for startup is a W. S and now the great thing about the startup showcases, we're seeing the startups that are very near, or some of them have even reached escape velocity, so they're not, they're not tiny little companies anymore, they're in their transforming their respective industries, >>they really are and I think that as they start ups grow, they really start to lean into the power of the cloud. They as they start to think, okay, we've we've got our basic infrastructure in place, we've got, we were serving data, we're serving up a few customers, everything is actually working pretty well for us. We've got our fundamental model proven out now, we can invest in publicity and marketing and scaling and but they don't have to think about what's happening behind the scenes. They just if they've got their auto scaling or if they're survivalists, the infrastructure simply grows to meet their demand and it's it's just a lot less things that they have to worry about. They can focus on the fun part of their business which is actually listening to customers and building up an awesome business >>Jeff as you guys are putting together all the big pre reinvented, knows a lot of stuff that goes on prior as well and they say all the big good stuff to reinvent. But you start to see some themes emerged this year. One of them is modernization of applications, the speed of application development in the cloud with the cloud scale devops personas, whatever persona you want to talk about but basically speed the speed of of the app developers where other departments have been slowing things down, I won't say name names, but security group and I t I mean I shouldn't have said that but only kidding but no but seriously people want in minutes and seconds now not days or weeks. You know whether it's policy. What are some of the trends that you're seeing around this this year as we get into some of the new stuff coming out >>So Dave customers really do want speed and for we've actually encapsulate this for a long time in amazon in what we call the bias for action leadership principle where we just need to jump in and move forward and and make things happen. A lot of customers look at that and they say yes this is great. We need to have the same bias fraction. Some do. Some are still trying to figure out exactly how to put it into play. And they absolutely for sure need to pay attention to security. They need to respect the past and make sure that whatever they're doing is in line with I. T. But they do want to move forward. And the interesting thing that I see time and time again is it's not simply about let's adopt a new technology. It's how do we how do we keep our workforce engaged? How do we make sure that they've got the right training? How do we bring our our I. T. Team along for this. Hopefully new and fun and exciting journey where they get to learn some interesting new technologies they've got all this very much accumulated business knowledge they still want to put to use, maybe they're a little bit apprehensive about something brand new and they hear about the cloud, but there by and large, they really want to move forward. They just need a little bit of help to make it happen real >>good guys. One of the things you're gonna hear today, we're talking about speed traditionally going fast. Oftentimes you meant you have to sacrifice some things on quality and what you're going to hear from some of the startups today is how they're addressing that to automation and modern devoPS technologies and sort of rethinking that whole application development approach. That's something I'm really excited to see organization is beginning to adopt so they don't have to make that tradeoff anymore. >>Yeah, I would never want to see someone sacrifice quality, but I do think that iterating very quickly and using the best of devoPS principles to be able to iterate incredibly quickly and get that first launch out there and then listen with both ears just as much as you can, Everything. You hear iterate really quickly to meet those needs in, in hours and days, not months, quarters or years. >>Great stuff. Chef and a lot of the companies were featuring here in the startup showcase represent that new kind of thinking, um, systems thinking as well as you know, the cloud scale and again and it's finally here, the revolution of deVOps is going to the next generation and uh, we're excited to have Emily Freeman who's going to come on and give a little preview for her new talk on this revolution. So Jeff, thank you for coming on, appreciate you sharing the update here on the cube. Happy >>to be. I'm actually really looking forward to hearing from Emily. >>Yeah, it's great. Great. Looking forward to the talk.

>>Hello. And we're here at the cube startup showcase made possible by a Ws. Thanks so much for joining us today. You know when Jim McDaid Ghani was formulating her ideas around data mesh, She wasn't the only one thinking about decentralized data architecture. Hello, Fresh was going into hyper growth mode and realized that in order to support its scale, it needed to rethink how it thought about data. Like many companies that started in the early part of last decade, Hello Fresh relied on a monolithic data architecture and the internal team. It had concerns about its ability to support continued innovation at high velocity. The company's data team began to think about the future and work backwards from a target architecture which possessed many principles of so called data mesh even though they didn't use that term. Specifically, the company is a strong example of an early but practical pioneer of data mission. Now there are many practitioners and stakeholders involved in evolving the company's data architecture, many of whom are listed here on this on the slide to are highlighted in red are joining us today, we're really excited to welcome into the cube Clements cheese, the Global Senior Director for Data at Hello Fresh and christoph Nevada who's the Global Senior Director of data also, of course. Hello Fresh folks. Welcome. Thanks so much for making some time today and sharing your story. >>Thank you very much. Hey >>steve. All right, let's start with Hello Fresh. You guys are number one in the world in your field, you deliver hundreds of millions of meals each year to many, many millions of people around the globe. You're scaling christoph. Tell us a little bit more about your company and its vision. >>Yeah. Should I start or Clements maybe maybe take over the first piece because Clements has actually been a longer trajectory yet have a fresh. >>Yeah go ahead. Climate change. I mean yes about approximately six years ago I joined handle fresh and I didn't think about the startup I was joining would eventually I. P. O. And just two years later and the freshman public and approximately three years and 10 months after. Hello fresh was listed on the German stock exchange which was just last week. Hello Fresh was included in the Ducks Germany's leading stock market index and debt to mind a great great milestone and I'm really looking forward and I'm very excited for the future for the future for head of fashion. All our data. Um the vision that we have is to become the world's leading food solution group and there's a lot of attractive opportunities. So recently we did lounge and expand Norway. This was in july and earlier this year we launched the U. S. Brand green >>chef in the U. K. As >>well. We're committed to launch continuously different geographies in the next coming years and have a strong pipe ahead of us with the acquisition of ready to eat companies like factor in the U. S. And the planned acquisition of you foods in Australia. We're diversifying our offer now reaching even more and more untapped customer segments and increase our total addressable market. So by offering customers and growing range of different alternatives to shop food and consumer meals. We are charging towards this vision and the school to become the world's leading integrated food solutions group. >>Love it. You guys are on a rocket ship, you're really transforming the industry and as you expand your tam it brings us to sort of the data as a as a core part of that strategy. So maybe you guys could talk a little bit about your journey as a company specifically as it relates to your data journey. You began as a start up. You had a basic architecture like everyone. You made extensive use of spreadsheets. You built a Hadoop based system that started to grow and when the company I. P. O. You really started to explode. So maybe describe that journey from a data perspective. >>Yes they saw Hello fresh by 2015 approximately had evolved what amount of classical centralized management set up. So we grew very organically over the years and there were a lot of very smart people around the globe. Really building the company and building our infrastructure. Um This also means that there were a small number of internal and external sources. Data sources and a centralized the I team with a number of people producing different reports, different dashboards and products for our executives for example of our different operations teams, christian company's performance and knowledge was transferred um just via talking to each other face to face conversations and the people in the data where's team were considered as the data wizard or as the E. T. L. Wizard. Very classical challenges. And those et al. Reserves indicated the kind of like a silent knowledge of data management. Right? Um so a central data whereas team then was responsible for different type of verticals and different domains, different geographies and all this setup gave us to the beginning the flexibility to grow fast as a company in 2015 >>christoph anything that might add to that. >>Yes. Um Not expected to that one but as as clement says it right, this was kind of set up that actually work for us quite a while. And then in 2017 when L. A. Freshman public, the company also grew rapidly and just to give you an idea how that looked like. As was that the tech department self actually increased from about 40 people to almost 300 engineers And the same way as a business units as Clemens has described, also grew sustainable, sustainably. So we continue to launch hello fresh and new countries launching brands like every plate and also acquired other brands like much of a factor and with that grows also from a data perspective the number of data requests that centrally we're getting become more and more and more and also more and more complex. So that for the team meant that they had a fairly high mental load. So they had to achieve a very or basically get a very deep understanding about the business. And also suffered a lot from this context switching back and forth, essentially there to prioritize across our product request from our physical product, digital product from the physical from sorry, from the marketing perspective and also from the central reporting uh teams. And in a nutshell this was very hard for these people. And this that also to a situation that, let's say the solution that we have became not really optimal. So in a nutshell, the central function became a bottleneck and slowdown of all the innovation of the company. >>It's a classic case, isn't it? I mean Clements, you see you see the central team becomes a bottleneck and so the lines of business, the marketing team salesman's okay, we're going to take things into our own hands. And then of course I I. T. And the technical team is called in later to clean up the mess. Uh maybe, I mean was that maybe I'm overstating it, but that's a common situation, isn't it? >>Yeah. Uh This is what exactly happened. Right. So um we had a bottleneck, we have the central teams, there was always a little of tension um analytics teams then started in this business domains like marketing, trade chain, finance, HR and so on. Started really to build their own data solutions at some point you have to get the ball rolling right and then continue the trajectory um which means then that the data pipelines didn't meet the engineering standards. And um there was an increased need for maintenance and support from central teams. Hence over time the knowledge about those pipelines and how to maintain a particular uh infrastructure for example left the company such that most of those data assets and data sets are turned into a huge step with decreasing data quality um also decrease the lack of trust, decreasing transparency. And this was increasing challenge where majority of time was spent in meeting rooms to align on on data quality for example. >>Yeah. And and the point you were making christoph about context switching and this is this is a point that Jemaah makes quite often is we've we've we've contextualized are operational systems like our sales systems, our marketing system but not our our data system. So you're asking the data team, Okay. Be an expert in sales, be an expert in marketing, be an expert in logistics, be an expert in supply chain and it start stop, start, stop, it's a paper cut environment and it's just not as productive. But but on the flip side of that is when you think about a centralized organization you think, hey this is going to be a very efficient way, a cross functional team to support the organization but it's not necessarily the highest velocity, most effective organizational structure. >>Yeah, so so I agree with that. Is that up to a certain scale, a centralized function has a lot of advantages, right? That's clear for everyone which would go to some kind of expert team. However, if you see that you actually would like to accelerate that and specific and this hyper growth, right, you wanna actually have autonomy and certain teams and move the teams or let's say the data to the experts in these teams and this, as you have mentioned, right, that increases mental load and you can either internally start splitting your team into a different kind of sub teams focusing on different areas. However, that is then again, just adding another peace where actually collaboration needs to happen busy external sees, so why not bridging that gap immediately and actually move these teams and to end into into the function themselves. So maybe just to continue what, what was Clements was saying and this is actually where over. So Clements, my journey started to become one joint journey. So Clements was coming actually from one of these teams to build their own solutions. I was basically having the platform team called database housed in these days and in 2019 where basically the situation become more and more serious, I would say so more and more people have recognized that this model doesn't really scale In 2019, basically the leadership of the company came together and I identified data as a key strategic asset and what we mean by that, that if we leverage data in a proper way, it gives us a unique competitive advantage which could help us to, to support and actually fully automated our decision making process across the entire value chain. So what we're, what we're trying to do now or what we should be aiming for is that Hello, Fresh is able to build data products that have a purpose. We're moving away from the idea. Data is just a by problem products, we have a purpose why we would like to collect this data. There's a clear business need behind that. And because it's so important to for the company as a business, we also want to provide them as a trust versi asset to the rest of the organization. We say there's the best customer experience, but at least in a way that users can easily discover, understand and security access high quality data. >>Yeah, so and and and Clements, when you c J Maxx writing, you see, you know, she has the four pillars and and the principles as practitioners you look at that say, okay, hey, that's pretty good thinking and then now we have to apply it and that's and that's where the devil meets the details. So it's the four, you know, the decentralized data ownership data as a product, which we'll talk about a little bit self serve, which you guys have spent a lot of time on inclement your wheelhouse which is which is governance and a Federated governance model. And it's almost like if you if you achieve the first two then you have to solve for the second to it almost creates a new challenges but maybe you could talk about that a little bit as to how it relates to Hello fresh. >>Yes. So christophe mentioned that we identified economic challenge beforehand and for how can we actually decentralized and actually empower the different colleagues of ours. This was more a we realized that it was more an organizational or a cultural change and this is something that somebody also mentioned I think thought words mentioned one of the white papers, it's more of a organizational or cultural impact and we kicked off a um faced reorganization or different phases we're currently and um in the middle of still but we kicked off different phases of organizational reconstruct oring reorganization, try unlock this data at scale. And the idea was really moving away from um ever growing complex matrix organizations or matrix setups and split between two different things. One is the value creation. So basically when people ask the question, what can we actually do, what shall we do? This is value creation and how, which is capability building and both are equal in authority. This actually then creates a high urge and collaboration and this collaboration breaks up the different silos that were built and of course this also includes different needs of stuffing forward teams stuffing with more, let's say data scientists or data engineers, data professionals into those business domains and hence also more capability building. Um Okay, >>go ahead. Sorry. >>So back to Tzemach did johnny. So we the idea also Then crossed over when she published her papers in May 2019 and we thought well The four colors that she described um we're around decentralized data ownership, product data as a product mindset, we have a self service infrastructure and as you mentioned, Federated confidential governance. And this suited very much with our thinking at that point of time to reorganize the different teams and this then leads to a not only organisational restructure but also in completely new approach of how we need to manage data, show data. >>Got it. Okay, so your business is is exploding. Your data team will have to become domain experts in too many areas, constantly contact switching as we said, people started to take things into their own hands. So again we said classic story but but you didn't let it get out of control and that's important. So we actually have a picture of kind of where you're going today and it's evolved into this Pat, if you could bring up the picture with the the elephant here we go. So I would talk a little bit about the architecture, doesn't show it here, the spreadsheet era but christoph maybe you can talk about that. It does show the Hadoop monolith which exists today. I think that's in a managed managed hosting service, but but you you preserve that piece of it, but if I understand it correctly, everything is evolving to the cloud, I think you're running a lot of this or all of it in A W. S. Uh you've got everybody's got their own data sources, uh you've got a data hub which I think is enabled by a master catalog for discovery and all this underlying technical infrastructure. That is really not the focus of this conversation today. But the key here, if I understand it correctly is these domains are autonomous and not only that this required technical thinking, but really supportive organizational mindset, which we're gonna talk about today. But christoph maybe you could address, you know, at a high level some of the architectural evolution that you guys went through. >>Yeah, sure. Yeah, maybe it's also a good summary about the entire history. So as you have mentioned, right, we started in the very beginning with the model is on the operation of playing right? Actually, it wasn't just one model is both to one for the back end and one for the for the front and and or analytical plane was essentially a couple of spreadsheets and I think there's nothing wrong with spreadsheets, right, allows you to store information, it allows you to transform data allows you to share this information. It allows you to visualize this data, but all the kind of that's not actually separating concern right? Everything in one tool. And this means that obviously not scalable, right? You reach the point where this kind of management set up in or data management of isn't one tool reached elements. So what we have started is we've created our data lake as we have seen here on Youtube. And this at the very beginning actually reflected very much our operational populace on top of that. We used impala is a data warehouse, but there was not really a distinction between borders, our data warehouse and borders our data like the impala was used as a kind of those as the kind of engine to create a warehouse and data like construct itself and this organic growth actually led to a situation as I think it's it's clear now that we had to centralized model is for all the domains that will really lose kimball modeling standards. There was no uniformity used actually build in house uh ways of building materialized use abuse that we have used for the presentation layer, there was a lot of duplication of effort and in the end essentially they were missing feedbacks, food, which helped us to to improve of what we are filled. So in the end, in the natural, as we have said, the lack of trust and that's basically what the starting point for us to understand. Okay, how can we move away and there are a lot of different things that you can discuss of apart from this organizational structure that we have said, okay, we have these three or four pillars from from Denmark. However, there's also the next extra question around how do we implement our talking about actual right, what are the implications on that level? And I think that is there's something that we are that we are currently still in progress. >>Got it. Okay, so I wonder if we could talk about switch gears a little bit and talk about the organizational and cultural challenges that you faced. What were those conversations like? Uh let's dig into that a little bit. I want to get into governance as well. >>The conversations on the cultural change. I mean yes, we went through a hyper growth for the last year since obviously there were a lot of new joiners, a lot of different, very, very smart people joining the company which then results that collaboration uh >>got a bit more difficult. Of course >>there are times and changes, you have different different artifacts that you were created um and documentation that were flying around. Um so we were we had to build the company from scratch right? Um Of course this then resulted always this tension which I described before, but the most important part here is that data has always been a very important factor at l a fresh and we collected >>more of this >>data and continued to improve use data to improve the different key areas of our business. >>Um even >>when organizational struggles, the central organizational struggles data somehow always helped us to go through this this kind of change. Right? Um in the end those decentralized teams in our local geography ease started with solutions that serve the business which was very very important otherwise wouldn't be at the place where we are today but they did by all late best practices and standards and I always used sport analogy Dave So like any sport, there are different rules and regulations that need to be followed. These rules are defined by calling the sports association and this is what you can think about data governance and compliance team. Now we add the players to it who need to follow those rules and bite by them. This is what we then called data management. Now we have the different players and professionals, they need to be trained and understand the strategy and it rules before they can play. And this is what I then called data literacy. So we realized that we need to focus on helping our teams to develop those capabilities and teach the standards for how work is being done to truly drive functional excellence in a different domains. And one of our mission of our data literacy program for example is to really empower >>every employee at hello >>fresh everyone to make the right data informs decisions by providing data education that scaled by royal Entry team. Then this can be different things, different things like including data capabilities, um, with the learning paths for example. Right? So help them to create and deploy data products connecting data producers and data consumers and create a common sense and more understanding of each other's dependencies, which is important, for example, S. S. L. O. State of contracts and etcetera. Um, people getting more of a sense of ownership and responsibility. Of course, we have to define what it means, what does ownership means? But the responsibility means. But we're teaching this to our colleagues via individual learning patterns and help them up skill to use. Also, there's shared infrastructure and those self self service applications and overall to summarize, we're still in this progress of of, of learning, we are still learning as well. So learning never stops the tele fish, but we are really trying this um, to make it as much fun as possible. And in the end we all know user behavior has changed through positive experience. Uh, so instead of having massive training programs over endless courses of workshops, um, leaving our new journalists and colleagues confused and overwhelmed. >>We're applying um, >>game ification, right? So split different levels of certification where our colleagues can access, have had access points, they can earn badges along the way, which then simplifies the process of learning and engagement of the users and this is what we see in surveys, for example, where our employees that your justification approach a lot and are even competing to collect Those learning path batteries to become the # one on the leader board. >>I love the game ification, we've seen it work so well and so many different industries, not the least of which is crypto so you've identified some of the process gaps uh that you, you saw it is gloss over them. Sometimes I say paved the cow path. You didn't try to force, in other words, a new architecture into the legacy processes. You really have to rethink your approach to data management. So what what did that entail? >>Um, to rethink the way of data management. 100%. So if I take the example of Revolution, Industrial Revolution or classical supply chain revolution, but just imagine that you have been riding a horse, for example, your whole life and suddenly you can operate a car or you suddenly receive just a complete new way of transporting assets from A to B. Um, so we needed to establish a new set of cross functional business processes to run faster, dry faster, um, more robustly and deliver data products which can be trusted and used by downstream processes and systems. Hence we had a subset of new standards and new procedures that would fall into the internal data governance and compliance sector with internal, I'm always referring to the data operations around new things like data catalog, how to identify >>ownership, >>how to change ownership, how to certify data assets, everything around classical software development, which we know apply to data. This this is similar to a new thinking, right? Um deployment, versioning, QA all the different things, ingestion policies, policing procedures, all the things that suffer. Development has been doing. We do it now with data as well. And in simple terms, it's a whole redesign of the supply chain of our data with new procedures and new processes and as a creation as management and as a consumption. >>So data has become kind of the new development kit. If you will um I want to shift gears and talk about the notion of data product and, and we have a slide uh that we pulled from your deck and I'd like to unpack it a little bit. Uh I'll just, if you can bring that up, I'll read it. A data product is a product whose primary objective is to leverage on data to solve customer problems where customers, both internal and external. So pretty straightforward. I know you've gone much deeper and you're thinking and into your organization, but how do you think about that And how do you determine for instance who owns what? How did you get everybody to agree? >>I can take that one. Um, maybe let me start with the data product. So I think um that's an ongoing debate. Right? And I think the debate itself is an important piece here, right? That visit the debate, you clarify what we actually mean by that product and what is actually the mindset. So I think just from a definition perspective, right? I think we find the common denominator that we say okay that our product is something which is important for the company has come to its value what you mean by that. Okay, it's it's a solution to a customer problem that delivers ideally maximum value to the business. And yes, it leverages the power of data and we have a couple of examples but it had a fresh year, the historical and classical ones around dashboards for example, to monitor or error rates but also more sophisticated ways for example to incorporate machine learning algorithms in our recipe recommendations. However, I think the important aspects of the data product is a there is an owner, right? There's someone accountable for making sure that the product that we are providing is actually served and is maintained and there are, there is someone who is making sure that this actually keeps the value of that problem thing combined with the idea of the proper documentation, like a product description, right that people understand how to use their bodies is about and related to that peace is the idea of it is a purpose. Right? You need to understand or ask ourselves, Okay, why does this thing exist does it provide the value that you think it does. That leads into a good understanding about the life cycle of the data product and life cycle what we mean? Okay from the beginning from the creation you need to have a good understanding, we need to collect feedback, we need to learn about that. We need to rework and actually finally also to think about okay benefits time to decommission piece. So overall, I think the core of the data product is product thinking 11 right that we start the point is the starting point needs to be the problem and not the solution and this is essentially what we have seen what was missing but brought us to this kind of data spaghetti that we have built there in in Russia, essentially we built at certain data assets, develop in isolation and continuously patch the solution just to fulfill these articles that we got and actually these aren't really understanding of the stakeholder needs and the interesting piece as a result in duplication of work and this is not just frustrating and probably not the most efficient way how the company should work. But also if I build the same that assets but slightly different assumption across the company and multiple teams that leads to data inconsistency and imagine the following too narrow you as a management for management perspective, you're asking basically a specific question and you get essentially from a couple of different teams, different kind of grass, different kind of data and numbers and in the end you do not know which ones to trust. So there's actually much more ambiguity and you do not know actually is a noise for times of observing or is it just actually is there actually a signal that I'm looking for? And the same is if I'm running in a B test right, I have a new future, I would like to understand what has it been the business impact of this feature. I run that specific source in an unfortunate scenario. Your production system is actually running on a different source. You see different numbers. What you've seen in a B test is actually not what you see then in production typical thing then is you're asking some analytics tend to actually do a deep dive to understand where the discrepancies are coming from. The worst case scenario. Again, there's a different kind of source. So in the end it's a pretty frustrating scenario and that's actually based of time of people that have to identify the root cause of this divergence. So in a nutshell, the highest degree of consistency is actually achieved that people are just reusing Dallas assets and also in the media talk that we have given right, we we start trying to establish this approach for a B testing. So we have a team but just providing or is kind of owning their target metric associated business teams and they're providing that as a product also to other services including the A B testing team, they'll be testing team can use this information defines an interface is okay I'm joining this information that the metadata of an experiment and in the end after the assignment after this data collection face, they can easily add a graph to the dashboard. Just group by the >>Beatles Hungarian. >>And we have seen that also in other companies. So it's not just a nice dream that we have right. I have actually worked in other companies where we worked on search and we established a complete KPI pipeline that was computing all this information. And this information was hosted by the team and it was used for everything A B test and deep dives and and regular reporting. So uh just one of the second the important piece now, why I'm coming back to that is that requires that we are treating this data as a product right? If you want to have multiple people using the things that I am owning and building, we have to provide this as a trust mercy asset and in a way that it's easy for people to discover and actually work with. >>Yeah. And coming back to that. So this is to me this is why I get so excited about data mesh because I really do think it's the right direction for organizations. When people hear data product they say well, what does that mean? Uh but then when you start to sort of define it as you did, it's it's using data to add value, that could be cutting costs, that could be generating revenue, it could be actually directly you're creating a product that you monetize, So it's sort of in the eyes of the beholder. But I think the other point that we've made is you made it earlier on to and again, context. So when you have a centralized data team and you have all these P NL managers a lot of times they'll question the data because they don't own it. They're like wait a minute. If they don't, if it doesn't agree with their agenda, they'll attack the data. But if they own the data then they're responsible for defending that and that is a mindset change, that's really important. Um And I'm curious uh is how you got to, you know, that ownership? Was it a was it a top down with somebody providing leadership? Was it more organic bottom up? Was it a sort of a combination? How do you decide who owned what in other words, you know, did you get, how did you get the business to take ownership of the data and what is owning? You know, the data actually mean? >>That's a very good question. Dave I think this is one of the pieces where I think we have a lot of learnings and basically if you ask me how we could start the feeling. I think that would be the first piece. Maybe we need to start to really think about how that should be approached if it stopped his ownership. Right? It means somehow that the team has a responsibility to host and self the data efforts to minimum acceptable standards. This minimum dependencies up and down string. The interesting piece has been looking backwards. What what's happening is that under that definition has actually process that we have to go through is not actually transferring ownership from the central team to the distributor teams. But actually most cases to establish ownership, I make this difference because saying we have to transfer ownership actually would erroneously suggests that the data set was owned before. But this platform team, yes, they had the capability to make the changes on data pipelines, but actually the analytics team, they're always the ones who had the business understands, you use cases and but no one actually, but it's actually expensive expected. So we had to go through this very lengthy process and establishing ownership. We have done that, as in the beginning, very naively. They have started, here's a document here, all the data assets, what is probably the nearest neighbor who can actually take care of that and then we we moved it over. But the problem here is that all these things is kind of technical debt, right? It's not really properly documented, pretty unstable. It was built in a very inconsistent over years and these people who have built this thing have already left the company. So there's actually not a nice thing that is that you want to see and people build up a certain resistance, e even if they have actually bought into this idea of domain ownership. So if you ask me these learnings, but what needs to happen as first, the company needs to really understand what our core business concept that they have, they need to have this mapping from. These are the core business concept that we have. These are the domain teams who are owning this concept and then actually link that to the to the assets and integrated better with both understanding how we can evolve actually, the data assets and new data build things new in the in this piece in the domain. But also how can we address reduction of technical death and stabilizing what we have already. >>Thank you for that christoph. So I want to turn a direction here and talk about governance and I know that's an area that's passionate, you're passionate about. Uh I pulled this slide from your deck, which I kind of messed up a little bit sorry for that, but but by the way, we're going to publish a link to the full video that you guys did. So we'll share that with folks. But it's one of the most challenging aspects of data mesh, if you're going to decentralize you, you quickly realize this could be the Wild West as we talked about all over again. So how are you approaching governance? There's a lot of items on this slide that are, you know, underscore the complexity, whether it's privacy, compliance etcetera. So, so how did you approach this? >>It's yeah, it's about connecting those dots. Right. So the aim of the data governance program is about the autonomy of every team was still ensuring that everybody has the right interoperability. So when we want to move from the Wild West riding horses to a civilised way of transport, um you can take the example of modern street traffic, like when all participants can manoeuvre independently and as long as they follow the same rules and standards, everybody can remain compatible with each other and understand and learn from each other so we can avoid car crashes. So when I go from country to country, I do understand what the street infrastructure means. How do I drive my car? I can also read the traffic lights in the different signals. Um, so likewise as a business and Hello Fresh, we do operate autonomously and consequently need to follow those external and internal rules and standards to set forth by the redistribution in which we operate so in order to prevent a car crash, we need to at least ensure compliance with regulations to account for society's and our customers increasing concern with data protection and privacy. So teaching and advocating this advantage, realizing this to everyone in the company um was a key community communication strategy and of course, I mean I mentioned data privacy external factors, the same goes for internal regulations and processes to help our colleagues to adapt to this very new environment. So when I mentioned before the new way of thinking the new way of um dealing and managing data, this of course implies that we need new processes and regulations for our colleagues as well. Um in a nutshell then this means the data governance provides a framework for managing our people the processes and technology and culture around our data traffic. And those components must come together in order to have this effective program providing at least a common denominator, especially critical for shared dataset, which we have across our different geographies managed and shared applications on shared infrastructure and applications and is then consumed by centralized processes um for example, master data, everything and all the metrics and KPI s which are also used for a central steering. Um it's a big change day. Right. And our ultimate goal is to have this noninvasive, Federated um ultimatum and computational governance and for that we can't just talk about it. We actually have to go deep and use case by use case and Qc buy PVC and generate learnings and learnings with the different teams. And this would be a classical approach of identifying the target structure, the target status, match it with the current status by identifying together with the business teams with the different domains have a risk assessment for example, to increase transparency because a lot of teams, they might not even know what kind of situation they might be. And this is where this training and this piece of illiteracy comes into place where we go in and trade based on the findings based on the most valuable use case um and based on that help our teams to do this change to increase um their capability just a little bit more and once they hand holding. But a lot of guidance >>can I kind of kind of trying to quickly David will allow me I mean there's there's a lot of governance piece but I think um that is important. And if you're talking about documentation for example, yes, we can go from team to team and tell these people how you have to document your data and data catalog or you have to establish data contracts and so on the force. But if you would like to build data products at scale following actual governance, we need to think about automation right. We need to think about a lot of things that we can learn from engineering before. And that starts with simple things like if we would like to build up trust in our data products, right, and actually want to apply the same rigor and the best practices that we know from engineering. There are things that we can do and we should probably think about what we can copy and one example might be. So the level of service level agreements, service level objectives. So that level indicators right, that represent on on an engineering level, right? If we're providing services there representing the promises we made to our customers or consumers, these are the internal objectives that help us to keep those promises. And actually these are the way of how we are tracking ourselves, how we are doing. And this is just one example of that thing. The Federated Governor governance comes into play right. In an ideal world, we should not just talk about data as a product but also data product. That's code that we say, okay, as most as much as possible. Right? Give the engineers the tool that they are familiar basis and actually not ask the product managers for example to document their data assets in the data catalog but make it part of the configuration. Have this as a, as a C D C I, a continuous delivery pipeline as we typically see another engineering task through and services we say, okay, there is configuration, we can think about pr I can think about data quality monitoring, we can think about um the ingestion data catalog and so on and forest, I think ideally in the data product will become of a certain templates that can be deployed and are actually rejected or verified at build time before we actually make them deploy them to production. >>Yeah, So it's like devoPS for data product um so I'm envisioning almost a three phase approach to governance and you kind of, it sounds like you're in early phases called phase zero where there's there's learning, there's literacy, there's training, education, there's kind of self governance and then there's some kind of oversight, some a lot of manual stuff going on and then you you're trying to process builders at this phase and then you codify it and then you can automate it. Is that fair? >>Yeah, I would rather think think about automation as early as possible in the way and yes, there needs to be certain rules but then actually start actually use case by use case. Is there anything that small piece that we can already automate? It's as possible. Roll that out and then actually extended step by step, >>is there a role though that adjudicates that? Is there a central Chief state officer who is responsible for making sure people are complying or is it how do you handle that? >>I mean from a from a from a platform perspective, yes, we have a centralized team to uh implement certain pieces they'll be saying are important and actually would like to implement. However, that is actually working very closely with the governance department. So it's Clements piece to understand and defy the policies that needs to be implemented. >>So Clements essentially it's it's your responsibility to make sure that the policy is being followed. And then as you were saying, christoph trying to compress the time to automation as fast as possible percent. >>So >>it's really it's uh >>what needs to be really clear that it's always a split effort, Right? So you can't just do one thing or the other thing, but everything really goes hand in hand because for the right automation for the right engineering tooling, we need to have the transparency first. Uh I mean code needs to be coded so we kind of need to operate on the same level with the right understanding. So there's actually two things that are important which is one its policies and guidelines, but not only that because more importantly or even well equally important to align with the end user and tech teams and engineering and really bridge between business value business teams and the engineering teams. >>Got it. So just a couple more questions because we gotta wrap I want to talk a little bit about the business outcome. I know it's hard to quantify and I'll talk about that in a moment but but major learnings, we've got some of the challenges that you cited. I'll just put them up here. We don't have to go detailed into this, but I just wanted to share with some folks. But my question, I mean this is the advice for your peers question if you had to do it differently if you had a do over or a Mulligan as we like to say for you golfers, what would you do differently? Yeah, >>I mean can we start with from a from the transformational challenge that understanding that it's also high load of cultural change. I think this is this is important that a particular communication strategy needs to be put into place and people really need to be um supported. Right? So it's not that we go in and say well we have to change towards data mesh but naturally it's in human nature, you know, we're kind of resistance to to change right? Her speech uncomfortable. So we need to take that away by training and by communicating um chris we're gonna add something to that >>and definitely I think the point that I have also made before right we need to acknowledge that data mesh is an architecture of scale, right? You're looking for something which is necessary by huge companies who are vulnerable, data productive scale. I mean Dave you mentioned it right, there are a lot of advantages to have a centralized team but at some point it may make sense to actually decentralized here and at this point right? If you think about data Mash, you have to recognize that you're not building something on a green field. And I think there's a big learning which is also reflected here on the slide is don't underestimate your baggage. It's typically you come to a point where the old model doesn't doesn't broke anymore and has had a fresh right? We lost our trust in our data and actually we have seen certain risks that we're slowing down our innovation so we triggered that this was triggering the need to actually change something. So this transition implies that you typically have a lot of technical debt accumulated over years and I think what we have learned is that potentially we have decentralized some assets to earlier, this is not actually taking into account the maturity of the team where we are actually distributed to and now we actually in the face of correcting pieces of that one. Right? But I think if you if you if you start from scratch you have to understand, okay, is are my team is actually ready for taking on this new uh, this news capabilities and you have to make sure that business decentralization, you build up these >>capabilities and the >>teams and as Clements has mentioned, right, make sure that you take the people on your journey. I think these are the pieces that also here, it comes with this knowledge gap, right? That we need to think about hiring and literacy the technical depth I just talked about and I think the last piece that I would add now which is not here on the flight deck is also from our perspective, we started on the analytical layer because that's kind of where things are exploding, right, this is the thing that people feel the pain but I think a lot of the efforts that we have started to actually modernize the current state uh, towards data product towards data Mash. We've understood that it always comes down basically to a proper shape of our operational plane and I think what needs to happen is is I think we got through a lot of pains but the learning here is this need to really be a commitment from the company that needs to happen and to act. >>I think that point that last point you made it so critical because I I hear a lot from the vendor community about how they're gonna make analytics better and that's that's not unimportant, but but through data product thinking and decentralized data organizations really have to operationalize in order to scale. So these decisions around data architecture an organization, their fundamental and lasting, it's not necessarily about an individual project are why they're gonna be project sub projects within this architecture. But the architectural decision itself is an organizational, its cultural and what's the best approach to support your business at scale. It really speaks to to to what you are, who you are as a company, how you operate and getting that right, as we've seen in the success of data driven driven companies is yields tremendous results. So I'll ask each of you to give give us your final thoughts and then we'll wrap maybe >>maybe it quickly, please. Yeah, maybe just just jumping on this piece that you have mentioned, right, the target architecture. If we talk about these pieces right, people often have this picture of mind like OK, there are different kind of stages, we have sources, we have actually ingestion layer, we have historical transformation presentation layer and then we're basically putting a lot of technology on top of that kind of our target architecture. However, I think what we really need to make sure is that we have these different kind of viewers, right? We need to understand what are actually the capabilities that we need in our new goals. How does it look and feel from the different kind of personas and experience view? And then finally, that should actually go to the to the target architecture from a technical perspective um maybe just to give an outlook but what we're what we're planning to do, how we want to move that forward. We have actually based on our strategy in the in the sense of we would like to increase that to maturity as a whole across the entire company and this is kind of a framework around the business strategy and it's breaking down into four pillars as well. People meaning the data, cultural, data literacy, data organizational structure and so on that. We're talking about governance as Clements has actually mentioned that, right, compliance, governance, data management and so on. You talk about technology and I think we could talk for hours for that one. It's around data platform, better science platform and then finally also about enablement through data, meaning we need to understand that a quality data accessibility and the science and data monetization. >>Great, thank you christophe clement. Once you bring us home give us your final thoughts. >>Can't can just agree with christoph that uh important is to understand what kind of maturity people have to understand what the maturity level, where the company where where people organization is and really understand what does kind of some kind of a change replies to that those four pillars for example, um what needs to be taken first and this is not very clear from the very first beginning of course them it's kind of like Greenfield you come up with must wins to come up with things that we really want to do out of theory and out of different white papers. Um only if you really start conducting the first initiatives you do understand. Okay, where we have to put the starts together and where do I missed out on one of those four different pillars? People, process technology and governance. Right? And then that kind of an integration. Doing step by step, small steps by small steps not boiling the ocean where you're capable ready to identify the gaps and see where either you can fill um the gaps are where you have to increase maturity first and train people or increase your text text, >>you know Hello Fresh is an excellent example of a company that is innovating. It was not born in Silicon Valley which I love. It's a global company. Uh and I gotta ask you guys, it seems like this is an amazing place to work you guys hiring? >>Yes, >>definitely. We do >>uh as many rights as was one of these aspects distributing. And actually we are hiring as an entire company specifically for data. I think there are a lot of open roles serious. Please visit or our page from better engineering, data, product management and Clemens has a lot of rules that you can speak about. But yes >>guys, thanks so much for sharing with the cube audience, your, your pioneers and we look forward to collaborations in the future to track progress and really want to thank you for your time. >>Thank you very much. Thank you very much. Dave >>thank you for watching the cubes startup showcase made possible by A W. S. This is Dave Volonte. We'll see you next time. >>Yeah.

(upbeat music) >> Hello everyone. We're here at theCUBE startup showcase made possible by AWS. Thanks so much for joining us today. You know, when Zhamak Dehghani was formulating her ideas around data mesh, she wasn't the only one thinking about decentralized data architectures. HelloFresh was going into hyper-growth mode and realized that in order to support its scale, it needed to rethink how it thought about data. Like many companies that started in the early part of the last decade, HelloFresh relied on a monolithic data architecture and the internal team it had concerns about its ability to support continued innovation at high velocity. The company's data team began to think about the future and work backwards from a target architecture, which possessed many principles of so-called data mesh, even though they didn't use that term specifically. The company is a strong example of an early but practical pioneer of data mesh. Now, there are many practitioners and stakeholders involved in evolving the company's data architecture many of whom are listed here on this slide. Two are highlighted in red and joining us today. We're really excited to welcome you to theCUBE, Clemence Chee, who is the global senior director for data at HelloFresh, and Christoph Sawade, who's the global senior director of data also of course at HelloFresh. Folks, welcome. Thanks so much for making some time today and sharing your story. >> Thank you very much. >> Thanks, Dave. >> All right, let's start with HelloFresh. You guys are number one in the world in your field. You deliver hundreds of millions of meals each year to many, many millions of people around the globe. You're scaling. Christoph, tell us a little bit more about your company and its vision. >> Yeah. Should I start or Clemence? Maybe take over the first piece because Clemence has actually been longer a director at HelloFresh. >> Yeah go ahead Clemence. >> I mean, yes, about approximately six years ago I joined and HelloFresh, and I didn't think about the startup I was joining would eventually IPO. And just two years later, HelloFresh went public. And approximately three years and 10 months after HelloFresh was listed on the German stock exchange which was just last week, HelloFresh was included in the DAX Germany's leading stock market index and that, to mind a great, great milestone, and I'm really looking forward and I'm very excited for the future for HelloFresh and also our data. The vision that we have is to become the world's leading food solution group. And there are a lot of attractive opportunities. So recently we did launch and expand in Norway. This was in July. And earlier this year, we launched the US brand, Green Chef, in the UK as well. We're committed to launch continuously different geographies in the next coming years and have a strong path ahead of us. With the acquisition of ready to eat companies like factor in the US and the plant acquisition of Youfoodz in Australia, we are diversifying our offer, now reaching even more and more untapped customer segments and increase our total address for the market. So by offering customers and growing range of different alternatives to shop food and to consume meals, we are charging towards this vision and this goal to become the world's leading integrated food solutions group. >> Love it. You guys are on a rocket ship. You're really transforming the industry. And as you expand your TAM, it brings us to sort of the data as a core part of that strategy. So maybe you guys could talk a little bit about your journey as a company, specifically as it relates to your data journey. I mean, you began as a startup, you had a basic architecture and like everyone, you've made extensive use of spreadsheets, you built a Hadoop based system that started to grow. And when the company IPO'd, you really started to explode. So maybe describe that journey from a data perspective. >> Yes, Dave. So HelloFresh by 2015, approximately had evolved what amount, a classical centralized data management set up. So we grew very organically over the years, and there were a lot of very smart people around the globe, really building the company and building our infrastructure. This also means that there were a small number of internal and external sources, data sources, and a centralized BI team with a number of people producing different reports, different dashboards and, and products for our executives, for example, or for different operations teams to see a company's performance and knowledge was transferred just by our talking to each other face-to-face conversations. And the people in the data warehouse team were considered as the data wizard or as the ETL wizard. Very classical challenges. And it was ETL, who reserved, indicated the kind of like a style of knowledge of data management, right? So our central data warehouse team then was responsible for different type of verticals in different domains, different geographies. And all this setup gave us in the beginning, the flexibility to grow fast as a company in 2015. >> Christoph, anything to add to that? >> Yes, not explicitly to that one, but as, as Clemence said, right, this was kind of the setup that actually worked for us quite a while. And then in 2017, when HelloFresh went public, the company also grew rapidly. And just to give you an idea how that looked like as well, the tech departments have actually increased from about 40 people to almost 300 engineers. And in the same way as the business units, as there Clemence has described, also grew sustainably. So we continue to launch HelloFresh in new countries, launched new brands like Every Plate, and also acquired other brands like we have Factor. And that grows also from a data perspective, the number of data requests that the central (mumbles), we're getting become more and more and more, and also more and more complex. So that for the team meant that they had a fairly high mental load. So they had to achieve a very, or basically get a very deep understanding about the business and also suffered a lot from this context, switching back and forth. Essentially, they had to prioritize across our product requests from our physical product, digital product, from a physical, from, sorry, from the marketing perspective, and also from the central reporting teams. And in a nutshell, this was very hard for these people, and that altered situations that let's say the solution that we have built. We can not really optimal. So in a, in a, in a, in a nutshell, the central function became a bottleneck and slow down of all the innovation of the company. >> It's a classic case. Isn't it? I mean, Clemence, you see, you see the central team becomes a bottleneck, and so the lines of business, the marketing team, sales teams say "Okay, we're going to take things into our own hands." And then of course IT and the technical team is called in later to clean up the mess. Maybe, maybe I'm overstating it, but, but that's a common situation. Isn't it? >> Yeah this is what exactly happened. Right. So we had a bottleneck, we had those central teams, there was always a bit of tension. Analytics teams then started in those business domains like marketing, supply chain, finance, HR, and so on started really to build their own data solutions. At some point you have to get the ball rolling, right? And then continue the trajectory, which means then that the data pipelines didn't meet the engineering standards. And there was an increased need for maintenance and support from central teams. Hence over time, the knowledge about those pipelines and how to maintain a particular infrastructure, for example, left the company, such that most of those data assets and data sets that turned into a huge debt with decreasing data quality, also decreasing lack of trust, decreasing transparency. And this was an increasing challenge where a majority of time was spent in meeting rooms to align on, on data quality for example. >> Yeah. And the point you were making Christoph about context switching, and this is, this is a point that Zhamak makes quite often as we've, we've, we've contextualized our operational systems like our sales systems, our marketing systems, but not our, our data systems. So you're asking the data team, okay, be an expert in sales, be an expert in marketing, be an expert in logistics, be an expert in supply chain and it's start, stop, start, stop. It's a paper cut environment, and it's just not as productive. But, but, and the flip side of that is when you think about a centralized organization, you think, hey, this is going to be a very efficient way across functional team to support the organization, but it's not necessarily the highest velocity, most effective organizational structure. >> Yeah. So, so I agree with that piece, that's up to a certain scale. A centralized function has a lot of advantages, right? So it's a tool for everyone, which would go to a destined kind of expert team. However, if you see that you actually would like to accelerate that in specific as the type of growth. But you want to actually have autonomy on certain teams and move the teams, or let's say the data to the experts in these teams. And this, as you have mentioned, right, that increases mental load. And you can either internally start splitting your team into different kinds of sub teams focusing on different areas, however, that is then again, just adding another piece where actually collaboration needs to happen because the external seized, so why not bridging that gap immediately and actually move these teams end to end into the, into the function themselves. So maybe just to continue what Clemence was saying, and this is actually where our, so, Clemence and my journey started to become one joint journey. So Clemence was coming actually from one of these teams who builds their own solutions. I was basically heading the platform team called data warehouse team these days. And in 2019, where (mumbles) become more and more serious, I would say, so more and more people have recognized that this model does not really scale, in 2019, basically the leadership of the company came together and identified data as a key strategic asset. And what we mean by that, that if he leveraged it in a, in a, an appropriate way, it gives us a unique, competitive advantage, which could help us to, to support and actually fully automate our decision making process across the entire value chain. So once we, what we're trying to do now, or what we would be aiming for is that HelloFresh is able to build data products that have a purpose. We're moving away from the idea that it's just a bi-product. We have a purpose why we would like to collect this data. There's a clear business need behind that. And because it's so important to, for the company as a business, we also want to provide them as a trustworthy asset to the rest of the organization. We'd say, this is the best customer experience, but at least in a way that users can easily discover, understand and securely access, high quality data. >> Yeah. So, and, and, and Clemence, when you see Zhamak's writing, you see, you know, she has the four pillars and the principles. As practitioners, you look at that say, okay, hey, that's pretty good thinking. And then now we have to apply it. And that's where the devil meets the details. So it's the for, the decentralized data ownership, data as a product, which we'll talk about a little bit, self-serve, which you guys have spent a lot of time on, and Clemence your wheelhouse, which is, which is governance and a federated governance model. And it's almost like if you, if you achieve the first two, then you have to solve for the second two, it almost creates a new challenges, but maybe you could talk about that a little bit as to how it relates to HelloFresh. >> Yes. So Chris has mentioned that we identified kind of a challenge beforehand and said, how can we actually decentralized and actually empower the different colleagues of ours? And this was more a, we realized that it was more an organizational or a cultural change. And this is something that someone also mentioned. I think ThoughtWorks mentioned one of the white papers, it's more of an organizational or a cultural impact. And we kicked off a phased reorganization, or different phases we're currently on, in the middle of still, but we kicked off different phases of organizational restructuring or reorganization trying to lock this data at scale. And the idea was really moving away from ever growing complex matrix organizations or matrix setups and split between two different things. One is the value creation. So basically when people ask the question, what can we actually do? What should we do? This is value creation and the how, which is capability building, and both are equal in authority. This actually then creates a high urge in collaboration and this collaboration breaks up the different silos that were built. And of course, this also includes different needs of staffing for teams staffing with more, let's say data scientists or data engineers, data professionals into those business domains, enhance, or some more capability building. >> Okay, go ahead. Sorry. >> So back to Zhamak Dehghani. So we, the idea also then crossed over when she published her papers in May, 2019. And we thought, well, the four pillars that she described were around decentralized data ownership, product, data as a product mindset, we have a self-service infrastructure. And as you mentioned, federated computational governance. And this suited very much with our thinking at that point of time to reorganize the different teams and this then that to not only organizational restructure, but also in completely new approach of how we need to manage data, through data. >> Got it. Okay. So your businesses is exploding. The data team was having to become domain experts to many areas, constantly context switching as we said, people started to take things into their own hands. So again, we said classic story, but, but you didn't let it get out of control and that's important. And so we, we actually have a picture of kind of where you're going today and it's evolved into this, Pat, if you could bring up the picture with the, the elephant, here we go. So I will talk a little bit about the architecture. It doesn't show it here, the spreadsheet era, but Christoph, maybe you could talk about that. It does show the Hadoop monolith, which exists today. I think that's in a managed hosting service, but, but you, you preserve that piece of it. But if I understand it correctly, everything is evolving to the cloud. I think you're running a lot of this or all of it in AWS. You've got, everybody's got their own data sources. You've got a data hub, which I think is enabled by a master catalog for discovery and all this underlying technical infrastructure that is, is really not the focus of this conversation today. But the key here, if I understand correctly is these domains are autonomous and that not only this required technical thinking, but really supportive organizational mindset, which we're going to talk about today. But, but Christoph, maybe you could address, you know, at a high level, some of the architectural evolution that you guys went through. >> Yeah, sure. Yeah. Maybe it's also a good summary about the entire history. So as you have mentioned, right, we started in the very beginning, it's a monolith on the operational plan, right? Actually it wasn't just one model it was two, one for the backend and one for the front end. And our analytical plan was essentially a couple of spreadsheets. And I think there's nothing wrong with spreadsheets, but it allows you to store information, it allows you to transform data, it allows you to share this information, it allows you to visualize this data, but all kind of, it's not actually separating concern, right? Every single one tool. And this means that it's obviously not scalable, right? You reach the point where this kind of management's set up in, or data management is in one tool, reached elements. So what we have started is we created our data lake, as we have seen here on our dupe. And just in the very beginning actually reflected very much our operation upon this. On top of that, we used Impala as a data warehouse, but there was not really a distinction between what is our data warehouse and what is our data lakes as the Impala was used as kind of both as a kind of engine to create a warehouse and data lake constructed itself. And this organic growth actually led to a situation. As I think it's clear now that we had the centralized model as, for all the domains that were really lose Kimball, the modeling standards and there's new uniformity we used to actually build, in-house, a base of building materialized use, of use that we have used for the presentation there. There was a lot of duplication of effort. And in the end, essentially the amendments and feedback tool, which helped us to, to improve of what we, have built during the end in a natural, as you said, the lack of trust. And this basically was a starting point for us to understand, okay, how can we move away? And there are a lot of different things that we can discuss of apart from this organizational structure that we have set up here, we have three or four pillars from Zhamak. However, there's also the next, extra question around, how do we implement product, right? What are the implications on that level and I think that is, that's something that we are, that we are currently still in progress. >> Got it. Okay. So I wonder if we could talk about, switch gears a little bit, and talk about the organizational and cultural challenges that you faced. What were those conversations like? And let's, let's dig into that a little bit. I want to get into governance as well. >> The conversations on the cultural change. I mean, yes, we went through a hyper growth through the last year, and obviously there were a lot of new joiners, a lot of different, very, very smart people joining the company, which then results that collaborations got a bit more difficult. Of course, the time zone changes. You have different, different artifacts that you had recreated in documentation that were flying around. So we were, we had to build the company from scratch, right? Of course, this then resulted always this tension, which I described before. But the most important part here is that data has always been a very important factor at HelloFresh, and we collected more of this data and continued to improve, use data to improve the different key areas of our business. Even when organizational struggles like the central (mumbles) struggles, data somehow always helped us to grow through this kind of change, right? In the end, those decentralized teams in our local geographies started with solutions that serve the business, which was very, very important. Otherwise, we wouldn't be at the place where we are today, but they did violate best practices and standards. And I always use the sports analogy, Dave. So like any sport, there are different rules and regulations that need to be followed. These routes are defined by, I'll call it, the sports association. And this is what you can think about other data governance and then our compliance team. Now we add the players to it who need to follow those rules and abide by them. This is what we then call data management. Now we have the different players, the professionals they also need to be trained and understand the strategy and the rules before they can play. And this is what I then called data literacy. So we realized that we need to focus on helping our teams to develop those capabilities and teach the standards for how work is being done to truly drive functional excellence in the different domains. And one of our ambition of our data literacy program for example, is to really empower every employee at HelloFresh, everyone, to make the right data-informed decisions by providing data education that scales (mumbles), and that can be different things. Different things like including data capabilities with, in the learning path for example, right? So help them to create and deploy data products, connecting data, producers, and data consumers, and create a common sense and more understanding of each other's dependencies, which is important. For example, SIS, SLO, state of contracts, et cetera, people get more of a sense of ownership and responsibility. Of course, we have to define what it means. What does ownership means? What does responsibility mean? But we are teaching this to our colleagues via individual learning patterns and help them upscale to use also their shared infrastructure, and those self-service data applications. And of all to summarize, we are still in this progress of learning. We're still learning as well. So learning never stops at Hello Fresh, but we are really trying this to make it as much fun as possible. And in the end, we all know user behavior is changed through positive experience. So instead of having massive training programs over endless courses of workshops, leaving our new joiners and colleagues confused and overwhelmed, we're applying gamification, right? So split different levels of certification where our colleagues, can access, have had access points. They can earn badges along the way, which then simplifies the process of learning and engagement of the users. And this is what we see in surveys, for example, where our employees value this gamification approach a lot and are even competing to collect those learning pet badges, to become the number one on the leaderboard. >> I love the gamification. I mean, we've seen it work so well in so many different industries, not the least of which is crypto. So you've identified some of the process gaps that you, you saw, you just gloss over them. Sometimes I say, pave the cow path. You didn't try to force. In other words, a new architecture into the legacy processes, you really had to rethink your approach to data management. So what did that entail? >> To rethink the way of data management, 100%. So if I take the example of revolution, industrial revolution or classical supply chain revolution, but just imagine that you have been riding a horse, for example, your whole life, and suddenly you can operate a car or you suddenly receive just a complete new way of transporting assets from A to B. So we needed to establish a new set of cross-functional business processes to run faster, drive faster, more robustly, and deliver data products which can be trusted and used by downstream processes and systems. Hence we had a subset of new standards and new procedures that would fall into the internal data governance and compliance sector. With internal, I'm always referring to the data operations around new things like data catalog, how to identify ownership, how to change ownership, how to certify data assets, everything around classical is software development, which we now apply to data. This, this is some old and new thinking, right? Deployment, versioning, QA, all the different things, ingestion policies, the deletion procedures, all the things that software development has been doing, we do it now with data as well. And it's simple terms, it's a whole redesign of the supply chain of our data with new procedures and new processes in asset creation, asset management and asset consumption. >> So data's become kind of the new development kit, if you will. I want to shift gears and talk about the notion of data product, and we have a slide that, that we pulled from your deck. And I'd like to unpack it a little bit. I'll just, if you can bring that up, I'll, I'll read it. A data product is a product whose primary objective is to leverage on data to solve customer problems, where customers are both internal and external. so pretty straightforward. I know you've, you've gone much deeper in your thinking and into your organization, but how do you think about that and how do you determine for instance, who owns what, how did you get everybody to agree? >> I can take that one. Maybe let me start as a data product. So I think that's an ongoing debate, right? And I think the debate itself is the important piece here, right? You mentioned the debate, you've clarified what we actually mean by that, a product, and what is actually the mindset. So I think just from a definition perspective, right? I think we find the common denominator that we say, okay, that our product is something which is important for the company that comes with value. What do you mean by that? Okay. It's a solution to a customer problem that delivers ideally maximum value to the business. And yes, leverage is the power of data. And we have a couple of examples, and I'll hit refresh here, the historical and classical ones around dashboards, for example, to monitor our error rates, but also more sophisticated based for example, to incorporate machine learning algorithms in our recipe recommendation. However, I think the important aspects of a data product is A: there is an owner, right? There's someone accountable for making sure that the product that you're providing is actually served and has maintained. And there are, there's someone who's making sure that this actually keeps the value of what we are promising. Combined with the idea of the proper documentation, like a product description, right? The people understand how to use it. What is this about? And related to that piece is the idea of, there's a purpose, right? We need to understand or ask ourselves, okay, why does a thing exist? Does it provide the value that we think it does? Then it leads in to a good understanding of what the life cycle of the data product and product life cycle. What do we mean? Okay. From the beginning, from the creation, you need to have a good understanding. You need to collect feedback. We need to learn about that, you need to rework, and actually finally, also to think about, okay, when is it time to decommission that piece So overall I think the core of this data product is product thinking 101, right? That we start, the point is, the starting point needs to be the problem and not the solution. And this is essentially what we have seen, what was missing, what brought us to this kind of data spaghetti that we have built there in Rush, essentially, we built it. Certain data assets develop in isolation and continuously patch the solution just to fulfill these ad hoc requests that we got and actually really understanding what the stakeholder needs. And the interesting piece as a results in duplication of (mumbled) And this is not just frustrating and probably not the most efficient way, how the company should work. But also if I build the same data assets, but slightly different assumption across the company and multiple teams that leads to data inconsistency. And imagine the following scenario. You, as a management, for management perspective, you're asking basically a specific question and you get essentially from a couple of different teams, different kinds of graphs, different kinds of data and numbers. And in the end, you do not know which ones to trust. So there's actually much (mumbles) but good. You do not know what actually is it noise for times of observing or is it just actually, is there actually a signal that I'm looking for? And the same as if I'm running an AB test, right? I have a new feature, I would like to understand what is the business impact of this feature? I run that with a specific source and an unfortunate scenario. Your production system is actually running on a different source. You see different numbers. What you have seen in the AB test is actually not what you see then in production, typical thing. Then as you asking some analytics team to actually do a deep dive, to understand where the discrepancies are coming from, worst case scenario again, there's a different kind of source. So in the end, it's a pretty frustrating scenario. And it's actually a waste of time of people that have to identify the root cause of this type of divergence. So in a nutshell, the highest degree of consistency is actually achieved if people are just reusing data assets. And also in the end, the meetup talk they've given, right? We start trying to establish this approach by AB testing. So we have a team, but just providing, or is kind of owning their target metric associated business teams, and they're providing that as a product also to other services, including the AB testing team. The AB testing team can use this information to find an interface say, okay, I'm drawing information for the metadata of an experiment. And in the end, after the assignment, after this data collection phase, they can easily add a graph to a dashboard just grouped by the AB testing barrier. And we have seen that also in other companies. So it's not just a nice dream that we have, right? I have actually looked at other companies maybe looked on search and we established a complete KPI pipeline that was computing all these information and this information both hosted by the team and those that (mumbles) AB testing, deep dives and, and regular reporting again. So just one last second, the, the important piece, Now, why I'm coming back to that is that it requires that we are treating this data as a product, right? If we want to have multiple people using the thing that I am owning and building, we have to provide this as a trust (mumbles) asset and in a way that it's easy for people to discover and to actually work with. >> Yeah. And coming back to that. So this is, to me this is why I get so excited about data mesh, because I really do think it's the right direction for organizations. When people hear data product, they think, "Well, what does that mean?" But then when you start to sort of define it as you did, it's using data to add value that could be cutting costs, that could be generating revenue, it could be actually directly creating a product that you monetize. So it's sort of in the eyes of the beholder, but I think the other point that we've made, is you made it earlier on too, and again, context. So when you have a centralized data team and you have all these P&L managers, a lot of times they'll question the data 'cause they don't own it. They're like, "Well, wait a minute." If it doesn't agree with their agenda, they'll attack the data. But if they own the data, then they're responsible for defending that. And that is a mindset change that's really important. And I'm curious is how you got to that ownership. Was it a top-down or was somebody providing leadership? Was it more organic bottom up? Was it a sort of a combination? How do you decide who owned what? In other words, you know, did you get, how did you get the business to take ownership of the data and what does owning the data actually mean? >> That's a very good question, Dave. I think that one of the pieces where I think we have a lot of learning and basically if you ask me how we could stop the filling, I think that would be the first piece that we need to start. Really think about how that should be approached. If it's staff has ownership, right? That means somehow that the team has the responsibility to host themselves the data assets to minimum acceptable standards. That's minimum dependencies up and down stream. The interesting piece has to be looking backwards. What was happening is that under that definition, this extra process that we have to go through is not actually transferring ownership from a central team to the other teams, but actually in most cases to establish ownership. I make this difference because saying we have to transfer ownership actually would erroneously suggest that the dataset was owned before, but this platform team, yes, they had the capability to make the change, but actually the analytics team, but always once we had the business understand the use cases and what no one actually bought, it's actually expensive, expected. So we had to go through this very lengthy process and establishing ownership, how we have done that as in the beginning, very naively started, here's a document, here are all the data assets, what is probably the nearest neighbor who can actually take care of that. And then we, we moved it over. But the problem here is that all these things is kind of technical debt, right? It's not really properly documented, pretty unstable. It was built in a very inconsistent way over years. And these people that built this thing have already left the company. So this is actually not a nice thing that you want to see and people build up a certain resistance, even if they have actually bought into this idea of domain ownership. So if you ask me these learnings, what needs to happen is first, the company needs to really understand what our core business concept that we have the need to have this mapping from this other core business concept that we have. These are the domain teams who are owning this concept, and then actually linked that to the, the assets and integrate that better, but suppose understanding how we can evolve, actually the data assets and new data builds things new and the, in this piece and the domain, but also how can we address reduction of technical depth and stabilizing what we have already. >> Thank you for that Christoph. So I want to turn a direction here and talk Clemence about governance. And I know that's an area that's passionate, you're passionate about. I pulled this slide from your deck, which I kind of messed up a little bit, sorry for that. But, but, but by the way, we're going to publish a link to the full video that you guys did. So we'll share that with folks, but it's one of the most challenging aspects of data mesh. If you're going to decentralize, you, you quickly realize this could be the wild west, as we talked about all over again. So how are you approaching governance? There's a lot of items on this slide that are, you know, underscore the complexity, whether it's privacy compliance, et cetera. So, so how did you approach this? >> It's yeah, it's about connecting those dots, right? So the aim of the data governance program is to promote the autonomy of every team while still ensuring that everybody has the right interoperability. So when we want to move from the wild west, riding horses to a civilized way of transport, I can take the example of modern street traffic. Like when all participants can maneuver independently, and as long as they follow the same rules and standards, everybody can remain compatible with each other and understand and learn from each other so we can avoid car crashes. So when I go from country to country, I do understand what the street infrastructure means. How do I drive my car? I can also read the traffic lights and the different signals. So likewise, as a business in HelloFresh we do operate autonomously and consequently need to follow those external and internal rules and standards set forth by the tradition in which we operate. So in order to prevent a, a car crash, we need to at least ensure compliance with regulations, to account for societies and our customers' increasing concern with data protection and privacy. So teaching and advocating this imaging, evangelizing this to everyone in the company was a key community or communication strategy. And of course, I mean, I mentioned data privacy, external factors, the same goes for internal regulations and processes to help our colleagues to adapt for this very new environment. So when I mentioned before, the new way of thinking, the new way of dealing and managing data, this of course implies that we need new processes and regulations for our colleagues as well. In a nutshell, then this means that data governance provides a framework for managing our people, the processes and technology and culture around our data traffic. And that governance must come together in order to have this effective program providing at least a common denominator is especially critical for shared data sets, which we have across our different geographies managed, and shared applications on shared infrastructure and applications. And as then consumed by centralized processes, for example, master data, everything, and all the metrics and KPIs, which are also used for a central steering. It's a big change, right? And our ultimate goal is to have this non-invasive federated, automated and computational governance. And for that, we can't just talk about it. We actually have to go deep and use case by use case and QC by PUC and generate learnings and learnings with the different teams. And this would be a classical approach of identifying the target structure, the target status, match it with the current status, by identifying together with the business teams, with the different domains and have a risk assessment, for example, to increase transparency because a lot of teams, they might not even know what kind of situation they might be. And this is where this training and this piece of data literacy comes into place, where we go in and trade based on the findings, based on the most valuable use case. And based on that, help our teams to do this change, to increase their capability. I just told a little bit more, I wouldn't say hand-holding, but a lot of guidance. >> Can I kind of kind of chime in quickly and (mumbled) below me, I mean, there's a lot of governance piece, but I think that is important. And if you're talking about documentation, for example, yes, we can go from team to team and tell these people, hey, you have to document your data assets and data catalog, or you have to establish a data contract and so on and forth. But if we would like to build data products at scale, following actual governance, we need to think about automation, right? We need to think about a lot of things that we can learn from engineering before, and just starts as simple things. Like if we would like to build up trust in our data products, right? And actually want to apply the same rigor and the best practices that we know from engineering. There are things that we can do. And we should probably think about what we can copy. And one example might be so the level of service level agreements, so that level objectives. So the level of indicators, right, that represent on a, on an engineering level, right? Are we providing services? They're representing the promises we make to our customer and to our consumers. These are the internal objectives that help us to keep those promises. And actually these audits of, of how we are tracking ourselves, how we are doing. And this is just one example of where I think the federated governance, governance comes into play, right? In an ideal world, you should not just talk about data as a product, but also data product that's code. That'd be say, okay, as most, as much as possible, right? Give the engineers the tool that they are familiar with, and actually not ask the product managers, for example, to document the data assets in the data catalog, but make it part of the configuration has as, as a, as a CDCI continuous delivery pipeline, as we typically see in other engineering, tasks through it and services maybe say, okay, there is configuration, we can think about PII, we can think about data quality monitoring, we can think about the ingestion data catalog and so on and forth. But I think ideally in a data product goals become a sort of templates that can be deployed and are actually rejected or verified at build time before we actually make them and deploy them to production. >> Yeah so it's like DevOps for data product. So, so I'm envisioning almost a three-phase approach to governance. And you're kind of, it sounds like you're in the early phase of it, call it phase zero, where there's learning, there's literacy, there's training education, there's kind of self-governance. And then there's some kind of oversight, some, a lot of manual stuff going on, and then you, you're trying to process builders at this phase and then you codify it and then you can automate it. Is that fair? >> Yeah. I would rather think, think about automation as early as possible in a way, and yes, it needs to be separate rules, but then actually start actually use case by use case. Is there anything that small piece that we can already automate? If just possible roll that out at the next extended step-by-step. >> Is there a role though, that adjudicates that? Is there a central, you know, chief state officer who's responsible for making sure people are complying or is it, how do you handle it? >> I mean, from a, from a, from a platform perspective, yes. This applies in to, to implement certain pieces, that we are saying are important and actually would like to implement, however, that is actually working very closely with the governance department, So it's Clemence's piece to understand that defy the policies that needs to be implemented. >> So good. So Clemence essentially, it's, it's, it's your responsibility to make sure that the policy is being followed. And then as you were saying, Christoph, you want to compress the time to automation as fast as possible. Is that, is that-- >> Yeah, so it's a really, it's a, what needs to be really clear is that it's always a split effort, right? So you can't just do one or the other thing, but there is some that really goes hand in hand because for the right information, for the right engineering tooling, we need to have the transparency first. I mean, code needs to be coded. So we kind of need to operate on the same level with the right understanding. So there's actually two things that are important, which is one it's policies and guidelines, but not only that, because more importantly or equally important is to align with the end-user and tech teams and engineering and really bridge between business value business teams and the engineering teams. >> Got it. So just a couple more questions, because we got to wrap up, I want to talk a little bit about the business outcome. I know it's hard to quantify and I'll talk about that in a moment, but, but major learnings, we've got some of the challenges that, that you cited. I'll just put them up here. We don't have to go detailed into this, but I just wanted to share with some folks, but my question, I mean, this is the advice for your peers question. If you had to do it differently, if you had a do over or a Mulligan, as we like to say for you, golfers, what, what would you do differently? >> I mean, I, can we start with, from, from the transformational challenge that understanding that it's also high load of cultural exchange. I think this is, this is important that a particular communication strategy needs to be put into place and people really need to be supported, right? So it's not that we go in and say, well, we have to change into, towards data mash, but naturally it's the human nature, nature, nature, we are kind of resistant to change, right? And (mumbles) uncomfortable. So we need to take that away by training and by communicating. Chris, you might want to add something to that. >> Definitely. I think the point that I've also made before, right? We need to acknowledge that data mesh it's an architectural scale, right? If you're looking for something which is necessary by huge companies who are vulnerable, that are product at scale. I mean, Dave, you mentioned that right, there are a lot of advantages to have a centralized team, but at some point it may make sense to actually decentralize here. And at this point, right, if you think about data mesh, you have to recognize that you're not building something on a green field. And I think there's a big learning, which is also reflected on the slide is, don't underestimate your baggage. It's typically is you come to a point where the old model doesn't work anymore. And as had a fresh write, we lost the trust in our data. And actually we have seen certain risks of slowing down our innovation. So we triggered that, this was triggering the need to actually change something. So at this transition applies that you took, we have a lot of technical depth accumulated over years. And I think what we have learned is that potentially we have, de-centralized some assets too early. This is not actually taking into account the maturity of the team. We are actually investigating too. And now we'll be actually in the face of correcting pieces of that one, right? But I think if you, if you, if you start from scratch, you have to understand, okay, is all my teams actually ready for taking on this new, this new capability? And you have to make sure that this is decentralization. You build up these capabilities and the teams, and as Clemence has mentioned, right? Make sure that you take the, the people on your journey. I think these are the pieces that also here it comes with this knowledge gap, right? That we need to think about hiring literacy, the technical depth I just talked about. And I think the, the last piece that I would add now, which is not here on the slide deck is also from our perspective, we started on the analytical layer because it was kind of where things are exploding, right? This is the bit where people feel the pain. But I think a lot of the efforts that we have started to actually modernize the current stage and data products, towards data mesh, we've understood that it always comes down basically to a proper shape of our operational plan. And I think what needs to happen is I think we got through a lot of pains, but the learning here is this needs to really be an, a commitment from the company. It needs to have an end to end. >> I think that point, that last point you made is so critical because I, I, I hear a lot from the vendor community about how they're going to make analytics better. And that's not, that's not unimportant, but, but true data product thinking and decentralized data organizations really have to operationalize in order to scale it. So these decisions around data architecture and organization, they're fundamental and lasting, it's not necessarily about an individual project ROI. They're going to be projects, sub projects, you know, within this architecture. But the architectural decision itself is organizational it's cultural and, and what's the best approach to support your business at scale. It really speaks to, to, to what you are, who you are as a company, how you operate and getting that right, as we've seen in the success of data-driven companies is, yields tremendous results. So I'll, I'll, I'll ask each of you to give, give us your final thoughts and then we'll wrap. Maybe. >> Just can I quickly, maybe just jumping on this piece, what you have mentioned, right, the target architecture. If you talk about these pieces, right, people often have this picture of (mumbled). Okay. There are different kinds of stages. We have (incomprehensible speech), we have actually a gesture layer, we have a storage layer, transformation layer, presentation data, and then we are basically putting a lot of technology on top of that. That's kind of our target architecture. However, I think what we really need to make sure is that we have these different kinds of views, right? We need to understand what are actually the capabilities that we need to know, what new goals, how does it look and feel from the different kinds of personas and experience view. And then finally that should actually go to the, to the target architecture from a technical perspective. Maybe just to give an outlook what we are planning to do, how we want to move that forward. Yes. Actually based on our strategy in the, in the sense of we would like to increase the maturity as a whole across the entire company. And this is kind of a framework around the business strategy and it's breaking down into four pillars as well. People meaning the data culture, data literacy, data organizational structure and so on. If you're talking about governance, as Clemence had actually mentioned that right, compliance, governance, data management, and so on, you're talking about technology. And I think we could talk for hours for that one it's around data platform, data science platform. And then finally also about enablements through data. Meaning we need to understand data quality, data accessibility and applied science and data monetization. >> Great. Thank you, Christoph. Clemence why don't you bring us home. Give us your final thoughts. >> Okay. I can just agree with Christoph that important is to understand what kind of maturity people have, but I understand we're at the maturity level, where a company, where people, our organization is, and really understand what does kind of, it's just kind of a change applies to that, those four pillars, for example, what needs to be tackled first. And this is not very clear from the very first beginning (mumbles). It's kind of like green field, you come up with must wins to come up with things that you really want to do out of theory and out of different white papers. Only if you really start conducting the first initiatives, you do understand that you are going to have to put those thoughts together. And where do I miss out on one of those four different pillars, people process technology and governance, but, and then that can often the integration like doing step by step, small steps, by small steps, not pulling the ocean where you're capable, really to identify the gaps and see where either you can fill the gaps or where you have to increase maturity first and train people or increase your tech stack. >> You know, HelloFresh is an excellent example of a company that is innovating. It was not born in Silicon Valley, which I love. It's a global company. And, and I got to ask you guys, it seems like it's just an amazing place to work. Are you guys hiring? >> Yes, definitely. We do. As, as mentioned right as well as one of these aspects distributing and actually hiring as an entire company, specifically for data. I think there are a lot of open roles, so yes, please visit or our page from data engineering, data, product management, and Clemence has a lot of roles that you can speak to about. But yes. >> Guys, thanks so much for sharing with theCUBE audience, you're, you're pioneers, and we look forward to collaborations in the future to track progress, and really want to thank you for your time. >> Thank you very much. >> Thank you very much Dave. >> And thank you for watching theCUBE's startup showcase made possible by AWS. This is Dave Volante. We'll see you next time. (cheerful music)