The API for absurdity

Every important technology goes through a hype cycle.

You’ve probably seen the Gartner Hype Cycle diagram: inflated expectations, followed by despair and eventually a pragmatic understanding of the technology’s value.

World-changing promises tend to turn into mundane reality — if they don’t fall off the roller coaster entirely.

The Gartner Hype CycleThe Gartner Hype Cycle

Cloud APIs have progressed pretty far through this cycle, with the best of them powering essential business services every day. Still, the “API economy” suffers periodic hype eruptions. One bit of API enthusiast rhetoric that concerns  me is the “composable enterprise,” a do-it-yourself approach to piecing together entire enterprise solutions.

Companies that have built successful businesses around the sale of discrete API services that can be plugged into larger applications would like to see this trend carried to an implausible extreme, where enterprises will move from buying software solutions to assembling their own business applications out of myriad APIs and microservices. The payoff is said to come in the form of ultimate, infinite customization.

Let’s get real: That is not going to happen. At least, it’s not going to become the norm across the vast majority of enterprises. Most technology buyers, including the innovators, only go DIY with their IT when they believe they have no choice. Their need is for APIs that let them plug holes and fill gaps without having to work too hard. They are looking for the simplest path to getting the results they want.

Most enterprises are not in just one business, and tend to adopt, rather than create, software.

There are exceptions. Uber famously incorporated a selection of premium APIs into its mobile app for functions like looking up your location, notifying the driver to come pick you up and accepting payments. The ability to access third-party software features à la carte is perfect for an innovative business that needs to combine bits of functionality in a way that no one has before, without incurring the risks and costs of maintaining the necessary tech stack. In other words, composition of services can be a big part of what makes a killer app a killer app.

While some enterprises are scrambling to foster Uber-like innovation of their own, the needs of businesses whose specialization is not software creation are invariably different. Starting from scratch, a company can piece together a custom call center or CRM that matches its exact needs. On an enterprise scale, that tends to look like reinventing the wheel.

Most enterprises are not in just one business, and tend to adopt, rather than create, software. Problems like how to handle customer service calls or organize customer records have been solved over and over again by software companies whose systems address a wide variety of business needs. The typical enterprise buying strategy is to standardize on a technology platform that is the best fit for the lion’s share of their requirements.

That doesn’t mean APIs are irrelevant for software adopters, only that assembling a core enterprise system from scratch makes no more sense than trying to build your own car out of nuts, bolts and ball bearings. Smart technology buyers have a bias toward cloud platforms with strong APIs that  bridge the gap between the “best fit” and the “perfect fit.”

In my work on APIs for a cloud-based communications platform, the most common example I see is customers needing to access data differently than they can through our administrative dashboard. No matter how much we work on making reports customizable, there will always be customers who want to graph the data in a different way or combine it with customer records from another system. Or they might want to be able to send automated SMS text messages, such as shipping notifications, and allow the recipient to reply by text or phone.

A software creator is more likely to need discrete API services, whereas a software adopter (which is most enterprises) is more likely to need a whole software solution, supplemented by APIs. An enterprise shooting for Uber-like digital transformation might be tempted to tap multiple APIs and microservices to create custom applications, but is much more likely to do so by stitching together a set of best-in-class business software with highly accessible APIs.

Somewhere, sometime, I am sure there will be an exception to the rule — an enterprise that pieces together an important application from a grab bag of APIs and does a great job of it. But even that wouldn’t make them a “composable enterprise” unless they start doing it routinely.

We can embrace the API economy without embracing this delusion. If software is “eating the world,” as Marc Andreessen famously said, cloud APIs are its latest snack. They just aren’t the whole meal.