Digital Transformation: You’re Doing It Wrong If You’re Not Looking At APIs

Every enterprise has valuable data and APIs. Posit your business ecosystems and developer communities as ongoing partnerships to ensure maximum functionality and innovation.

Cultivating communities of partners and outside developers is a significant part of any organization’s move toward maximizing the value already present in its software systems.

Every enterprise in the world has valuable data and functionality in its systems—they wouldn’t be in business otherwise. But on their own, these enterprises can only do so much with these digital assets, especially if their internal developer programs are rooted in legacy paradigms or particular skills that don’t fully address changing customer needs.

Consider a restaurant chain offering online ordering. Its software systems include latent value, such as the ability to look up restaurant locations or to identify and order specific menu items. But to maximize how that potential turns into actual value, the restaurant chain needs to make these systems available to developers who use them to build apps. Some of these developers work inside the company, and some of them work within its partner ecosystem—but all of them contribute to translating abstract value into the real-world result of a customer placing an order via the digital channels they prefer.

To make this happen, the chain might rely on a third-party payments processor that lets customers not only order food items but also pay for them using the methods they prefer. Its software might integrate with a delivery service, not only making it easier for customers to order from the restaurant but also exposing the restaurant to new potential customers attracted to the delivery service. The service itself might integrate functionality from a partner that provides mapping and navigational capabilities, helping delivery drivers to find the best route and customers to track their incoming meals.

All of these connections involve developers composing different software systems to create different efficiencies or customer experiences. Consequently, the overall expression of value for the restaurant chain relies on the interaction of many software systems, both inside and outside the company, and the efforts of many developers, both inside and outside the company.

In this article, we’ll explore why these business ecosystems and developer communities are so critical to success, as well as how enterprises can better position themselves to capture the value these communities and partnerships can generate.

Why some developer programs don’t work

A starting point for all enterprises is that customer engagement is evolving faster than ever and is more oriented around digital interactions.

This means the role of IT is no longer technology curation but rather strategic enablement through technology—that is, to not just maintain systems but manage them such that the enterprise can recognize, execute on, and maximize the value they contain. To do this, IT needs to make the systems securely and consistently available both to internal and external innovators who can use them for new projects.

Think about those restaurant chains again and how they’ve had to change how they interact with customers. Doing so was not just about keeping systems online or doing custom integrations. Rather, it was about making the business’s systems available for developers making new apps and interoperable with a potentially limitless ecosystem of partner systems.

This is easier said than done. Often, when I talk to leaders at large companies about their developer program, I find they have many staff developers and work with many external developers—but they also have a bloated IT stack that includes several layers of platforms. This bloat, and the way different business units approach it, leads to helter-skelter programs for partners and outside developers—and to limited, inefficient progress.

In these instances, many business units form external partnerships, hence the large developer footprints. But because of the bloat, decentralized partnering processes, and inconsistent developer experiences, co-innovation is limited to certain pockets of the enterprise’s portfolio.

Each business unit may have its own way ​​of onboarding external partners and developers, forming agreements with them, giving them access to whatever corporate assets they’re supposed to work with, and so on. Business units with no visibility into one another’s projects can easily duplicate efforts, and developers face both unnecessary levels of bureaucracy and inconsistent experiences.

This creates a number of problems. For example, if a media company wants its content available in as many third-party apps or on as many third-party platforms as possible, that company probably doesn’t want a separate IT integration process between each business unit and each third-party. Likewise, if a bank wants its customers to be able to make transactions within other third-party apps they use, such as retail apps, the bank probably doesn’t want a separate IT integration process for each app.

Moreover, with no unified “digital front door” for partners, many aspects of the business go comparatively ignored by the outside. Software integrations are driven by the goals of individual business units but lack a more holistic vision. With some of the value in the enterprise’s systems brought to life and some left mostly dormant, the organization’s aggregate ability to share technologies with partners is uneven—and so too is its ability to innovate or adapt to changing customer needs.

Smoothing out this bumpy ground starts with a consistent approach to APIs and API management.

APIs are essential to digital transformation in large enterprises

APIs (Application Programming Interfaces) are how software systems talk to one another, even if they were never meant to do so. APIs are sometimes created as bespoke integrations, never to be used outside the current project, but that approach perpetuates the problem outlined above, with scattered custom integrations rather than a unified way to expose and manage access to digital assets. Instead, APIs are most valuable when they are standardized and managed to help developers modularly, repeatedly, and quickly combine data and functionality to create new apps and services.

By creating and maintaining APIs designed for self-service developer consumption (i.e., not just for a one-off integration), a business can achieve at least two things:

1. Help internal developers to more easily leverage valuable data and functionality to produce new digital products: For example, UCLA recognized that departments throughout the university needed to build apps that leveraged financial data and functionality. By building and managing a unified APIs platform for this and similar use cases, the university’s IT team has increased the ease and speed with which developers can build and deploy new apps. API calls, a close proxy of how APIs (and the apps they power) are being adopted, increased from only 1 million calls in 2020 to over 11 million calls in the first half of 2021. Pitney Bowes, meanwhile, has shaved as much as 70% off software design cycle timelines just by making digital assets accessible and shareable via a unified API platform.
2. Facilitate the sharing of valuable digital assets between internal teams and with partners to create ecosystems in which all parties can symbiotically combine their software to better attract and serve customers. AccuWeather, for example, makes its weather data available to tens of thousands of external developers via APIs. This relationship generates revenue for AccuWeather, as some of the APIs are monetized, while also increasing the number of developers innovating with its services. Moreover, it also produces value for developers, who use AccuWeather’s APIs to create more compelling apps. Similarly, Arab Bank provides APIs that help fintech partners build new services for Arab Bank customers, all while complying with the various regulations in the financial industry.

But there’s a catch: the processes of yesteryear aren’t easy to change. APIs have been around for a long time as a way to connect systems, but the idea of APIs as IT’s digital nervous system or the building blocks for new combinations of software is relatively new. Enterprises undergoing digital transformation must address not only their technology stack, but also the IT culture around the technologies.

Frequently, there is little order to an organization’s API efforts, with a dozen or so different business units all approaching APIs differently. Some units embrace “integration-first” ideas, others adopt more modern “ecosystem-first” ideas, and overall, only some of the value housed in an enterprise’s systems ends up maximized.

Over time, this approach effectively results in a dozen unique “IT enterprises” within a larger organization, each with its own standards and partner onboarding strategies. A partner would have to create 12 unique business relationships in order to use all the different corners of the enterprise, and other external developers attracted to the enterprise’s digital assets will be forced to navigate a fragmented path. This approach introduces friction at almost every turn: different billing relationships, onboarding and approval processes, pricing models, API protocols, and so on. Such inconsistency limits the organization’s ability to increase the number of external contributors innovating with its digital assets and introducing them to new customer bases, which limits the enterprise’s strategic agility overall.

Related: check out our article about UCLA’s standardized API program and our blog about how Arab Bank is using APIs to accelerate innovation with partners.

The API layer beneath your applications is a source of insights

In my experience consulting with large enterprises, I’ve noticed many leaders seem confused by questions about how much traffic their APIs have generated and how many APIs they have shipped. Terms like “shipped” and concepts such as traffic measurements are typically focused on applications, not the APIs from which applications are composed.

Applications are important, but the API layer beneath—where different systems coalesce easily or don’t; or where different systems can or can’t be easily manipulated—is where a lot of the strategic insight and agility can be found or blocked.

But this attitude can create silos that separate sources of value across the enterprise. Applications are important, but the API layer beneath—where different systems coalesce easily or don’t; or where different systems can or can’t be easily manipulated—is where a lot of the strategic insight and agility can be found or blocked. Which data sources are used most often across all apps? Which pieces of functionality are most widely leveraged for new uses? Which system, among the many that combine for a user experience, is responsible when app performance degrades? Looking at apps won’t necessarily tell you this— but looking at APIs will. 

An API embraced by lots of developers across many business units and partner organizations is an obvious opportunity for growth and an obvious sign of data or capabilities that may fit into many use cases across many industries. An application that serves only a narrow, specific use case may be an end in and of itself, with little to indicate whether its constituent components are harbingers of anything more. It’s easy to focus on applications because that’s where customer interactions often occur, but the insights aren’t always about what existing customers are doing with an existing application so much as what external partners are doing with APIs to expand customer appeal. For example, this kind of developer creativity is how payments systems are being leveraged for applications outside their original use cases, such as to facilitate small business lending and home loans.

Capturing such insights, and encouraging such external API adoption to occur, starts with standardized API design and management best practices across all business units. This is a rejection of integration-only ideals that some business units may still embrace. APIs are not just connections between systems, intelligible only to their creators for single purposes, but rather products for developers, standardized and managed to make innovation easier, to accelerate the creation of new services, and to measure API usage for insights into future improvement.

Read this next: To learn how Google Cloud customers are using API management to accelerate innovation, read our story about Magalu, one of the biggest retailers in South America.

Composing digital assets into value with API management

Innovation means treating the developers using your APIs as first-class citizens, the same way you treat your customers who consume the apps and digital services that those developers build. 

To do this, the building and managing of APIs can’t be a fragmented effort that varies across teams or focuses on one-time integrations instead of developer reuse and open-ended opportunity. The value a given company possesses is often best-maximized when it is combined with partners for richer functionality or extended to external developers who can innovate with the value, attach it to other types of value, and introduce it to new categories of user. 

Download our State of API Economy report to see how digital business ecosystems drive innovation and efficiency.