The API Management Theory
In an effort to dip into digital, many turn to API Management solutions to launch a handful of public APIs — but often, the theory doesn’t match the desired outcome.
A common strategy assumes there’s vast monetization behind Open Web APIs, B2B APIs, and Product APIs. It typically starts small to prove the API economy is worthwhile, then looks for answers on how to scale. But as most know, scaling with consistency and speed is HARD and, just because you built it, doesn’t mean they’ll come.
Hence the call for Agile development, with its easy-to-follow framework to address the quick build of many: start from the outside-in; diversify your assets; spin out multiple MVPs; bake in consistency and reuse of design artifacts; test religiously; fix as you go; and pull or scale as soon as the results are in…
Agile or no, it’s not enough to depend solely on your public dev portal APIs or hackathons to support digital transformation AKA API management (and anyway, should your developers be the ones making business decisions?)
It’s also not enough to assume everyone in your organization knows how to identify what will make a great API, or how to design it and run it like a product. (API Product Management).
At this point many have built a handful of APIs, often fantastic products. But there is a massive delta in what is currently running vs. target state, and opportunity costs if we stay at the status quo.
One Forrester study of the total economic impact of an API management solution found net profits of 11 million after 3 years. Meanwhile, we have a market offering billions (one of our customers is predicting 100 million in net profit over the course of 1 year).
The problem is, many companies don’t build for reuse. This was a lesson we had all already learned from Amazon in retail, and it has become even more important for AWS’s API-centric business.
“Once customers started building their applications and systems using our APIs, changing those APIs becomes impossible, as we would be impacting our customer’s business operations if we would do so. We knew that designing APIs was a very important task as we’d only have one chance to get it right.”
-Werner Vogels, Amazon CTO
The headline: APIs are forever. Point-to-point is not. Focusing only on external APIs, without building for reuse in the form of reconfigurable internal APIs is a mistake. It’s this underlying business capability layer (Fig. 1) that unlocks your greatest level of potential — the digital foundation which puts companies at the lead to build new products at scale.
Fig 1. The API Management theory misses the mark by focusing on Open Web APIs, B2B APIs, and Product APIs. The focus should be on building out the layer between while supporting.
The call is to move away from a point-to-point base and towards reuse, flatter architecture, modularity, and the ability to quickly discover and scale what works the best.
To achieve true digital maturity, companies must take the route Amazon, PayPal, etc. have taken, and build out their internal layer of decoupled, digitized core components for each domain.
What True Implementation Looks Like
Currently, 5 of the major banks are creating API channels (See: slide 8–9) that are on their way to equal footing with their other channels — branch, ATM, mobile, and web. This internal channel will not only feed into the other channels, providing better service and faster updates to each, but it will also provide new external uses as well.
As a digitalML customer from one of those banks says, “We’re designing our APIs so they’re always ready for external consumption. We’ll let the business decide if they ever are, but it’ll never be a technical deficiency that holds us back.”
To reach this state, the API focus must include the layer of internal Business Capability APIs, as well as the API Products built from them, allowing facade APIs to reuse core capabilities with as little effort as possible.
The greatest API monetization, our clients are seeing, lies in the availability and reuse of well-managed Capability APIs and API Products you can build to support your own digital experiences without having to split dividends with involved partners or third-parties. So you can unlock what you’re great at, what has always set you apart from everybody else, by wrapping APIs around your products and super-charging them.
Fig 2. The focus should be on building out your internal layer of APIs so that you can quickly build your own innovative API Products to support digital experiences and touchpoints along customer journeys.
Build for Reuse: It Sounds Simple Because it is.
If you’re going to build it anyway, you might as well build for reuse.
Break it into its pieces by domain, and keep a global common model for each business function. This way, the next time around you can group the capabilities you need, and automate what’s repeatable. With ignite’s ability to generate the code from the design to any language, the process from idea to delivery is so self-serviceable, even nontechnical users can do it. For example:
“Oh wow, that Taco Bell & Lyft pairing gave me some ideas. What if we pull Lyft into our registry experience to pick up the bride-to-be for her in-store visits,” says the CMO of a giant retailer. She logs into ignite, groups the Registry API Product with 3rd party Lyft API, organizes the flow, and sends it straight to development, who really only need review and publish the code templates. “What’s the turnaround on that? 2 weeks. Perfect. I’ll go ahead and task the Design team to update the UI.”
Because you’ve already gathered the requirements, designed the logical details, abstracted them from the implementation, and baked in good governance with speed, the building blocks are ready to plug and play because you know they were designed according to the business model. There’s no 2 month lag to wait for security checks, because you built security into the design. There’s no flurry of requirements gathering because the requirements are long gathered; the details are in the API metadata and available to your global company.
“digitalML chose to come at API Management from the Design side. Others have come at it from the runtime… consider what is more important to you to begin with — the proper design, flexibility, data lineage OR runtime criteria such as lookup, metrics etc.” –Gartner Customer Review
No more duplication, no more multiple teams building the same product on two sides of the globe. With the proper tool, they have the visibility now to see, not only what exists, but what’s in production.
Modern API Management is a lot more than managing a handful of external APIs.
The shift of awareness in API Management theory is evidenced by two trends.
The first trend we’ve mentioned. It’s the focus shift from facade APIs only to include the scalable creation of an API Catalog. A portfolio of APIs supporting business capabilities, available for innovation, or quick responsiveness for those “Why didn’t I think of that?” moments.
The companies who spent the last few years and large sums of money to build out 7–8 external API products didn’t do so in vain. The journey was costly, yes, but it proved the point — that APIs are a worthy initiative.
But those who built API Products with reuse in mind now have 7–8 external APIs plus an API Catalog with healthy coverage.
They’re now discovering the benefits of having access to all of those reusable building blocks (which we call Business Capability APIs) for every new API Product built.
They’re able to build API Products at an increasing rate, by grouping the existing components together, extending to create new (say in a new region your /Policy API Product requires a few new resources), or refactoring one-off microservices.
As more of these reusable components start to fill out more of their API Catalogs, these companies are seeing grand returns.
Now they’re prioritizing Business Capability APIs to build out coverage for their domains — and the goal state we’re seeing there, as we’ve mentioned before, usually sits anywhere from 400 to 2,000. Or greater. High enough to require management.
API Product Managers
Which leads to another trend of late: some of the forerunners are assigning API Product Managers to manage the many business capability APIs, external APIs, and imported third-party APIs, with visibility on what’s running where or expected versus actual performance. Take a look for yourself — it’s out there, and the job list is growing monthly.
With API Product Managers, the business can lay down 70 ideas for this new role to clarify which are closest to launch-ready. API Product Managers are responsible for supporting the ability — take /Policy for example — so they’re able to assign and prioritize whatever supports that capability.
ignite allows them to easily call up the building blocks each API Product is dependent on, the product flow, the resources used, and even the owners of each domain. This is the difference between API Management and API Product Management; we’re treating the components like what they are. Products. Much easier to track than spaghetti.
You can’t strap the Agile saddle on IT without giving them the right tools to scale.
IT is great at turning predictability into process, yet many companies struggle at the crossroads where Business wants Agile’s speed and flex, but IT without time or process is one big bottleneck waiting to happen.
For many companies, despite all of its buzz, a step towards the API economy took them one step further from Gartner’s concept of BiModal alignment (which we’ll touch on next week). But for those who put efforts into getting API Products and Business Capability APIs in order, the results are vastly different.
Have a project? Ready to share and discuss? Let’s talk. Book a call today.