Chapter 12. Continuing the Journey

We demand rigidly defined areas of doubt and uncertainty!

Douglas Adams

API management is a complex subject, and we’ve had to cover a lot of ground in this book to explore it. After a brief discussion of the challenge and promise of API programs (Chapter 1), we examined the foundational concept of API governance (Chapter 2) and what it means to do decision-based work. Focusing on decisions led us to a model of decision making with elements we could distribute or map. Mapping decisions gave us a powerful, nuanced way of managing API work.

With this focus on decision-making as a foundation, we started our API journey in earnest by introducing the first important API management factor: a product perspective (Chapter 3). Treating the API as a product that solves a problem for a target audience gives you a guiding light for deciding which decisions matter the most. We started with this product approach by focusing on the work of creating a single API product. Our experience tells us that the context of local optimization for an identified use case (such as Clayton Christensen’s “Jobs to Be Done”) is important. Starting from a single use case is also easier to grasp than starting by tackling the complex landscape that inevitably comes as you add more and more APIs to your system.

In this first set of chapters, we also explored the local context of an API by taking a tour of the API pillars (Chapter 4), learned about API styles (Chapter 6), and worked through the stages of your API product lifecycle (Chapter 7). With these tools, you can establish a solid foundation of API practice that can result in consistent, coherent APIs built in a way that supports tracking and managing the flow of work from the create step through to the retirement phase of your APIs.

The next important API management factor we covered was that of your company’s overall organization and culture. This topic is much too broad (and important) to be left to just a couple of chapters here, but we want to be sure to highlight two fundamental organizational elements we all deal with when it comes to introducing and maintaining a healthy API program. The first of these is nurturing a company-wide ethos of continuous improvement (Chapter 5). Creating an organization-wide environment that has the right levels of psychological safety and a relentless striving to experiment to make things better is a tough job. And it is an essential element for a successful API program over the long term. But company-level efforts are only the start. You also need to create similar levels of trust and experimentation at the team level. For that reason we also devoted a chapter to the concept of API teams (Chapter 8). Here we discussed roles within a team and the larger task of designing and maintaining the teams themselves. By leading with an overall dedication to continuous improvement backed up by a concentrated effort to support effective teams, you can—over time—grow a strong, healthy culture in your company that leads to high-quality APIs.

Finally, we added the third factor of API management: scale. We introduced you to the API landscape and the 10,000-foot view of the complex system. The last section of the book focused on the concept of system optimization and the decisions that go along with it. We introduced the notion of API landscapes (Chapter 9) and how your API landscape affects the API lifecycle (Chapter 11). Working at this landscape level can be quite challenging. Here, all the elements we covered earlier—governance, products, culture, and scale—come together in a complex mix of interactions. Our hope in these last couple of chapters was to give you some guidelines and share some advice on what kinds of challenges to expect as you create your company’s unique blend of APIs that make up your organization’s singular system-level landscape.

That’s a lot of information, frameworks, and models—but at the heart of API management are those four fundamental parts: governance, products, culture, and scale. No matter what kind of APIs you have, what industry you are operating in, or the size of your company, you’ll need to manage APIs from all of those perspectives. Ideally, we’ve given you a set of tools in this book to help you start doing that today.

Continuing to Prepare for the Future

It’s hard to say what the future will look like, but we’re certain that the connectedness of software isn’t a passing trend. As architectures become more reliant on components being interoperable or integrated, the demand for API management will grow, even as the protocols, formats, styles, and languages that underpin it change and evolve. Indeed, since we released the first edition of this book just a few short years ago, there has been a surge of interest in managing multiple APIs (what we call landscapes). There has also been a growing attention paid to lowering the barriers to use, reuse, and integration—all things we discussed in 2019.

We’ve tried to write this book in a way that will be useful for you regardless of the specific technology choices you face. The core concepts of governance, product, culture, and scale are essential and timeless for API management. So, even as everything changes around you, you’ll have a set of concepts and frameworks that will help you make sense of it.

You can use the API-as-a-Product approach to help drive your design and implementation choices. This will give you the freedom to create APIs that fit your users’ long-term needs instead of finding yourself at the mercy of short-term industry trends and hype cycles. You can also distribute API decision-making based on the goals, talent, and context of your organization instead of trying to clone the working culture of the latest successful startup.

Above all, we encourage you to embrace the complexity of the system you are managing rather than fight it. Get an understanding of how time and scale change the work that needs to happen. Use the API product lifecycle and the landscape journey to frame your working context. Play the “what if?” game with the landscape variables to assess your system: What if the variety increases? What if velocity stops being important? Your answers to these questions might not be prescient, but they’ll definitely be enlightening. And they most assuredly will lead you to opportunities to continually improve your system.

Continue Managing Every Day

When you’re faced with a big problem in a complex, complicated domain, it’s easy to feel overwhelmed. At the beginning of this book, we talked about decision quality. One of the most important elements of making a good decision is the information you have available to you. That includes learning how other people have solved similar problems, understanding your current context, and gaining more certainty about the future impact of any decision you make.

It is important to spend time gathering that kind of information about API management in order to make better decisions. At the same time, if you spend too much time gathering information, you’ll never get a chance to learn by doing. When you’re dealing with the uncertainty of a complex adaptive system, the reasonable way to move forward is to take small bites out of your problem. Tackle one small thing, learn from it, and move on to the next thing.

In our experience, the best way to do that is to apply techniques like Deming’s PDSA cycle, introduced in “Incremental Improvement”. Use the data you have today and come up with a theory. Take that theory and plan an experiment. Find a safe place in your organization to try the experiment. Measure the results, and start again. You don’t need Agile processes, Lean methods, Kanban boards, DevOps tooling, or a microservice architecture to start managing your APIs. All those things are useful and have their place, but you don’t need them to get started. All you need is a theory, a good measurement, and a willingness to execute and experiment safely and consistently.

When it comes to a complex domain like API management, this is the best way to move forward—and the good news is you can start doing that right now. Find something in your API system that you think can be improved, and use what you’ve learned in this book to perform an experiment. Learn as you go, and grow as you learn. Before you know it, you’ll have an API management system that works for you as much as you’ve worked to build it.

Even better news is that you can continue this cycle of tackling small problems for as long as you want. This is the continuous part of Continuous API Management. The challenges will always be different, and the solutions will evolve over time along with technology and experience. But the general approach will stay that same.

It’s a long journey. But our experience, and that of most of the companies we’ve talked to, tells us that it doesn’t have to be a difficult one. If you’re armed with the API management knowledge that we’ve gathered in this book and have a willingness to search for a solution that fits your company’s unique needs, you’ll have a big advantage. Your path will be clearer, and you’ll have a much better chance of making progress.

The more progress we make, the closer we can get to reaching our goals. And continuing that is a good thing for everyone.

If you find an error or have any questions, please email us at admin@erenow.org. Thank you!