Confluent, Inc. (CFLT) Earnings Call Transcript & Summary

Okay. I don't know what to call this. I think we have a special session. This is a special session. Welcome to the special session. So I'm Michael Turits, an Enterprise Software Senior Research Analyst here at KeyBanc. It's a fun and special session. We're here to talk about Confluent and data streaming and Apache Kafka. And we have with us today, Jay Kreps, immediately to my left. Jay is the CEO and Co-Founder of Confluent, ticker CFLT. We have coverage of that. We were on the IPO here at KeyBanc. Jay will tell you a little bit about his background. But he was formerly at LinkedIn, where he was an original author of the project called Apache Kafka, and then, as I said, co-founder of Confluent. And then in addition to that, of course, we now have with us KeyBanc's Chief Data Officer, Mike Onders, merely to his left; and then Scott Tucker. You just told me what to call you by role, but you've got to -- that's Senior Business Technology Executive, Open Banking, Head of Kafka Messaging Technology. Is there nothing...

You can add some more words in there, if you want.

Yes. He's our hands-on Kafka guy. And I like the fact that's Open Bank, maybe you can talk a little bit about that. But in any case, thank you. Thank you all very much for being here. So I want to start and say the idea is here, twofold. One is for Jay to tell you a little bit about the -- where -- why was it the Kafka came into being, how he brought it there, how he sees a vision for Kafka and for Confluent more broadly. But then, two, talk about how we're implementing Kafka and Confluent here at KeyBanc.

So we'll start with you, Jay, and I would say, let's do that. Let's give us an overview of Kafka. And by the way, I forgot exactly where the name came from. But some of you -- I had this 3 years, but I do actually have a PhD in comparative literature. Kafka was a writer, so thanks for doing that.

It's obviously well placed with this one...

Perfect. It's perfect.

We're going to have the existential...

The existential, there we go. But a more optimistic view to encompass a little dark, but I think...

That's right. That's right. Well, so as you kind of hinted, I was at LinkedIn, and that's where this open-source project was originally created. The idea was to focus on data in motion. And so like what does that mean? Well, like most data technology, had really been oriented around how do I store a little pile of data? How do I look up the right bits at the right time for one application? That's kind of the hallmark of databases. A ton of incredible research went into that. That was a very sophisticated platform. But if you look at an organization like LinkedIn, it wasn't like we had one database. We had hundreds of databases and hundreds of applications that all had to kind of come together into one company in service and set process.

Just of your service for years, just for framing. So when was it you started at LinkedIn? What years were you there? What were you starting to think of about?

Yes, I was there from about 2007, and I was involved in a lot of the next-generation infrastructure, analytics, kind of machine learning use cases. I was actually brought in to kind of help use the data, but then ended up more in the infrastructure layer because that was kind of the first step to really being able to harness it. So yes, a lot of the early work I did was on scaling databases there. But one of the things I realized right away was, hey, if we want to take advantage of the data we have, it's not just about scaling this application to that application, it's about how it actually comes together. How does data flow between things? How can we act on the data we have.

Can I throw in the real-time buzzword?

You can throw the real-time buzzword.

Okay. Real time. [indiscernible]

Yes, yes, yes. So there was one fact that was really weird to me, which was, at the end of the day, we would pull data out of all these systems, and we would ship it to like this what we would now call a data a lake and data warehouse. And then we'd run this batch processing on it, and we would come up with some results, some of which we were trying to feed back into this product. And it was really hard to do that because if you think about it, the customers who were there at the time who generated that data, they may not be back the next day. And so you've kind of done all this processing, and they're not even there for it. And so it didn't really make sense. We have this business that kind of operated all the time in real time. And then a lot of the processing technology, the most sophisticated use of data was not and could not be because of technological limitations. And then if you think about it, that's kind of how all companies are. Pretty much all of them work here in reality and real-time continuously. And it's kind of a weird...

They do now. They probably didn't at 1 point.

Yes. No, well, I think even humans work continuously in real time. It's this weird outgrowth of mainframe technology that's just kind of batch processing mindset. And it's taken a while to shed it because there's a lot of technological complexity to doing that well. But that's what's happened with the rise of Kafka and a lot of the streaming is the ability to think about data as something that's always evolving and happening and think about the processing as something that happens with it. And so early on this was an internal layer in LinkedIn. We released it as open source to really resounding...

[indiscernible] also?

I think it was probably around 2011, 2012, really to resounding silence because nobody had any idea what...

It was not exciting.

Yes. So we thought it was going to be like the next best things to sliced bread. Nobody knew what we were talking about. But we spent some time talking to some of the other tech companies, and this became really the kind of foundational layer for all the flow of data and the harnessing of data in that kind of next generation of tech companies, the Ubers and Airbnbs and Netflixs. And as this kind of movement around streaming started to grow, we realized, "Hey, this isn't unique to tech companies." Actually, in many ways, harnessing data is even more important and more challenging in some of the larger enterprises where they have more software systems, more investments more lines of business, more basically diversity and [ sprawl ] that they have to put back together. And the pressure on them is very much the same, to have a digital side of the business that interacts with customers, to be able to operate more efficiently. And that was when we left to start Confluent and really kind of take it out to the broad market, and that was in 2014.

So let me ask you 2 questions then. What is it -- is there something about -- this one is a very geeky question and maybe one is more of a business. Because there's something about what we think of as cloud-native architectures or modern architectures that requires this real-time data treatment that Kafka enables, a; and then b, from a customer perspective, like end customer, like we'll get to it, obviously, KeyBanc's customers, what is in the way of what we're looking for that requires this kind of real-time data? So an architectural question and then jump right over to a customer end-user perspective.

Yes, yes. Architecturally, this definitely is an important layer in a lot of the microservices architectures, which internally is kind of the more modern thing people tend to build towards, and it helps to plug together lots of disparate applications. But you don't necessarily need that to take advantage of it. Even organizations, which have no micro services, have lots of different systems with data that need to come together. And so, yes, in a sense, one of the interesting things for Confluent that's maybe different from a lot of tech companies is, we tend to not be coming to customers and telling them to, "Hey, rip out everything and rewrite it with us." Very much our story is about connecting some of the older things, the mainframes, relational databases, things that have important data that run big parts of the business and connect that out into some of the newer applications that are driving next-gen customer experience or doing some of the new initiatives that require new software, really being able to connect that together is an important part of what we do. And then for customers, yes, that's very much the goal is being able to bridge all that, do it in real time, being able to bridge between on-premise systems and cloud systems, being able to bridge between old and new and being able to really bring to bear the data that companies have in the right way, in the right -- at the right time to try and make their business better, serve their customers better, be more efficient, all those things.

I guess where I was leading is just like me as like someone going online. What do I need as a customer these days in terms of my customer experience that says, "Man, you've got to have something like Kafka delivering this on the bat?"

Yes, yes. Well, you wouldn't experience this all the time when you don't have it, right? So you show up to any organization or company that you work with, and you expect the interaction to have full context on what you do with them. What kind of a customer are you? Which parts of that business do you interact with? What is it that might be relevant that you need to know? What is not relevant? And when you don't get that, when you get things that are out of sync that aren't in line with what you would expect, you're kind of frustrated. And it just doesn't seem like a modern digital customer experience.

I hope Newark Airport and United Airlines is a customer because my experience in the last month tells me that they're not doing this.

Yes, yes. I would say that, that's actually an area that's definitely started to invest in this area and really needs it. These are industries that are older.

I mean, seriously, so I'm going to get -- love United, big user, but this has been a terrible couple of months for air travel. And I was -- in the airport, I'm sure some of you had this experience, but what was on the board and what was on my phone and what I was getting from customer service were all 3 things. My flight that had been canceled the night before was listed as boarding. So in any case...

Yes, yes. It's a perfect example of an industry that is extremely real time. It's all about flights and the dispatching of baggage, passengers, what's available, what's not available. So it's all very real time, but it was all built on very old technology a long time ago. And it doesn't quite work as well as you would expect it to for something in the modern world. And indeed, that investment is happening. And I think it significantly improves the customer experience, and it significantly improves their operations. Because when they don't know what's available, they end up padding out. You have to have extra -- this happens in retail where you end up with extra inventory. It ends up in travel or maybe you end up with unsold seats. It happens across the board where you're not really reacting to the full set of information you have or you're not reacting quickly to what's happening.

Last question I have before I move over to our guys here. Open source. So Kafka is an Apache open-source project. You started Confluent. This is a big, big question, this whole question of monetizing, commercializing open source. I don't know. I just -- I mean, a couple of things I can remember. My son is 23 and a software engineer, but I remember when I was rolling out of Red Hat years ago and tried to explain to him because he was curious how people could make money selling free software. And I feel like I explained it to him, but there's lots of different ways to do that. So what is it -- and sometimes it makes sense, sometimes it doesn't. For example, we don't really actually have that many Kubernetes companies out there at the moment.

That's right. That's right.

But we do now have an important company in Confluent selling Apache and monetizing Apache Kafka and broader capabilities. What is it about Apache Kafka that you looked at it and said, "Hey, good, did it open source? No. I can build a company around this. Why can you add value around this project and around associated types of technologies?

Yes. Certainly, as we were getting started, I think there was a lot of people who didn't believe the open-source companies were very viable. But there was really an evolution of these models. And so if you look at what a company like Confluent does, it's very different from Red Hat. We're not selling support services around the open source. We really have a very differentiated piece of software that we license, and we have a cloud service, which is amazing and world-class. And those are really significant investments in proprietary technology, which allow us to have an edge and just be much better in terms of TCO than you would be with the open source, much better in terms of the feature set and experience. And so then that value proposition becomes very compelling because this is something where maybe you're -- the open-source software could be free, but you're going to spend a lot on cloud infrastructure, on people. The advantage of these managed cloud services is to roll up all of that and then take away the whole problem and just do it well and say, "Hey, we're going to come in, we're going to make sure that you have world-class operations at scale. We're going to make it so that you can just elastically consume what you need. And by the way, we're going to bring to bear a product experience that's 100x better than what you would have with some internal infrastructure offering." And that's actually really compelling to customers. That often customers feel like they're kind of at the mercy of these infrastructure layers, they can only move as fast as their infrastructure teams. Getting something like that allows customers to really move quickly. And I think that's what's really been a tailwind is for us as a business and for all these next-generation technology layers.

Yes. Okay. So let's flip over to KeyBanc. So Again, Mike and Scott, maybe you can -- I wrote this question up and I said, can you describe our history with both Kafka open source and with Confluent. But I think we did come to them both at about the same time, right? I don't think we -- were we ever purely open source on Kafka?

So we did have 1 use case to start that is open source before we got engaged with Confluent. It was around log aggregation. So we did that, so gathering those logs, enriching the data and then putting them in a logstash. So we were using it for that. But our first real use case across the bank was with Confluent.

All right. So why don't you -- I don't know if you want to handle it Scott, or you want to handle it, Mike, but talk about our history, therefore, with starting from that, both with Kafka as open source and Confluent. And we didn't really touch on this when we're talking a minute ago, Jay, about why we decided that Kafka was important as opposed to older, let's call, legacy messaging architectures, like MQ messaging. There are plenty of others going all the way back to what we just call message-oriented middleware, back to TIBCO and further back to webMethods and all this kind of stuff. So what was it in terms that we thought that we needed to see in Kafka that was important to us even though we had some of these other capabilities?

So a lot of it is around -- so there's legacy technologies, whether it's MQ, whether it's ETL batch, right? They serve specific purposes for us, but [ moderately ], it's point to point. What we were seeing in our business is a bigger need to get events across the organization that you would then react to in different ways. So as a simple example, somebody opens an account. We both want to be able to communicate to them via an e-mail notification or text message as well as update some of our internal systems to be ready for them to onboarding online banking and then maybe send that to our fraud system to make sure that we do the right checks there. So there was multiple needs. And instead of having kind of that one-to-one integration that we had with legacy integrations, integration technologies, we decided, hey, this Pub/Sub, this data streaming is more beneficial for us. So you create...

Let's stop there because that's an important differentiation, right? So there was real-time messaging going back, I don't know, 30 years, if you will. So you mentioned Pub/Sub really quickly. And also I've said that we get points for saying central nervous system. So if your central nervous system hub, nervous system is core. So in terms of this architecture that Kafka has is differentiated, talk a little bit about this Pub/Sub architecture, the centrality of Kafka within it and. Why that seemed important versus these other technologies that we have?

We have macro. It's a little bit of macro. And kind of tying it to what Jay said, right? As a bank, we have 1,000 applications, 300 of them are already SaaS or ASPs. So they're not in our data center, 300 are vendor packages in our data center and about another 300 are custom. All of our legacy core accounting were mainframe apps, right? And MQ is the way to get to the mainframe for the longest period of time with guaranteed messaging. Then we stack webMethods in front of that to talk to distributed systems that then still have to go to MQ. He's on like, "Hey, if you look at a wire processing, it go from a wire origination system that was distributed, to webMethods, to MQ to talk to a mainframe, back to an MQ, back to webMethods. Well, what's happening, if you talk about the customer experience right now, many of you -- like how many you get alerts by your credit card all the time, right, especially if your kids are using your credit cards, right? You're getting an alert where they're at, and you expect that now. I was at a gas station, and I've used a credit card my entire vacation. But I've stopped at a Flying J, and I get this message, "Hey, did you just buy $151 of gas at Flying J?" I didn't put the thing in my car yet, which -- but the correct answer was no. But I knew if I said no, they'd lock my credit card, but I didn't buy $151 of gas. But the consumers are expecting alerts real time. Well, our legacy core accounting systems were batch, and so you're struggling this legacy in real time. And now you've got multiple systems that want that data all at the same time. So if you do a transaction, it's got to go through the fraud system. It's going to go the e-mail system. It's going to go to alerting engine because the customer wants to be alerted. It's got to go to core accounting system. It's got to go to the data supply chain to get registered. So now you've got 6, 7, 8 systems that don't want that same data. and the Pub/Sub isn't better than saying, "Oh, I'm going to do point-to-point and MQ here." And the other thing we're finding, as core modernization happens, those cores are now getting to be real-time event-based, where, before, it was all batch, batch calculations, you got a statement once a month. But now people expect, which is when we started open banking was, our fintechs and our partners want that data realtime too, right? And so they don't want to wait for a month-end statement. They want that data flowing back to their ERP system the same way we want it. So it's really sprawling out the messaging across many platforms. So that's kind of the backdrop. And then he did on webMethods and the whole messaging architecture. So you start looking at that and you say, Kafka architecture is a better way to solve this problem, right?

And it's also more efficient from a delivery standpoint, right? So you build it once to put the messages in Kafka and then everybody comes and consumes them versus the point-to-point, where we're building specific integrations with those 6 or 7 systems, right? So it makes it a lot more efficient in our delivery and keeps our costs down and moves this forward much faster.

Where -- from a broader perspective, what is the overlay of shares that we, at KeyBanc, are moving cloud? And we're moving primarily to GCP to Google Cloud Platform. Just is there -- how is what we do with Kafka and Confluent? How does that fit in with that migration and with our use of things like BigQuery and Google?

Yes, all of our data -- we saw our data migration 2 years ago. So we moved Teradata to Google, and we turned off Teradata. Our on-premise data lake will be shut down at the end of this year. So all of our data is [ all on ] analytics. But as I mentioned, SaaS vendors are moving all over. So we use Adobe in the cloud. Actimize is going to the cloud. So you've got these -- everyone moving in different directions, and you still need this messaging architecture to connect this across. So if we're going to do real-time Adobe, next best action, they need data real time to know what's an expect action. So you got to flow through there. So you're trying to connect multi-cloud to a lot of people. And the complexity is getting harder and harder. Before, it was all in your data center, all on-prem, that's not the state where the industry is going. So this interconnect architecture and Pub/Sub, where multiple platforms that might be in multiple locations want that data at the same time, it's driving that messaging architecture.

Did we consider any alternatives to Kafka? I mean, there are other technologies out there. Google has a Pub/Sub offering. There's a competitor called Redpanda. There is a competitive technology called Pulsar. Did we look at any of these?

We did. So it was about 3 years ago when we went down and started this journey. So we did look at all the players at that point in time. Some of them are a little bit more mature now than they were back then. But when we really looked at it, what we liked with Kafka and with Confluent was the architecture fit, what we needed. There was a lot of excitement and buying a lot of companies using Kafka, the open source, and moving to Confluent. So we felt like we were with an industry leader that can help us. And the road map, we really liked the road map of where Jay and team were taking the technology, so that really kind of got us sunk in to go there. It's something we continually see, as anybody does, and we continue to look at who's out there and who's doing what. But I think Jay and team have done a great job, especially with Confluent Cloud, just continue to extend the capabilities that make it easier and easier for us.

And Jay brought this up, we are -- for all the vendors we worked with, moving to them, managing their own software, we don't want to manage the servers. We don't want to manage the security patches. We don't want to manage the hardware. And we want to take advantage of elastic compute because the stuff is going to grow really fast. And if you do a merger, you can expand on a dime. So it's on our road map. I think Jay has a slide, I'm going to say this right, where you start off just doing a POC on Kafka then and you start replacing a lot of your core primary messaging, and that's what we're at. We're replacing our fraud interconnect with Kafka and some of our onboarding, processing and eventing and alerting with Kafka. And then it will become a mission-critical, business-critical application. We'll move it to the cloud. Eventually, it will become our central nervous system at the bank.

Yes. So let's -- I think we've often talked about some of these issues a little bit, but I'll ask you the question. Why do we pay for Kafka? Why do we pay Confluent? Why do we -- you said it started with open source, Apache Kafka, what are the reasons where do you see them? And at the moment, we're not doing Kafka. We are not doing Confluent Cloud. So we're already paying for it even without moving to the cloud. So what are the reasons that we were paying for and are paying for it even without going to the cloud, and then on top of that, why cloud might be something else that's commercially attractive to us?

Yes. So Jay touched on this earlier. So it's not just the support of it, right? They didn't just take open-source Kafka and say, we'll support it for you. They've built a lot of capabilities on top of that. They're very specific to Confluent. For example, being able to do replication and handle DR situations and that, they've built the components to help us do that. If we were to go open source and really handle that, we'd have to build all that ourselves. So there's a lot that we found valuable there. And obviously, as a large corporation, having the support of the experts is something we enjoy that comfort as well, right? So if we were a much smaller company, you might get away with -- we'll just do open source, and if someone breaks us out that big of a deal. But as we continue to make this more and more part of our ecosystem, then if bad things happen, it's a bigger impact across our customer base. So having the folks there that are experts that can help us along the way is great. And it's more than just kind of supporting it. They work with us on a weekly basis about our use cases and help us understand what's a good use case, what's not. They work with our application teams to help them get more integrated in using Kafka. So there's a lot of benefit that they provide to us that you just wouldn't get on open source.

So actually, that's a good transition. Let's talk use cases. We say what -- from a really end customer point of view -- well, some of them might be more tactical, but some of them I think really has use cases for KeyBanc's customers. What are the places -- where do we start in terms of use cases? What have we added? And where might we go longer term in terms of the use cases? How broad could this be in terms of use case deployment at KeyBanc?

Yes. So I can get very broad. Where we started with this is really around customer and transactional data, things like opening accounts and changes to customer profile that we're using to drive some of our learning and also internal system updates. So we kind of started there. As Mike mentioned, we're now moving into our fraud interconnect and updating that, which, I mean, a client doesn't necessarily, on a day-to-day basis, see that. But when the fraud happens and we catch it and reach out to them and say, "Hey, this wasn't you. Let's help you," they're very glad that we do that. So those are a couple of areas that we've started in. Where we want to take it is really getting in the customer behavior. So not just transaction, but we see the behavior of them coming into online banking or going to a branch and doing certain activities. Then it helps us better understand what's going on with them and maybe better be able to react to that and help them where they need to be helped as opposed to -- we've all had these experiences, right? You call in to get support from your bank or from another company, and you get passed around and no one has the [ context ] and they can't help you. So much better if when they call in, you could say, "Hey, are you calling about this account you were just trying to open? I saw that you were doing this 10 minutes ago or an hour ago. Is this the thing you need help with?" And then we have the context already ready, and we can help them more quickly and get them on their way.

I think the other big one, they'll have it, because I do run the Chief Data Officer and wear a couple of different other has. But most of our data, supply chain data analytics is batch-oriented, moving nightly through the models and into mods for analytics, that's all moving towards real time, too. So as the core systems become real-time in event, we no longer will have to do batch, full-volume batch, delta processing rather than just changing the data on the fly. And I think where Jay is going, with streaming analytics, then that becomes more possible, right? So if we're flowing the data in real time, we can analyze it in real time, we can run models in real time, we can detect fraud faster. The faster we detect fraud, the faster we prevent it, the less loss we have in fraud, right? So all that stuff is moving in motion. We can do a lot more stuff for the client and help them out as well as lower our fraud costs and detect that faster, right? Because a lot of that stuff happens batch, right? An e-mail doesn't happen real time. It happens overnight, most of the time.

And in the future, where do you think the future use cases could possibly be that we haven't explored yet?

I think what I've said, I think moving all our data to being in motion with analytics being available on that pipe, that's the future, and we've got work to do to get there, as well as working with the apps that need to be able to push that data more real time than batch, right?

I wanted to talk about go-to-market and ask Jay about that in a minute. But let's take a little bit of a break and see if there are any questions from the audience at this point. It was really technical discussion at this point, but -- yes?

Just about the last comment you made about you were more than real time and then shutting off the on-prem. How do you think about your kind of your costs as you go more real time, use more data? And then [indiscernible].

It depends. I mean when we went full batch ETL, that takes a heavy load to run full extracts and then compare last -- this night's extract to last night's extract to get the delta processing that flow through. So it's a t rade-off of where you're going to consume that compute, right? And I think you might find it less expensive to stream in real time than to try to move full batch processing in that kind of a model, right? We do some of it today. So certain transactions that hit our core, even though our core only process at night, we have kind of a shadow database that stimulates real time that gives you a pending transaction. But that stuff will flow to the alert engine so that if you say I want to know if a payment hits my account or if a deduction hit it, that will flow out kind of real time today, even though the batch will process at night and then sync up. So I don't know -- I think it's our trade-off of where the compute is happening, that would be my view.

How real time is real time [indiscernible].

Yes. So I would say, it's dependent on the use case. In many use cases, it's in milliseconds, right, because we can move that fast. But there are use cases where the need is only within seconds. And that really comes down to a lot as the -- on the consuming side of the equation. So we'll get the messages there very quickly. It's just how timely do they get consumed, and that's really based off of the systems that they are integrating.

Yes?

What percent of 1 is the use case? [indiscernible]

That's a really good question. I don't know that we thought about like, as a percentage, how much, but I would say there's a fairly significant amount. Because every time we're looking at building these, traditionally, you would have built all of them one-to-one. So what we're doing right now is we're trying to replace them in the fraud space and move forward. I would say, bare minimum, you're talking in the 25%, 30%, and that's a conservative low, right? I don't want to oversell and say everything is going to be replaced by this. But I think what -- where is more important is where we enhance. So there may still be one-to-one interactions that happen between systems. But if we also put that same message into Kafka, now it becomes more available for everybody else. So I don't replace that one, but now I have enhanced it to now others can use it this [ way ].

Yes, I was going to ask even more broadly like not just replacing like one messaging, but what else gets replaced at KeyBanc in terms of the IT stack? So is it ETL, is it database?

MQ is in our sights, right?

Which is one-to-one messaging...

Which is one-to-one. And I think -- because I think where we see a lot of that MQ is we know other systems want that same data, right? That's for sure. I don't know about all ETL, but if the store system can support eventing in real time, we would plug it into Kafka rather than run it through a batch ETL process. But I think we're seeing more and more of our vendors start to support Kafka connectors, which then helps us. So we were working with Actimize trying -- or we're working with Dovetail, our wire processing system; trying to talk to Bridger, OFAC checking; and they're both now starting to support Kafka connectors, where, before, that was a webMethods and MQ kind of messaging. So the more the vendor support to Kafka, the easier it is for us to plug it into our overall ecosystem, right?

Yes, this is one of the bigger changes happening in the larger ecosystem is, for a long time, there was no technology to do real-time data movement and processing at that kind of scale that could handle workloads like ETL. And then there's also not integration since that doesn't exist. And so what's happened really in the last few years is kind of spinning that up, where technology gets better, there's more integration, technology gets better, there's more integration...

And the integration takes place a lot around Kafka because it has that presence.

Yes. So I think what we're seeing happen is there were a bunch of fragmented technologies around data movement, right? So messaging systems were these kind of application-to-application, point-to-point real-time. ETL was this kind of batch-oriented, but high volume, high-processing load to usually a relational data warehouse, but sometimes something else. There's 2 or 3 other categories of application integration. They all had kind of these weird pros and cons. And I think the value is exactly what's been described here of having something where you can kind of publish the data once, have it go to many things and have it be scalable enough, real time enough, sophisticated enough and processing that you can kind of meet the needs broadly of these different use cases and not have to resend the same data 5 times in 5 ways.

And yes, I mean the other thing, I mean, this was a real story. A wire system had an issue, but if you traced it, it went from the wire system to webMethods to MQ to OFAC to MQ to webMethods, back to wired, [ direct ] it to notify, and it wasn't working. But every one of those had their own logs. So you had to chase log by log by log by log trying to figure out where did it stop and [ light ] a stop versus having a single Pub/Sub, where you could see who picked it up, when did they pick it up, when did they put it back if there was a reply. Like that architecture, we think, will be significantly streamlined and better to operate than like going hop-hop-hop and then trying to trace it through multiple logs, right, that weren't connected.

So I want to bring up go to market. And I feel like -- so I don't know, [ assuming ] landed and expanded. A lot of companies I saw they have a land-and-expand model. It's like, great. That's wonderful, then there's a transition. As opposed to like not add customers and have the other's [ contract ] model. But in any case, I feel like landing is relatively easy for Confluent and Kafka to the extent that people in technology know about Kafka. They might have 1 use case. But what -- I don't know, Jay, talk to me about how you think about that for Confluent? In other words, how much emphasis do you put on landing? And for me, I'm very interested in the expand part of that because I see those initial use cases. But how do you go about helping people say, "Oh, you can do this, and you can do this, here's how we can enable that."

Yes. That's exactly right. So the way we thought about it is our goal is to really get the land stage, get the volume up. There's a lot of open-source Kafka. We think we have a great offering that we would love people to start with, with their first experience. Our goal is to make that as low [indiscernible] as possible.

So hit those people who have got some Kafka to begin with?

Yes, yes. We don't need to go take over all the usage of data in the organization just to serve that 1 use case as it comes around. And then as you expand and this grows to have a more strategic role in the company, where it's connecting many different teams, you need to have a more senior relationship. You need the people who are plotting out architecture and making decisions across the company to understand what it's good for and what it's not. You need to help guide how that progresses. And so yes, the goal for our team at the low end is make it easier and faster and better to get going. And then as we go, it's about how can we help guide the customer and make sure that they're successful with this broadly, and it continues to spread and become a really successful data platform for them over time. And so yes, maybe that's the same as you would hear for any company, but it's a little bit unique in the streaming area because, to some extent, the platform gets more valuable as there's more streams in it. Because the data itself is reusable, as you start to have these core things that the business does available, you get more and more applications that want to attach to that and use it. And so if we guide it well, it becomes a thing that kind of takes on with a life of its own.

So over the last couple of years, as you've become a bigger company, as your customers are already starting to get more widespread with Kafka, what have you done in terms of that go-to-market organization? In other words, have you developed customer success people, more -- you have more post-implementation capabilities, you verticalized. What have you done to enable those?

Yes, there's been, I think, significant maturity on our side. We're trying to help customers be successful. There's some amount of grouping and going after a segment. So we knew how to care for different parts of the market differently, more attention for larger customers as they get to scale, a much more of a kind of prescriptive methodology, like now that we've seen a lot of companies do this successfully, we want to help people get on to that path to success. And yes, that's been a very significant effort for us, and I think quite successful. I think the test of this stuff is always in the harder times in the market. That's when you see how well you've done by your customers. Are they really getting value out of your solution, and they're not, is when money is tight. And I've been really proud of our performance through what's a fair amount of pressure on tech and tech spend over the last, whatever you want to call it, 9 months plus. We've done really well. And our NRR has held up. Retention has held up. The business has done really well, and that's kind of people voting with their dollars in terms of what they really need and what they really don't.

We're worked in towards the end, but I want to make sure we hit the generic topic. So let's ask our guys internally here. So where are we in terms of GenAI initiatives within the firm? And how is that influencing, Mike and Scott, what we're thinking about in terms of our data strategy and possibly what we might be doing with Kafka?

Well, we said there can't be a session here without a GenAI question, right?

Can't be.

Hopefully -- hope you all went to the breakfast keynote, right, all about GenAI.

I'm doing another one right after. So...

So what are we doing? We're blocking with at key. Technically, that was the first thing...

You're blocking it less, by the way. I couldn't get any website 3 weeks ago with a .ai domain name. A few have opened up. So I appreciate that.

Yes. So when it first came out, security said, we don't know much about it. We have concerns about intellectual capital. Our legal team had a lot of concerns. So they just shut down anything that said GenAI. But internally, we've created an advisory group, legal is in there, compliance, our tech teams. We've changed our appropriate use policy so that employees use it. They're, at least, a help to the policy. We've opened up a team to do POCs. So we're working both with Microsoft, the OpenAI that Microsoft is licensing as well as what Google is doing, and collecting use cases from across the bank. I think what I heard this morning, I think, is relevant to key. It is -- there's a lot more problem within the bank that have to do with structured data than there are that have to do with unstructured content generation, right? So I don't think so Silicon Valley Bank crashed because they didn't have GenAI, right? I think interest rate risk management has -- all that stuff is structured data analytics, and I think there's still a lot of room for banks to leverage AI in general. I do think that what was said this morning that you can take sub-optimal people and make them better if they're having it. So I think of it more as augmented AI rather than generative. So if your job requires you to generate content or summarize content, you can be better with generative AI. I think the 1 use case that wasn't really spoken about this morning, I was surprised, is to assist our developers, right? I think it's really going to help bring subpar developers up better, help you code faster, find bugs faster. And I think that's something that I didn't really hear, but that's one of the use cases we're looking at inside the bank, too.

All right. So maybe I'll pass it over to you, Jay, because you had an Analyst Day, geez, it was more than a month ago now, it's a while ago? This is summer.

Yes, something like that.

All right. It's in New York, it's fun. So talk about where you think that Kafka and Confluent fit in to like, let's call it, the emerging GenAI stack?

Yes. Yes. I think I hear a lot of similar stories. Customers are looking at where they can put this into practice. A lot of it is kind of augmenting people's work. That's usually a combination of bringing together a pretty smart language model and some of the data they have in their organization. And so we're really in the supply chain for that data about the organization. And so that can be in the form of some kind of support or customer agent that's helping and is available externally. It can be some kind of an internal tool that helps the people have the right answer with less training. We're really that supply chain for the company's data to make sure that it's there at prompt time, it's up to date with what the customer has actually done. It may not be obvious, but that's particularly important for some of these use cases. The most frustrating thing is if you're interacting with some chatbot that's telling you about your state of your account yesterday, right? Like obviously, the reason you're interacting now is because of something you are trying to do right now. And so yes, we have customers very much in that mode. And then some use cases around the processing of data that -- text data that can be done kind of asynchronously. So those are some of the areas where we've seen adoption. And I think, generally, even prior to the GenAI use case, it's going back to the structured prediction. This was one of the original motivations for Kafka. Like I said, I kind of came in to run these analytics in machine learning, use cases for data at LinkedIn. The first thing we had to do is figure out how to get all the data, get it to be correct, get it to be up to date and fold it back into some of the user experience. And in a sense, the GenAI stuff, what I think it does is it emphasizes that kind of real-time prompt inference time side of things more. And it opens up this technology in a significant way to businesses without having to build these kind of intricate custom models that are handled for that 1 problem. And so yes, I think that's going to be certainly a tailwind for Confluent and for the modernization of data architecture just to help companies harness their data in this way.

So it's your view that, that need for driving more proprietary data, real-time data into the query process with GenAI model, that will drive more demand for real-time [ data ]?

Yes, I think that's right. Now I think that hits as this stuff starts to turn into real workloads internally, right? And it sounds like, for you guys, that's kind of -- the process is starting, but it's not quite there. That's when I think we feel the full impact, probably both in terms of the value for you guys, but also in terms of the kind of [indiscernible]

I think my big analogy is J.A.R.V.I.S. from Iron Man, right? I mean Iron Man had J.A.R.V.I.S. there to talk to all the time. So I think that GenAI is going to make voice as an interface much more comfortable for consumers. And this -- and if they're using voice to talk more, they're going to ask for more information more frequently, which will drive the need for more demand for data in real time, more analytics. So you can get in your car and talk to -- I think people get much more comfortable -- if they're more comfortable talking to Siri and Alexa, it's just going to get better and better. And that conversational will happen, which they'll be asking for more data more frequently than they do today. Because they're not going to call the call center until they can find the time to call them and all that stuff, right?

So is that demand for more real-time data and [ inference on ], is that enough to be an incremental revenue driver or growth driver? Or do you also think that you could have some kind of direct monetization or SKU relative?

Yes, yes. I mean, I think the big force is that kind of data supply chain, and that's a big thing, I think. There's more investments we're making to help augment that, make it easier. Do we connect into that ecosystem in the right way? Can we support the right kind of processing of that data and our stream process? And there's a lot that we can do to accelerate that. But nonetheless, yes, that data supply chain is one of the critical pieces for this whole movement around data.

So I was going to ask you this question, which we're asking everybody, serves as a poll question. Do you think that the incremental revenue growth from GenAI of your business comes second half of this year, first half of next year, second half of next year or '25 and beyond?

Yes. I would say next year is when we'll start to feel it. I mean, I feel like the tendency [indiscernible]

Sometime next year? Beginning, first half, second half?

Yes, I mean, it's hard to tell, and it depends on what volume. I mean we have real production use cases today. So if you were like, hey, when are you feeling the impact? I suppose we're feeling some impact now. When is it moving large numbers in large ways? That one's a little harder to call. But I do think people tend to underestimate the impact and overestimate the speed that it comes for these kind of bigger technological shifts. Like how quickly can you reorient complex interactions in a bank to take advantage of this? It takes time, right? And so like when does the bulk of the value for KeyBanc or Confluent come in? It's coming when it's doing something real in production, that's kind of when we're going to feel it. And that will take some time. There will be other companies that maybe can be a little bit faster and looser. Maybe they get there a little bit quicker. But I still think it's not like a second half of this year where we start to feel the big impact. I think the companies that will feel that will be the ones that are kind of earlier in that cycle, right, where maybe you're buying something from OpenAI or some of the consumer applications that can jump a little faster. I think the enterprise use of step does have kind of a slightly longer ramp, but a lot of value behind it when it does.

Okay. 45 minutes. That was fun. Thanks, guys.

Thank you.

Thanks, Jay. Thanks, Mike. Thanks, Scott.