 Okay, we're back with Justin Borgman, CEO of Starburst, Richard Jarvis, is the CTO of Emus Health and Theresa Tung, is the cloud first technologist from Accenture. We're on to lie number three. And that is the claim that today's modern data stack is actually modern. So I guess that's a lie. It's that it's not modern. Justin, what do you say? Yeah, I mean, I think new isn't modern, right? I think it's the new data stack. It's the cloud data stack, but that doesn't necessarily mean it's modern. I think a lot of the components actually are exactly the same as what we've had for 40 years, rather than teradata, you have snowflake, rather than informatica, you have 5Tran. So it's the same general stack, just a cloud version of it. And I think a lot of the challenges that have plagued us for 40 years still maintain. So let me come back to you, Justin. But okay, but there are differences, right? I mean, you can scale, you can throw resources at the problem, you can separate compute from storage. You really, you know, there's a lot of money being thrown at that by venture capitalists and snowflake you mentioned, it's competitors. So that's different. Is it not? Is that not at least an aspect of modern? Dial it up, dial it down. So what do you say to that? Well, it is. It's certainly taking, you know, what the cloud offers and taking advantage of that. But it's important to note that the cloud data warehouses out there are really just separating their compute from their storage. So it's allowing them to scale up and down, but your data is still stored in a proprietary format. You're still locked in. You still have to ingest the data to get it even prepared for analysis. So a lot of the same sort of structural constraints that exist with the old enterprise data warehouse model on-prem still exist. Just yes, a little bit more elastic now because the cloud offers that. So, Teresa, let me go to you because you have cloud first in your title. So what's say you to this conversation? Well, even the cloud providers are looking towards more of a cloud continuum, right? So the centralized cloud, as we know it, maybe Data Lake, Data Warehouse in the central place, that's not even how the cloud providers are looking at it. They have new query services. Every provider has one that really expands those queries to be beyond a single location. And if we look at a lot of where the future goes, right? That's going to very much follow the same thing. There was going to be more edge. There's going to be more on-premise because of data sovereignty, data gravity, because you're working with different parts of the business that have already made major cloud investments in different cloud providers, right? So there's a lot of reasons why the modern, I guess the next modern generation of the data stack needs to be much more federated. Okay, so Richard, how do you deal with this? You've obviously got the technical debt, the existing infrastructure. It's on the books. You don't want to just throw it out. A lot of conversation about modernizing applications, which a lot of times is a microservices layer on top of legacy apps. How do you think about the modern data stack? Well, I think probably the first thing to say is that the stack really has to include the processes and people around the data as well. It's all well and good changing the technology, but if you don't modernize how people use that technology, then you're not going to be able to scale because just because you can scale CPU and storage doesn't mean you can get more people to use your data to generate you more value for the business. And so what we've been looking at is really changing in very much aligned to data products and data mesh. How do you enable more people to consume the service and have the stack respond in a way that keeps costs low because that's important for our customers consuming this data, but also allows people to occasionally run enormous queries and then tick along with smaller ones when required. And it's a good job we did because during COVID, all of a sudden we had enormous pressures on our data platform to answer really important life-threatening queries. And if we couldn't scale both our data stack and our teams, we wouldn't have been able to answer those as quickly as we had. So I think the stack needs to support a scalable business, not just the technology itself. Well, thank you for that. So Justin, let's try to break down what the critical aspects are of the modern data stack. So you think about the past five, seven years. Cloud obviously has given it a different pricing model, de-risk experimentation that we talked about, the ability to scale up, scale down. But I'm taking away that that's not enough. Based on what Richard just said, the modern data stack has to serve the business and enable the business to build data products. I buy that, I'm a big fan of the data mesh concepts even though we're early days. So what are the critical aspects, if you had to think about the paying, maybe putting some guardrails and definitions around the modern data stack, what does that look like? What are some of the attributes and principles there? Of how it should look like or how it's- What it should be. Yeah, yeah. Well, I think, and Theresa mentioned this in a previous segment about the data warehouse is not necessarily going to disappear, it just becomes one node, one element of the overall data mesh. And I certainly agree with that. So by no means are we suggesting that snowflake or Redshift or whatever cloud data warehouse you may be using is going to disappear, but it's not going to become the end all be all. It's not the central single source of truth. And I think that's the paradigm shift that needs to occur. And I think it's also worth noting that those who were the early adopters of the modern data stack were primarily digital native born in the cloud, young companies who had the benefit of idealism. They had the benefit of starting with a clean slate. That does not reflect the vast majority of enterprises and even those companies as they grow up, mature out of that ideal state. They go by a business. Now they've got something on another cloud provider that has a different data stack and they have to deal with that heterogeneity. That is just change and change is a part of life. And so I think there is an element here that is almost philosophical. It's like, do you believe in an absolute ideal where I can just fit everything into one place or do I believe in reality? And I think the far more pragmatic approach is really what data mesh represents. So to answer your question directly, I think it's adding the ability to access data that lives outside of the data warehouse, maybe living in open data formats in a data lake or accessing operational systems as well. Maybe you want to directly access data that lives in an Oracle database or a Mongo database or what have you. So creating that flexibility to really future proof yourself from the inevitable change that you won't encounter over time. So thank you. So Teresa, based on what Justin just said, I might take away there as it's inclusive, whether it's a data mart, data hub, data lake, data warehouse, it's just a node on the mesh. Okay, I get that. Does that include Teresa on on-prem data? Obviously it has to. What are you seeing in terms of the ability to take that data mesh concept on-prem? I mean, most implementations I've seen in data mesh, frankly, really aren't adhering to the philosophy there, maybe it's data lake and maybe it's using glue. You look at what JPMC is doing, Hello Fresh. A lot of stuff happening on the AWS cloud in that closed stack, if you will. What's the answer to that, Teresa? I mean, I think it's a killer case for data mesh. The fact that you have valuable data sources on-prem and then yet you still want to modernize and take the best of cloud. Cloud is still like we mentioned, there's a lot of great reasons for it around the economics and the way ability to tap into the innovation that the cloud providers are giving around data and AI architecture. It's an easy button. So the mesh allows you to have the best of both worlds. You can start using the data products on-prem or in the existing systems that are working already. It's meaningful for the business. At the same time, you can modernize the ones that make business sense because it needs better performance. It needs something that is cheaper or maybe just tap into better analytics to get better insights. So you're going to be able to stretch and really have the best of both worlds. That again, going back to Richard's point that is needful by the business. Not everything has to have that one size fits all set a tool. Okay, thank you. So Richard, you were talking about data as product. I wonder if you could give us your perspectives here. What are the advantages of treating data as a product? What role do data products have in the modern data stack? We talk about monetizing data. What are your thoughts on data products? So for us, one of the most important data products that we've been creating is taking data that is healthcare data across a wide variety of different settings. So information about patients demographics, about their treatment, about their medications and so on and taking that into a standards format that can be utilized by a wide variety of different researchers because misinterpreting that data or having the data not presented in the way that the user is expecting means that you generate the wrong insight. And in any business, that's clearly not a desirable outcome but when that insight is so critical as it might be in healthcare or some security settings, you really have to have gone to the trouble of understanding the data, presenting it in a format that everyone can clearly agree on and then letting people consume in a very structured and managed way even if that data comes from a variety of different sources in the first place. And so our data product journey has really begun by standardizing data across a number of different silos through the data mesh so we can present out both internally and through the right governance externally to researchers. So that data product through whatever APIs is accessible, it's discoverable but it's obviously got to be governed as well. You mentioned appropriately provided to internally but also external folks as well. So you've architected that capability today. We have and because the data is standard, it can generate value much more quickly and we can be sure of the security and value that that's providing because the data product isn't just about formatting the data into the correct tables. It's understanding what it means to redact the data or to remove certain rows from it or to interpret what a date actually means. Is it the start of the contract or the start of the treatment or the date of birth of a patient? These things can be lost in the data storage without having the proper product management around the data to say in a very clear business context, what does this data mean and what does it mean to process this data for a particular use case? Yeah, it makes sense. It's got the context. If the domains own the data, you're going to cut through a lot of the centralized teams, the technical teams, the data agnostic. They don't really have that context. All right, let's end. Justin, how does Starburst fit into this modern data stack? Bring us home. Yeah, so I think for us, it's really providing our customers with the flexibility to operate and analyze data that lives in a wide variety of different systems, ultimately giving them that optionality. Optionality provides the ability to reduce costs, store more in a data lake rather than data warehouse. It provides the ability for the fastest time to inside to access the data directly where it lives. And ultimately with this concept of data products that we've now incorporated into our offering as well, you can really create and curate data as a product to be shared and consumed. So we're trying to help enable the data mesh model and make that an appropriate compliment to the modern data stack that people have today. Excellent. Hey, I want to thank Justin, Teresa and Richard for joining us today. You guys are great. Big believers in the data mesh concept. And I think we're seeing the future of data architecture. So thank you. Now remember, all these conversations are going to be available on thecube.net for on-demand viewing. You can also go to starburst.io. They have some great content on the website and they host some really thought provoking interviews and they have awesome resources. Lots of data mesh conversations over there and really good stuff in the resource section. So check that out. Thanks for watching. The data doesn't lie or does it? Made possible by starburst data. This is Dave Vellante for theCUBE and we'll see you next time.