Inverting the API is the Digital Transformation that Enterprises Need to Participate and Compete in an API Economy

Motivation, challenges, and opportunities

Application programming interfaces (APIs), and subsequently the API economy, are rapidly becoming the enablers of digital transformation. While most firms understand the mechanics of an API, few have embraced it as a means to increase their own business value. The API economy refers to all the business models, practices, and assets that will drive the digital economy as more enterprises externalize their services through APIs. Essentially, the API economy is the enablement of an enterprise to safely expose its services and data, in turn generating value for the business.

All businesses hold data and provide related services that inherently hold value but are typically only available internal to the organization. But to participate and effectively compete in this API economy, a business must also consider turning itself inside out by inverting some of these APIs. In the report “How APIs Create Growth by Inverting the Firm,” Benzell et al. describe how exposing private APIs increases the value of an organization. We extended the phrase to ‘Inverting the API,’ a process by which a business externalizes a private API by making it available as a partner or public API.

Quick Recap on APIs

APIs enable developers to build applications and products with ease and agility. They facilitate the rapid integration of software from different parts of a business and interact with services provided via partner APIs or public APIs.

APIs can also enable integration of new services between enterprises by allowing data access and the exchange of shared capabilities. It is this access to data where APIs offer the most attractive opportunities while posing the greatest challenges and risks. APIs allow users to access data from different services in a secure way, without having to go through the security measures of each individual service provider. But improper design of APIs may cause the organization to inadvertently expose data leading to the many challenges we see in the industry today.

Per Postman’s State of the API 2022 report, “integration with internal systems” was the top reason why organizations decided to consume APIs, which provides the easiest way for businesses to participate in the digital economy. This is important because integration tooling then becomes a crucial point when enterprises choose their technology of choice for an API-first strategy.

Business Motivation

The most classic example of enabling private APIs for the larger ecosystem to consume is Amazon Web Services (AWS). Amazon saw an opportunity to enable customers to use Amazon’s own compute infrastructure in a self-service, on-demand manner. This was not new for them as they already had all the self-service and automation tools for internal developers. It was Amazon’s opportunity to drive business growth and led to the birth of cloud computing as we know it today. While skeptics ruled enterprises would never adopt the cloud, in the 15 years since its introduction, cloud computing has become a ~$1 trillion industry and the valuation of Amazon has grown more than 10-fold over a decade, largely due to the success of AWS. This spurred the creation of a new vertical.

But businesses have still yet to recognize the full potential of APIs to increase business value. While there might be several reasons to overlook the prospect of increased return, the compelling motivation is cybersecurity. Since protecting an organization’s assets is the highest priority for IT, most organizations introduce onerous best practices and workflows that limit business agility and ultimately restrict profits. But the goal of security should be to unlock the latent value of an enterprise and not constrain it.

Qualifying APIs for Inversion

‘Inverting the API’ is not just a technical issue of making it available for others outside the organization. The granularity of an APIs exposure (GRAPE) leads to the business debating whether an API can be safely inverted. In a ‘grape test’ an enterprise needs to determine whether they are inadvertently exposing data that could be deemed competitive, or data which might run afoul against Governance, Risk, and Compliance (GRC), and how well the API is architected from a security viewpoint. In essence enterprises do not want to leave any ‘grapes’ for the picking.

Once an API makes it through this audit, it is still a business decision whether to make the data available via a partner or public API, and the goal of the IT organization should be to give the business the tools to do so in a safe and secure manner. We need to let developers create more value by being as granular as possible to expose various services which typically would be focused within the enterprise. These APIs could be tested with ‘friendly’ external customers and partners, but this process is so onerous today that most businesses refuse to go this route. The solution is for GRC and security teams to provide guardrails that prevent anything untoward from happening while still promoting autonomy.

Challenges—Primarily Technical

So, where do we go from here? Assuming the business value of inverting an API is understood and the grape test passed, there are still technical challenges ahead.

• Security informs everything—GRC and security are beneficial because there is a dark side of APIs. Hackers search for APIs to use in their attacks. Malicious actors are motivated and persistent, employing many techniques and constantly improvising to circumvent the security of APIs. Enterprises lacking appropriate security best practices will be hard-pressed to make their private APIs public.
  
  
• Discovering and Auditing APIs—Sanitizing an enterprise of lost, orphaned, or unsecure APIs is a tough problem. Developers leave their groups or organizations without cleaning up services they are developing and testing. Even well-disciplined software teams slip up letting services run well past development, testing, and end-of-life stages. Another issue with APIs is documentation when new developers don’t know the full potential of the data being returned. This again points back to security.
  
  
• Connectivity—Even if a business finds compelling motivation to leverage their private APIs for external customers or partners, connecting an API behind three layers of firewalls in an enterprise is a daunting task. While business units may take many months to validate and justify the ROI to make this practical, one cannot just take an internal API and make it public; connectivity is a process as well. Consequently, agility suffers and developers cannot innovate at a rapid pace.

Ultimately, what we must realize is business agility in an untrusted environment is extremely hard. IT processes are informed, defined, and dictated by different security concerns. They exist for a purpose and cannot be circumvented.

Opportunity—The Enterprise IS the Platform

Once a business pivots to thinking how to compete in the API economy, the need to invert their APIs becomes a natural decision. The next logical step is to imagine the entirety of their business as a platform and envision ways to work toward that goal.

Kristin R. Moyer, vice president and distinguished analyst at Gartner, said, “The API economy is an enabler for turning a business or organization into a platform. Platforms multiply value creation because they enable business ecosystems inside and outside of the enterprise to consummate matches among users and facilitate the creation and/or exchange of goods, services, and social currency so that all participants are able to capture value.” (Mulesoft)

Taking a firm through this journey is not without its challenges, and this is where vendors share responsibility with the IT organizations. The business needs to understand which aspects of their internal assets can or will benefit the larger community and expand their value. The vendor ecosystem must deliver tools and technologies that help businesses safely invert APIs and unlock the value of the enterprise as a platform.