 Hello, and welcome to this episode of our series, The Road to Intelligent Data Apps. In this series, we're focused on the evolution of the modern data stack into the new platform for applications or what we're calling the sixth data platform. I'm Shelly Kramer, Managing Director and Principal Analyst here at the Cube Research. Before we get into our conversation and more introductions, I just want to set the stage a little bit. There's a big transition that's underway and it's part of the challenge that organizations face and the transition that they're navigating is that they need to be able to do a few things, actually many things differently than what we've done before. I will admit right up front to bias, but in my opinion, there are two better people suited to share gray matter on this topic than my colleague and fellow analyst here, George Gilbert and our guest today, Bob Muglia. As I introduce you, Bob, I have to admit when I was thinking about this, first of all, I feel like I've seen 70 billion podcast episodes featuring you. I mean, like I know what your office looks like. So you've been making the rounds lately. But I think you're both old enough to remember that phrase, and I don't know who it was that said it. Was it Johnny Carson who said, my next guest needs no introduction. That's what I think about when I think about you, Bob. I think that could probably not be any more true. So some backstory here, and I can't believe there's anybody watching or listening to this who doesn't know Bob. But Bob was the president of the precursor to Microsoft's Enterprise Division. He grew the business to a paltry 14 billion. Most recently, he was a CEO of Snowflake leading it from zero revenue until it was ready for an IPO as the largest ever debut of an enterprise software company, no small accomplishment. Today, as I mentioned, I see Bob everywhere I go. He's the mentor to an investor in some of the most exciting companies driving the evolution of the modern data stack. Of course, the modern data stack is becoming the new platform for applications as we're seeing raw cloud infrastructure recede into the background. Last but not least, Bob is, I'm going to be Bob's favorite person because I show up with his book. Bob's also the author of the datapreneurs focused on the promise of AI and the creators who are building our future. Bob, welcome to our show. Thanks, Shelly. Great to be here. Well, we're so glad to have you and George. Always nice to spend time with you, so gentlemen, let's get to it. I want to start off with some basics. Bob, let's start with you. Let's talk a little bit about what's involved in building the modern data platform. I'm thinking here about your keynote at the Knowledge Graph Conference in 22, which seems like forever ago. But with all the governance tool categories you talked about, will all of those categories be adjuncts to the five major platforms? Or do you think customers will be able to assemble a modular multi-vendor platform? Well, customers have always used multiple vendors. Let me just start by saying that. When I was running Snowflake, I think still to this day, many customers still use both Databricks and Snowflake together as part of their solution set. So it's not uncommon that people work with multiple vendors and I think it's important that they continue to be able to do that. The platforms are maturing. Each one of them is different. They all do very similar things and they're trying to provide very similar services to customers, but they are doing it in somewhat different ways. I think each one of them will continue to improve what they can provide in terms of governance and every other aspect of their platform, and they are accommodating to ISVs that are building on top of it and are essentially these super-clouds that are being put together, the data clouds, are definitely platforms on their own. I don't know whether I would agree that the clouds are receding as you put it exactly, but there's clearly another layer that's been built on top and that's being targeted by ISVs and that can be selected by customers. There's some real major impediments to cross-vendor solutions, and the one that I'm most focused on at the moment is that what's clear is that the data lake is emerging as the place where data is stored, by and large, data of all kinds that includes structured and semi-structured data, but it also includes videos and documents and everything else, text data that's of great interest for people as they begin working with large language models. And what we now have is a set of, we have technologies that essentially unify and provide a coherent way of looking at data from both a file perspective as well as from a table perspective. Unfortunately, there are three different standards that exist to this today. Customers have to select what they're working with and there are some incompatibilities, significant incompatibilities between them. You know, the ones that, the first one that probably came out was Hootie and it was established by, has been adopted by a number of very large enterprises, Silicon Valley for sure, but it's used by a relatively small number of companies, but the companies that are using it are all very, very large. There's Delta, which was really created by Databricks and has been adopted by Microsoft. And then there's Iceberg, which is used by Snowflake and Google. And although Amazon talks about multiple, they've definitely focused quite a bit on Iceberg. So Iceberg has, it's very strong contingent. And so what we have right now is a little bit of a beta versus VHS situation in terms of the fact that customers are putting their data into a given type of data lake. And while the data storage in all of these is the same, they're all essentially using Parquet files and fortunately the data itself is compatible. The metadata associated with it, the metadata that turns these files into tables is all different in its structure. Now, the unfortunate thing about that is, is that it means that these systems don't work together the way they should. The positive aspect of it is that the metadata is quite small relative to the size of the data. And so it may be possible to just translate and transform it across that. And we're beginning to see some solutions that try to accomplish that. One in particular is gaining a little bit of traction called X-Table. But it's, and that allows you to have data in one of these formats like Delta or Iceberg and then it'll convert it to another format so it can be used by a different vendor. We still haven't seen whether that's going to work for customers yet and hopefully this year we'll find out if that solution will be adequate to work through some of this compatibility issue. But that's the one that's bugging me the most right now because it's a showstopper for customers. Yeah, absolutely, George. Let me build on that, Bob, because that sounds like the differences even if the metadata that defines what's in the Parquet files to turns them into tables, the semantics probably can't be that different. They're not different! Right, okay. It's just different because they're different. There's no reason for this. What happened here is that when Delta was released it was not released fully as open source. So it was not adopted, but Hoody was the precursor to all of this I think and for a variety of reasons, people didn't want to adopt that and I think there are some technical issues there. But Delta kind of came out and because of business reasons and it wasn't fully open source another alternative Iceberg emerged as that but we now have this incompatibility. So, but extend that thought as customers put observability tools and data quality rules and they start adding more and more semantics. The data platforms, this is the example we used with Molymne, with Jean-Claude Venam starting on two Volvo trucks that are growing apart. Like customers might be able to support different data platforms today because even going between Iceberg and Delta is not that big a deal if you've got this intermediate format and the semantics aren't that different. But as you add more and more metadata those data platforms seem like they would become harder and harder to bridge. Well, the question is, can you fully bridge them or not? And does a solution like this X-Table solution which is really essentially a copy and transform it when a change occurs or on an interval basis you can take a look at one of these platforms and it'll convert the metadata into a different format. And it does that asynchronously but that may be adequate for this solution. It's unclear right now whether that's gonna solve the problem or not. It is a mess for customers. This is an unfortunate situation right now because customers are making bets associated with which data like format they're gonna use and when they do so it does have some limitations at least today. Maybe those limitations will be lifted in a year from now and I hope so. So looking out further and I'm saying this problem looks like it'll get worse because it's not just table formats where underneath it's still just a table. I'm saying as you add all the other- Everything on top of it. Yeah, it starts to build. So you've got really two scenarios that seems to me like tech companies can figure out how to blow the stuff together with chewing gum and baling wire because they have the sophisticated teams that can design it and operationalize it, manage it. But what happens to the mainstream customers? Do they then just wait for the data? The mainstream, to me it's pretty obvious. The mainstream customers are gonna choose one of these platform investors and go deep into it because that's the rational thing you can do today and you can make very good solutions work if you're staying within a single vendor and environment. It's just the complexity of when you're trying to mix and manage things that becomes more challenging. Shelly, you might have wanted to key off the Salesforce as a, even though their solution is immature, their data cloud might be a solution to this problem. Yeah, and I think that we had a guest on from Salesforce Data Cloud here in the last couple of weeks and that's part of what we were talking about was the complexity issue. And if no one rationalizes the complexity from tool overlap, then does it leave an opening for something like the Salesforce Data Cloud or some other solution to become an attractive alternative solution? I think for some customers where the majority of their data is related to that application vendor, it makes sense. I mean, the reason why, however, these data platforms have grown up to exist is because there's a multi-vendor situation in terms of the applications you work with. So while Salesforce can say, oh, use the Salesforce Cloud in Adobe, we'll say use the Adobe Cloud. And the problem is, which one are you gonna, which one are you gonna sort of go to Oracle? Which one are you gonna sort of bet on? The benefit, presumably, of a Snowflake of Databricks or one of the vendors, the cloud vendors like Microsoft Fabric or BigQuery, is that it should work with all the data from all of those vendors. And you really want to do that. I mean, I don't think that, I don't know that the fundamental problems I'm describing actually go away just because you abstracted to an application platform. I mean, you still are putting the data in some format, right? And one of the benefits of the, and one of the reasons why these data lakes have become popular is, Abe, it's for all data types. I mean, that's super important today where we have a lot of document-oriented data that's interesting, videos, photos, things like that, are all part of the information that is being collected by organizations. And data lakes are a natural storage location for that. But when you start to do that, you have a very heterogeneous set of data that's coming together. And again, it would be helpful if there were some common formats to put it in. The fact that these things are, generally speaking, open source is a good thing. The fact that they haven't converged on one is not so good. And I'm hopeful, we'll see. I hope that these translation-oriented solutions provide a stopgap for customers. And maybe someday we will see the open source version of a data lake that the one to rule them all, but we haven't seen that. The other thing I would say is there are problems that even when you look inside these different solutions that are unsolved, I mean, in particular, if you sort of think about what a data lake and a format like iceberg or Delta is supposed to do, it essentially provides a common way of storing data and then providing you different views on that data. One being a SQL view that's provided through some kind of a database. And the other being a file-oriented view. Typically, that's expressed in something like a Python program as a data frame. In a way, think of the data frame and the SQL query as the two core developer interfaces. The challenge we have today is that we don't see the same view between those two, even with iceberg. Because once you begin to put governance on top of that data and you start to restrict columns and rows, you have to block access or provide consistent access into that data frame view coming in through Python or you have to block it. And kind of the whole purpose of this thing was to not block it. And there's no solution for that today. Although vendors are beginning to discuss that. And I think that we may begin to see 18 months, 12 to 18 months, we may begin to see solutions that do that. And perhaps that's an opportunity to further unify things. Or maybe an opportunity that it'll fragment even more. I don't know. We'll see what the vendors decide to do as time goes by. Well, and I think one thing that we can all agree is a given is the rapid evolution of this space is absolutely where we are. So what we have today and where we'll be in 12 or 18 months could be interesting. Yeah, and the fact, if you're using any one of these five different data platforms to work with all of your data in a cohesive way, you're at least, you're operating in the modern world and you're at least taking the step forward. There's a lot of additional steps we can take and a lot of problems yet to be solved. But at least putting all of your data together inside one of these data platforms is clearly the right thing to do. And they're all building basically the same thing, basically. So talking about these data, the five major data platforms that are in use today and the current state of affairs today, I'd love it if we could kind of get you to walk us through sort of the Bob Mungley review of these five major data platforms. Let's start with Snowflake. Well, I think Snowflake has come from the perspective of the business analysts working with data and that's where they historically were as a data warehouse. They've expanded now to be a complete data platform and are really focused on running applications and getting applications to run inside their data cloud. Probably the most interesting thing Snowflake is doing this year is shipping snow park container services, which is essentially a set of interfaces for applications of all types to be built on top of Snowflake as a platform, as a data platform. And this includes tools, data tools that people will use and sort of the data at the eyes of e-vendors that are working with Snowflake, building things that augment what Snowflake does and compliment what Snowflake provides, as well as applications that are completely focused, bespoke applications, targeting a variety of different vertical and horizontal solutions. And so they're focusing on that. They're trying to be a complete platform, provide a cohesive interface for people to very easily write code, to build, to take the models, the ML models that exist in the world, apply those into that environment. So that's kind of Snowflake. It's become an advanced enterprise development environment for modern data applications. Along those lines, Bob, does it, to what extent do they need low latency transactions to operationalize the decisions that come out of those applications? To some extent, there's a modest number of low, I mean, they do need it for sure. They have a product in Unistore, they can use for that, but they do need it to a certain extent. But again, I'm not, I don't think that the applications that people, I have a separation between people applications, applications that people work with day in and day out and intelligent or data applications. We're really talking about the intelligent or data applications that are being built on here. So the high volume transactional applications, the credit card processing, all that sort of stuff, that's not gonna go on to the data cloud anytime soon. And I don't think you'll start to see that. But there's a whole new set of apps that are getting built. And so, sort of higher latency, slower transactions are enough for that class of applications, maybe along with workflow orchestration, because you still- Exactly, you just don't have that many trends. You don't have that many individual transactions that you have in the more characteristic people oriented applications. And so, I think that you'll continue to see a lot of those things operating separately from the data clouds. So to what extent is their multi-model execution engine a big advantage over other data platforms? I think it's the integration that Snowflake provides end to end and the simplicity of putting all these pieces together. You know, I could see, I think this issue that I mentioned about having a consistent view between a data frame and a SQL query, Snowflake probably is well-positioned to provide that as they advance their governance structure, certainly if they're working within their own proprietary environment versus inside the iceberg data lake. So you'll see Snowflake doing a number of things, just to make it easy for enterprises to pick up models that exist, whether it's Lama 2 or GPT-35, Turbo, whatever they wanna work with, incorporate those sorts of models into the applications and begin to build these new intelligent apps. You know, Snowflake is really trying to target the enterprise customers and the ISVs that support them as in providing a cohesive environment and also to work between customers because Snowflake really has the only effective data sharing environment today. And many customers are doing data sharing on Snowflake and you don't see that extent on the other platforms. There's data sharing, but not like Snowflake. So let's take that as a transition point into Databricks. Distinguish the Snowflake data sharing from the Databricks data sharing. Well, Databricks is really nascent in what they're doing with data sharing where Snowflake's environment is much broader. More problematic is that Databricks is data sharing architecture with Delta and Microsoft's data sharing architecture with Fabric are not the same thing, which is crazy, absolutely crazy in my opinion. I know why it happened, but it's absolutely, it's always a people thing, right? It's never, there's not a common sense sort of thing to have happen. So we'll see what winds up happening. You know, Databricks on the other hand has been the place that people go to actually build these models. In whether it was first generation machine learning models or the large language transformer based models, people are building it on Databricks and with their acquisition of Mosaic ML, they are well positioned for people who wanna create models. And so, in a way, they've always targeted a much more data science specific crowd and they continue to do that as a large part of their target audience. And Snowflake has never really, that's not been their cup of tea. So it's a little bit of a different target audience and it very much speaks to where these two different companies have come from. But to help us distinguish between Databricks then as an application platform. So if they say, you know, you can build data apps on Databricks, you can take the models you've built and turn them into applications that can operationalize decisions. What in the platform still needs to be built out to make it as comprehensive and as simple as what's in Snowflake? I mean, Databricks has never built the end-to-end orchestration the way Snowflake has built it. And they've always had, they've come from the perspective of the developer first, always in what they've done versus the business analyst or even the business operations person that wants to use a tool like DBT to actually do transformations. It's just a different perspective. You can do all the pieces in Databricks but I think you're probably writing a little bit more code on your own. And I hear from customers it's a little harder to put those solutions together on Databricks. Okay, are they, to what extent have they tried to redefine the competition with Snowflake to be not what data do we manage to and convert it into what data, how much of your data estate can we govern with our operational and business catalog? And how might they eventually add abstraction to that in terms of business semantics? Yeah, we'll see over time. I mean, they announced the Unity catalog last year they're putting a lot of energy on it. I think it's good what they've done in that space and they're doing some things to be helpful there. The problem with all of these catalogs right now, I mean, there are people that are trying to do a semantic layer of any kind is, and this is kind of just you discussed at length and you know, when you talk to Mulham in your podcast with Mulham recently of relational AI is that the database semantics that we need for the semantic layer just don't exist in the modern data stack. You need to have graph-oriented capabilities and the ability to work with hierarchical data much more effectively than you can work with it in a SQL database and it's been a problem that everybody has faced as they've tried to put these systems together. So, you know, I continue to believe and I mean, I'm a first principles kind of guy and there's no proof that I'm right about this but I continue to believe that where the industry needs a solution for a knowledge graph database and that is what we're lacking is a database for knowledge graphs and when we have that I think these solutions will begin to emerge much more rapidly because if we are able to put more of the logic and the information into that semantic layer and store it naturally in there versus, I mean, trying to store this stuff in relational tables it just tables are not meant to store the semantic layer I mean, you can make your head hurt and you can make something work but it's not what you want to have happen. But what about the scenario where I just talked to Varun at Atlan the other day and he's trying to be a collaborative workspace in a business catalog that starts to capture business semantics. So imagine unity as a catalog that becomes a collaborative workspace and then it's backed by a relational knowledge graph perhaps not as expressive as relational AI meaning maybe it just has business rules that it doesn't have all the... Perhaps, perhaps we'll see that. I mean, we don't know. The thing is building this has been hard. It's not been easy for people to build these things. You know, the traditional graph databases are built using navigational models where they literally hard link the pieces together and in an analytic environment where what you're doing is asking questions of unknowns that structure doesn't work that well because you have to pre-define the questions that you can ask and when you go off the road you're in the desert, you're off roading in a big way. And so whereas you're used to in working with tables if you can express these things as tables in a typical SQL database you can just issue a join commander or structure it any way you want. The problem is this data doesn't fit into that tabular format. And so what we need is the set of semantics that allow you to work with it. And to me that is the right answer to this has been the relational knowledge graph. It's been a pursuit that, you know, Mulham recently, you know, you've talked to Mulham that's been on for a good part of his life and for me the last four years. And, you know, we definitely see a light at the end of the tunnel. I mean, this is definitely coming together now. One of the most important things that happened in my opinion in the last year from what's going on with relational AI is that we've been able to come up with a team has been able to advance the user interactive model, the programming interface model to be more natural for developers. Trying to transform, there's a lot of concepts here and we need to hide a lot of those concepts to be honest with you. And so we've now have some abstractions that I think we'll begin to see that we're much more familiar for developers to work with. So I'm very encouraged, very encouraged by the fact that this technology is gonna come to market. I think it's gonna come to market this year. I think it'll come to market in a way that is understandable by developers and will really begin to solve a lot of problems. The other thing that is important in all of this and it relates somewhat to the conversation you have about portability between different platforms is that the way Mulheim has designed relational AI is as an add-on on top of, or he calls it a coprocessor on top of these data platforms. Snowflake being the first of those that they're targeting but you could target the others as well and there's conversations about that. And it allows these semantics to essentially be added on top of the semantics that exist in the platform. It's not trying to replace them because you can't replace, it doesn't replace what a SQL database can do but it does things a SQL database can't do. It's a new layer. It's a new layer. It's the semantic model layer. It's the knowledge graph layer that defines how the business is connected together and how all of the components relate. And while the number of concepts that any given business has is actually relatively small, the number of relationships that exists across the different data state is just gigantic with thousands and thousands of tables and God knows how many columns and everything else. So I'm trying to think about how, this is what Mulheim's got is it's the righteous way to do it. And what I'm wondering about is what are others? Quick and dirty, is there a quick and dirty way to do it? Is that what you're doing? I'm thinking it's righteous. I'm struggling with that. I want that quick and dirty way, but we haven't found it yet. The sort of the, in a way, the odd way people, I've seen people do it that it works is to take a document or a database like Mongo or something like that and a search thing like Elasticsearch and try and put the two together somehow and you can kind of, you know, the search engine, the search engine sort of becomes a joint engine. It's a little bit weak, but it provides you some of the capabilities. Because so I'm thinking somewhere between the righteous way that Mulheim's figured out and something better than that chewing gum and bailing wire, like a less advanced relational knowledge graph that might come out. And there's triple stores. I mean, the typical way people do this is a variety of triple stores, but those are essentially navigational. I don't know, we'll see. It could happen. I mean, and I'll be answered. The answer to this is very simple in my mind is that if relational AI is able to establish a product that solves a bunch of these problems in a reasonable timeframe, let's say the next 12 to 18 months, then I think it can establish a standard associated with that. If it takes another five years, then forget it and we're gonna have to see something else. But I don't think, as an investor, I sure hope it doesn't take five more years. What do you think Microsoft might attempt between like Fabric and the Power Platform and then all the other services that are now connectors you know, inside Power Platform, including Co-Pilot Studio, you know, as a low code or no code kind of attempt. What might- I think they're the 800 pound gorilla in the room to be honest with you on this and the real strength that they have. I mean, you know, there's two things about this. One is that fabric is quite real. Let me just start by saying they've built a good product in Fabric. I mean, it's their third version, the first two versions weren't so great. This is in classic Microsoft form, the V3 is a good version and this is their V3 and it'll be a good Microsoft product. You know, that means it'll be appeal to Microsoft customers. You know, in a way, Snowflake does a lot of the same things Microsoft does in the sense that Snowflake is good at connecting the dots together and providing a solution and Microsoft, it did too. I mean, that's not by accident, let me say that. I mean, I certainly, you know, Christian came, the current head of product came from Microsoft and of course I came from Microsoft. So we learned a lot there. We learned a lot there that's been applied to Snowflake and a lot of the lessons that came from Microsoft is they're being applied. So they're gonna do a lot of the same things to their customers. The big thing that's interesting is Power BI and it'll be interesting to see they have not yet released co-pilot for Power BI. They just, Microsoft just in the last week or so has released a number of their co-pilots into production for Office 365 but they've not released Power BI co-pilot yet. It'll really be interesting to see what they do there. Recognize that Microsoft and Power BI has had a semantic model to build on top of for a long time, they had DAX. It's not the prettiest language on earth but they've had a fundamental semantic model as a basis for Power BI for a long time which I expect to see them leverage where they do the co-pilot. Okay, and so that's my question which is can they generalize that first for other Microsoft products to use besides Excel, you know, other developer tools, even if it's just the Power Platform and is DAX expressive enough to do more than BI type. No, not in its current form. It's only, it needs to be more expressive for sure and you need to have a lot more semantics in there than people would put in a Power BI model but it's a good start. And if you're trying to do English natural language to SQL, it can contain quite a bit of the core concepts that are required to do that. In all those cases right now, I mean, in the cases of everybody that's trying to do English to SQL, the error rate is too high still on that and people are still struggling with getting the accuracy of those things to an acceptable level and we aren't there yet. Maybe within 12 to 18 months we will be, we'll find out, but it'll be interesting to see when Microsoft enters the fray. When isn't that semantic layer, however minimally expressive, you know, for like BI concepts like bookings, billings and revenue, things like that would be critical for getting English in there. Critical. If nothing else you have to define terms, if you must define terms that are business specific terms because, you know, a language model isn't, you know, it's not, you know, it's not a genie or something. It can't make, it can't find out things out of thin air. If you have a business term that you use in your company that doesn't have generally accepted meaning to other customers, that must be defined somehow. Absolutely. In order to be able to have the language model do the right thing. And today that's defined in the heads of these business analysts and data programmers and things. And it ultimately needs to be expressed inside these semantic models. Microsoft lacks the tools to build a semantic model just like every other company does. They have, however, a gigantic portfolio of research and other things they could potentially call on to do things. And they did do some really interesting work on some of these things in actually the LinkedIn team but it's totally different group. I mean, at Microsoft it doesn't necessarily provide the ability to that translate into a generalized product. We'll see, we'll see over time. The challenges that exist for everybody in terms of the database support to define this semantic model is a problem for Microsoft as well. So what about Google? Are they, you think they're the furthest along among the hyperscalers when it comes to the LinkedIn? I saw that in your, why do you think Google might be the furthest along instead of curiosity? Maloy or what are the reasons you think about Google? Because they had gone the farthest, maybe until fabric in having a data-centric architecture where there was one set of metadata that all the tools shared in Vertex. Yeah, BigQuery, yeah. And then BigQuery uses it. The, I forgot, data plex is the metadata. Vertex uses the data through data plex. In other words, they were metadata-centric and that seemed to be farthest along in having all the tools. Well, the interesting question is can Google put those pieces together in a way that makes it easy for customers to work with? I mean, I continue to hear that Google has a lot of really good tools and some customers, if you go all in, they can be very successful with it. But in general, Google has had its own sort of way of doing things, so we'll see over time. And can they do that faster than some of the competition? Right, and then they have, in terms of incumbency, they're essentially in third in the three-horse race of the clouds in the US and Europe. So we'll see over time. Of the primary incumbent, in terms of data platforms, can Amazon, which started with these stovepipe products, move to a data-centric architecture? No, I don't think so. I was wondering. It's just not in their DNA. I mean, they build a toolbox and they build a great toolbox. I mean, if you want a hammer, man, it's a high-quality hammer or the screwdriver or the drill, they're all really good, but they have to be drilled together and stuff. And that's just sort of the Amazon way of doing things. It would take, Amazon has never demonstrated this, let me say this. So it's a cultural thing. It's not just a product heritage thing. Okay. I mean, this is arguably why Snowflake was able to be successful in the first place. We built a better product that was more integrated and Amazon just wasn't able to do that, even though they had, you know, some might think a significant head start initially with Redshift. That said, Amazon stuff is quite good and a lot of stuff runs on Amazon and people use it a lot. So that all true, but they tend to build it themselves. So, Shelley, go ahead. Do you have another question? Well, I was just going to go on the transition to Gen AI. You go ahead, Shelley. Yeah, I think now what we want to talk about a little bit, Bob, is what your thoughts are on the role that Gen AI can play in accelerating all aspects of application development, like for modeling data and the business and that sort of thing. Well, I mean, I think in general, we're seeing, first of all, the first generation of Gen AI products are these co-pilot products. And, you know, we're going to see, you know, the next six months is going to be the era of the co-pilots and we're going to see a lot of co-pilots come out from a lot of different companies. Some of them will be very, very useful and some of them may not be that useful at all. I mean, we'll see over time how that sort of goes. And that's kind of how that goes with everything, right? You know, the second sort of generation of these things are going to be far better information retrieval, you know, using RAG techniques, you know, and that, and we'll start to see those products as well. I think this year, you know, might be more second half before we see more completed products by and large, but we'll start to see some of that. And those techniques are very, very important. RAG techniques are very, very important to doing things like improving the accuracy of the translation of natural language into SQL commands. That it's necessary to do that. I think the third sort of generation of these things will be these semantic models in these knowledge graphs, if you sort of ask. And I think RAG and knowledge graphs are going to be very, very copacetic and very integrated together because a knowledge graph can be used to improve the results of what a transformer model can do. And so we'll start to see that those pieces fit together. The other thing that's really important is that, you know, while the number of concepts that any given business may have is not that many, the complexity of how those concepts interrelate really rapidly move beyond the point of what humans are able to understand in large organizations. Okay, so. And I think what we're going to see a lot of is models being used, transformer models being used to help build the semantic layer. And I think that's going to become quite common in the next 18 to 24 months. Can that break the 50 or 60 year hex on the inability for just about any organization to build a top-down model of how the organization works? That's the theory anyway, George. That's the theory. The hex is, the hex may be tougher to break than we know, but that's the theory is that this will do it. So game this out. What are alternate scenarios for getting to that? We're going to get to an enterprise model, but what are some alternate scenarios where, you know, you might have bottom-up islands and then somehow you build an ontology that integrates those. Is that possible? I mean, I think you'll see that to some extent and we've sort of always had that to some extent, right? I mean, every island that's been created in a sense those islands are called applications today in a way, aren't they? And I think we'll see that. But we integrated them, we kicked the can down the road to the data warehouse to integrate them, but can we create one coherent model, you know, even if they started bottom-up? Well, I think that, again, my current view is that, no, not without being able to use machine learning to help us create those models, that they will be a very critical co-pilot tool to help us create these models. So what would it look like to a developer? Or a development organization? What it looks like, first of all, I think some of these tools will be, and there's actually probably 10 companies that are doing something in this space right now. Let me start by saying that everybody sees that this is an interesting thing. And I think you can do a lot of tools, there will be tools that are available that you can give access to your data estate, look at the schemas that are out there, the catalogs that are out there, look at the queries that have been run in the past, query logs are an incredible source of information, look at the DBT models that maybe people might have created, looking at these different model sources to use to derive from that a semantic model. And I think we'll start to see tools that do that. A lot of it will be somewhat, I mean, I think what'll happen is, you know, you'll point these tools at your data sources, and it will essentially try and create a first version of your semantic model, which you can then augment and then continue to edit. And it probably is an interactive thing because stuff's happening all the time that you don't know about, right? And this stuff can help you discover things you don't know about and bring them in. But again, it's going to, I think for at least a number of years be a co-authoring process where the tools will help the data operations people, the people that are defining the data models and help them to build it. I do really think that the role of data ops have said this before, and I do totally believe it, that data operations is going to change considerably in the next few years. I mean, if you sort of look, if we kind of went through a period of history, you know, data ops was data preparation, you're worrying about data prep. Five years ago, a lot or seven years ago, a lot of that was being done programmatically through Spark. It's still done to that way to some extent, more and more that's moved into relational commands that are issued through SQL and tools like DBT that's taken up a larger and larger percentage of this. And that's what data ops people are often doing today in terms of defining the semantics of the business and the data models. I think we'll move away from data model definition to business model definition by data ops and ultimately the data models will get derived from that. Yeah, that makes sense. Wow, that is a very concrete and compelling vision because it gives us a path from what's going on today. Yeah, yeah, it happens in steps like everything else. It's not going to, you're not going to wake up and go da-da-da-da, it's all there. It's not going to work so well. Well, another question along these lines. So we've got 60 years of investment in packaged applications or, you know, 50 years. And that, is that going to be- It changed a bit in that period of time, by the way. Well, different 50 years ago than they do today. But they don't go away. Like you said, it doesn't happen overnight and we don't trash them. I mean, we've still got, you know, mainframes running, airline reservations and banking, you know, operations. So my question is, as we build this semantic model, this digital twin of a business, to what extent do you encapsulate or not encapsulate, to what extent do you capture the capabilities of those applications in the semantic model versus just call out to them when you- More and more, I mean, I think it depends. It very much varies. At first, you're simply duplicating the semantics inside the semantic layer that exists inside the applications. Over time, that semantic layer can be used to execute more and more of what you're actually doing. And in fact, when you do that, there's the potential to dramatically improve performance of some things. Some things, it doesn't matter because the underlying application is doing a fine, fine job of it. But there are a number of places where people are looking at trying to solve a set of problems, problems that involve complex graph queries as an example, where you just, the tools to do this don't really exist today and people are seeing, and we've already seen some of this with the early customers with RAI, where they have an existing application that's often running on Spark. It's not working the way they want it to work. It's taking forever to finish. By moving it onto a knowledge graph platform to actually process it, it can dramatically improve the performance because you're able to leverage a set of algorithms that frankly are just not available to the average developer. I mean, these are being developed by PhD people and they're being applied in a generic way inside this data platform. And just like those algorithms, those set of algorithms that were created 40 years ago in the early days of the SQL databases have provided incredible leverage to the business developer. You don't have to rewrite all those queries yourself. You just issue a SQL command. We'll see that same kind of leverage as the semantic data platform and knowledge graph emerges. Let me follow that up with a question about where is value? So for decades, there were big companies starting with Oracle and then Microsoft was SQL server in managing the data and huge value in managing the process. What I'm hearing, and I'm curious about your perspective is this new data platform, the richness of this model seems like it will draw so much value from what once was in a packaged app and what once was in a data manager that it will be the 800 pound gorilla and there's less, okay. You're projecting a bit. You're projecting a bit because we've got a long way to go to get there. You know, those applications have been performance tuned for 50 years and we've not done any of that for this. But yes, I mean, over time, the grand vision of all of this, I mean, in a way, the Holy Grail is the executable model, right? That is the Holy Grail that we've been looking that some have been searching myself included for quite some time and it can be applied more and more, but it's not gonna replace because of the existing investment and everything else is not gonna replace things. I think the first place we'll start to see it is in these governance sorts of scenarios where we begin to, we search for areas within the enterprise where there are inconsistencies of algorithms, inconsistencies of results. At the same time, there is something like that. It causes horrible problems, you know, where one application or one group is coming up with one result and the other is coming up with a different result because they have a different, they simply have a different equation in place. Understanding those sorts of things and understanding what the desired state of the system is and performing desired state management where you seek to converge each of these systems to a consistent desired state. I think that's what we'll start to see a lot of. That sounds like you wanna share the semantics that might be in the BI semantics, data quality, entity resolution. Exactly. And I think that was defined in one place leveraged by all of these things, wouldn't it be? Yeah. Okay, that's compelling. And understood that it would take us, you know, forever to remove all the value which isn't gonna happen in applications or databases, but I'm thinking about where is value being added most in the future? It's in this model. Right. And you can't, I mean, you know, this is where, for example, if you've got tools that have existing metrics defined in them, I mean, those tools are probably gonna continue to leverage their code that's executing against that. But what you can do is make sure that those metrics defined in that tool matches the metric in the semantic layer. And it's consistent. And people aren't working with different equations which happens all the time. It happens all the time. Big problem. So I want to, being mindful of time, I wanna make sure we're on track here. And so as we hone in on this last part of our show, I wanna talk about the role of relational KG and imagining data and apps. And you spoke just a moment ago about governance and sort of the complexity and the challenges that are involved there with governance. So, you know, my first question is, how might a relational KG help customers build an extraction across data platforms? Well, I mean, there's so many problems you can't solve in governance today, governance day, that there's no data solution to solve. As I say, you know, the simple question, you know, I just fired Fred. What data did Fred have access to? Right. Very, very hard question, I mean, to answer today. And, you know, conceptually these solutions could provide answers to questions like that. I think by up-leveling these things, remember, I'm talking about desired state management where you define the state that you want, the desired state inside the semantic layer. And then the system looks at management, system looks at all the different parts of the data state to ensure that they're all operating consistently. That can provide a tremendous amount of value. Now, there's a long way to go from where we are today to what I just described, but that is essentially the kind of path that management products have undergone for many years. This is what we did years and years ago when we figured out how to manage Windows PCs. Every one of them was a semantic mess out there. I mean, every single Windows PC had its own registry and all that garbage. What we wanted to do is make sure they were all consistent in the way that an enterprise could make sure they were consistent in the way that they thought was important. And it's very similar techniques that need to be applied here. Yeah, that makes sense. What's the biggest technical risk? It's, you know, where my head goes is we've had 50 years of research improving SQL query optimizers and now we're doing a semantic query optimizer. And, you know, hopefully it won't take 50 years, you know. It won't take 50 years, no. So where is the risk? I didn't take 50 years before to do quite a lot either, though. I'm running many things. There were a lot of good solutions that started getting developed in the 80s and 90s. So, you know, I think the biggest risk is, frankly, just these things are very major projects. I mean, no one's ever built one of these things before on a relational knowledge graph. So there's many, many, many unanswered questions working through those questions in a way that is successful. There is some risk that relational AI will, you know, be a great proof of concept, but never be a, you know, the product that will actually solve the problems. In that case, it'll be some delay before somebody else comes along and gets it right. I completely believe this is the right thing to do. I mean, in my heart of hearts, I believe that this is where the world has to go. And it's simply a question of having the technical challenges associated with that answered in a way that is cohesive with a business solution that allows, you know, a company like Relational AI to be successful inside this environment. Right now, I feel very optimistic. I feel very optimistic. The team has solved some of the hardest problems, you know, which I mentioned earlier, the idea of the semantics that the developer is seeing. And we now have some very different views on that than we did as little as a year ago. And I feel very, very good about the progress that's being made, but it's not easy. It's not easy. And the real risk is that it's just gonna take longer than anyone thought and maybe, you know, maybe it has to, maybe we whiff it and somebody else has to come along, but no one to happen. Isn't that sort of the rule? Whenever you're building something, it always takes twice as long and costs at least twice as much. As an investor, I can tell you that's true. At least twice as much. So, you know, so what will it mean to have an integrated model of a business that's always being updated and always learning? I mean, that's really kind of an exciting concept to think about. Yeah, and then think about that in connection with the large language models and the future models that we're going to have, the multimodal models that we're gonna see in the next few years. It's really interesting. It's the foundation for the, you know, it's the foundation for, you know, really artificial general intelligence in some sense. You know, kind of just like humans, right? Constantly updating, embracing a mindset of always learning. I have, personally, I have four daughters, two of whom are grown and gone, but two of whom are high school seniors, kind of, you know, getting ready to go to college and all of that. And one of the things I'm constantly preaching in a way that only an annoying parent does is, you know, embrace continuous learning, always be curious, you know, regardless of what career path you go down, what you choose to study, you know, this is the key to success, is that constantly updating your operating system. And, you know, Bob, so much of your work has been centered on the people that are part of this equations and not just algorithms and machines behind the next wave of AI. And I feel like, you know, I've been talking about digital transformation and working with clients on their digital transformation journeys before we coined that term in the industry. And one of the things that I've always said from my soapbox is that, you know, digital transformation, effective digital transformation is not about technology. It's about the people. It's about the processes. And it's about the technology. And I think that, you know, based on what I've seen, based on what I've read in your book, that's something that you, I think, is a principle tenet of yours as well. And people play a big role here. It's all about the people. I mean, these things are not created. The people create all of these tools and they have, you know, all of the concerns and challenges and everything else that every other person has. So yeah, it's all about the people. A lot of brilliant people working on these things, but they have to work together and make it all happen. So as we wind down our show, my last question is if you have one piece of advice, and I know you have many pieces of advice, but if you have one key piece of advice that you would leave with our viewing or our listening audience as they're thinking about all of this, what is that advice? I mean, I continue to say that jump full in to the modern data stack, you know, choose one or more of these vendors, begin to build a solution, begin to put all your data in one place, you know, start to work to have a, you know, have a data operations team that is creating a consistent model, begin to define what are the semantics. I mean, even if you can't put it in a fancy new knowledge graph, you could still define the core business terms and put it in English. And that, by the way, is gonna go a long way. Because I think that one of the things that people, that these transformers will do is they'll take the English descriptions that people, that businesses create and use it to help define the underlying semantic model. But start working on this stuff. You gotta be in the middle of all this stuff right now and figure out what problems matter to you and your business, and then focus on working with vendors that are trying to solve that. You know, it's time to be in this space and everybody should be putting all of their data in one place, making it very, very easy to work with, ensuring they have the governance they need on it. I mean, these are all problems and opportunities that exist for everybody today. And the only way to get from here to there is to push your sleeves up and to get your hands dirty and to dive in. Jump in. Yeah, absolutely. Well, Bob Mungley, thank you so much for joining us today, George. It's always a pleasure to our viewing and listening audience on this Road to Intelligent Data Apps series. We're always happy to have you. Be sure and hit the subscribe button. And Bob, I know this isn't our first conversation and it won't be our last conversation, but we are so grateful for you taking time for us today. Well, I enjoyed it. Good conversation.