The API (R)Evolution
A short API retrospective, from SOA to digital transformation and beyond
By Ed Anuff
Application programming interfaces, or APIs, have and continue to be the de facto standard for building and connecting modern applications. In the simplest terms, APIs let software talk to other software — which means they put more developers to work developing more applications in less time.
Though enterprises have used APIs for years, there’s been a shift in the way these interfaces are viewed within organizations. Many competitive, forward-looking businesses now think about APIs not just as an integration technology to connect apps and data but as software products that empower developers to unlock new digital business models and opportunities.
Indeed, the adoption, design, and management of APIs is increasingly driven not by IT middleware requirements but by strategic business goals relevant to all leaders in the organization.
Supplanting SOA: How APIs became the de facto way to build software
About a decade ago, many businesses relied on service-oriented architectures (SOA) in their IT organizations. While SOA allowed IT teams to connect previously-siloed internal systems, many technology leaders soon realized that SOA-based infrastructures were not always an effective way to extend developer ecosystems or service consumption beyond the perimeter of the enterprise.
Though SOA was an important IT development that some enterprises have successfully implemented, it typically requires skilled architects to implement effectively. Moreover, in many organizations, SOA has become overly prescriptive, with governance often applied by a centralized center of excellence that locks down digital assets rather than making them more easily accessible and easier for developers to use. While many enterprise leaders were enthusiastic about SOA’s potential to help them produce more reusable services, many SOA adoptees ended up setting a very high bar for service design that resulted in a deterrence to sharing and reusing services — the exact opposite of the initial goals.
This unfulfilled promise of SOA to enable IT teams to more quickly deliver more reusable services was the initial impetus that drove many enterprises to look at revisiting and recasting their services strategies as API programs instead.
API-based architectures, in contrast to classic SOA, are designed for decentralized teams, very lightweight governance, and iterative, fast development. API-first businesses often release APIs quickly in the form of minimum viable products that are protected from misuse through the digital circuit-breaker of API management, and then use analytics to iteratively improve these APIs based on how they’re being used. And because APIs abstract backend complexity behind a consistent interface, they decrease the understanding of backend systems that a developer needs to possess. This shift democratizes access to digital assets, making it easier for developers of almost any expertise level to leverage systems and data.
Not too long after APIs began to prove themselves as an alternative to SOA, mobile computing emerged in a big way, and businesses everywhere focused on the need to create a new type of application — the mobile app — that could deliver data and services to customers wherever they were.
Mobile apps required, and continue to require, a different set of security and developer workflows than those used in traditional enterprise architectures, and these needed to be supported with new operational models to stimulate new types of mobile services. While mobile apps didn’t have a clear analog to traditional enterprise architectures, they did have something in common: APIs as the mechanism to share data and services.
All of these trends have meant that many successful companies have shifted away from centrally governed SOA practices and toward smaller, faster-moving teams that leverage APIs — and now even microservices — to work in parallel without slowing one another down. Compared to legacy paradigms, the API-first approach is often seen as being more adept at keeping pace with rapidly shifting market dynamics and continually evolving customer preferences.
APIs and digital transformation
The most recent business driver for API usage has been digital transformation. Increasingly, businesses are looking to digitally transform to be more competitive and support new types of business models that involve complex partnerships or new types of product distribution.
The hallmark of digital transformation is being able to do business with customers, wherever they are, across an evolving array of transaction modes or interaction types. Today, essentially everything that goes into making a company more digital — delivering new customer experiences, building software ecosystems, moving to multi-cloud environments — involves APIs.
Because APIs make it easier to securely share digital assets while masking backend complexity, APIs mean companies don’t have to shoulder their historical burdens. Instead, they can focus on maximizing their proprietary strengths by sharing data, systems, and functionality with customers, partners and developers. As APIs attract an ecosystem of developers, the API provider may even rely on ecosystem participation to fill go-to-market gaps and extend its services and data to new markets and use cases.
Consider, for instance, how a movie theater company might benefit from creating an API that lets any developer build movie showtimes into a web app, and how this ecosystem could be further enriched if payments APIs and navigational APIs that provide directions to nearby theaters were added to the mix. For the movie theater company, more developers leveraging these APIs means more ways for consumers to interact with the company’s services — and more opportunities to sell tickets, build brand equity, create customer loyalty, launch new services, and so on.
The value of APIs is still growing
With APIs proving to be the key to securely delivering connected experiences, streamlining partner interactions, and promoting new platform business models, can they still be considered integration technology? The answer is yes, they can, and indeed they often are. But it’s important for IT leaders to understand that while APIs do promote integration, it’s dangerous to use “integration” as shorthand to describe APIs.
Broadly speaking, integration is an umbrella term for connecting systems and applications that are essential to building the complex architectures that enterprises need. The problem is that “Application Integration” often refers to a category of solutions that has become associated with a number of specific middleware technologies. On Google’s Apigee team, we’ve found that defining APIs just as integration technology encourages a mindset in which using a centralized middleware architecture is mistakenly seen as sufficient for building a modern, connected business.
Indeed, many enterprises have evolved toward a connected IT architecture, with business-critical software spread across multiple cloud providers and SaaS applications. Often, organizations not only connect but also manage, secure, and monitor these increasingly connected architectures with APIs. So while APIs continue to be important components of connecting applications and data across increasingly heterogeneous IT architectures, their value often goes well beyond that.
APIs have come a long way in the past 10 years, from anonymous pipes between systems to the foundation on which modern business is built. Despite expanding use cases and widespread adoption of APIs as business drivers, the API management category is in the early stages of adoption according to industry analysts. With the increase in adoption of public cloud technologies and leading businesses moving to modernize the application stack with cloud-native technologies, APIs are positioned to play an even more significant role as they enable efficiencies in managing on-premises application infrastructure and in shifting workloads to the cloud.
[Looking for more digital transformation insights? Read our eBook, The Digital Transformation Journey.]
