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

Hello, and happy Friday, everyone. Thank you for attending today's IBM community webcast featuring the middleware community and the cloud integration group. My name is [ Jessica ], and I'll be moderating today's webcast. Our topic for today is Accelerate your API-led Innovation agenda with API Connect Version 10. Before we get started, please note that the audio is played through your computer or device and there is no dial-in number. To view the demo in full screen -- or excuse me, to view the slides in full screen, just click the 4 arrows located at the top right corner of the slide spot. Please be sure to check out the resource list for upcoming webinars and sign up for demo days and office hours. [Operator Instructions] Tomorrow, we'll e-mail everybody a copy of this webinar recording along with the slides, but encourage everybody to navigate to the cloud integration group to post any additional question. Now I'd like to introduce our presenter for today, we have Tony Curcio joining, who is the Director of API management and gateway at IBM. Welcome, Tony.

Thanks, [ Jess ]. Appreciate it. And I want to thank everybody who's joined for today's session. I can look through the attendee list and see a number of people from really around the world as far as Japan this morning or this evening for you all. And so just welcome to today's call. I'm very, very happy about getting our API Connect Version 10 in market. If any of you have been looking through Passport Advantage, you will have seen your media refresh for our partners who've also joined through the PartnerWorld application. Of course, a lot of material out there as well. And over the next series of weeks and really the past couple of weeks, there will have been a number of blogs and other articles and things that we've made available. The knowledge center has also come online this week where you can learn some more information. So a lot of places for our customers, our partners, and other IBM-ers to go and learn and discover just a number of the wonderful things that we have delivered here in Version 10. I'll take the next now 28 minutes to go through highlights of what's in this release. Probably be talking as quickly as I can to fit as much as I can in during this time. But I'll also say, in addition to the places that I've cited where you can find more information, be it at the middleware community, knowledge center, et cetera, of course, also feel free at any point -- I invite customers, partners to reach out to me, glad to entertain conversations as we move forward together on this journey of partnership that we have. API-led Innovation is a title that we really find interesting because, as customers have adopted our API management solution over the past numbers of years, they've done incredible things when we look at whatever the industry is, banking, telecommunications, retail, manufacturing. As they're starting these API programs, really, it is about the fundamental business transformation, how we allow our development community, and our partner community and ecosystem in general to move faster through the use of APIs and achieve new business transformation, customer experience transformation, and start really new opportunities for doing business, and frankly, making money in the enterprise. And we do this through allowing people to use data, use services that we expose through well-managed APIs. And of course, the security of those APIs is paramount. The ability to make sure that when we move forward with an API program, we can do so in confidence. And so the authorization, the authentication of anyone who's going to be a subscriber to an API, that's really foremost for what we do as an API management technology. But really, as equal and powerful is the ability to then socialize those and reach out to the development community so they can understand what these APIs are in order to solve the business challenges that they have. And so when we think about that domain, we really want to focus on who are these users, how do we improve experiences for them. And so you'll see in Version 10 quite a bit that we've done in that way. But just a little bit reflecting on the journey. Version 10 is really an extension of what we built in Version 2018, which was new cloud-native microservices architecture. It's the fundamental building blocks of an API management software. And so with 2018, we had allowed for deployment across multi-cloud or our hybrid cloud architectures, controls playing in one location, gateways distributed in various locations, analytics, microservices that could be co-located with the gateways in order to provide security and privacy and aligning to regulatory requirements. And so that V2018 release for us was fundamental about the adoption of containerization, microservices, Kubernetes layers, all of that goodness. Version 10 takes that same architecture and continues to optimize on it. But in addition to that, of course, we're going to talk today about the new capabilities that are also then available on that backbone of this microservices architecture. Some have asked and I'll say very quickly, why Version 10 after going 2 years? Just to standardize across IBM. In jest, we say Version 10 is twice as good as Version 5. So you'll be the judge of that, I'm sure. But really, a great amount of goodness and engineering innovation that we put into this release. So really diving right in. Four key areas that we talk about with Version 10. And of course, there is a tremendous amount of different things that we'll talk about that are in this release, and you can go to our Knowledge Center and see the release notes about what's new and get a bit more deep dive on any one of these capabilities and beyond for some other things. I'll give a few highlights, but the 4 that I really want to dive into are the ones that you see here, and we'll see some backup slides that further drill in. So on optimized access to distributed data. One of the revolutionary technologies that's come up in the API management space has been GraphQL. And we talk about it being revolutionary because of the way it affords API consumers to have an easier way to consume through the API layer a variety of different data or other operations that they need to work with in ways that they couldn't before. And just to describe that very quickly. In a typical pattern with APIs, I'll go retrieve a customer by ID and then I'll go get the customer details and then maybe issue another request for customer address information, maybe another one for phone information, et cetera. And this pattern of send a request, get a response, use some information from that one to send another response, it means that API consumers, these developers need to understand a vast number of your APIs and work through each one iteratively. And that, of course, introduces some layers of latency. But really, the problem domain that GraphQL looks to solve is, can't we just make the request simpler. So GraphQL leverages a query language, another QL, in order to make that more efficient. Now what I could do is select customer name, customer address, customer phone with one statement, that query goes to GraphQL back end, and it comes back and gives the resolution of all of those pieces. So that's a great accelerator for the development community, i.e. the API consumer. But where GraphQL has some weaknesses is it removes some of the governance controls that an organization can otherwise assert. And so when we've been speaking over the last couple of years, and also as a sponsor, we participate as a member of the GraphQL open source community, we find that the governance gaps have been a block for our enterprise customers to want to move forward. And what they've asked in many cases is for IBM to help solve that. And so what we're doing and innovating really as the first vendor to do this in the space is introducing governance GraphQL, the ability to control very discretely the query, the response, the cost structure around that number of levels to do that. So the API product manager can adopt in confidence the technology that is GraphQL. So the governance for GraphQL. That's the first pillar. We'll look more at it on the next slide. While not everybody is using GraphQLs, some are starting, some have implemented, but many are still exploring. What everybody really is concerned with is the second pillar, which is the quality of my API program. We have developments coming from various parts of the organization. Everybody is moving at record speed to achieve new business objectives. And how do we ensure that as people are building, they're doing so with quality in mind? And how do we lower the cost of everybody pervasively, building quality? So IBM, in the cloud, we've introduced about 18 months ago a capability called Test and Monitor. This is a great technology that automates the ability to generate test cases based on the shape of the API. Then use that synthetic tests that we build in order to align that to your whole CI/CD pipeline. But the overall goal then is, of course, to simplify the test experience for your API and then ensure higher levels of quality. And so we think this is a great accelerator for basically every customer to help them with their testing and quality and monitoring mission. The third pillar is one where we see a bit more alignment for the kind of questions that come from the architect perspective. Many people are saying, APIs, we love them. We've adopted them. Our API management technology domain is successful, and we've got lots of projects that are using it. But we see this other thing that's coming up in its events. And how do we bridge across the organization need for API as well as the organization need for event. And the case in point that I tend to go to is either I'll talk about an airline app or a banking app. Airline app is -- I open their app, I query to see what my seat is. It tells me that I've been checked in, et cetera. I go through that experience. That's a very API-centric model because I'm engaging as the user and I'm issuing the yes, please check me in. But if the flight gets delayed or I get an upgrade, thank God, sometimes, I get those upgrades, it sends me an event. And so my engagement model could be either one of those. Banking, similarly, right? I go in, I issue a deposit through the little phone app, all through an API framework. But if my balance goes too low or my credit level has changed, it's an event-centric interaction with me as a consumer. And so we see this emerging need increasingly to bridge through the events in the API architectures, and IBM is investing very significantly in that. We'll talk a little bit more about that when we get to its background slide. And finally, enterprise-scale operations. With 2018, which I explored in the prior slide, we made a great bet from IBM in the API management space to rearchitect the microservices' architecture. Well, in the history of the last 2 years has proven that to have been a great bet, right? The idea that Kubernetes is a common orchestration layer from managing containerized software of any kind microservices architecture as the way that things can get operated in a framework like that. That is something that we did in 2018. With Version 10 now, we're taking that to the next level and introducing support for operators in the OpenShift and Kubernetes framework. Many may not be familiar exactly what operators are. Of course, there's quite a bit of content out there, if you're not. But if you look at OpenShift operators, you'll find a little bit more about that. It's a very specific perspective on how we get to higher levels of automation with the back end of a microservices' framework. And so across IBM in general, all of our middleware technology are moving to operators or have moved to operators. And of course, we're doing that here with Version 10. And again, I'll explore that a little bit more in detail.

Do see a question came in. As an architect, what's the right level of certification to obtain on API Connect? And do we offer vouchers? Thanks for that question. There's a lot of information that's out there. And very soon, we're going to be launching a new program about learning more about API. There's been a number of blogs and white papers that I could point you to. The certification that we have out there, which is still very valid, is on our skills portal on ibm.com. And so you could, for sure, point to that. And then I would encourage the person who asked the question to reach out, and I can get you some links for that as well. And [ Jess ], [ Jessica ], who introduced the show today, she's going to be posting these out in the community, and we'll make sure that those links are available to everybody there as well.

All right. So diving a little bit more into GraphQL. This really is another way to run an API management program. It does change some of the dynamics of how you look at what that endpoint is that gets exposed and subscribed to. But you really want levels of control. And so what we have done with our support for GraphQL is we can read in the schema through the GraphQL server. We can allow the product, API product manager to authorize or shut down different fields, which they do or don't want to expose depending on the plan and the subscriber, which plan the subscriber has subscribed to. We also have a cost-based model for the queries that could be executed. And so what you can say is, in this particular plan, we don't want to afford expensive queries. And what we can also do is align to the back end and say, actually, anything that's coming from this source is a much more expensive query for us. Now you might do that because it's on a system that actually just can't service a lot of payloads. Might do that because it's a history information, and it will itself be costly because it returns a lot of detail. And so the API program manager then can, of course, tune the GraphQL inputs to how they want. It can also say, I never want somebody to send a query that's more than 3 levels, 5 levels deep. And of course, that's another way to protect the back end. And what we know from our journey over the last 40 years, with SQL, there are attacks that people can do when it's a query that's being exposed, right? You almost get to the levels of denial-of-service attacks based on people writing extensive queries. And so what we want to do is protect the infrastructure from that kind of an attack and also afford the same kind of minute and granular controls to the API product manager to say, we will authorize everybody to do this kind of thing, but also protect the back end from anybody doing this kind of thing. And again, with IBM now, you have these kind of controls built into API Connect Version 10. And I'll just showcase very proudly the engineering team behind this. They've issued patents around a lot of this technology. This really is unique, great IP that IBM is bringing to market here with our support for GraphQL. The automated behavior testing, this is taking that testing and monitoring technology and building it into the microservices framework that is API Connect. And so we can scale out and scale up and scale down the same way as all of our other microservices components. But really, the key thing is that levels of automation. We can look at an API response, which might be a data model that's thousands of records long, multiple levels deep. And based on that response, your tester or your developer can say, we want to validate all of these different fields. We automate the generation of all those artifacts. And so that's a tremendous timesaver for the API developer. They could then go in through a no-code approach and tweak things as they see fit. They could say, well, actually, a good response looks like this one, but it also looks like these other 10. And so we'll automate all of those things. Once each one of those test cases has been iterated on and asserted, we capture that, while the unit tester, the developer can play that back as they're making changes. They can then actually take that as a package and put it into the CI/CD pipeline just like any other artifact. What you get then is a tremendous opportunity to then automate the regression-testing life cycle around your API and the services, again, that go along with them. Finally, we see a lot of use in a lot of proof points, as we've had this technology in the cloud for the last couple of years, and now bringing it here, we'll see even more of it. You bring -- some of those tests and put them into -- sorry, there's a little bit noise going on I guess, I'm not quite sure why. But put those into production and say, let's monitor this subset of those every N number of minutes, and -- which is great because then the API product manager has visibility to, is my system continuing to be healthy, are my APIs returning data the way I expect them to? So it's not just a system status. It's like the API behavior status. And again, a great accelerator to anybody who's looking to do testing and improve the overall quality of the program. Also, with Version 10, in that same vein, with testing and debugging, we've introduced a new, a deeper level of debug tooling. This is an interactive debugger. What you're seeing here is the API assembly has actually multiple paths through it. It's a lot of different ways that could have done based on what the request was and based on the nature of it. What you're seeing here actually is the specific trace through that API assembly, and so only the nodes actually that were executed. You can drill into any one of those steps to see what the request was, how it responded. And not just the packages of information, but also the latency. And so if you have a slowdown, you have results you didn't expect, you'll see that actually as part of this. If you do identify that's something that looks fishy, you can use the little Edit button there on the bottom right to jump from this display of the debug information directly back into the full assembly in the context of where you were. And so it's a great experience for the developer, the API developer as they're moving through and defining these policies to figure out, how do I troubleshoot something that's not looking quite right to me. And so that interactive debugger, NetView and Version 10 works across the hybrid cloud architecture, also works very directly in your local sandbox with the LTE that we offer. And so very, again, proud of this new feature coming in at Version 10. I mentioned a little bit about the airline apps, the banking app, how APIs and events need to come together more. There actually is a really rich road map that we're doing here. I don't want to spend time on it on this call just for the sake of the length I have. If anybody is interested in more in what we're doing there, again, reach out to me, be glad to share in the context of a more personal conversation. Our first step on this journey is, we have a long legacy providing protocol translation support, right? Different systems speak different languages. And of course, where we have restful API interfaces, the newer -- some newer technologies like Kafka, they're using different protocols for how they are communicating the kind of ways that you need to interact. And so with Version 10, we're providing new nodes that can take the protocol from any of the other ones that we support in our data power gateway, and bridge that over to Kafka, bridge that over to AMQP. That adds to the events framework that we already support being MQ and JMS. So basically doubled the number of event-centric endpoints that we can work with. Also, another pattern that you can imagine is subscribing to a Kafka topic. So it's watching for those changes. And then taking that and sending out a new protocol on the other side. So those are capabilities that are part of data power. If anybody on the call is a data power, multiple protocol gateway user, you get those values. That same Kafka support, then can fold up through our gateway scripting into the API later as well. This way, you can afford the API layer the same protocol translation with the event framework. And you could see a different patterns that might emerge for you based on, again, how this solution architect is envisioning, APIs and events need to come together. So again, broader support here in Version 10 of that, with additional support for Kafka. And you see Events Stream too, that's our IBM Events Kafka version, but Kafka in general is supported as well as the AMQP protocol. So those are the first 3 pillars. The fourth one here, of course, then is the better support in the microservices framework for operators, this operator. And it's not only that and it's not only OpenShift again, this is support that we had for Kubernetes in general. We're also doing other things. So while operators help us with the resiliency and restart capabilities, scale up, scale back, these types of things, there's other investments that are going into our Version 10 for looking at things like self-healing for continuous availability, simplified, automated backup and restore around the components that are running in the microservices architecture. So deeper support for the ops roles within the organization to get to higher levels of availability across that hybrid cloud architecture. So in addition to those 4, you're going to see some other things that are new and emerging. This one actually is a bit more IBM-wide topic, which goes into our support for -- sorry, we're just seeing a couple of questions came in. I'm going to just pause on this one and just look what the questions were. Are we going to be able to see the interface of the APIC today? Actually, that was a great segue then to this slide. And apologies if my audio was cutting in and out. Hopefully, that's stabilized. I did note that a couple of minutes ago. We had some weirdness there. Yes. So thanks for asking that question. We'll look a little bit more at that. And somebody who'd like to get a comprehensive road map. Yes, we could definitely do deep dives in other settings, reach out to me, whether you're a customer, a partner, the team is poised to take a lot of those interactions going forward. Yes. So on the question of the APIC interface, what you saw on the debug slide where we were looking at the new -- debugger, you might have noticed that it looks and feels a bit different than Version 2018 did. And what we've been doing is adopting a set of components that are open source. IBM actually is a primary contributor to the Carbon project. Carbon is a sort of react technology standards for how the interface will act and react to the user experience. So this is something that we've adopted across all of IBM software, IBM middleware. And you'll see increasingly that IBM software looks and feels and works the same way regardless of which technology you're operating in. And so this is a good accelerator. If you are working in one piece of, let's say, the cloud pack for integration in doing things in MQ, and then you want to adopt our Kafka, those actually increasingly because we're using the same components, work the same, look the same, feel the same. And again, that's a great productivity accelerator. So the simple and enhanced user experience is, of course, that. We've introduced in the API Connect UI specifically new search features and discovery that would be, primarily in the manager, where if you're in one of our screens, it's got an enhanced back end search to filter through very large API catalogs and bring you the kind of assets you're looking for. Then, of course, because we're adopting Carbon across all of these components, when API Connect is part and parcel of the cloud pack integration, you'll see it's looking and operating the same way as other ones. So these couple of screens, the debugger screen, of course, is the other one that we have here in the presentation for today. Some other things in addition to these experiences that we just talked about, new auditing and tracking information. For those who are interested in some regulatory controls, that they need to satisfy additional auditing and who is changing, what are they changing, the kind of things that people are doing when they log in, and when they log out, and more robust work for all of that auditing in the Version 10 release. Portal customizations, when we did Version 2018, we introduced APIs across the board for anything that you could do in the manager, where you build a plan, subscribe, these kind of activities. You can interact with the APIs, you don't have to go through the user interface. With portal though, we hadn't actually automated to that same extent or opened up the [indiscernible] as it were to the same extent. With Version 10, we introduced new APIs so you can do the same thing with your portal. And where people were really interested in doing this is the life cycle around portal development. You may, in a development environment, customize the look and the feel and the interaction model that you want to tune us exactly for your external branding as it were. And then you want to take that and promote that through your test in QA and into pre-prod and prod the same way. The APIs around portal in this release, allow you to do that. And so that design development experience interacts the same way across your software life cycle as everything else. Control for customer onboarding. Many people look at self-subscribing. I can go to the portal, whether I'm an internal or external user. And your API product manager may allow for subscriptions. And so I can go and self-register, and of course, then I have access to the APIs under this plan. While a user -- an end user identifying themselves as interested in that way is really interesting. So this way, you have a pull model for your APIs. You still may want some levels of approval. And so in Version 10, now we allow for approval of that onboarding experience so people can still pull, but you, as the product manager, get the final word on whether or not they're approved to actually consume them from the APIs. Next one, governance for universal policy enforcement. We have these global policies. And oftentimes, we say we want consistency in our API program. We don't want everybody building APIs in different ways. One of the great ways even with Version 2018 that we had was these global policies. I can build them once, everybody inherits them. They don't have to spend time even thinking about it, basically just operates that way, and we've asserted governance. And we've expanded our policies to do some pre-flow actions. And so if you think about -- before it ever gets into the domain of the API assembly execution, we want these things to execute, to exert higher levels of control and maybe even shortcut the fact that it ever goes down to that layer. And so we now support global policy for these pre-flow actions. And then the vanity endpoint support, that speaks for itself. So hopefully, what you're getting -- and we're getting towards the end of our 30 minutes here, but it's the sense of the value of Version 10 to the different players around the API life cycle. So depending on who your team is and maybe the API developer, it might be then able to use GraphQL as a great accelerator for their program that they're putting forward to the community. But they'll really get some benefits out of that testing, automation as a way to get higher-level APIs, identify a problem sooner, the interactive debugger, again, accelerating a lot of what they're doing. The API product manager, similarly, the fact that he can trust GraphQL now as a part of this API program is wonderful for him, the ability to take those tests and put them into production so he can monitor the quality of the program. Again, great accelerator. The API consumer, he -- of course, better quality APIs, the ability to consume through one query, that GraphQL query, and retrieve a lot of information and good for him. Your DevOps teams, all of the automation that we put into microservices architecture through the use of operators, again, a great benefit to him. And finally, the IT architect, trying to work through events and APIs and manage it in a consistent way. We're making great strides in our ability to do that, with the protocol support between them. I know we're at the top of the time here. There were about another 6 questions that had come in. What we'll probably going to need to do is take these offline to the IBM community and get everybody answers in that venue. And I will say, Jeff, out there. You noticed the typo on my slides. Thank you for that feedback as well as one of those comments. So with that, I'm going to just point to a few things that are maybe, call fashion. There's been a tremendous amount of writing that we've done through our IBM team in white papers on the topics like security and testing and aligning to an agile pipeline. And so these are great papers. If you're new to API in general, where you might want to start is the recommendation for the API Economy Center of Excellence. It's a great way to think about, how do I put a program together? What are the key roles? Who are the people? And what are the kind of activities that they'll do, that we want to make sure they're part and parcel of our API program? Some of the other ones, really like the bottom right, where it's agile API development, that's -- I'm looking to get to higher levels of automation around how APIs are deployed into production. What should I be thinking about? And then how does API Connect help me in achieving some of that levels of automation? So some great papers. And again, I would encourage you to find those. And we'll put these URLs also out in the community. Feel free to snapshot this slide also if you're looking to do that. Finally, I'm just going to say thanks for spending half an hour with me. Very excited about Version 10. Both these benefits and API Connect that we've reviewed today as well as one of the ones in data power, which is that event protocol support also for our data power customers. I think these are great accelerators to building new solutions as you're doing your API-led Innovation work in your respective organizations. Again, feel free to always contact me. I'm [email protected]. Happy to get queries coming from all of our friends out in the community. So thanks. [ Jess ], anything else to close out?

Just a friendly reminder that everyone should expect an e-mail with the recording, slides and the link to the discussions and for additional question. Other than that, we hope you have a wonderful weekend. Thank you so much.