APIs for the Right Business Case
Ep. 14: Erik Wilde, Catalyst at Axway
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us is Erik Wilde, Catalyst at Axway, author and standards contributor. He helps organizations on their Digital Transformation journeys, making sure that vision, strategy, and technology are aligned, and that they are complemented by business and organizational initiatives.
Lawrence Ebringer, Moesif’s CMO, is your host today.
Listen to the episode on SoundCloud above, watch it on our YouTube Channel or download it on Apple or Google.
Table of Contents
- 1:55Drive Value From Your APIs
- 3:53Focus on a Super Valuable Business Capability
- 8:23BSchool Students Focus on API Biz Cases
- 11:54The Internet of APIs - APIs Under the Hood
- 15:17The Best API Style Is Determined By The APIs Purpose
- 17:13Why Security Is Important to API Health
- 23:30API Observability vs API Monitoring
- 26:28Measuring API Success via Metrics and Conclusions
- 30:15The Future of the API Ecosystem as a Whole
Larry: Welcome to Episode 14 from Moesif’s APIs over IPAs Podcast Network. I’m Lawrence Ebringer, your host today and the Chief Marketing Officer of Moesif, The API Observability Platform.
Joining me is Eric Wilde, prolific YouTuber, author, standards contributor, Catalyst at Axway and, most recently, guest lecturer at UC Berkeley’s Haas School of Business.
Eric’s been working in web technologies and APIs for most of his career. Although his background is in computer science, he believes that technology is rarely the factor holding back organizations, so now he focuses on helping with strategy to ensure companies succeed.
Welcome Eric, where in the world do we find you?
Erik: Thanks, thanks for the warm welcome Larry and thanks for having me. Right now, you can find me in Berkeley because I was planning on attending an on-campus course here for four days, like the first four days of this week. Well, like so many things, last minute it turned into an online thing but I’m still here. So yes, I’m in the East Bay and I think you were somewhere down the peninsula right.
Larry: I’m actually just across the bay bridge in San Francisco. Berkeley’s quite a change from your usual home. Where do you domicile for most of the year?
Erik: I live in Zurich now. I used to live in Berkeley for quite a while, when I used to work at Berkeley but we moved to Zurich a couple years ago. We still like to come back here because it’s just such a lovely place.
Drive Value From Your APIs
What should API professionals be focused on today? People no longer need to be convinced why APIs matter, they’re popping up like mushrooms. Rather, the focus in on what makes a good API, how do I get my team to design them and how do I support them with a platform.
Larry: Right, that is very true. That is very true.
Jumping right in, you and the Three Musketeers recently released a new edition of the seminal work continuous API management. Besides the covers’ color photo, what’s new and how has the API ecosystem changed in the last three years since the first edition?
Erik: That’s a good question. What’s new is to some extent, you could say that by now what happens is that we have to less and less tell people why APIs matter, that they are important, and how to design APIs, so to speak. We have to talk more about how to do that at scale.
Like a good friend of mine, Isabelle Mauny, on some podcast said, “APIs are popping up like mushrooms left and right.”. And I think that to some extent is true. I think as more and more organizations who didn’t see that, of course, they are using APIs, everybody’s using APIs. You cannot use computers nowadays without using a lot of APIs.
But managing those and figuring out how do I get to the APIs that drive value for an organization, not just “we have an API so probably good things will happen”. But also understanding what is a good API? What is maybe not such a great API? How do I get my teams to design good APIs? How do I support them with a platform?
All of these things, I think we’ll still see momentum picking up in the industry in terms of understanding that APIs are not the only thing you need, but they can be a limiting factor. So it’s important to really manage that, and not just hope for the best.
Evaluate and optimize your APIs with Moesif’s powerful API monitoring.
Focus on a Super Valuable Business Capability
An API is really just an interface. Delivery of the business value is important, but it’s not the most important thing to consider when developing an API offering.
Larry: Hmm, very interesting. What a great segway to one of your pins tweets, which reads, “It’s more important to build APIs for the right things than it is to build the right APIs for things”. I mean, not only is that a tongue twister but it’s a little bit difficult to unpack. Could you unpack it for us and tell us what you mean by it.
Erik: Sure sure.
I think one of the important things about an API is to understand it is really just an interface. An API is the delivery mechanism for a capability and sometimes I think, us in the API space, we overestimate the importance of the delivery, over what is being delivered. What I mean by that is saying that if you have the nicest API in the world, wonderfully documented, perfectly designed, using all the right http methods, and doing all these things right, but it provides access to a capability that nobody has a need for. That API doesn’t make any sense, it may be a beautiful thing to look at aesthetically, but certainly will not drive any business value.
On the other hand, if you have a super valuable business capability that has, maybe not the greatest API, but one that people can somehow live with, that will be much more valuable.
In the end I think it’s more important to at least, at the very first step to think about what is it that I’m designing an API for, before you jump right into, “which http method do we use”, and you know all these kinds of things. I think sometimes we really get to focus on the technical part of the design, we don’t really focus enough on what we are actually designing as a product, and not so much just as its delivery.
I think the recent books and I think we have a nice wave of books that are published right, so Michael Amundsen just published one. There was one by James Higginbotham recently, right. There’s one by the API Handyman and in all of these books, I think are now focusing on the whole process, not just “What do you do technically?”, but “How do I design the right thing?”.
I think we are understanding that more and more, but it’s still something that I think we have to focus on and make sure that that part of the design is an important step. We are very careful with that before we jump into the technical details.
Larry: Very interesting, yeah. It’s interesting that, when we sign up with new customers, classically, the CEO is the product man and the product, the business case and all of the issues involved in making the complete product are far more important, we see, then actually implementing the API platform in the right way. So your analysis of the product manager having a very important and strategic role in API platforms is something that we see as well, in our customer base.
Erik: And it is, I think, in the end, right? It is important to think about what is the value that I’m producing and some of the examples that are used all the time. Like Twilio, Stripe and all these things, I mean I like these examples as well.
But in the end, Stripe is not as successful as they are, because their API is good. But Stripe is successful because everybody needs payment services and they provided an API for that right? That’s the main reason.
And then, they also did a good job at designing that product right? But without that initial idea of thinking about “Well, really everybody needs payment services and nobody wants to do it themselves”, so why not have a good API for that right?
That was the thing that turned them into the company they are today, and then they just executed well on that which is also important right.
Learn more about who uses your APIs and how with Moesif.
BSchool Students Focus on API Biz Cases
UC Berkeley’s Haas students know lots of business is going to APIs. Teaching scalable and sustainable business models prepare students for the ever-changing API landscape.
Larry: Very very true, very true. Yeah I mean, I think there were a lot of examples out there, where you might have a great implementation, but you don’t necessarily have a great business case to justify your company, and even though we’re in a very frothy point in time, in the API space. I think the market and investors still look for revenue and traction in the marketplace, as opposed to a really glossy, well designed API implementation.
Erik: Yeah, that’s the thing right? Again, this week for four days, I basically spent the Business School here, and I mean they understand that APIs are important because there’s a lot of business going to APIs. But, when they look at APIs, they don’t get excited about “Well, do they use HTTP Post in the right way?”. They ask questions like “Well, is there a business for that?”. Like what’s your business model? How are you going to build a sustainable business around delivering that thing as a service? And then maybe you should also design it well on a technical level, but that’s really not the main thing. It’s important but it’s not the main thing and it’s not definitely not the only thing that we should focus on.
Larry: Right, right. We recently had on our podcast a lead API product person at a large enterprise software company, and her task was to really come up with the whole plan of implementing some of their functionality over an API. Some of their customers were asking for it, but that wasn’t enough justification. It was interesting talking to her that the most important aspect of getting this right was that primarily it had to be a center of revenue. It had to have something that moved the needle for the executive C suite team to say “Yes, this is worth investing in.”.
Erik: Yeah and if you do it well, you can use the API also to understand a little bit what people are more or less interested in. A little while ago, I talked with Tanya Vlahovic, who I think is now at Salesforce, she used to be at eBay back then. And she told the story, where eBay, it was important to have an API but initially they thought “Well the API will be important for people to maybe look for items and do these kinds of things” which they are.
But what turned out, which drove much more value, was that the API now drives the most value by large companies putting their excess inventory on eBay. Right? And they do that through an API, and they need an API because, of course, they have to sell, I don’t know, like 100,000 pairs of shoes. You need an API to make sure that this inventory gets from wherever you are into eBay.
Having an initial set of APIs and then understanding that “Hey, this seems to be something that really drives value”, and then putting more effort into that right? That is a good way to understand that we have to figure out what is really driving business, and then we can kind of allocate our resources in that direction.
Understand your API adoption and scale with confidence with Moesif
The Internet of APIs - APIs Under the Hood
APIs are complex, but understanding the basic building blocks of creating and supporting an API are important to building a great API product.
Larry: Right. Very, very salient point, very interesting. So slight non sequitur and really to jump from the business case to more of the underlying technology and understanding technology in general. I really liked your YouTube 12 minute explainer on how the Internet works, where you explain IP, TCP, SSL and UDP.
Share with us why you think such an understanding is important for API professionals.
Erik: So what I think is important to understand really, at a certain level, at least, how this whole API stuff really works under the hood.
Of course you don’t have to understand, like everything down to glass fiber, and I mean at that point, I mean I also would have no idea how those things work. But I think it’s important to really understand the basic mechanics so that you also understand some of the risks, and some of the things that may happen right.
For example, you can get delays, you can get, depending on the technologies right, you can get duplications of things, of course, always APIs can kind of cut out right.
I think it is important to go a little bit deeper than just understanding http and json, and to understand what is that built on. Show me at least the foundation of that, and the foundation of that then would be TCP IP.
I think that also helps, for example, you become more aware of the fact that things might fail right? A lot of things that we still see, I think, is that too much design in the API space are just built on the happy path, assuming that everything will always go right. Now you see a lot of applications that if things don’t go right, they fail miserably. And you can easily say that “Well, that wouldn’t have been necessary” right? By better understanding how things can fail, you would be able to have a more robust application by just taking that into account.
I think this is important for somebody who works with that, and takes APIs as the tooling that they work with to assemble pieces. To understand how things can go wrong, I understand that they can go on wrong, how they can go wrong, and then I can better design for those cases.I think designing for failure becomes more and more important.
Just recently, we had this article from Gartner predicting that in 2025, I think they said, “Organizations will depend on three times as many external dependencies to APIs as they have today.” And that will mean more and more that you depend on others, which is good, because you can assemble things so that’s nice. But you also have to manage those dependencies responsibly, and maybe build things so that, if that thing fails, I still do at least part of my job right?
And I think that understanding sometimes it’s still something where we need a little bit more foundation to really understand what can go wrong, so then we just design a little bit more resilient and robust systems.
The Best API Style Is Determined By The APIs Purpose
There are many types of API styles to pick from, but the “right” style can be determined by the API project. Why are you building an API is just as important to the process as how.
Larry: On that subject, do you have a laundry list of popular API styles that you would choose or you would highlight above others?
Erik: I have these five styles that I talk about when I give an overview of styles, where you have the resource oriented style, the hypermedia style, RPC, like the good old function oriented function calls, and then you have query-oriented styles, such as GraphQL, and even event-based APIs.
In the end, I think API is just a tool, the tooling that allows us to build new things out of existing building blocks that are connected to a network. Better understanding what kind of tool is a good thing, for which design, for which purpose that I think is a good thing to do. This whole fundamentalism around like rest is always the right thing or GraphQL is always the right thing or event based is always right thing. I think we’re slowly getting away from that a little bit and that’s good.
Mostly what I try to tell people is be less fundamentalist and better understand that there are different styles. They are not inherently good or bad, they just have different constraints around them. To better understand how they work, and maybe also better understanding, in which case, which style, maybe a better choice. I think that turns you into a better designer because in the end, designers should not just always say “I’m always doing things this way”. As a designer you should be able to understand that you have to design for a problem, and for people who are faced with that problem. You have to give them a solution that works well for that context.
Collaborate with teammates to monitor KPIs with Moesif’s custom dashboards.
Why Security Is Important to API Health
Good API security starts with understanding your API landscape. Having a comprehensive understanding of what APIs are actively in use is critical to building a security framework.
Larry: Very interesting, yes. There are a multiplicity of styles and implementation procedures that seems more and more difficult as an API platform provider that we have to support, but I suppose that is the nature of the beast.
Talking of big changes in API platforms and third party solutions that one has to be aware of. Tell us your perspective on API security, why is it important, how can we facilitate the gold standard for security and also what is your perspective on the recently standardized latest version of fhir for APIs.
Erik: Okay let’s get started with security.
Security of course is super important. APIs always provide some way to interact with your system landscape, it may be read only, but even then it’s probably some kind of risk that you’re exposing. There’s always the ability that this could be misused in some shape or form.
The very starting point for a good API security is to just understand which APIs you even have, and it is amazing to me, like I work with a lot of really big organizations. Whenever we talk to the people in those organizations, they have no idea which APIs they have. There are people in the organization, who build APIs and publish APIs because they just need to get some job done. They may not be aware of the fact that there is a platform where they could secure it, or they just say “It’s good enough, it just talks to my application so how bad could it be”. There’s all these kinds of missing practices sometimes around understanding that every API is a potential security risk.
You have to think about what’s the worst thing that can happen and that worst thing often actually could be prepared. It’s not like security is such a super complicated thing, it’s just a set of practices that people need to understand that they have to apply those practices. You can provide them with pretty good tooling to make sure that they don’t have to do that much themselves.
But it’s still something within an organization, where I think we’re still oftentimes seeing that it’s not done in a disciplined enough way. Sometimes it’s pretty amazing I’ve seen organizations where at some point, for example, they just closed certain ports in their firewalls. Basically said for a little while let’s not pass through traffic that goes through certain ports, and then they just basically wait for reports coming in, about “Hey, this application stopped working”. Then people understand it’s like “Oh, there seems to be an API there”. Nobody ever told anybody, people just created it and it runs there. It may not be security at all right, and nobody even knew that this was there.
It’s very important that you find this application before some hacker. This is like this whole space of observability that we see that is exploding right now. I think that very much, it is also fueled by this, sometimes you have to observe things, just to plainly understand what is even happening in my network.
The bigger the organization gets sometimes, the less organizations are actually knowing what is happening. I think this is kind of a rather basic aspect of security that is almost more important than the details of “How do you do it” on a technical level. I think those pieces we have in play pretty well, once you know that you have an API, how to secure it, how to provide tooling for doing that. Just knowing that you have APIs and which ones they are, who should get access to it, and all these kinds of things. I think that sometimes almost the tricky part because there’s so much unknown stuff going on your network.
Larry: Right, very true, very true. We had Alissa Knight recently on our podcast and she was talking about man in the middle intercepts and how to avoid that with APIs. Her big takeaway, which really underlines your issue of just knowing which APIs you have out there. Her big takeaway is you can solve 90% of this problem by making sure that when you authenticate a user, that doesn’t necessarily mean they have access to everything. When she hacked people’s APIs, she found that I could be authenticated but then, by changing some of my tokens, just one or two characters, I could now gain access to a whole other set of users API payload material. She said it was amazing, I mean, she’s published this. She did it for medical applications and also banking applications. She said it’s amazing the number of people who because they think “Oh well, this person’s authenticated, now they can have access to anything.”.
Erik: Yeah, I think that is number one on the owasp security list. It’s object level access, it’s like people just assume that you have access to something so here’s everything. Just going through the owasp top 10, that already is, in light of organizations, you will find it, “Yeah, you know, we actually have not all of our applications are doing so well.”.
Get deep API analytics with confidence with Moesif’s SOC2 compliant, client side encryption.
API Observability vs API Monitoring
Observability and monitoring may seem synonymous, but they are two sides of the same coin. Observability is about putting mechanisms in place to enable active iteration. Monitoring can be viewed as a technical layer of observation.
Larry: Right, very true, very true. Going back to something you touched upon, which was that there is a big movement now for API observability.
Why don’t you give me your definition of what is the difference between API observability and API monitoring. Why is observability, more importantly, stays and just pure monitoring.
Erik: I will not give you definitions, because I would need to think about that for a little bit longer. But I think, at least in the way that I use it, and I think most people would use it, would be to say that monitoring typically is something that you put in place if you have an API. It’s a rather technical and specific component that you put there and say “Let’s count the number of accesses” or whatever it is. It’s a very specific kind of layer of observation that puts it like this, right, but it’s more specific around, I guess, we need to look at something that we know.
I think observability is much more rooted and with the tools that we see that are coming up, it’s much more rooted in this idea of we know there’s stuff going on. But we don’t exactly know what it is, how it behaves, maybe even what we have. So we observe the environment, we observe what’s happening and we actually learn from that. It’s not so much just learning by counting things, such as monitoring. We learned that we had certain APIs that we didn’t really know, we learned that there are certain ways how these APIs are being used that we didn’t think were getting used.
I would say it’s much deeper inside, there’s also much fancier technology involved that really tries to not just count bytes but to really get a meaningful understanding of what’s going on. To help you better understand what’s going on, and then you can do all these things, where you can also reverse engineer like Phil Sturgeon, he recently published a piece, where it’s about inferring open API information from just monitoring traffic basics or observing traffic. These kinds of things, which I would say, are much, much more insightful ways of looking at traffic than just the rather simple monitoring that we have in place.
Larry: Right, very true. I mean slightly self serving but I work for an API observability company. We’re always pushing the fact yeah, you can count server uptime, latency and issues on GEO location. But really, you get a whole bunch more business value by actually delving into the nuance of what’s in your payload, and how your customers are actually using it. That seems to have an awful lot more value.
Get deep, granular analytics and metrics on your APIs and users with Moesif.
Measuring API Success via Metrics and Conclusions
Gauging API efficacy is not always as simple as selecting one metric to measure against. Because an API is just a tool, measuring success should start at the business goals for the API as well as any insights found during API usage.
Very interesting segway into measuring the value of APIs. How would you gauge whether your API is successful and how if it’s not successful, what metrics do you think are important, or what conclusions can you draw from what you’re monitoring, and observing then turn it into a performance API.
Erik: Let me go out on a limb here and say, an API cannot be successful. The thing that can be successful is a capability, a product, or something that you are actually delivering through an API. I have this video, I have to point it out, because it’s one of my favorite ones, where I talk about beer. The analogy I’m giving is that the APIs, the delivery mechanism, so it’s like a bottle or a can, it’s the way you get the beer. What really matters in the end is the beer, but the beer is not the delivery mechanism, there’s a difference, and I think that is something that is still important to really understand that the API… Don’t focus too much on the API, just the API is just the mechanics to get things going.
In the end, you have to think about what is the business that I’m trying to do with this. What is the actual capability that I’m working with, and that would be more like somebody who does product management right? Who’s really responsible for designing that product, delivering that product, making sure it’s getting used, monitoring how it’s getting used, figuring out that it generates more revenue than it costs us to run it.
To that extent, I think pure API metrics are just a relatively small part of that. Where you can see it’s okay here’s maybe an additional way of how we provide access to this capability. In the end, what really matters is “Do we drive business?”, so I think this whole idea of an API having value is maybe interesting, but mostly it’s really about do I push the right things in the right direction.
Larry: Very interesting, yes. Yeah, it’s important again going back to Jeannie Hawrysz from SaS, her perspective on creating APIs in existing enterprise software company, your API has to be a central revenue conscious, can’t just be a nice to have or because a product manager wanted to put it out there. The business case and the business metrics are the most important thing you have to get right.
Erik: Sorry but because it’s so dear to my heart, I mean there are these cases where I’ve seen companies, where one of the things they did was basically really counting API accesses, and this was not so interesting and almost created bad incentives, because instead of creating better APIs that would be more granular so then you can get more stuff done with one APIs. They were incentivized to basically have “No, we have these 25 API, if you want to get anything done, you have to call all 25 of them”. Then say well it’s good right, you have 25 API calls here so that’s probably not good, but I understand why this is going on and somebody should stop this from happening.
Connect your API analytics to your greater business goals and accelerate adoption with Moesif.
The Future of the API Ecosystem as a Whole
The API landscape will continue to evolve with better bridges between the technical and non-technical aspects, enabling business success.
Larry: Right, absolutely. Look at the right metrics, don’t just count metrics for the sake of metrics sake, absolutely. So my final question, crystal ball gazing, what does the future hold for the whole APIs ecosystem look like?
Erik: So I think what will happen in an API space is that we will see there will be better bridges between the technical aspects of APIs, and the not so technical aspects. I think, right now, we still don’t have enough of an overlap and a smooth transition between the more business minded side of things, really understanding what are the capabilities that we should have, what are the capabilities we should make available.
Also thinking about now, do we have APIs for that, like should we invest in building those, and then saying okay someone should design those things, but we also need someone to think about which things should be designed. Going back to building the right things and building them right. I think almost at some point, we have overdone it a little bit with the developers, developers, developers, because of course developers are super important. But they also have to develop the right stuff, and I think building better bridges to make sure that what is getting built is understood by everybody. That I think is important and in part, I found this super interesting this week, that when you talk to companies here in the Bay area, of course they are very technically minded, and there you don’t have to explain that much what APIs are and so forth. But on the other hand, If I go back home to Switzerland and talk to organizations in Germany and Switzerland, who are not so natively digital. The divide between the business side, and the digital side, for the IT side, it’s still much bigger.
I think crossing that divide and making sure that everybody understands what’s going on, everybody understands what needs to happen, I think that is something where we still have to develop better tooling, do more education. So that in the end, everybody really understands, what is it that we all should be doing, and how can I contribute. It’s not just developers who are contributing, it’s everybody, and I think that is something where we will hopefully see big change.
Larry: Great, great. Yeah, I totally agree that there has to be a team effort. There’s more than just focusing on a great developer experience to get your product out there, and get it successful in the marketplace.
So where can our listeners hear more from you,and obviously, please give us an unadulterated plug of your latest excellent publication.
Erik: Sure. Sadly, I cannot hold up our book because I don’t have it with me, but of course everybody should check out our latest book “Continuous API Management” second edition, published just a month ago, two months ago now. I hope everybody finds it interesting, it is specifically about APIs and a conference case because we thought when we started the whole initiative around it, this is really where the world is going, and I think continues to go that way so that’s good for us.
In terms of where you can find me, of course, you can always find me on Google. But the main outlet that I have these days is my YouTube channel, so just put my name into YouTube, and you’ll find my channel. It’s called “Getting APIs to work”.
I have a lot of interesting guests there, who talk about their API practices, their experiences in API space so check that out, and other than that you will find in my usual places such as Twitter and LinkedIn.
Larry: Great. Well, it was a pleasure speaking to you today Eric. Thank you very much for your insights, I’m sure our listeners will find them educational and very useful.
Erik: Thank you so much for having me Larry, and I hope this is not the last time that we’re doing this. I always like talking about API things and where the space is going.
Larry: Certainly. Love to do it again so until next time, thank you very much Eric.
Make Your API Platform Successful With Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.