Listen on
IBM’s $11 billion acquisition of Confluent signals a fundamental shift in how large enterprises will approach real-time data. This is not just a major transaction; it reshapes the market for streaming data infrastructure, impacting strategic decisions for data leaders building next-generation AI and operational systems. Understanding IBM’s motivation for such a significant investment clarifies the future trajectory of enterprise data architecture.
CorrDyn Principal James Winegar analyzes the deal with host Ross Katz, offering a critical perspective on its implications. They discuss what this acquisition means for both IBM’s existing enterprise customers and the broader data ecosystem, particularly concerning open-source Kafka’s future. The conversation also examines the practical applications—and inherent costs—of streaming data, challenging common assumptions about the urgency of “agentic commerce” and other real-time use cases.
Key Takeaways
IBM targets enterprise AI and mainframe modernization with Confluent.
IBM’s willingness to pay an $11 billion premium for Confluent underscores its strategic intent to expand real-time data capabilities across its vast enterprise client base. The acquisition integrates Confluent’s streaming platform directly into hybrid cloud environments and mainframe modernization efforts, providing low-latency data necessary for advanced AI workloads. This move strengthens IBM’s position as a vendor providing complete infrastructure solutions for highly regulated, large-scale operations.
Real-time data value depends on decision-making speed, not just AI integration.
While “agentic AI” often suggests an inherent need for real-time data, its true value depends on the speed of business decisions. For applications like e-commerce checkout flows, low-latency data makes immediate human interactions more effective, driving conversion. However, if decisions occur over days or weeks, investing in costly real-time infrastructure becomes inefficient. Leaders must tie real-time infrastructure investment to specific, fast-moving business outcomes.
Open-core Kafka’s future innovation may consolidate under managed offerings.
Confluent, as the company behind open-source Kafka, defined the standard for real-time data movement. With IBM’s acquisition, the incentive shifts towards expanding the managed Confluent platform and its add-ons for enterprise customers, potentially slowing innovation contributions to the open-source core. While open-source Kafka will remain the baseline API, future advanced features and integrated tooling will likely come from vendor-specific managed services, impacting data teams relying solely on open-source solutions.
Consolidation aims to provide single-vendor, cross-cloud data ecosystems for large clients.
IBM’s strategy, visible in acquisitions like Red Hat and HashiCorp, positions it to offer integrated, end-to-end data ecosystems across hybrid and multi-cloud environments. The Confluent acquisition extends this strategy into real-time streaming, allowing IBM to provide a standardized, compliant platform that avoids vendor lock-in to specific hyperscalers while deepening its own enterprise client relationships. This approach simplifies complex data infrastructure management for global organizations with diverse deployment needs.
Related: CorrDyn helps clients build strong data engineering systems and develop clear technology strategy for complex data environments. Explore how we approach digital transformation and data cost optimization for large organizations.
Full Transcript
Jason: Welcome to Eventual Consistency. One of the things we see is that the data industry has a lot of noise. Every week there’s a new tool that’s going to revolutionize something or a LinkedIn post about how you’re doing it all wrong. We’re not here for that. We’re here to talk about what’s actually happening. Honestly, the way that you would talk about it with your team. Today IBM’s buying Confluent for $11 billion. Let’s talk about what that actually means.
Ross Katz: All right, the big story we’re digging into today: IBM is acquiring Confluent. For those who don’t know, Confluent is the company behind Kafka-based data streaming. They help move data in real-time between applications, across clouds, and through APIs. If you’ve ever built a system that needs to process events as they happen, rather than in batches, then you’ve probably at least looked at Confluent/Kafka. The deal is all cash, $31 per share, which values the whole thing at about $11 billion. That’s a 34% premium over where Confluent was trading before the announcement, so IBM is clearly paying up for this, although not at the massive multiple you would normally see with tech acquisitions. The official line is that this strengthens IBM’s hybrid cloud and AI strategy, making real-time data streaming more central to their platform, especially for AI workloads that need fresh data constantly flowing. The deal’s expected to close by mid-2026, assuming shareholders and regulators sign off. Jay Kreps, Confluent CEO and co-founder, is expected to join IBM software after it closes. James, with that context, first question: What’s your immediate reaction when you saw this news?
James Winegar: I’ve been of the opinion that Confluent was stagnant in their offering, cause they had populated pretty much all of the customers that they could have. If you look at their stock over the last few years, you could see that understanding of stagnation. With IBM saying that they’re going to do a premium on the trade price, they must think that there’s something there versus just the baseline. It’s a 35% over the baseline or something like that. Instead of just doing the baseline, they said they’d trade extra, so they must think that there’s at least that much meat on the bone to get. Part of that’s on the consulting side. They just bought HashiCorp for Terraform and Vault and all these other things, and they’ve bought some other companies like Red Hat in the past. There’s StreamSets, which was a data movement tool before, but Confluent is the standard for how to move data around in real-time, or streaming, or whatever you want to say, cause Confluent made Kafka. Kafka’s the API of moving data around in real-time. IBM’s gonna try to expand into their existing customers with some hybridized Confluent platform and then sell a bunch of consulting work on top of that, cause that’s where a lot of their multiplier comes from. There’s gotta be something there.
Ross Katz: Yeah. What came to mind for me was this idea — my understanding, and you can correct me if I’m wrong, is that a lot of customers that use IBM are customers that have mainframes, we’re talking enterprise scale customers with serious compliance obligations. And when you’re talking about Kafka on top of that, you’re talking about near real-time use cases. You’re talking about super low-latency use cases where they need to take real-time action on the streams that are coming off of their systems. What I’m hearing you saying is basically, they’re going to be able to expand their existing relationships by bringing in the standard for Kafka deployment into these existing relationships. But then it’s also, if you’re adopting Kafka and you want — as my understanding, Confluent is the managed version, it’s the supporters of Kafka giving you the officially supported managed version of Kafka. If you’re buying that, then you’re probably the type of company that’s going to want the enterprise-scale compliance heavy stuff that IBM’s going to sell you both from a software perspective and from a services perspective. What do you think about that?
James Winegar: Yeah, I’m not an expert on this, but one of the things is Confluent on z/OS. z/OS is their mainframe basically. You can trigger these events within your banking deposit application or something like that, it gets ingested in a relatively easy-to-configure hub with Confluent and then that can get fanned out to wherever you need it to be, whether that’s another system on-premise or pick your cloud provider, because they’re going to support all of them. What I’m thinking there is that it gives them a play in the mainframe modernization where the mainframe still in place, but also they capture more of the underlying, basically all of the infrastructure needed to support the organization’s real-time use case.
Ross Katz: Yeah. To me, you talked about the premium that IBM is paying over the share price for Confluent. There’s a story you can tell yourself about how there’s strategic value to the streaming stuff that’s going on, and so what is that strategic value? What is everyone talking about right now? It’s AI and agentic AI. An idea that’s been thrown around is that in this world where you have agents taking action on all of your data, there’s going to be more and more streaming use cases because you’re going to have more and more opportunities for these agents to be consuming your data, taking an action in another system, in another context, and the agents are the new robotic process automators that are taking action in a different system with a light degree of intelligence or logic on top of it. My thought here is that IBM is probably thinking, yes, there’s a sell into our existing customer story, yes, IBM becomes a part of your hybrid cloud story if you need to use Confluent for that managed real-time streaming, and then there’s the story of how streaming becomes the next big thing. We’ve heard this story before, batch is just a version of streaming, but maybe this time it’s real where agents are driving the adoption of streaming in a way that wasn’t really happening previously.
James Winegar: Any decision system is going to need low latency, and low latency implicitly is going to be this Kafka type infrastructure to make sure that all your context is up to date, etc. You got some RAG pipeline or something like that, but the thing that moves data around is a streaming system. Most likely you’ve got Kafka in place or some Kafka system-like. You’ve got Amazon and Microsoft or Google who have all their various flavors of Kafka available.
Ross Katz: Okay, we’re talking about what is the play from IBM’s perspective, but the other natural question is, why should anyone else care about this move that IBM is making?
James Winegar: When we think about all the acquisitions in the data space in general, an acquisition always comes with uncertainty about what the future entails because you don’t know what IBM’s strategy is. Pick any other acquisition that happened fairly recently, like dbt and Fivetran or something like that. You don’t know what’s actually going to happen. You can make an educated guess. IBM buying Confluent is going to be a little bit more focused on expansion of capability rather than limiting factors. When I look at the Terraform acquisition, that I feel like is just — HashiCorp wasn’t profitable and they were just looking for a buyer, and IBM’s thinking they can extract value out of that asset across their enterprise customers. When I think about Kafka, I see a different story there. There is incremental value to add because it’s tied in with their ecosystem. Let’s compare to AWS and Microsoft and Google. These three major hyperscalers have Kafka offerings, but they don’t play well with each other.
Ross Katz: You were talking about the analogy between the acquisition of HashiCorp and Terraform and this, and one of the commonalities that jumps out is both of those are acquisitions of companies that have an open core, open-source platforms that they’re offering, that are also available in managed approaches. Would love to hear from you, how do you view these as the same and different, and what does that mean in terms of the Confluent acquisition?
James Winegar: I feel like the HashiCorp acquisition, which is Terraform and Vault and those types of things, was more of just an exit. How do you get an exit, and IBM turns that into a thing that they can extract as much value out of as possible without too much incremental value-add to their customers. It’s mostly just make as much money as they can off of that asset that they purchased. Maybe it gives them a little bit of consulting work for their existing customers that they already have — maybe some acqui-hire stuff too, like you have people who built this thing. Basically, it’s more of an extension of their consulting arm rather than extension of their ecosystem play in a way that’s going to be extremely valuable to IBM. The Confluent acquisition, there’s incremental value to be had there because they have a better story than just Confluent by itself. They have mainframes, z/OS, they got Red Hat, they got a lot of cloud integration across multiple clouds. With that being said, the Kafka offering — because Kafka’s open core, every cloud provider’s got their own version of Kafka they’re deploying, but they don’t play nicely together. There’s not a schema registry that’s standardized. Confluent also has that. They have the ecosystem play for Kafka itself, they can manage that story, but tie it in with hybridization of cloud or across clouds, which avoids some vendor lock-in across the ecosystem. Now you’re locked into IBM at that point, but you’re not locked into AWS or Microsoft, etc. If you have a mainframe, you’re already locked into IBM. You can’t escape to a certain extent.
Ross Katz: As you’re talking, one of the fears that I think data leaders probably have, especially ones that are already on Kafka, is IBM going to support the open-source side of Kafka? The expansion of the capabilities in open source. As you’re describing the value that they’re bringing, being at the center of that hybrid cloud, what’s going through my head is, does that mean that they have an incentive to continue to contribute back to Kafka open source or do they have an incentive actually to just make Confluent IBM’s version of what the other hyperscalers are offering and then use the Confluent team to expand the capabilities and bring everyone who’s doing Kafka across clouds into the IBM ecosystem. Do you have any thoughts on that?
James Winegar: That’s a hard question. Who’s your buyer? Is almost the thing I think about there. Is your buyer the CIO, CTO, or is your buyer the data team, or is your buyer the app teams that are trying to take advantage of real-time infrastructure, etc. Confluent is usually a pretty strong architectural point in what a company is doing. Then there comes a point where it gets complicated enough that you need to have the one enterprise support, maybe even compliance mandated. And two, just all the add-ons to be easy. There are open-source versions of all this stuff that Confluent has in its product, but now you have to bolt those things together. There’s a pretty strong story just for, hey, I’m going to bring these things together and have it in one spot. I got one vendor to deal with, it handles all this stuff. I already got mainframes, I’ve just expanded that kind of relationship there. Likely I’m already buying Red Hat licensing for some of my on-prem stuff. If I have a mainframe, I’m definitely paying IBM for that. Probably working on a bunch of modernization because mainframes are expensive per compute. I’m probably working on some modernization to enable AI workloads and things like that and keep a central banking application on the mainframe only. I can shift that to wherever I need it to be. Maybe I’m a global organization, it doesn’t make sense for me to have this in my primary data center. I’m pushing some of the stuff to Mumbai or something like that, because I have something that’s located in India that I’m trying to have low latency and they have the option to really push that wherever they need to at that point. I can go anywhere with this, honestly, cause it’s such a flexible platform.
Ross Katz: Yeah, that makes sense. What I’m hearing is that, just like all open-core companies, the open-source product is an onboarding to the managed services. When your buyer is the application developer or the product manager on a particular portion of your application or the application itself, then maybe open-source Kafka is what you need. But when you hit a certain scale, when you hit a certain complexity, when you hit a certain level of global reach or compliance obligations, then you need the managed version. So IBM still has the incentive to at least keep Kafka open-source going as the primary thing. It is the API of real-time.
James Winegar: Right. Kafka has defined that. Everybody else has to meet Kafka compatibility at a minimum.
Ross Katz: Yeah. It sounds like at least from my perspective, we can put that fear to bed that they’re going to abandon open source when that’s one of the main ways that they get a foothold into-
James Winegar: More they could say that the open-source capability is done enough, and focus in on the managed offerings that they do provide, because it is the standard already. From an open-core standpoint, that innovation is going to be gone. We’re going to move to the management interfaces that Confluent offers and how does IBM make incremental money off of that from existing Confluent customers and then IBM’s existing customers that aren’t using Confluent, which I think they can sell into pretty easily.
Ross Katz: Yeah. That statement is, I think, the fear that people have about, for example, the dbt Fivetran acquisition, but it’s interesting to view it through this kind of lens. One of the takes I’ve seen out there, and I mentioned it at the top of the episode, was this idea that the real play with acquiring Confluent, with being the main backers of Kafka, which as you just stated, is the benchmark that all of the other streaming APIs have to meet, is this idea that AI agents are going to be actioning off of streaming data for a growing proportion of companies in the years to come. One of the questions that I have, one of the takes that I’ve seen out there, is this idea that now IBM is going to own agentic streaming, the interface between agent and streaming. It doesn’t resonate with me because I just see through our business that we’re constantly talking to people about real-time costs real money. There’s this idea out there that your dashboard needs to be real-time when you’re only looking at it on a weekly basis or a monthly basis. If you don’t have humans that need to be looking at things on a millisecond-by-millisecond basis, if it’s good enough for you if humans are looking at things on a daily basis, or even if the data that they’re looking at when they’re looking at a dashboard is up to the last 10 minutes or so — this idea that agents are going to need this microsecond-level latency that we don’t need our human agents to — doesn’t hold much water. Obviously, a lot of big enterprises that need that fan-out real-time capability are using Kafka and it’s the benchmark for a reason. But this idea that owning Confluent and owning Kafka gives you a beachhead on the future of agentic commerce doesn’t hold a lot of water for me. I’m interested in what you think about that.
James Winegar: The need for real-time is almost always dictated by the system itself. In our business we’re mostly doing analytics workloads for people, and they’re not really making real-time decisions — are not the things that are happening. However, when you’re developing an application product, etc., if there’s a human in the loop, it’s really a problem anyway. So you’re making some type of automated decision making in there. For automated decision making, I think actually it’s going to be a pretty big deal that it’s on the stream, especially with commerce, because that’s a pretty fast interaction. I would disagree, honestly, with the commerce side, this coming from the lens of the work we normally do, which is post-hoc analysis for e-commerce companies and things like that. But this is actually help a user with the checkout flow so that they pick the five items or whatever they want as quickly as possible. Google just put out this thing recently about agentic commerce that people should read if you want to dig into it. Pretty much, you get a person, you get them to pay money, as quickly as possible. Whatever interaction there is that leads to them not paying money in less time is wasted interactions. There was the Amazon study from a long time ago where they just made the website run faster and they got some crazy amount of lift, and that set the benchmark for everybody needs low-latency page loads. AI real-time, what I really think is that decision making, if we’re going to have decision making, automating the decision making using AI agents will drive incremental value enough to justify the expenditure on the systems to support it. But if you don’t have a decision to make in that real-time time horizon, that milliseconds to seconds time horizon, well then you’re just wasting that infrastructure. At the same time, if I already have the infrastructure, I’m already baked into this infrastructure and I’m capacity planned for it, why build another system over here to support something else. Really having a system that can support — this is data right now, this is the data that I need in 10 minutes, and this is the data I need tomorrow, based on polling the information from systems, you can start to tackle that. There’s definitely meat on the bone, particularly with large enterprises, to try to drive decision timeframes down to increase conversions or various things like that.
Ross Katz: Yeah, I really love what you’re saying and it reframes my thinking in a couple ways. Number one, it makes sense that in the context of analytics, there are very few use cases in which real-time is really critical, but in the context of a checkout flow, that real-time really has a lot of value. The other thing you reframed for me is when people talk about agentic commerce, I always think they’re talking about consumers outsourcing to agents to do the commerce on their behalf, which I would call myself relatively bearish on because there’s just so much trust that needs to be built up between the consumer and the agent and between the agent and the company that I think we’re a long way from that amount of trust being available in the system where everybody’s going to agree this is a good way of doing business. But the example you gave wasn’t that. The example you gave was an agent who is in the cart with you recommending the items that you need while you’re shopping in order to get you to that purchase faster, and it’s using the intelligence that the agents have available in order to make the experience of making the purchase for a human more effective. The real-time nature of it is because of what you said with regard to Amazon and the latency of their site. The faster you get them to their goal on your site, the more financial opportunity there is for you as a company. There’s all of these opportunities where the agent is in the checkout flow and the consumer is the human in the loop for that flow, and those are the places where this agentic commerce really has a lot of opportunity, at least in the foreseeable time range to really increase the amount of economic activity that’s happening.
James Winegar: Let’s back it up a second too. For your e-commerce companies, this is actually not as big of a thing because most e-commerce companies are not actually that big. But now let’s take — Google’s the one who published this paper. Now let’s take the viewpoint of Google. Google has Google Shopping. Google Shopping is effectively a gigantic recommendation engine where they’re trying to get you to purchase an item as quickly as possible for all these same reasons we’ve talked about. I know from some of our customers that Google Shopping drives a substantial amount of conversion for them. If Google can drive more conversion by having the customer as the human in the loop in this quasi-recommendation engine that’s agentically driven, well the conversion rate’s going to go up, Google’s going to make more money, a lot of e-commerce companies will make more money as well, but Google’s going to charge them more for that conversion, or per click, or whatever monetization strategy they have. But who really wins in these environments is the tech-enabled organizations that take money off the top. Google, Amazon, Microsoft, IBM to a certain extent by working on these systems in support of those other scaled companies. Just imagine a Procter & Gamble or something like that. Huge opportunity for them. But if you compare that to my deodorant supplier, yeah, it’s not even worth thinking about for them.
Ross Katz: Yeah, not unless Shopify adds it as a plug-in to their checkout flow or something along those lines. But to bring this back to IBM, what you just described is also a massive consulting project that IBM can sell into enterprise customers in order to implement the thing that we just described. There’s partially the real technology opportunity, but then there’s also the dream of that technology opportunity that can become a project that only IBM, they would say, can implement because they bring Confluent to the table and they have the Confluent team behind the scenes that can really optimize it.
James Winegar: If you’re at IBM, we can make it work because we can literally do the thing that’s necessary to make it work for you. You can run on a forked version of Kafka if you want to make it work for you. All you got to do is pay us.
Ross Katz: Right. That makes a lot of sense. To close this out, we’re going to do this segment called What We’re Watching, which is an opportunity for James and I to share one thing that’s happening in the data space or in the industry at large that we think is worth keeping an eye on. James, if you’re ready, you want to kick us off?
James Winegar: In general, acquisitions are pretty strong right now because of funding, etc. When we look at consolidation of the data ecosystem between Databricks, Snowflake, IBM, etc., why are these acquisitions happening and what is the impact that they’re going to have? Those are the types of things I’m thinking about. How does that tie into our overall strategy about what things make sense for those customers.
Ross Katz: On my end, I’m keeping an eye on the recent announcement from Anthropic of their Cowork, which is their Claude Code for knowledge work. I’m keeping an eye on it because it’s both confirming all of the hype that’s been coming previously about AI able to do our jobs, but it’s also an evolution in the tooling that’s available to us as people who work with data on a day-to-day basis: the data engineering workflow, the data analyst workflow, the data scientist workflow, but also the lives of the executive business stakeholders who tend to consume the analytical assets that we produce or help to produce for our clients. It’s the shift in the nature of work and how that changes the way that people are thinking about how data integrates into their work. I’ve felt for a long time that the reason why our data work is so important is because at a certain point your business is at a scale where you can’t understand what’s happening by watching the people who are walking through your front door. You have to look at data in order to understand what’s happening in your business. As the pace of business gets faster and you have presumably the same number of people doing more work, or fewer people doing the same amount of work, then your need for transparency and visibility into your operations just expands. There are supply-side effects of this on the business and also demand-side effects of this on the business as it pertains to data. That’s an exciting trend that I’ve been thinking about.
Jason: That’s it for this episode of Eventual Consistency. If you want to talk about your data challenges or you think we got something wrong and want to tell us how, you can find us at corrdyn.com. We’re doing this every two weeks, so we’ll see you next time, where maybe we’ll be a touch more consistent. Thanks for listening.
