6    Building an External Developer Platform

To be a child is to imagine how cool it will be when you’re grown up. Then you’ll be able to do things like drive a car, hang out at a shopping mall with friends, stay up late at night, kick a football far across the field, wear lipstick, or smoke a cigarette. Clearly, some aspirations are both achievable and desirable. Others prove to be unimportant, even undesirable, or unachievable.

Companies that were not born digital are just starting to imagine what it will be like when they are digital. As they transform, they will achieve some of their aspirations. Others will prove to be unimportant, even undesirable, or unachievable.

Our conversations with executives suggest that many companies in the early stages of digital transformations aspire to power an entire ecosystem—you know, like Apple. The idea is to create a platform like iOS and make its services available to third-party app developers. Those developers then sell their apps to your customers and you tax the revenues. Next thing you know, your market capitalization is skyrocketing.

Of course, this is not the way every company’s aspiration will pan out. GE built its Predix platform to collect and analyze IoT data in ways that would improve management of customers’ industrial assets.1 GE anticipated that external developers would create components to expand the functionality of the Predix platform. But customer demand developed slowly and developers didn’t demonstrate much interest in providing the expected functionality.2

Despite this cautionary tale, most companies will find value in extending their digital platform to support ecosystem partners.3 What is actually desirable and achievable in these partner relationships is another question.

The Apple Aspiration

It’s worth noting that Apple’s ecosystem of app developers was not part of the company’s initial business model. Early on, Apple’s internally developed applications capitalized on the mobility and connectivity capabilities of digital technologies. Before inviting external developers to post apps in the App Store, the company had become internally proficient at creating apps: the browser, the email client, the short messaging services tool, the camera, the weather app, and the productivity tools. Although Steve Jobs initially resisted opening the iOS platform to external developers,4 he eventually recognized that Apple did not need to own all the apps. By then Apple was in the driver’s seat. Because Apple owned the underlying infrastructure and access to customers, app developers could see huge benefits from building their digital offerings on Apple’s platform.

Unless you can provide the best solution to your customers’ every need all by yourself, you, like Steve Jobs, will have to tap into the creativity of outside parties as you generate digital offerings. Otherwise, you’ll find yourself, poorly equipped, competing against alliances of powerful companies. Urgency is also a factor. While a company may prefer to develop its own components rather than use partners’ components, its customers may have little patience for the time it takes to do that. Thus, ultimately, an ecosystem will be important to most companies’ digital success.

The business models of many by now legendary digital start-ups, including Salesforce, eBay, Uber, and Facebook, are based on ecosystems. Indeed, the hype around ecosystems is creating a sense that everyone can and should build a winning platform that links a vibrant community of third-party providers and consumers.

An ecosystem is a business model that seeks to connect multiple sides of a market (e.g., app users and app developers on iOS; drivers and ride-seekers on Uber; posters, readers, advertisers, and game developers on Facebook), so they can interact directly with each other. Ecosystems exhibit virtuous-circle, cross-side network effects: the more participants there are on one side (e.g., developers), the more value will be created for participants on another side (e.g., users) and vice versa.5

It’s more exciting to focus on the brilliance of this strategy than on the embedded culture that will hinder a company’s ability to deliver on it. As earlier chapters have detailed, companies learn how to build and manage platforms of reusable digital components over the course of a long journey. Opening up a company’s components to external parties adds another set of design challenges. To address those challenges, you will need a fifth building block: an external developer platform.

An External Developer Platform Extends a Digital Platform

An external developer platform (ExDP) is a repository of digital components open to external partners. It’s useful to think of two different kinds of external developer platforms:

  1. An ExDP that allows partners to use the company’s internally developed components in the partner’s offerings. For example, the Google Maps ExDP makes functionality and data related to Google maps available to external developers for use in other companies’ offerings.6 Kabbage’s ExDP makes its automated lending engine available to other financial services companies.7
  2. An ExDP that provides an industry platform by creating a market for related digital offerings. For example, Apple invites application developers to make their offerings available to owners of Apple devices through their App Store. Similarly, Salesforce offers extensions developed by third parties to their customers through their AppExchange.

An ExDP supports ecosystem partnerships by securely exposing digital platform components via APIs to external parties. (Recall that an API—application programming interface—is the code that allows one component to request another component to complete the task it was programmed to do.) To facilitate partner use of internally developed API-enabled components, external developer platforms usually include a developer portal that provides a catalog and descriptions of all available components (often referred to as APIs, for short). ExDPs also provide tools like software development kits (SDKs) to help external developers quickly write new code that leverages the services performed by the platform’s components.8

In chapter 4 we described digital platforms as repositories of digital components—data, infrastructure, and business components. A well-designed digital platform consists of API-enabled components. The APIs give a company the ability to configure offerings from components in a modular, “plug and play” fashion rather than writing a monolithic heap of code for each offering. Once an API is developed, its security and governance features dictate who can access the API, and thus use the underlying service. In essence, an external developer platform (ExDP) extends to external parties access to the APIs for a selected set of components on a company’s digital platform. Companies can offer open access to APIs through a public online developer portal or they can limit access to selected partners. Figure 6.1 depicts the relationship between a company’s digital platform and its external developer platform.

Figure 6.1

Ecosystem enabled by an external developer platform

Some companies have an urgent need to manage external access to their digital platform. For example, as part of efforts to give individuals greater control over their data, open banking requirements in Europe and Australia require that the largest financial services companies allow verified third parties to access customer account information or initiate payment services via APIs.

Westpac New Zealand, part of Westpac Group, a large financial services company, developed figure 6.2 to describe how it intends to provide access to customer data and related banking services to external parties. The ExDP accesses business and data components residing in the company’s digital platform, which, in some cases, will access data and link to processing in the company’s operational backbone. (Another reminder that the operational backbone is table stakes!)

Figure 6.2

Westpac’s depiction of how its external developer platform works

Source: Westpac New Zealand Limited

Westpac technology leaders have observed that the ExDP establishes new relationships with third-party developers. These developers are not only partners but they are also, in effect, customers of the company’s APIs. As companies create their ExDPs, they will be defining business models for this new kind of customer—one that develops additional services for the company’s end customers.

The established companies we researched are in the early stages of building their external developer platforms.9 Because it’s such early days, best practices are just starting to emerge. DBS Bank in Singapore, Uber, Royal Philips, and Schneider Electric provide examples of how companies are approaching external developer platforms. DBS and Uber are providing business and data components that partners use in developing their offerings. Philips and Schneider are developing industry platforms that provide the infrastructure for other companies’ offerings.

In 2018, only 1.5% of established companies had a widely adopted and valuable external developer platform. Another 11% of companies were in the process of rolling one out.10

DBS Bank Provides Banking Services to Partners

DBS Bank offers its outside partners access to more than 200 API-enabled digital components. Although some components provide infrastructure services (such as an authorization service for secure access to DBS’s APIs), most components provide business and data services. These include credit card management, calculation of loan eligibility, a listing of customer channel preferences, calculation of foreign exchange rates, a listing of DBS ATM locations, a wide variety of payment services, and some analytics services such as customer spending patterns. DBS brands some of the products (e.g., DBS credit cards, DBS ATMs); in other cases, the partner’s customer might be unaware of DBS’s role.

DBS is still learning what kinds of ExDP services and related business models will maximize benefits for customers, third parties, and the bank itself. Some components, like those related to credit cards, could increase DBS’s revenue from credit cards. In other cases, DBS is targeting customer satisfaction. The company measures the benefits in terms of “customer stickiness.” For the most part, DBS is not attempting to generate revenues on component usage fees at this time.

The value to DBS’s partners is their ability to quickly ramp up digital offerings that have a financial (e.g., payments) element. Partners can focus on developing unique digital offerings by taking advantage of DBS’s core capabilities rather than try to duplicate them (and compete with DBS on what might become commodity services).

One partnership that is generating benefits for all stakeholders is DBS’s partnership with soCash, a fintech11 that developed an app allowing a user to locate a participating retail store (like a 7-Eleven) and “withdraw” money from the store’s cash register by using the app rather than by finding an ATM. In the background, the soCash app is interacting with DBS’s external developer platform APIs to withdraw money from the user’s account with DBS and deposit it in the merchant’s account. DBS does not receive any fees from soCash. Instead, DBS benefits from a decreased need to stock ATMs with cash. DBS also realizes increased satisfaction on the part of its customers who enjoy the convenience of accessing cash when no DBS ATM is nearby.

Another DBS partner, Tally, an Indian ERP software provider, is enabling straight-through processing of payments using DBS’s payments API. Business customers using the Tally ERP can initiate the transfer of funds from their DBS account to suppliers, for example, right from their ERP when they execute an accounts payable transaction. This saves a step in a customer’s accounts payables processing.12

DBS initially experimented with the value of an ExDP by inviting 15 start-ups to a two-day hackathon to see what start-ups might be able to offer based on an initial list of APIs that could possibly be provided on an external developer platform. The start-ups had many viable business ideas. They also identified some additional business APIs that DBS had not considered. Since the hackathon, DBS has been moving aggressively to offer services externally.

To make it easy for partners, DBS provides a website portal where potential partners can view a catalog of its digital services.13 For new partners who become interested in accessing its digital services, DBS lays out a 3-step process:

  1. Sign up on-line for a DBS developer’s account.
  2. Experiment in a secure sandbox, where the partner can test a linkage to the DBS API.
  3. Request production access so that the connection to the DBS service goes live.14

Exposing digital components externally has highlighted for DBS the importance of a well-designed and -managed internal digital platform. Initially, DBS allowed individual business units to develop their own API-enabled components. This accelerated innovation within the lines of business but it led to duplication across the lines of business, and essentially resulted in each line of business developing its own digital platform.

When DBS decided to offer components externally, leaders realized that their multiple digital platforms meant that they would be presenting multiple external developer platforms to potential external partners. This would make it harder and less appealing for developers to partner with DBS. Technology leaders have used these concerns about DBS’s ExDP to initiate discussions on rationalizing and consolidating relevant internal digital platforms. DBS Innovation Group’s Head of Innovation, Bidyut Dumra, explained how they handled this challenge:

We knew we were not going to be the “first” financial developer portal, so we set our ambition on being the “best.” This translated into a vision of having a single public-facing portal for partners and enabled us to bring all the lines of business and system owners to the same table to discuss and decide on how to make it happen. The resulting developer portal was launched in November of 2017 as the largest financial API portal globally, with over 150 APIs and 50 live partners using its services.

DBS is developing a single catalog of its more than 3,000 internal APIs. This effort will facilitate both internal and external reuse of digital components.

To encourage potential partners to participate in its ecosystem and to scale the use of its ExDP, DBS is investing in a new ecosystem partner engagement process. On the business side, the process includes opportunity discovery and partner onboarding, as well as the definition of joint commercialization and marketing options and the tracking of relevant business metrics. On the technical side, it involves security vetting, the identification of relevant new and reusable APIs, and the definition of how a service will be supported by DBS and the partner. DBS is finding that implementing—and where possible, automating—standard processes for partner management is important to driving value from an ExDP.

DBS expects its external developer platform to leverage its digital offerings and expand the services available to its customers. Uber has been exposing its APIs to customers for a number of years. It is still learning how to capture the opportunities and manage the challenges of an ExDP.

Uber Supports External Developers

Uber, which launched its ExDP in 2014, has a team of more than two-dozen people taking responsibility for oversight of platform development.15 This team aims to empower developers—particularly external developers—to build what the company refers to as “moving experiences.” The APIs exposed on Uber’s external developer platform are, in effect, digital offerings for external developers and their customers. For Uber, the key benefit of its external developer platform is that external developers create digital functionality that increases demand for Uber services.

Uber has an Affiliate Program to encourage external developers to create apps and applets that drive business to Uber.16 In turn, affiliates are rewarded US $5 for each new US-based customer they refer to Uber. The company’s ExDP provides external developers with access to API-enabled business components, as well as to software development kits. Uber also makes available integration elements (such as buttons and widgets), which enable partners to give their customers access to Uber rides with a simple click of a familiar-looking Uber icon.

Uber provides access to its digital platform through three major sets of APIs: one focused on ride requests and in-ride services; another focused on drivers; and a third on business customers. Through these sets of APIs, Uber offers a variety of functionality with which third parties can create new digital offerings.

For example, Payfare, a financial technology company, built an app leveraging the Uber Driver API. Individual drivers can sign up with Payfare to authorize daily (instead of the usual weekly) payment for the Uber driving they do each day. Payfare captures drivers’ earnings data in real-time. Then, for a 1% fee, Payfare processes payments directly to each driver’s Payfare Mastercard account. The Uber-Payfare partnership generates benefits for all stakeholders: Payfare benefits from the fees drivers pay; Uber benefits from its ability to better attract and serve drivers; drivers get cash when they need it.

Of course, many potential partnerships fail—a reminder that companies must generate shared customer insights related to their ExDP services. For example, in 2014, Uber created UberRUSH, a delivery and logistics service for small businesses that used Uber drivers to deliver packages and other items. Uber built the UberRUSH API to allow both internal and external developers to add logistics services like real-time tracking, signature confirmation, delivery price quotes, and summary reporting for Uber’s business customers. Uber’s expectation was that increased logistics functionality would make the company an increasingly desirable transportation option for businesses. In other words, the benefits to Uber would be increased transportation revenues.

UberRUSH attracted mostly small start-up businesses, like an on-demand dry cleaning service, various restaurants, and a peer-to-peer drone marketplace. Apparently, however, UberRUSH consumed resources, specifically drivers, in ways that generated less revenue than standard Uber services for both drivers and the company. As a result, in 2018, Uber shut down UberRUSH (and thus its API).17 This kind of test-and-learn experience is common as companies start building their ExDPs.

Uber’s Developer Platform team includes a developer-relations team, an API platform team, an API features team, and partner software developers.18 The team establishes priorities for development of both its digital platform and its ExDP. Team members identify internal needs by working with their business development colleagues. They also get ideas from external developers, through one-on-one interactions and a variety of forums and hackathons held around the world. They target large industry players (e.g., Hyatt, United Airlines, StubHub!, and Amazon Echo), all of whom facilitate Uber ride requests for their customers. Uber also attracts a long tail of developers who build applications for niche markets.

ExDP governance at Uber is mainly focused on generating opportunities. Accordingly, Uber gives business partners full control over data that flows into the partners’ applications. Sales and business development teams negotiate contracts and specific terms of use with large brand-name partners. For all other external developers, Uber has established standardized terms of use to which the developer commits when accessing ExDP functionality. Uber closely monitors uses by third parties and the terms of use indicate that Uber can implement a “kill switch” if it perceives a partner is misusing a service.

DBS and Uber are exposing business and data components to third-party developers. Philips and Schneider do some of the same, but their visions are more focused on creating industry platforms by also exposing infrastructure components.

Philips Builds an Industry Platform

Many companies aspire for their ExDP to become an industry platform (like GE’s Predix). For example, Philips is building an industry platform for healthcare. Philips’s ExDP leverages the company’s digital platform, HSDP19 (HealthSuite Digital Platform), providing access to components that will allow partners to build applications on its core infrastructure.

Whereas DBS and Uber are primarily providing partners with access to business and data components, companies building industry platforms are more likely giving their partners access to infrastructure components. HSDP, for example, provides infrastructure components on an Amazon Web Services (AWS) cloud foundation. In particular, HSDP has built seven categories of technical components that facilitate access to and control of IoT sensor data generated by healthcare technology and equipment:

  • Authorize—provide centralized identity and access management and ensure data privacy
  • Host—provide tools to monitor system status and application performance across global deployments
  • Connect—manage, update, monitor, and collect data from smart devices ranging from consumer-grade wearables to large medical systems
  • Store—acquire, access, and manage data from applications through a cloud-hosted repository
  • Analyze—furnish the infrastructure to build decision-support algorithms and machine-learning applications
  • Orchestrate—provide tools for workflow optimization, rules management, routine task automation, and communications coordination
  • Share—provide interoperability between HealthSuite-enabled applications and devices with external third-party systems

Philips has opened its external developer platform to a “by invitation only” group of friendly external developers. This can expand as the company builds a bigger portfolio of components and can better identify the opportunities to leverage the company’s ExDP. Over time, Philips expects internal and external applications built on HSDP to facilitate greater individual control over healthcare data and greater integration of data within healthcare systems. If large numbers of healthcare providers and customers rely on HSDP, Philips will likely start generating revenues not only on its digital offerings for healthcare customers but also on its provisioning of a healthcare industry platform.

Although Philips is experimenting with making selected components available (i.e., analytics and AI services) to third parties, the company is concentrating on building up its internal digital platform. That focus should accelerate development and reuse of the company’s internally developed components. Philips’s growing portfolio of offerings will almost surely provide useful components for third parties, when it’s ready to take on that management challenge.

Schneider Electric Creates an Ecosystem for Energy Management Solutions

Like Philips, Schneider Electric envisions offering an industry platform. Schneider recognizes that its industry is facing a major shift in its approach to innovation. This shift is revolutionizing the customer experience and engagement. It is also re-centering the conversation between suppliers and buyers around solving problems instead of building better equipment. Accordingly, Schneider has developed Schneider Electric Exchange,20 an ExDP designed to support an ecosystem of IoT energy management and automation solutions suppliers and buyers. The ExDP allows ecosystem stakeholders such as developers, data scientists, end-users, inventors, entrepreneurs, and more to create, collaborate, and scale solutions. Schneider, through its ExDP, orchestrates this open ecosystem.

To interest external developers, Schneider Electric kick-started its ExDP in April 2018 by identifying several challenges that needed to be addressed. A hackathon invited external developers to propose solutions to three challenges. The best solutions received a reward. To prepare for the hackathon, Schneider identified APIs to share analytics and data sets that would be most important to developers trying to address the proposed challenges. In this way, Schneider Electric is both building its ExDP (Schneider Electric Exchange) and gaining offerings developed by third parties. The company plans to conduct additional hackathons as it develops and exposes developer APIs. By increasing digital offerings available on its exchange, Schneider generates more traffic and positions itself as an ecosystem driver.21

Industry platforms, like those Philips and Schneider are developing, have the potential to generate revenues from taxes on partners who use the platform to sell digital offerings. For any company developing such a platform, however, future revenue streams are not assured. Companies have to experiment to learn how to create a revenue-generating ExDP value proposition.

Who Needs an External Developer Platform?

A company’s external developer platform allows it to expand the number and scope of customer offerings and generate new revenues or increase customer satisfaction. In short, an external developer platform allows a company to reap advantages of scale. Because the distribution costs of software are immaterial, reusing digital components offers a theoretical opportunity to increase their value at near-zero cost. In other words, an ExDP increases the payback on investments already made in a company’s digital platform.

This does not mean that an ExDP is “free.” Indeed, in 2018 Philips was reducing its emphasis on building external connections to HSDP because those efforts were diverting attention from other more important digital efforts. For example, supporting external developers required designing and automating ecosystem partner management and onboarding capabilities. Henk van Houten, Philips’s chief technology officer, explained the tension between building internal components versus building the ExDP:

Commercializing a digital platform externally is not a convincing proposition if you are not migrating your own existing and most successful businesses onto it, solving all implementation difficulties in practice, and demonstrating the end user value. So this is the first priority. It is a bit of a dilemma, as external users will be needed to drive scale.

Schneider Electric has also focused most of its resources on building out EcoStruxure, its internal digital platform. Its occasional use of hackathons allows the company to start taking advantage of partnerships, while the company develops and commercializes internal EcoStruxure offerings. ExDP efforts will surely ramp up over time.

Many executives have told us that they are not interested in building an external developer platform. They are focused on getting benefits from their own digital offerings. Our sense is that, in the early stages of a digital transformation, ignoring an ExDP may be a realistic—even wise—strategy.

Nevertheless, our research has found that all five building blocks, including the external developer platform, are interdependent. The experiences of companies like DBS highlight these interdependencies. The ExDP has placed demands on the company’s operational backbone and forced the company to rationalize and further professionalize its digital platform. Like its digital platform, DBS’s external developer platform requires attention to prioritization decisions, component ownership, and iterative, Agile methodologies—key characteristics of the company’s accountability framework. Finally, customer experiments and insights are important to better understand the intersection between what customers want and what DBS and its external partners can jointly deliver.

Just as an ExDP is dependent on the other building blocks, an ExDP can help build other digital capabilities. For example, an ExDP has unique requirements and can be a natural place to experiment with autonomous teams and accountabilities. It exposes the company to an entirely new set of stakeholders with conflicting and convergent needs, which provides opportunities to build customer insight capabilities. And it can provide useful components that could be added to a digital platform. In other words, a well-managed ExDP will almost certainly boost other building blocks. Unlike the other four building blocks, however, it’s hard to even start to build an ExDP unless a company has already developed some capability related to the other four.

Designing and Developing an External Developer Platform

As the DBS, Uber, Royal Philips, and Schneider Electric examples demonstrate, designing an external developer platform to power an ecosystem of developers has the potential to grow revenues, profits, and customer satisfaction.22 However, we do not recommend that companies guess what kind of external developer platform the world needs and set out to build that platform. Instead, they should first develop a valuable portfolio of reusable components for their own digital offerings. They can then make some of those components available externally as they mature their other digital building blocks.

Building an ExDP takes more than exposing APIs of internal components and cataloging them in a developer portal. Your first challenge will be identifying what kinds of digital components will generate benefits for you, your customers, and your partners. Then, you will need to stimulate external innovation that configures offerings from those components.

In our survey, the average share of total revenues generated from digital offerings was 5%. Those few companies with a well-developed external developer platform generated, on average, 20% of their revenues from digital offerings.23

Identifying which digital components have the greatest potential to provide strategic benefits may be challenging. A component that entails or embeds company-specific data is likely to be uniquely valuable to external parties. Similarly, a component that embeds knowledge or capabilities that your competitors do not possess is likely to be competitively distinctive. On the other hand, any components that are not unique or non-substitutable are commodities, for which there might eventually be a race to the bottom. Ultimately, you want your ExDP to provide access to components that potential partners either do not wish to develop themselves or may not be able to develop in time to meet market demands—and, of course, that enhance their value to customers.

As we’ve noted, external developer platforms come in two flavors. One involves exposing business and data components that enable partners to create digital offerings leveraging your data or business functionality. The other creates an industry platform exposing infrastructure components that enable partners to add their digital offerings to your marketplace. In both cases, your business partners become customers of your ExDP. You’ll need to assign an ExDP owner who will take responsibility in three areas: (1) working with partners to identify valuable components, (2) governing how components are exposed and used, and (3) managing partner relationships.

Getting Your External Developer Platform Right

The external developer platform is just one of five digital building blocks. It probably should not be your first. But bypassing the opportunities that an ExDP offers poses a different competitive risk. And regulations like the open banking requirements in Europe and Australia may force development of an ExDP before a company is quite ready. For most companies an ExDP is likely to be a critical building block. Here is a summary of the key points from this chapter:

Notes