From 2.5 weeks to 1 day – Improving API delivery outcomes

Ikenna Nwaiwu works for 10x, a modern cloud-native core banking provider. 10x works with global banks to help them launch financial products to their customers quicker, cheaper, and better. He also helps teams build APIs, working in an API enablement role. Ikenna helps with API design, review, testing, and deployment, tool usage, facilitation, and the processes needed to build APIs.

API Ops is the end-to-end automation of the API development lifecycle. We’re using Git Ops and DevOps principles. It’s a way to help teams build APIs better and more efficiently and remove bottlenecks from systems. There are six main principles when we think about API ops.

• Use the design-first approach to building APIs. For teams building REST APIs with things like Open API, this involves defining or designing APIs and Open API before building the API.
• Store API definitions in version control.
• Automate API standards compliance. This ensures that API designs match the organization’s API style guide and that CAD designs do not introduce breaking changes.
• Run API conformance tests. This will run automated checks to ensure the API definitions deployed to the portal match the initial designs.
• Store API configuration in version control systems
• Reconcile and apply API config. Have automated ways to deploy API configuration to the API gateway.

API Ops is a way to improve the overall process around which teams build APIs. But I want us to take a step back and look at the whole process of building APIs and how we can improve that. Many API teams have inefficient processes when it comes to delivering APIs. This leads to poor lead time for testing, deploying and reviewing APIs, and poor-quality outcomes.  To solve this, the teams devise a list of things to do. This is good on its own but can be inefficient in improving API delivery processes. It can be overwhelming for teams as well.

To improve end-to-end delivery, lets think of A3 thinking. A3 has three main areas –

• Problems with action-item problem-solving
• A3 as an alternative to action-item problem-solving
• How to use A3 thinking

Action-item problem solving

Action-item problem-solving is about developing a list of actions for process improvement. Teams usually observe a process problem and devise a list of actions to resolve it. Then, they assign these actions to a member of the team or specific teams to resolve. It is a simple, straightforward approach. But it comes with its set of problems. It can be quite unscientific and scattershot. Presenting a list can make teams jump to solutions without understanding the wider context across multiple streams and the entire workflow. It can lead to local optimization. Local optimization is when we implement solutions at a local level that lead to a global determination, quality or lead time across the whole process.

A3 Thinking

A3 thinking is a visual and iterative problem-solving method incorporating a continuous dialog with colleagues. It’s a one-page report based on the plan, do, study, act (PDSA) cycle. It uses data to drive improvements. It adopts a systems view, so it uses systems thinking to try and understand the end-to-end impact of improvements. It is an efficient way to present information and helps drive team alignment.

The A3 report has eight main sections, including the proposer (problem owner) and the date. The Problem Owner is the person accountable for making the changes and has the influence to drive change in the organization.

1. Theme
2. Background – Give the context to the reader. They need to understand why you need to make this change and why it’s important to make that change.
3. Current conditions and problem statement—Here, you describe the problem statement in one or two sentences. It is very important to describe the current conditions, including data or the frequency of the problem. You can use diagrams, charts, etc.
4. Goal statement—Define the goal and specify the metric you want to use to improve your API process. For example, you might want to improve API consistency by 10% or 20%.
5. Root cause analysis—Perform a root cause analysis of the problem at hand using varied techniques to reach the root cause.
6. Countermeasures and target conditions—This is where we get into the meat of things. It involves brainstorming, talking with colleagues, etc. We come up with a list of actions that can resolve the problem, and we choose the ones we want to implement. The target conditions will explain how the process would look after the content measures have been implemented.
7. Effect confirmation—In this section, we compare the before-and-after metrics to determine whether the improvements have been successful.
8. Follow-up actions—If the improvement delivered results, we want to see how we can apply the results across the organization.

This is an eight-step objective and logical problem-solving approach. It involves continuous dialog with colleagues. It helps understand the wider context, the system’s view, the root cause of the problems, and their countermeasures.