Why Digital Transformations Need Modeled APIs

Application Programming Interfaces (APIs) are what make the moving parts of automation solutions connect and work together. They are often viewed as a technical concern, but their true value lies in how they are modeled to align with the business.

In this podcast, I consult with published author and API guru Erik Wilde, author of "Continuous API Management" and Digital Transformation Catalyst at Axway, on how we now need to approach the design and management of APIs in digital transformation environments. We discuss APIs for different communication protocols, the importance of modeling APIs in relation to business capabilities, and which traditional API practices may or may not still be relevant in a digital enterprise.

Listen to the podcast here (transcript is below):

Also listen to the podcast at Spotify, Google Podcasts and Apple Podcasts.

About the Contributors

Erik Wilde is an API expert and best-selling author of several books, include his latest title, "Continuous API Management". Erik acts as a Digital Transformation Catalyst at Axway.

Follow Erik at: www.dhirubhai.net/in/erikwilde

Subscribe to Erik's YouTube Channel: www.youtube.com/c/ErikWilde

Erik's Latest Book: Continuous API Management

Thomas Erl is a best-selling author and oversees the Pearson Digital Enterprise Series from Thomas Erl. He is the Founder and Senior Advisor for Transformative Digital Solutions Inc. and the CEO and Director of Learning and Development for Arcitura Education Inc.

Follow Thomas:?www.dhirubhai.net/in/thomaserl

Subscribe to Thomas on YouTube: www.youtube.com/@terl

Books by Thomas:?www.informit.com/authors/bio/f8d115ad-20cc-4d42-ad99-7e349d34f90d

Podcast Transcript

Thomas: Hello and welcome to another edition of the Real Digital Transformation Podcast. Today we have with us. Erik Wilde. Erik is a digital transformation catalyst at Axway and a published author who's been writing books for decades. His most recent book is Continuous API Management, published by O'Reilly, and Erik has a YouTube channel getting APIs to work at youtube.com/erikwilde, spelled with a K W-I-L-D-E.

Erik, welcome to the session today. How are you?

Erik: I'm good. Thanks Thomas, and thanks for having me. It's great to be on your channel.

Thomas: Thank you so much, Erik. So before we get started, tell us a bit more about what you do at Axway and what work you're doing right now in relation to digital transformation and APIs.

Erik: Sure. Yes, Thanks. So my work, so Axway, for those of you who don't know Axway, Axway is a software vendor. It has been around for a long time, over 20 years now. 11,000 customers worldwide, and the products of Axway are in the business-to-business integration space and specifically in API management. So like many other vendors, Axway is in the API management space.

And my role specifically is not so much to talk about our products, but to help our customers to do the right thing with the products. And that is what I find very interesting and exciting to see that digital transformation, of course, in most cases is not so much about just getting the right product and then everything will be fine.

It's always something that challenges you as an organization. It challenges you in terms of how you built your teams. It challenges you in terms of figuring out your business model where you want to go. And seeing all of these things for me as a technologist is really interesting because it also gives me a good idea to understand that technology can help in many ways, but it's never the only thing that's necessary.

So I spend quite a bit of my time, not so much with just looking at technology, but really with understanding what organizations are struggling with and trying to help them to make the most out of their API journey.

Thomas: Super. So speaking of APIs, let's first establish now in 2022 APIs are necessary for everything in our digital transformation environment and ecosystem to interconnect and function together because we do have different types of platforms, systems and technologies that have to work in concert in order to achieve our automation goals. So how would you describe the practice of API design and management this year as it has evolved? As it exists today, that field of practice, how would you define it?

Erik: That's, That's a good question. It is a field that has been around for quite a while now. I would say that what you see by now over the last couple years, you don't really have to explain to people anymore what APIs are, so they understand that APIs are necessary and what they do. I think what you see now more than before is. Two, I would say two major changes. One is that the API field is seeing more diversity, so now you have this idea of REST APIs. You have this idea of, of query based APIs like GraphQL. You have the idea of event based APIs. You, you hear a lot about Kafka and things like that, so, So the diversity in the API space has increased. And I think the other thing that you see now that becomes more and more clear is that organizations understand that APIs are not so much about just technology, but they are about exposing business capabilities.

So really understanding that even though it is a technical thing and it's very hard, but the value that you get out of APIs is not just because of technology, but also you make the right things available. So you need to focus on building the right kinds of APIs, and I think this is where we see more and more businesses understanding that it's not good enough to just have APIs, you need to have the right APIs.

Thomas: That's interesting. So, within a digital transformation solution environment, when we model APIs, we do so ideally so that each API corresponds to a well-defined business capability. Is that correct?

Erik: Yes, that is. That is the ideal case. It's correct, but it's not what always happens.

Thomas: Tell us what always happens. Tell us a little about how or why that does not happen and the consequences of not paying attention to how we should be modeling our APIs.

Erik: It's, Yeah, thank it's, it's a great question. I , the funny thing is I basically have this conversation every single day with different companies, right?

But so, so here's my observation is that the very top level realizes that yes, we wanna do digital transformation, and yes, APIs are a necessary part for doing that. So there is some kind of mandate where leadership says digital transformation is what we'll do. APIs are something that is needed to get this done, so let's do APIs.

And then I think there's a big gap between this messaging and then the more technically oriented folks saying: Well, we have APIs, we have hundreds or thousands of them. We have been building them for a long time so it's all good, right? We,?have APIs mission accomplished, and I think this is where oftentimes there really is a lack of communication between what are the APIs that we really need, right?

It's not made clear enough that we need business aligned APIs because just having technical APIs is not going to cut it. And then I think there often is this vacuum of, on the one hand everybody thinks: Oh, things are going great, we are having APIs, so things must be going well, and nobody really looks into, do we really have the right APIs.

And then you read all these articles and surveys by large companies like McKinsey and, and, and similar ones, right, who say Companies are disappointed by the return on investment in their digital transformation, and I would suspect oftentimes it's because there is this execution gap between understanding we need APIs but not really making sure that we have the right APIs and the right building blocks so that we can really get this digital transformation engine going.

Thomas: Okay, so let's imagine that you are hired as an API auditor for an organization that did not get the ROI it was looking for, and perhaps suspects that it may in part be due to some poorly modeled APIs. If you were to look at an environment such as the one you just described, where the technical professionals created a lot of APIs but perhaps did not pay attention to how they were modeled,?what is it you would look for?

How would you assess an API or a collection of APIs in terms of their quality or their effectiveness in support of achieving goals specific to digital transformation initiatives. What would you be looking for?

Erik: I think, I think you have to go in two directions. So one direction is basically top down asking what are we doing as a company?

And a lot of organizations are doing this in some shape or form, right? They build some kind of business, business capability model or some other semiformal way of how they break down what they are doing as an organization to create value. And then I would ask for all of these capabilities that we have now identified, do we have APIs for those? Right. So that would be the top down way, just looking at how many of our business capabilities do we really have in a digital representation? And if that number is not looking good, I think that's kind of a warning sign.

And then there's a bottom up way where you would say, Okay, you have a catalog of APIs. Now explain to me how those contribute to business value. So what is the, the business value proposition of those APIs. And I would suspect for a lot of those technical APIs, they don't really have that associated with them, which is fine at that technical level, but that again would be a warning sign if you have a lot of APIs where you, where you know that you need them for technical reasons, but you don't really have a good way of explaining how they create value for the business, and if both of those signs are showing up, I think you have a pretty strong indication that there is a gap to be filled where you need more APIs that are being designed from a business perspective so that you get these business aligned APIs.

Thomas: Okay. I, I've been in projects, I've, I've seen conversations, I've been part of conversations like this, So I'll, I, I just I'll, I'll be the devil's advocate for a moment.

Erik: Sure.

Thomas: Erik, And so I'm the technical guy and I'm saying: look, we just want these things to connect and efficiently exchange data so that the system, the solution performs to meet or above expectations. What is the business value of modeling them in one way or the other? Where, where do you actually get more return on investment??If, if we model an API so it corresponds to business entities or business processes in a certain way, as opposed to just being an efficient technical endpoint.

Where does your ROI come??

Erik: I can tell you a little story here, and that is actually true. So I went to a company and they had this, this thing where they had a lot of APIs, but they weren't quite getting out of it what they were hoping for. And I, I looked at the APIs and I asked them what they're doing, and they had told me that like to achieve one simple thing that that, I think that was kind of like opening an account or something, I don't quite remember, but it was like a relatively simple business thing to do. You had to use 17 APIs and you had to use them in a very specific way, and then it worked, but. Unsurprisingly, nobody used those APIs because it was really hard for developers to understand how to orchestrate those 17 APIs to integrate that functionality into their apps, Right? And then, And then I ask them, Why don't you just create one API that does that? And then developers, let's say, of a new app can very simply integrate that functionality into their app because it's one API that is well documented and works relatively easily.

And, and their explanation at that point was to say, Well, that sounds like a lot of work. And, in the end, also, we are actually measured against how many APIs we produce. So no, we're not doing that. But I think that was, that was one of those indications where if you're not thinking from the business capability side, then you're not really aiming at this reuse. That really is, I think this holy grail of APIs where you would say, Once I have built this capability, it should be easy for others to just reuse it without me having to explain them how this is done, and then they can build new applications using it. They can build up new business cases, making use of that functionality.

And if I don't have an API, that makes it easy for people to do that. And it's just like a technical end point then at many. In many cases, you just won't see that reuse. And then that is where I think the investment, just suffers. It just not, you don't get out of it what you were hoping for.

Thomas: Right. And because it's not really reusable, the next team that needs to build something that requires the same data, they'll just build their own API.

And then?you'll end up with a lot of redundancy in the environment. And then you'll end up with coupling issues where if the business logic underneath the API changes, it'll impact multiple different APIs across multiple solutions. And that's where we can get into a bit of a mess.

Erik: Yes. I think that that's exactly what you get and end up with. And that's, and that's I think, that's really the, the promise that APIs are making us by saying, if you built the right APIs, you get as much reuse as you can expect, and you might still end up with occasionally duplicate functionality here and there because somebody didn't like what they were seeing or whatever, but at least I think you maximize the chances that people can reuse things without having to really understand how they are implemented because they have interfaces that are well defined, easy to understand, hopefully in line with some guidelines that you have, and then that makes it much easier to actually reuse those interfaces.

Thomas: Mm-hmm. . Okay. So coming back to digital transformation, I mean, what you just described sounds like a solid best practice for working with APIs, regardless of the overarching, context of the methodology or the business solution, approach or strategy, but going now back to digital transformation and its specific objectives in terms of, incorporating data science technology in terms of being more data driven, data centric, and in terms of, achieving greater levels of customer-centricity, customer-centric features and improving customer experiences. When we look at those strategic goals of what we're investing in, in a digital transformation, how does that change? How we approach API design or API management or governance? Does it change how we model APIs to relate to the business or not?

Or, or are we, in your experience, are we still following the same or similar practices as we were three or five years ago?

Erik: I don't think it changes necessarily so much how we model APIs. I think that has been pretty constant for a while now, that?the overall mantra always is hide implementation specifics, right? Make it as easy as possible to understand and use. So just turn it into a good interface in the end. So I think that has been pretty constant over quite a while now. I think what we do see changing now, and, I just hope that we will see more of this in in the next couple of years, is that people also understand that just defining, implementing and having APIs is not good enough. What really drives value is when those APIs are getting used and reused. So you also have to think about, how do I make sure everybody knows about my APIs? How do I make it easy for people to find them, to use them to understand what kind of building blocks are there are there any ways how I can help people to better understand how they can maybe create new value chains in the organization by saying, Look, we have this wonderful new customer insight API that allows you to better analyze a customer's recent behavior and then you can make some predictions around what they might wanna do next and, and if that is something that you have developed and that has potentially a lot of value because now you can make better predictions what customer might prefer, then it would be a very good idea to make it very clear to everyone in the organization that there is this new capability that they can now use so that they can improve what they have or maybe they can even come up with new ideas of what they can build because now they can build something that is better targeted. So I think this is a shift that we're only seeing, I think, pretty early on right now, but really this shift of not just saying, “Oh, we have APIs, so everything is good”, but really to say, “No, no, no, no.

What we want is those APIs have to be used” and we have to actively help with that. We have to make it easy to find them and use them because only then they will drive the value that we want to see from our investments into those APIs.

Thomas: So how do you achieve that, especially in a larger organization, different project teams working on different things?

To introduce that ability for them to discover APIs that exist, to give them the opportunity to reuse those APIs. What, what type of management or governance mechanism do you introduce for that?

Erik: That, that's a very multifaceted question. But now, now I have to actually go into kind of product mode for just a minute because that's, that's the reason why I joined Axway about three years ago.

So, so one of the things that we've seen is that a lot of organizations are having multiple API gateways, right? So they may have maybe they have an Axway gateway they also may have some, a Apigee gateway or some, some MuleSoft, whatever, right? Like there's, there's a whole bunch of different vendors out there and oftentimes large organizations just end up with different solutions for historical reasons or because they have different business units that make different purchase decisions, whatever.

And what we have and what others are building now, also because it just makes sense, is to have this unified governance layer where you can manage all of your APIs regardless of where they are technically managed. Meaning that you now have one catalog that has all of your APIs, regardless whether they are managed in MuleSoft and a Apigee in Axway in Azure, in in Amazon, right? It doesn't matter. So you see them all in one place and then you can build a catalog, you can build a portal, you can build a marketplace. And I think this is something where organizations now are seeing that this is really the direction that they have to go in. That's, I think, a direction where we have seen the market really going very strongly in that direction. And I think this is also something where, in particular, larger organizations now are really looking at products that will help allow, will help them to do that.

Thomas: So is this similar in concept to what UDDI was for SOAP and and web services? Is that the same idea? A central service discovery repository?

Erik: Slightly maybe in, let's say concept wise, yes, but practically speaking it's a little different because UDDI was very tightly coupled with just being about SOAP and it, it was, it was not, I would say, the greatest success on earth. What we see now with these unified catalogs is that they try to be as agnostic as possible in terms of API technologies because we have more diverse landscapes nowadays, so that in this catalog of APIs, you can have REST APIs, you can have GraphQL APIs, you can have event based APIs. You could even have like file transfer definitions, right? Which also you could say are some kind of API because it's also parties exchanging information and the more diverse your catalog can be, the more of your API landscape you can actually cover and, and make sure that everybody is aware that there is an API for that. And it doesn't really matter whether somebody designed it in GraphQL or in REST. As long as there is an API, it's good to know that there is one that I can use.

Thomas: You mentioned now the support for diverse protocols that the central registry or, gateway provides support for going back to what you were saying about APIs needing to be reusable or ideally being reusable to provide long term return on investment, and also just for the ability for the organization to be agile and not have to redo change things or redo things that they did before because they were done redundantly. Does, how common is it for organizations now for digital enterprises to work with? Multiple different protocols, so REST alongside open GL or alongside other protocols. Does that not undermine the objective of those APIs being reusable? Even if they're modeled well, but then if you have different APIs based on different protocols, doesn't that pose a challenge for business value and reusability?

Erik: You could see it that way. The reality, I think nowadays really is that every organization that is a little bit larger will have different APIs, API styles, and API technologies in use sometimes just because that's what their software exposes, right?

So for example, if you have. SAP and you want to use some of those SAP APIs, well, you know, you, it's not your choice. They come in a certain flavor and then a certain technology. So either you use them that way or you don't, or you have to reimplement them. But that might not be that attractive. And I like, personally, I always thought that, just trying to say we only use one technology is in many cases, not such a great decision to make. If you have a large organization that does many different things and that evolves in many different directions,?we've seen I think we've seen companies trying to do this in many different shapes or forms, right? It's like we only do Java, or we only do this or that. And I think over time most organizations realize that it's not worth the effort. You have to control your ecosystem. I mean, you don't want people just to try out things because they're curious. They, they should have a good reason to move away from, let's say, the set of recommended technologies. But if there is a good reason, then it makes sense.

And if you are in a position that you can manage this because your tooling allows you to do that, then it's a decision where it may be more productive to say, Okay, now we have three different kinds of APIs. Instead of trying to say, well, every API that we design has to be REST or has to be GraphQL and then to realize that for some APIs, this is just not a good technology to expose things.

Thomas: So that is considered an acceptable level of redundancy if we have a business capability that we make available in three different APIs based on different protocols or technologies, that redundancy is considered reasonable given the fact that it is just a more practical approach to managing our overall ecosystem.

Erik: Well, I mean, that's a difference, right? So I wouldn't necessarily say that if you have one capability, it's maybe a great decision to say, Well, let's build three different APIs and three different technologies for this one capability. I mean, you can do that if there's a good reason for that, but maybe that's really something where you should think about it two or three times, but if you have three different capabilities and one seems to be very process oriented and the other one seems to be very data oriented, and the third one seems to be very event oriented, then it very well makes sense to say.?Well for one we use REST, and for the other one we use GraphQL and for the third one, we use some event driven API because the nature of the problem that we are trying to solve is a little different and we have different technologies who are well suited for these different kind of problem spaces. And then we just pick the best tool out of the toolbox that we have, and then we end up with different technologies, but they're good solutions in their own right for the problems that they're solving.

Thomas: What about wrapper APIs?

Whereby we have a API that we need to work with, let's say from SAP, but most of our solution uses REST or uses a certain protocol that is not supported by a proprietary API. How common is it these days to simply add another API on top of it to expose those functions with, via the protocol and nowadays messaging technology that we are using now, how common is that now? Is that, is that a best practice? I in terms of preserving consistency across API technology, or, or does that move away from a more diverse approach that we may want to support just out of practical considerations?

Erik: That's, that's a really good question. So it's interesting to look at the history a little bit. I think when I was, I was at CA before I joined Axway, and I think back then, so that's, let's say is 5, 6, 7 years ago, I think back then there were more cases where customers would buy a gateway just for doing these kind of wrappers, because the gateways, I think pretty much all of the gateways that you can buy have this kind of functionality in there where they can kind of consume, let's say, a SOAP API and then publish or REST API out of it. And you have to configure it a little bit, but you don't have to implement the whole thing yourself. And I think that was something that was pretty popular a couple years ago in particular, maybe in this transition period between, SOAP and rest when a lot of organizations were trying to kind of “RESTify” their SOAP services.

I think now you see that a little less maybe because REST has become, just the de facto standard, at least at some level and is a little bit more stable. So there is not this transition period anymore. And also because I think organizations have become more comfortable with the idea that, well, if an interface uses a certain technology, so be it.

We don't really have to wrap it. Maybe at some point when the technology gets so outdated that we cannot expect anybody to directly use it anymore, but other than that, it, we shouldn't waste our time kind of always, you know, moving from technology A to technology B to technology C, and instead, if we just say, well, we can use all of them, then we can really focus on the capabilities that we're exposing and not so much how we're exposing them.

Thomas: Super. We're almost out of time. This has been a really interesting discussion. I think we should continue this, and have another, um, podcast dedicated to it. But, let me just ask you one final question. So, If we are looking now at digital transformation initiatives, if we take into consideration the incorporation of data science systems, AI systems, neural networks that we may be delegating decision making logic to, or that we may want real time-data intelligence from, for our automation systems to be more responsive at run time, more, more responsive to customers, more responsive for performance reasons and, and just, you know, to behave more intelligently. To perform better in the market that we operate within. If you're talking to management about the importance of APIs, about the business value in creating them properly in managing and governing them properly, and they ask you well, to me, APIs are low level – they're down there. They do a lot of technical stuff. We are concerned with the front-end, the customer experience, how performant the system is when it's out there in, in a digital market. Explain to me why we should support and fund and be concerned about how we approach APIs beyond just modeling them around capabilities, but just in terms of their business value to, to help connect that consideration with all of what's being discussed around digital transformation, data science, data intelligence, customer experience, where, where's the connection? Where's the business value? Why is this important specifically to what we're trying to accomplish? If you're describing it not in a technical manner, but from a business perspective for managers, executive stakeholders, to understand.

You're there standing in front of the conference room with 20 people looking at you. How, how would you articulate that? I would probably drive it from the outside in and then directly go and say, Look, if you are building, let's say an app, a mobile app, let's say on a, on a phone for your customers, and you want to build a good experience that is at least as good as your competition, then very likely this mobile app will directly use APIs, right? This is what APIs are all about. You have an app that the customer is using and then they are doing some interactions with the app. Let's say they enter some data or they, they take a picture or whatever it is that your app is doing, and then at some point it's up to you as a business to react to that and to maybe give them a recommendation or make them an offer or decide that, Oh, this customer seems to be doing this or that. So maybe as a next step we should do. Whatever it is that you're doing. So in that case, right, you, you need this, just this very simple connection from this app that the consumer is using to interact with your organization.

And this app is your, is your proxy in the hands of the consumer. And that proxy needs to behave as well as possible. And that connection where the app is talking to, to back ends and is maybe getting recommendation is, is starting some data analysis process that should give you some, some insights as quickly as possible.

Typically, Right. You would say something around like 200 milliseconds. So, so it's, it's critical that you make the right things available that then the app builders can use and. And then somebody, let's say creating a different app, not on a mobile phone, but let's say this app is running in a car and a car entertainment system, they should be able to reuse that expensive capability that you have built to analyze user behavior or make recommendations and, and the more easy you make it to reuse those capabilities.

From all the different places where you are providing user experiences, the intelligence easier it is for you to build more user experiences, to build better user experiences, and to make sure that users really get the most out of the capabilities that you have somewhere in your IT landscape.

Thomas: Super, very well put.

Thank you. So before we conclude, Erik, could you tell us a bit more about the YouTube channel that you're running and what kind of content you publish and, and your plans for that channel?

Erik: Oh yeah. Thanks for giving me that opportunity. Yes. So yes, my YouTube channel is called Getting APIs to Work. You can just Google for that.

I'm sure you'll easily find it. It has my name added Erik Wild and, and the, the type of content that I'm producing. Really, it's, it's not a corporate channel. It's really kind of a API Community Channel, I would say so I mostly, it's really, I talk to people who are working with APIs in some shape or form.

Not so much really talking about like deep technical things, but more about trends, tools, experiences that people have made, what worked for them, what didn't work so well. So my goal really is to just. Give people like a little food for thought in the API space to point them to interesting resources. And I try to do this on a weekly basis.

And so if you're interested in APIs really, and you are interested in conversations around APIs, check it out and maybe subscribe. That would be great.

Thomas: Yeah, I think it's very valuable to have a resource like that because what you put out there, the discussions you have, the advice you provide, I mean, it, it's technical guidance that is not often easily obtained, especially because your channel is vendor neutral.

It just deals with common issues and technical considerations from what I've seen, and often IT professionals, they learn about APIs through a vendor platform and from the vendor's perspective, which,, is sometimes limited in terms of, you know, what's actually happening in the industry as a whole. So I think, your YouTube channel really fills that need, I, think it'll be valuable to many people.

Erik: Yeah, thanks for saying that. And also, I, I really have to get a shout out to, to Axway here because they support me creating this channel, even though I'm not promoting Axway. Right. So, so they really help that this kind of content is, can be produced, is made available to the API community.

And yeah, my goal really is to give something to people where they can learn from it. They can maybe explore things and, and if that goal is accomplished, then I think the channel really serves its purpose.

Thomas: Super. Well, thank you so much for your time today, Erik. I've been following your work for many years.

You're one of the renowned API subject matter experts in the world. Grateful that you could make time for us today, and I hope we can have an opportunity. For another session soon to get into some of the other topics I had in mind for today by, that we ran out of time for. But in terms of what we covered today, I think it was a very good discussion.

Erik: Thank you again. Thanks for having me, Thomas. It was great to intelligence be on your show and yes, for sure if you're up for it, let's have another one. I always like talking about APIs.

Thomas: Super, thanks again. Bye for now. Bye everybody.?

Please note that although this transcript was professionally prepared, it has not yet been reviewed by the contributors for accuracy. Please report any errors to the newsletter editor.