Understand the Power of Internal APIs

One of the biggest mistakes in modern information technology is using the wrong tool for the job. Any software architect will tell you that each layer has an area of responsibility. Though you could hack together a way to force more functionality where it doesn’t belong, it almost never turns out well. Usually, it just leads to maintenance costs, flaky integrations, the burden of supporting a proprietary architecture, and so on.

This is an escalating challenge because businesses expect more from their technology groups than in the past. IT is no longer just the curator of infrastructure; increasingly, it’s the enabler of new business opportunities and efficiencies. Now, more than ever, it’s important to use the correct tools and to identify solutions for today’s problems.

Most enterprise leaders understand this urgency, but in trying to address it, many make a big mistake: They think an API (application programming interface) platform is only for external use cases. For internal use cases, they turn to integration point solutions in which APIs are only designed within the narrow scope of the integration project at hand, not to facilitate developer consumption or support future extensibility.

Due to this mistake, many businesses limit the potential of one of the most powerful tools in the internal IT arsenal, cost themselves time and money, and risk disappointing their users.

APIs inside the enterprise

Make no mistake, APIs are fantastic at solving the problems of connecting external users with backend systems. It’s easy to see why enterprises think of APIs in these terms. But let’s look at what many internal IT teams are trying to solve and how APIs can play an essential role in these situations as well.

Connect different parts of the business to work more efficiently

This is essentially the same problem as connecting external users. APIs can provide an easily consumable layer of abstraction for connecting parts of a business, creating linkages that not only serve today’s needs but also (unlike classical integration techniques) provide the flexibility to adapt to changing requirements.

Enhance security

An API layer designed for developer consumption decouples consumption from the underlying complexity of systems of record, providing access controls and an audit trail for all system access.

Operate more efficiently

In many businesses, IT is being asked to do more with less. Using a well-understood, standard technology — like that provided by consistently designed RESTful APIs — allows a business to connect the right people with the right tools.

Save money

Internal APIs allow both cost savings and cost avoidance. An organization can achieve cost savings by doing existing tasks faster, automating with lightweight APIs instead of heavy customization. Cost avoidance is possible because the organization no longer needs to build or buy expensive connectors and proprietary integrations.

As the above attests, consumption-focused APIs can be as useful inside the organization as outside, and more organizations are taking note.    

“We use APIs for three categories,” said Thomas Squeo, senior vice president at telecom West Corp, earlier this year. “One is for our internal operations. Two is for accelerating our product teams from a platform consolidation standpoint, so anytime we see duplication in the portfolio or an opportunity to harden around certain market segments, we'll typically build an API around that and then reduce the footprint. And, the last area is third-party consumption, basically our customers and our partners consuming APIs that are built by our organization.”

Getting Started

Many enterprise leaders know they are moving too slowly, failing to adapt to modern architectural best practices, and frustrating their users with outdated applications, but they may not know how to change. In my role as a digital strategist, I’ve observed that the path forward can be relatively straightforward:

Have each team begin adding APIs to the platform. Enterprises shouldn’t worry if some teams don’t have APIs yet. APIs are lightweight and easy to create and publish.  

Require internal teams to communicate with each other through APIs. Once APIs begin populating the platform, people on one team no longer need to learn all the quirks and intricacies of other teams’ work. They don’t need to understand the naming conventions, technology choices, or database structures. Whether internal or external, APIs can hide that complexity, assuming they are designed in a consistent way, with a focus on facilitating developer consumption rather than just making a connection between systems.

Manage APIs as products. Leading enterprises increasingly manage APIs as products with full lifecycles and a permanent product owner who uses a customer-focused, data-driven approach to continually improve the platform. An API designed within the limited scope of a project may serve today’s needs, but if it isn’t built for extensibility and to promote developer consumption, it will be of limited use in the future.   

Investment in an API management platform. An API management platform will take care of core functionality: caching, traffic, authentication/authorization, security, scaling, monitoring, etc. Many solutions are available, saving enterprises the time, money, and resources of building their own.

Ditching legacy muscle memory. Why do so many companies get confused about the differences between legacy integration and APIs in the first place? Muscle memory. The past 15 years have been spent on integration. It’s in the vocabulary and comfort zone of most IT folks. The problem is, IT is not trying to solve yesterday’s problems, but today’s problems, which include:

Agility, scale, and communication at Internet scale. An API-centric architecture enables applications to be built in an agile fashion, future-proofed for new frontend technologies, deployed at scale, and easily connected to other systems inside and outside the enterprise.

Demise of the centralized service governance model. The rise of virtualization, IaaS, and PaaS, as well as a generation of Internet developers with easy access to server resources, have led to the demise of the centralized service governance model. Centralized SOA governance has ceded ground to API governance, which focuses on supporting application teams and agile, decentralized API-first architectures.  

Integration models rooted in appliance-heritage products don’t fit automation-centric DevOps processes. New API use cases, as well as new API-centric and microservice-based development efforts, often have little need for integration server technologies. As a result, heavyweight integration products have given way to a model where resources, including APIs and the systems they connect, are increasingly managed within the application tier by a set of DevOps tools designed for today’s agile enterprise.

As the above demonstrates, APIs are central to how modern IT functions. Indeed, APIs can provide a range of benefits and implications beyond those outlined here. For example, in an API-centric architecture, ETL (extract, transform, load) becomes obsolete. Instead, every app is responsible for exposing its data in a structured way via APIs. The API-based pull and push of application data enables a  feedback loop that can feed predictive intelligence engines, which can communicate back to the application via APIs to drive additional actions.

The use cases and benefits are numerous, but the key point is this: In this competitive market, missing the pivot from legacy integration to using APIs to connect internal systems might mean the difference between success and failure.

Brian Pagano is Global Platform Strategist for Google.