O’Reilly Media published its first book on API management in December of last year. I sat down with the book’s authors to explore some of the core concepts of the book.
The concept of API management originated a decade ago to help organizations participate in the burgeoning web API economy that was being fuelled by the rapid growth of mobile applications and cloud computing. Since then, API management has deepened its scope to address internal API concerns and evolved its practices to coordinate with the emerging paradigm of cloud-native technologies, microservice architecture, and DevOps.
O’Reilly Media published its first book on API management in December of last year. Continuous API Management provides a comprehensive context for the value of API management and examines the key areas organizations need to consider when looking to launch and leverage APIs. I sat down with the book’s authors to explore some of the core concepts of the book.
Mehdi Medjaoui is an entrepreneur and founder of the global API Days event series.
Erik Wilde is Partner and Principal Consultant at Good API.
Ronnie Mitra leads the International API and Microservices practice at Publicis Sapient.
Mike Amundsen is an internationally known author, speaker, and API Consultant.
Thanks to all of you for joining me today. You’ve covered a lot of perspectives in this book, from business motives, to architectural principles, to operational concerns. I find the concept of “distributed decision-making” – as a practical way of articulating the shift we’re seeing in the industry to more decentralized organizations – something that is prominent in leading API companies. However, my first question is simply about the title of the book. What is the significance of the qualifier, “continuous”?
Mike Amundsen: The notion of “continuous” is a theme throughout the book. As we talked to companies who were engaged in managing their API ecosystem – their landscape as we call it – we discovered that most of them saw their work as that of constant, and usually incremental, improvement. Just as the DevOps community talks about the value of continuous delivery, we think it is important to approach the API space as an opportunity for continuous management.
So we carry this theme of continuous to even refer to continuity. Companies that are successful in the API space maintain a level of continuity throughout their work. And that extends to the design, implementation, testing, deployment, and ongoing maintenance of both the individual APIs and the entire API landscape. Even the guidance we collected on how to create teams and cover the various roles needed to design and implement APIs has a level of continuous change and improvement built-in.
Finally, a key aspect of approaching this work from a “continuous” point of view makes it easier and more rewarding to make small, incremental improvements over time instead of trying to execute a kind of one-time “moon shot” attempt to change your APIs. By making the notion of continuous management the baseline of our guidance, we’re hoping people will see that you don’t need to engage in heroic efforts or “big bets” in order to make positive change to your existing API programs.
For a book on management – which it is – there is a lot of discussion on design and design thinking. In terms of design thinking, where do you see the biggest blind spots for organizations implementing APIs, and what is the most practical way to introduce it?
Ronnie Mitra: As Bill Moggridge said: “…there is nothing made by human beings that does not involve a design decision somewhere.” When it comes to API management, there are a ton of design decisions that need to be made: the organization structure, the decision processes, the interfaces, the tools — all of it needs be continuously created, curated, and improved. Making better design decisions will lead to a better result.
From my own observations, I’ll say there is a lot more acceptance of budgeting for API design work now than there might have been five or 10 years ago. But, if there is a general “blind spot” across the industry, it’s that most of that API design work rarely challenges established conventions. I’ve seen a lot of cases where the API design starts with unquestioned, truths — “it’s going to be HTTP,” “it needs to be RESTful,” “the docs are going to be formatted in three columns.”
That’s a nice way to get started because it means things can move faster. But the trade-off is that it denies you a chance to come up with something that is a better fit for your context. If you are looking for a competitive advantage, it makes sense to start with less of those constraining design assumptions so that you can work your way to an API system that gives you market differentiating value.
The term “API-as-a-product” has been a popular one for some time now, but it seems people struggle with the concept and how to implement it. What are the essential tenets of treating APIs as products?
Mehdi Medjaoui: In an era where “software is eating the world,” treating your APIs as products means that you need to consider how your API-exposed service will be differentiated versus other alternatives when potential consumers are evaluating what to integrate into their IT systems or business processes.
Product thinking in the API space goes back to a mandate Jeff Bezos sent to Amazon’s employees in 2002. According to some who were there, it stated:
“All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.”
Another way of stating that APIs need to be designed as if they will be one day be exposed to customers is to say that they need to be thought of as products.
How can you treat your API as a product? Make it easily discoverable, through an internal registry, a search engine, or via a developer portal. Make it easily consumable and frictionless for integration, more than just technically working. Design it according to user expectations, giving them interactive documentation, code samples in many programming languages, helper libraries and SDKs, an exploration console, and access to download its OpenAPI Specification. Rapid onboarding is important to make sure users are successful with the API as fast as possible once they have registered and been authenticated. APIs need to be monitored, managed, maintained, and versioned after they are consumed and integrated by your users. Finally, you need to have a usage-based financial strategy for your API, whether that is through internal chargeback mechanisms, by charging external users, or by providing free access to strategic users, depending on what drives your API’s business model. This is just a subset of considerations but gives you an idea about how different the product mindset is than the typical approach to IT services.
In my opinion, one of the most important ideas presented in the book is the distinction between the management of individual API products, and the management of what you call “API landscapes.” This may be new to many readers. What are the core considerations for managing a landscape of APIs?
Erik Wilde: In the book, we are telling the story of how APIs should be treated as products. The focus of organizations should be on enabling effective ways to create new products, and on establishing some coherence across them so that both API developers and API consumers can benefit from a similar “look and feel” of APIs. This works best when APIs are recognized as the core deliverable of every team. For this to work best, design practices and support and tooling must be developed in an organization to establish this ideal landscape of coherent and continuously evolving API products.
We also talk about “continuous architecting,” which is the question of how the constraints that an organization puts on APIs should evolve over time in response to feedback from API producers and API consumers. For example, an organization may have switched from recommending SOAP APIs as the default choice to HTTP/JSON APIs. With the advent of new API approaches such as GraphQL, this may become a new “experimental” API style that is used by some product teams and monitored by the API architecture team. This process helps to gather feedback, both in terms of how well it works for the developers, and also in terms of what kind of additional support/tooling could be established to better support this new type of API. “Continuous architecting” refers to this constantly evolving set of practices and support structures which are established to increase the efficiency of API teams. It is about evolving the architectural constraints for the design of individual products, which may sound a bit complicated, but actually is really important for making sure that the API ecosystem can flourish.
Last but not least, it is critically important to think of API landscapes not just as the APIs that you want to externalize, but as the enabling set of building blocks that should be available both internally and externally. Just looking at the APIs that are meant for external exposure is selling the digital transformation approach short, and thus means missing out on most of the value that can be created when new products can be built easily and quickly on an available set of existing building blocks.
I have one last question. Do you have any upcoming speaking engagements or other events where you will be discussing the book’s concepts?
Erik Wilde: I am looking forward to two tutorials I am running with Mike, one at The Web Conference in San Francisco in May, and one at the O’Reilly Software Architecture Conference in San Jose in June. I believe we will even have book signings at both of those events. I will also participate in two of the wonderful API Days events Mehdi Medjaoui is organizing, which will be in Zurich in May, and in Helsinki in June. If you want to talk about APIs, API landscapes, API strategy and programs, and digital transformation, I’d love to chat at any of those events!
Mehdi Medjaoui: As Erik mentioned, I will be at the API Days events around the globe: in Zurich May 21-22nd, Helsinki June 4-5th, Amsterdam June 18-19th, and San Francisco July 16-17th. Looking forward to seeing everyone there!
Thanks very much for your time, and especially your insights! I recommend your book highly to anyone who is interested in API management, especially on an enterprise scale.
Check out the Managing the full API lifecycle whitepaper to access more information on managing your API, from design to deprecation.
