How to Ensure APIs Drive Everlasting Organizational Value

Physicist and computer scientist Alex Wissner-Gross made headlines a few years ago with his definition of intelligence.

The definition derives from complicated concepts in physics and computer science and is expressed by a potentially intimidating equation: F = T ∇ Sτ. But the basic concept is relatively straightforward: intelligence “doesn’t like to get trapped,” as Wissner-Gross stated in a widely-seen TED talk, so it seeks to maximize future freedom of action.

Indeed, this idea isn’t so different from the even simpler notion—often attributed, perhaps apocryphally, to Stephen Hawking—that “intelligence is the ability to adapt to change.” That is, we all want to avoid bad outcomes, so in a constantly changing environment, intelligence is defined by one’s ability to avoid getting locked into particular scenarios.

Given that fear of “lock in” pervades enterprise IT across virtually all industries and operational models, the notion that intelligence is about maximizing future freedom of action is a useful framework for businesses navigating digital transformation and modernization. Often, the difference between a future of options and a future of dead ends involves how a company designs and manages its application programming interfaces (APIs).

APIs can be either stimulants or stumbling blocks

Businesses today face a dizzying array of technologies, device types, customer and partner preferences, backend systems, and so on. Some companies manage the chaos intelligently in the sense that Wissner-Gross describes; that is, they adapt to current conditions while keeping their options open in the future. But for many other companies, the complexity can be overwhelming, and it becomes easy to get cornered into use cases long after they’ve stopped providing value.

APIs are typically at the center of these adaptations, both good and bad. As the way software talks to software, APIs facilitate the exchange of value throughout the enterprise, whether it’s allowing internal systems to communicate, enabling web developers to work at different speeds than the backend teams on which their apps rely or inserting a business’s capabilities into larger ecosystems of external participants.

These APIs can be stumbling blocks when they’re just designed, managed, and perceived as pipes between systems—as just connectors that satisfy a current need to make data in one system accessible somewhere else. Depending on how the connection is implemented, it may not be easy to add additional connections in the future or even to reuse the data access that the initial API supplied.  

One may think of such crudely implemented APIs as railroad tracks without switches. Yes, the tracks can serve a short-term purpose—but without switches, they leave few options for new use cases or connections. They do not maximize future freedom of action.

If poorly-designed APIs are typified by a kind of myopia, what characterizes a well-implemented API—i.e., a rail with switches? A well-designed API starts with the understanding that an API does not merely make a connection now—it can also be used in the future. Likewise, an API isn’t just an IT pipe—it’s a product for developers that empowers them to build apps and services around existing data, apps, and functions. That is, an API product can stimulate a business.

This distinction has huge implications for how an API is designed and maintained.

If the API designer is thinking merely of building a connection, things like documentation and consistent design styles—i.e., the things that would let another developer leverage the API in the future—might not be considered. If the API designer is thinking of the API as a product, in contrast, these and other usability concerns will carry far greater weight.

Similarly, if the API designer is just installing digital plumbing, considerations for security and monitoring might be neglected. But if the API is designed as a product, the designer’s concerns will likely include OAuth protection, management tools that provide insight into how and by whom the API is being used, tools to implement quotas and other governance functions, and ways to leverage API user data to make the API more useful through future iterations.

It’s apparent from these distinctions that whereas simple APIs-as-integrators are often one-offs, API products can provide lasting value in more diverse ways—that is, they are more likely to maximize future freedom of action. What’s more, this difference in value is likely to grow as technology advances. Application development is growing increasingly granular and modular. Few apps use monolith approaches with massive amounts of code baked in—rather, most apps are built by combining existing APIs to make something new. The companies that design their APIs for developer consumption and reuse are paving their way toward this future—the companies that design their APIs as point solutions for single projects are not.   

Internal APIs and external APIs are both products

Though a product approach to APIs may be the more intelligent path, it can nonetheless be easy for enterprises to go the connector route, at least some of the time. Many business leaders recognize that externalized APIs—like the ones that let developers build applications around, say, Google Maps or natural language processing capabilities or weather data—-are products that need to be managed. But they may view internal APIs differently, reasoning that these APIs really are just connecting systems. Why invest the extra work in an internal API?

The reality, though, is that these business leaders aren’t saving the company from “extra work” so much as limiting what the company can do with the API later. If it turns out the API may have additional uses, whether internal or external, leveraging the API might not be easy or simple. It does not contribute well, if at all, to future freedom of action.

Moreover, even if an API is only used internally, it’s still a product to the internal developers who work with it. Why give outside developers a first-class experience while forcing internal developers to work with poorly-documented and poorly-supported assets? By treating internal developers as customers just as it does external developers, a well-managed API program can not only open new revenue opportunities outside the business but also contribute to improved efficiency and time-to-market within the organization.

In short, rather than dashing future possibilities, the product approach unlocks them—which seems like the smarter thing to do.

 

Comments (0)