International Business Machines Corporation (IBM) Earnings Call Transcript & Summary

Hello, and welcome, everyone. Thank you for attending today's IBM Community webcast featuring the Middleware Community. My name is Sofia, and I will be moderating today's webcast. Our topic for today is Build Real Time Apps with Confluent and IBM Cloud Pak for Integration. [Operator Instructions] Be sure to check out the links under the resources for Upcoming Webinars and all of the on-demand replay. There will be a question-and-answer session towards the end of the presentation, but we encourage you to ask questions throughout the webcast directly in the Q&A box located on your screen. Everyone will be e-mailed on-demand recording, along with the slides, and we encourage you to post any additional questions in the IBM Community from the link we provide. Now I'd like to introduce our experts for today. Today, we have joining us Savio Rodrigues, Vice President of IBM Application Platform & Integration Offering Management; and Chris Grim, Head of Americas, Confluent. Thank you, gentlemen, for being here and the floor is yours.

Great. Thanks, Sofia. Today, we're going to talk to you about building real-time applications with Confluent and the IBM Cloud Pak for Integration. CP for I to be short. And in doing so, we're going to talk about the partnership between IBM and Confluent that was announced, and some of you might have seen in late November of 2020. So at IBM, we believe that clients can gain real competitive differentiation by automating the enterprise. So automating the enterprises means automating business and IT work. It includes automating interactions between apps, data systems, otherwise known as integration. Now here's a surprising fact. 70% of digital transformation projects fail to achieve project goals. And they fail because of lack of integration quality. So at IBM, we've got a contrarian view here that going fast without the right approach, an approach that's guided by real-world data by your own operational data in a closed-loop that's continuously helping you improve the quality of your integrations using automation and AI will simply get you to the wrong place faster. And now we believe that clients such as yourselves need to rethink your integration strategy. We feel that every single integration must be closed-loop, meaning that the integration is using real-world operational data to inform the AI that's automating your integration work and that this operational data and the AI training that comes with this data must be specific to your enterprise. Because your most important integration processes are shared by no other company. So the data that feeds and trades the AI that's automating your interactions and your integrations must be specific to your company. Finally, we strongly believe that each integration will frequently involve multiple styles of integrations, such as APIs or Kafka events or messaging or iPass. So simply put, at IBM, we feel that every integration must be automated, closed-loop, and multi-style with AI that's informed with your company's operational data to continuously improve. So this rethink of your integration strategy will help you integrate faster and better. And we think that this rethink has to happen now because you're going to be spending a significant portion of your IT budget on automation and integration in 2021. And you don't want to end up in the wrong place faster. You don't want to end up in the 70% of digital projects that fail to meet project goals. So let's talk about how successful enterprises can utilize AI and operational data to integrate faster and better, and we'll do this by looking at 3 challenges we've seen at countless integration clients that we engage with as sponsor users for our offerings where we do integration modernization services projects with IBM. First one, there are many manual tasks from things like mapping fields and integration flows to creating integration flows themselves to writing API tests that exercise the full scope of the integration and the related back ends. And these manual tasks often require experts integration skills. This slows down the speed of your digital transformation projects due to the limited number of integration experts that you have. Second, problems are found in production, and they're often found after time-consuming problem determination by yet more experts by, in this case, integration operation admin experts, or worse, it's not actually a bug, but rather, it's an inefficient integration that is causing your company to pay overage fees to -- for its SaaS services such as Salesforce. And these inefficiencies, they remain hidden because your company lacks the operational visibility to continuously improve your integrations. And then finally, and this is very common, your integration teams are siloed. You might have an MQ team over here and app integration team over there and a Kafka team is somewhat different. And they all feel that their approach to integration is the way to solve the integration problem it had. Now let's talk about how to integrate faster and better. With IBM, you get automated integrations powered by AI leveraging best practices out of the box and a built-in asset repository that promotes reuse to reduce the skills barrier to integrating faster. Next, IBM uses a closed-loop integration life cycle automation approach that uses real-world data from your company, and it pairs it with IBM's AI to identify issues and make recommendations for continuous improvements so that you can integrate better. And you'll see a lot more focus on this in the 2021 time period from the IBM integration family. And finally, IBM has the broadest set of integration capabilities already to be used together. We see every integration as needing a multiple style of integration approach. So absolutely, you can use a Kafka broker or app integration flow to solve a particular problem. But don't you want to expose that for reuse via an API? Or don't you want to be prepared for the back end to be unavailable during an update commit so that you'll need to use messaging integrations? As you can see, using multiple styles of integration together to solve your integration needs, delivers results that are both faster and better than what you could have done before. So let me take a quick minute to ask some of you. First poll question. Are you looking to implement multiple styles of integration, i.e., API management, events, app integration, messaging, file transfer, and so forth today? So go ahead and click your answer, please, and we'll take a look at the results in a few seconds. All right. 5 more seconds. Okay. Great. And this is exactly what we're hoping to see that the majority of you're already using multiple styles of integration. That's great news. Now one of the most popular styles of integration that clients are looking at is event streaming. And I'd like to ask Chris to take you through why that is and why Confluent is the #1 enterprise event streaming provider on the market today? Chris, over to you.

Thank you, Savio, and great to be here. Good morning, good afternoon, good evening to everyone. So let's start with what does this really mean for your architecture, right? Gartner Research suggests that real-time situational awareness will be required for 80% of digital business solutions moving forward, and 80% of these new ecosystems will require support for event processing. So this diagram is really what it looks like to even attempt a digital transformation without event streaming. It's an architecture with a myriad of interconnected legacy systems that function via vast -- excuse me, batch processing and periodic queries on passive data, right? There's an untenable amount of point-to-point connections, as you can see, and it's a data architecture that's rigid, complex, and expensive. So many of the organizations that we speak with find themselves restricted by an infrastructure that looks like this. And this is what drives them to look for an alternative, and it's really what makes Kafka attractive to them. Kafka doesn't treat data as a fixed passive store or is data at reps. Rather, Kafka is data in motion. It's data that flows. So you no longer need to manually copy data across hundreds of systems. The stream of data can flow to every part of the company where it's needed in real time, which really allows companies to react and process this data stream as it occurs. So next slide, Savio. Let's talk a little bit about kind of how we got here. So this is what really has driven the explosive growth of event streaming via Apache Kafka. Kafka was originally developed at LinkedIn back in 2010 and then open-sourced via the Apache Software Foundation. It has seen massive open source adoption across hundreds of thousands of developers around the world and tens of thousands of organizations. So every organization born as a digital company is built on event streaming today. And 60% of Fortune 100 companies are leveraging event streaming via open-source Apache Kafka, and a majority of these are Confluent customers. Confluent founders, including our current CEO, are actually the original creators of Kafka. And in addition to all this, the Confluent team has written 80% of the Kafka commits and has over 1 million technical hours of experience with Kafka. So we really are the cornerstone of this technology. Let's jump to the next slide and talk about how a Confluent, our platform extends Apache Kafka to be a secure enterprise-ready platform and we help enterprises around the world successfully deploy Kafka at scale and accelerate their time to market, right? It's an architecture where all your systems applications are connected through a universal pipeline -- event pipeline through a vast library of prebuilt connectors, right? And this allows events that are stored in topics to be used and correlated to create these new conceptual applications at the top, like real-time inventory, and real-time fraud detection, and real-time customer 360, and learning models, and many others. And because of this success that our customers have achieved, we have been the benefactor of several very prestigious innovation awards from customers like Morgan Stanley, and JPMorgan Chase, and Bank of America, to name a few. So Savio, with that, I think we have a poll question, don't we for the audience? We do. So let's take a quick poll and get a feel for at what stage are you deploying an event streaming solution? If you could select the poll and your answer and Savio will pull up the results here in a moment before we get into the details of the Confluent platform itself.

Chris, we'll give them 5 more seconds.

Okay. Great.

Okay. Here we go.

Okay. So many are really just getting -- not started. They're investigating the benefits, which is a great place to be. And then we've got certainly a cohort that's looking at it right now. A lot of our customers start with a pilot or a development project. So that's great. And then you've got a smaller cohort in production and in development. So that's fantastic. So a lot to learn here, and certainly, there will be more to follow after this webinar. But let's jump to the next slide and talk a little bit more about the Confluent platform. So Confluent provides an enterprise-ready platform that extends the open-source Kafka platform. And this allows customers really to focus on innovation and speed to market so you can operate at scale. This is versus building everything yourself with open source. And when you look at the IBM Cloud Pak for Integration, you get the full Confluent platform with the expertise from both Confluent and IBM, and that's what makes us such a powerful combination. We're going to be able to provide turnkey enterprise-grade capabilities that truly unleash productivity. And I want to give a couple of examples of these because I think it's really important. So there's a rich prebuilt ecosystem of over 100 certified Confluent connectors to enable stream processing without spending time building or managing connectors. Open source Kafka for those that are familiar with it can be very complex and difficult to operate at scale, so we make that easy by providing our Confluent control center UI, which allows you to manage and monitor key operations, the health and performance of the Kafka clusters. And it really makes a big difference. DevOps automation is realized through our Confluent operator, which enables faster container deployment and dynamic performance and elasticity [ as you deploy ] Kafka. And we also offer global resilience to reduce the risk of downtime via our Confluent multiregion clusters, cluster linking, and replicator. And finally, one of the big benefits of working with Confluent IBM is that we're going to provide the security and user access that helps identify potential security threats, which many organizations like those on this presentation, consider as prerequisites when you're going to deploy mission-critical apps. And customers do that by leveraging our role-based access controls and our structured audit logs. So there's really a lot to offer there in the platform. And let's jump to the next slide, Savio, and talk about really like this transformation is happening real-time. I know it's the poll. We have many just starting. But I can tell you it's real. It's not just happening in Silicon Valley. And the biggest enterprises in the world across every industry are on a journey to become software-defined. It's happening with -- in areas like automotive and transportation through real-time, estimated time of arrival, whether it's companies like Lyft and Uber to your deliveries of groceries or take out via the -- through the pandemic. It's happening in banks through real-time fraud detection, where we're leveraging event streaming data across all kinds of business units. And banks are also using this and other financial services entities to deliver really a full set of innovative customer experiences. We see this a lot very high adoption in retailers, right, where when you shop online, you have real-time inventory information. That is Confluent and Kafka at its core. And it's changing how companies like oil and gas do analytics via IoT, manufacturing companies, how they do maintenance, right, and even how large defense organizations and government protect themselves against cybersecurity threats. A couple of the many, many use cases where Confluent enables world-class event streaming to deliver high-value enterprise-grade business applications. And so with that kind of overview, Savio, I'd like to hand it back to you and you can talk a little bit more about the partnership.

Great. Thanks, Chris. So I hope you're all as excited as IBM is about the great new innovations that Confluent will be bringing to our joint customers here. Through this partnership, you're going to get 1 IBM contract with unified support backed by Confluent. And you'll increasingly see integrations that make Confluent a first-class citizen within Cloud Pak for Integration. Now with IBM, you get Cloud Pak for Integration, which is a cross-enterprise integration platform that supports multiple cells of integration. You get the centralized management across clouds, proven DMZ-ready, never-been-hacked, enterprise security, and also more and more so in 2021, the AI-powered automations, set by real-world operational data in a closed-loop to continuously improve your current and future integrations. So we're really excited about bringing joint value to our joint clients here with Confluent. And I'll pass it back to Chris to talk a little bit more about what Confluent is bringing here.

Yes. So Confluent is bringing our full Confluent platform and all of the technology that we come to bear to support IBM in the CP for I bundle. I think it's a great opportunity to leverage Confluent through your existing IBM contract, through your existing IBM relationships, and your existing IBM support model, which many of you are so used to. So it's really a great partnership. We're very excited about that. Everybody at Confluent from the ground up is really supportive of the partnership and looking forward to being able to serve an even broader and more diverse set of our customers.

Great. Thanks, Chris. So let's talk about how -- an example of how you can start using Confluent and Cloud Pak for Integration today. Now hopefully, you haven't had to deal with a car accident or a claim recently. But if you did, you kind of know the drill, right? You make a claim often in a mobile application and then you wait. You can check the claim to see if it's been received, if it's been approved, will you get your rental car, was the damage assessed, when will we get your car back. So as a customer, you're waiting quite a bit. And so you have to refresh that app multiple times to get your status update. But you're not the only one. The -- for instance, if we look at Acme Insurance here. Acme Insurance's rental car partners have to interact with the back ends of Acme Insurance from an insurance system standpoint. Now if you decided to go and solve this problem through a single integration style approach, i.e., let's call it, imagine using API integration. So there'd be a mobile app. And the app is going to call some APIs and is going to read or get data and write or post data to a system of record. And Acme's partners and employees are going to directly use that system of record. So you can start seeing some of the challenges with this approach, right? Your end customers have to query for status updates. They are like -- all of us, they're impatient, and they're going to query often, and that's going to overload your back end. And your partners and employees shouldn't really have direct access to your system of records for performance or privacy or security reasons. So now with the multi-style integration approach, what you're going to do is you're going to add event integration, and you're going to add messaging integration. So in this scenario, your customers still use that mobile application, right? Now the difference is they get real-time updates of their status made possible through Confluent platform. And when Acme employees change data about the claim, i.e., it's been approved in the system of record, a change data connector fires up and pushes that event into Confluent so that it can be used to update, for instance, a claims database. This data can be sent to an analytics database or a partner-related database, all of that powered through Confluent. Now when your customers are creating a claim or changing a claim via the mobile app, API integration is still being used to -- because there's a data update that's required there. And that transaction, you're probably going to want to queue it in a message queue. And that's intentional to ensure that the changes get recorded in your system of record, even if the system of record or the connectivity to the system of record experiences intermittent outages. Now with this approach, what you end up with is providing a real-time user experience for your customers through Confluent and dramatically, up to 45x, reducing the load on your system of records while ensuring that transactions never get lost. This is why IBM believes a multi-style integration approach is needed for modern applications, and that's what you can do today with Confluent and IBM integration. So I've talked a little bit about Cloud Pak for Integration. And I want to spend just a minute on what is it, right? So with Cloud Pak for Integration, you get the broadest set of multi-style integration capabilities, your team can unlock data, apps and events securely via managed APIs, your team can connect, map, transform applications using an award-winning designer and powerful AI-driven automations. You get the industry's premier integration security gateway built for the DMZ and hybrid deployments that's never been hacked in 15 years, delivers over 30,000 transactions per second, and rely on enterprise-grade messaging that powers quadrillions of financial transactions a year. Now new in 2021, your team will be able to build no-code, low-code integrations with desktop applications or apps that don't have APIs via RPA. And your team will be able to analyze integration processes to uncover areas of improvement via process mining. So Cloud Pak for Integration is built on IBM Automation Foundation. So you'll see a lot more automations in the integration life cycle in 2021. Cloud Pak for Integration provides a unified experience across multiple styles of integration, with a shared asset repository while ensuring governance of those integrations, and you can deploy across any cloud. And as a result of this partnership, you can use Confluent, the market-leading event streaming integration provider with CP for I for your event streaming needs. So next question here. For those of you that are already looking at using event streaming technology, which solution are you using today? Open source Kafka, Confluent, Event Streams, AMQ streams, something else. I'll give you a few seconds, and we'll move to the next slide. 5 more seconds. Okay. So there's a healthy mix here between Open Source, Confluent, Event Streams, AMQ streams, and things that are beyond that list, which is great to see. We have seen a broad set of adoption around open source Kafka and Confluent. Now one of the things we have also seen is there's a strong demand for Confluent within the IBM customer base, which I'll touch on shortly in terms of explaining why we did this partnership. So now here are a set of multi-style integration capabilities that you can achieve with Cloud Pak for Integration and Confluent. First, many of you use IBM MQ or another messaging technology to ensure transactions get committed. But those business transactions, like payments or orders or reservations, they have valuable real-time data insight, as Chris was talking about, and they're helpful to power your digital transformation. So you can use MQ to Confluent or another capital provider to distribute the data from MQ messages via Confluent. Next, your events from apps or data stores often need to be mapped with other data or need to be transformed into different formats before they can be streamed from or to Confluent. With CP for I, you have a no-code approach to orchestrate these events using event-driven flows into hundreds of apps and data stores, which you can now stream with Confluent. Next, and this is coming in the next couple of months here with Cloud Pak for Integration, we recognize that Event Streams must be discoverable to your developers and governed by your administrators. So you want the socialization, the governance, the versioning of your event streaming that you already have for your rest so GraphQL APIs. With CP for I, you'll be able to do just that with your events that reside in Confluent or any other Kafka provider with Cloud Pak for Integration. And then finally, legacy apps and systems, they often have constrained transports, protocols, or security models. Using CP for I, you can translate the broadest set of interfaces into and out of Confluent so that you can virtually any app can participate in the real-time applications that you are building. Now Cloud Pak for Integration has increasingly become a business-critical integration platform for our clients. And clients have come to us saying, "I want to integrate third-party integration solutions, such as Confluent into the CP for I platform." In fact, Confluent was the #1 asked for ecosystem partner with Cloud Pak for Integration, which is why we went in and partnered with Chris and team here. Now additionally, as part of automating work for developers, administrators, including integration of developers and admins, we see modern DevSecOps processes playing a critical role here. That's why just today, we've announced a partnership with GitLab. You're going to see many more OEMs that expand the ecosystem of integration choices with Cloud Pak for Integration in 2021. Now we hope you are as excited as Chris and myself and the rest of the Confluent and IBM teams are here in terms of the joint value that we can bring together with Confluent and Cloud Pak for Integration, and we'd encourage you to get connected with one of our experts so that your company can integrate both faster and better while you're delivering those customer experiences that drive the innovation and real-time experience that your customers require with the partnership from Confluent and IBM. So with that, we can turn it over to some of the questions that you might have here.

Yes. So actually, Chris and Savio, not surprising. There are a number of questions about Event Streams. And so maybe to help with the answers, questions are around so Event Streams is it no longer a part of CP for I? Is -- and then a question about how does Event Streams compare to -- how does Confluent platform, sorry, compared to Event Streams? So it might be worth going a little bit more into the packaging of the CP for I product.

Yes. Let me handle the first question and then Chris can talk a little bit about the value-add differentiation around Confluent versus -- Kafka in general or Event Streams or other offerings, one of the things we've found here is that Cloud Pak for Integration is becoming an integration platform at our clients. And as a result, they want to use CP for I as the enterprise-wide platform that they plug their other integration styles into. And some clients have chosen Confluent instead of other Kafka provisions, including IBM Event Streams. And for those clients, we want to make sure that you can use Confluent with the rest of Cloud Pak for Integration. And this is uncomfortable, just very transparently. It's uncomfortable for IBMers in general. But being open to an open ecosystem means that there are going to be choices that customers make that aren't always the IBM technology. And we want to support that choice and provide an open ecosystem around Cloud Pak for Integration. So there are clients that will be continuing to use CP for I with Event Streams. There's clients that will use CP for I with Confluent. We want to support those choices because the value of having an open ecosystem is something that clients have told us is really important, and we are seeing that across the board at IBM.

Great...

Chris, do you want to spend just a minute on some of the value-add differences of Confluent?

Yes. Sure.

And I'm sure, some of the -- just the highlights.

Yes. So I think one of the things that has happened at Confluent over the last couple of years is we've pivoted from providing kind of world-class support solely for open-source Kafka into adding a lot of IP onto -- on top of Kafka to create the Confluent platform, which is the basis of the partnership with IBM. So many of those things that we talked about around role-based access controls and multi-region clusters and the ability to have a simple and easy-to-use UI to manage your Kafka top pit, those are things that are -- that is IP from Confluent that make deploying and scaling and really putting in the mission -- putting Kafka into mission-critical apps much, much easier. And that's a pivot we've taken. And I think, as you look at what's available in the Kafka market to support your business, you'll find that a lot of those capabilities are game-changers in terms of your ability to scale and manage an environment without having to use a full set of your engineers and having a lot of Kafka resources, right? We're finding that a lot of customers would rather have their developer spending time building high-value applications to support the business as opposed to like managing an infrastructure like Kafka when they can get help doing that kind of thing from a partner like IBM and Confluent.

Thanks, Chris.

Great. Yes. So, Chris, there's kind of a follow-on question here, which is, I'm a Confluent customer, what are the benefits of working with IBM?

Yes. So it's a great question. So you'll have -- as a customer, you'll have a choice, and that is -- you can continue to work directly with us, you can continue to work with IBM as well. And you have to -- you can decide based upon the value to you and your organization, what's the best way to access Confluent platform. I think what will drive this for a lot of customers is the value and support they receive from IBM. IBM does a lot of great things as it relates to managing a broad ecosystem of technologies and products that are far above and beyond the scope of Confluent. So as you see value in that and as you reap the rewards of that as a customer, I'm sure that will be interest when you look at how do you best support your Confluent platform.

Awesome. So, Savio, there's a question here about Confluent platform coming prepackaged with CP for I. So 2 questions on this. One is super easy, which is if -- which version of CP for I? And then a question about sort of the longer-range or -- about integration into the CP for I Cloud Pak?

Yes. Great, great. So the first question is very simple. The Confluent is an add-on to Cloud Pak for Integration. So it doesn't come prepackaged with Cloud Pak for Integration. It's a separately purchased add-on. And that was provided in late fourth quarter, so it would be on the 20.4.x release of Cloud Pak for integration that you can now use this Confluent add-on. And every future release of Cloud Pak for Integration will also have the add-on provided, so 2 specific points. It's not part of the package. It's added separately, and you can do that as of the fourth quarter release of Cloud Pak for Integration.

Great. And so then the next question is about whether or not Confluent supports OpenShift? And Chris, do you want to take that one?

I don't know that right off the top of my head. I think...

I'll take it.

Yes, Gary there -- or Savio, sorry?

Yes. The Confluent does support OpenShift. And some of the clients that are using Confluent can use CP for I with the Confluent add-on and OpenShift. You can choose to use the Confluent add-on without OpenShift also depending on your particular needs.

Okay. Great. And then there to kind of a follow-on to that kind of question as well. The question is, will it be possible to use Confluent without the Cloud Pak for Integration?

So I'll take that first, Chris, and you can add on to it. So the entire goal here is that we want to deliver a multi-style integration approach that uses event streaming from Confluent with other parts of the IBM integration platform. So we want the 2 things used together. There's integration being planned for the 2 offerings to come together. Very similar to what we have already with Event Streams in Cloud Pak for Integration. So can you use it separately? The answer is, if you license both, you can use them separately. Do we really think you're going to get a lot of value using things separately? Not as much as if you use it together because you can continuously start seeing that the multi-style integration approach is the one that is being used by modern integrations. So a long-winded way of saying, you have to acquire the 2 together, you could use Confluent with -- as a stand-alone as long as you're doing some integration with Cloud Pak for Integration, but we see much more value when you use the 2 together.

Okay. Great.

Chris, anything to add?

No, I think that was perfect. I mean, this is a better together story for everybody. I think you'll get a lot more value over time, leveraging both technologies, both platforms.

Great. And then, Chris, there was a question here about whether Confluent Cloud is part of this Pak as well?

It is not at this time.

Okay. Great. And then shift gears a little bit away from product into use cases. And so the question here is specific about telco use cases. But Chris, maybe you want to talk a little bit about Confluent platform and some of the top kind of use cases that you see with obviously answering the telco first?

Yes. I mean we have a number of telco customers today. We're very active in some of the 5G rollouts as it relates to everything from the IoT aspect of that to the customer experience. So a myriad of applications there. And I would encourage whoever is asking that question to reach out to us, and we can get you more information on that for sure. And then yes, there is a -- there is just a broad, broad -- this webcast doesn't give enough time to get into all of the use cases. But when real-time decisioning is critical and it becomes a difference-maker to a business, you can bet there's a Kafka use case that can support that. And that's where we see a large majority of the use cases that we support in the enterprise.

Okay. Great. And then, Chris, this -- next question for you. Is the -- question is about Confluent platform versus using a product like Microsoft Event Hubs. And I think this is a great opportunity to talk about hybrid cloud and multi-cloud and multi-data center kinds of use cases here. So why Confluent versus any other individual event platform like Event Hubs or PubsHub or anything like that?

Yes. I mean I think it comes down to, you can build a lot of capabilities with open-source Kafka and with some of the other suppliers on the market. But at the end of the day, what we're finding is more and more customers are migrating to the cloud, they're living in a hybrid environment where data is coming in from a variety of different sources. And the ability to have turnkey functionality that's supported by a world-class vendor like an IBM, like a Confluent is really the difference. And is really what most of our customers are moving towards and are more and more willing to pay for, quite frankly, right? I mean you can get open source versions of a lot of products at no cost. But you have to staff up the engineers to support that business. You have to make sure you have the resources and the capabilities to really run those environments. And over time, we're finding that more and more of our customers don't want to do that, especially as these environments change from private clouds to public clouds to high-security data centers that they continue to run and manage. And the focus is definitely moving towards how do I unleash productivity with our developers by letting them build great technology for our business and for our customers as opposed to running infrastructure and managing environments on core of event streaming technology.

Okay. Great. And so Savio, we have a question for you. So the question is, if Confluent used with IC for I, maybe they mean Cloud Pak...

IBM Cloud Pak, yes.

Yes. On Red Hat. Does it consume the Red Hat license entitlements?

That's a great question. The Red Hat OpenShift entitlements that come with Cloud Pak for Integration, the 3:1 ratio that was announced in the fourth quarter, that is for Cloud Pak for Integration itself. Now remember, this is an add-on. And so the add-on is separately licensed. And if you choose, you can run it without OpenShift. And in that scenario, there's no OpenShift licenses required. If you run it with OpenShift, the OpenShift licenses are separately purchasable. You cannot use the OCP that comes with CP for I, the core CP for I for that use case.

Okay. Awesome. And then there's another more technical question around for CP for I. We need a certain minimum amount of memory and CPU for all the integration capabilities. If we use Confluent instead of IBM Event Streams, wouldn't the cost be higher? And also the operations dashboard in CP for I, would it provide tracing for Confluent as well?

That's a great question. So let me address the second one first. Today, the operations dashboard does not support any of the additional add-ons that are available today or coming in the future. So today, Confluent is -- was one of the add-ons, it's not supported. So you get the operation dashboard capabilities for the core pieces of CP for I. That is something we are looking to change because, as I said, where we're heading with CP for I, is this becomes an integration platform that you plug other things into, some of which will be complementary to IBM integration, some of which will be a little bit of -- I'm not going to say a duplicate, but less complementary. And in both scenarios, we want to make sure that you get the values of end-to-end tracing. So there's work to be done in this arena to extend the operation dashboard capabilities beyond just what's on CP for I to include Confluent, but that's something that we are absolutely looking at. That's the second question. The first question around would the cost be higher because you're using additional memory and CPU? Not necessarily because remember, the -- there's a couple of different key components of CP for I. There are "shared services" for things like asset repo or the catalog. And for that, you're going to extend those components up for all of CP for I. Then you might decide I want to stand up a specific integration style like API management or like IBM Event Streams. And it's really that piece that you would say compare with Confluent. And the amount of cores or amount of memory that you would require for Event Streams versus Confluent is not dramatically different. So I don't think you'll see that the cost is going to go up in terms of memory and CPU usage. But we're happy to work with you on getting to specifics on your use case.

Okay. Awesome. So I think there's one last question here today. And Savio, it's for you. So can you talk about the effect on the IBM and Red Hat strategy, given that IBM CP for I already has Event Streams, and Red Hat has AMQ Streams, both of which are current implementations?

Great question. So one thing I'll mention is that IBM and Red Hat, there's absolutely a relationship between the 2 companies. There are things that we absolutely agree on and want to drive in the market like the adoption of OpenShift, the value that clients will get in terms of standardizing an OpenShift for an open hybrid cloud approach. Then there are things that we treat separately and individually within our 2 companies. So Red Hat and IBM have separate development teams, separate road maps for our integration technologies. So you might see AMQ Streams or other parts of the Red Hat integration portfolio go in one direction and IBM go in another direction. And that's based on the market needs from the clients we're serving, right? The different types of scenarios and so forth. So you won't always see a one-to-one relationship there. Now I was open about this, right? But if we're trying -- we can't always have our cake and try need it to, right? If we want CP for I to be an open ecosystem platform, that means that there are going to be things that we plug into the platform that are somewhat competitive with things that are delivered by Red Hat or delivered by IBM. And we've made the choice that we're going to let the customer decide because, at the end of the day, that's really the only vote that matters, and customers have been asking us for this choice of Kafka provider within Cloud Pak for Integration. And we want to make sure that we address that customer choice requirement. It is by no means easy. We've had lots of discussions within the team. But I think the value that we will deliver to customers by providing that choice and an open ecosystem, especially with a market-leading Kafka provider like Confluent, it makes the internal difficult conversations worth having because of the value we can drive to end clients.

Great. So I think that's it for the questions for today. There were several really technical questions. And I think the IBM Community is the right place to put those really technical questions, and we can also follow-up offline with the folks who answer them. And so Sofia, if you want to wrap?

Sure. Well, thank you for attending today's webcast, and thank you to our amazing presenters for sharing this great information. So a quick reminder to the audience that we will e-mail you the recording and slides and everything will be available tomorrow in the IBM Community, including some of the questions submitted in the Q&A today. Again, please be sure to post any additional questions and look for answers to questions submitted during the webcast in the IBM Community tomorrow. This concludes today's event. Thank you, everyone, and have a fantastic rest of your day.