转载于 迈克尔.莱皮奇

The observations and suggestions in this article stem from my years consulting with Fortune 500 digital programs around the world, distilling patterns that, in my professional opinion, have emerged as effective.

Why KPIs matter

Many executives at large enterprises are now connecting the dots between the performance of their core business and the relevance of digital capabilities powered by application programming interfaces (APIs). To facilitate next steps in realizing value from these critical assets, enterprises need to become savvy in the use of key performance indicators (KPIs) to drive digital programs, particularly the development of application programming interfaces (APIs).

Enterprises have long relied on KPIs to align all areas of the business, and this applies to digital initiatives as well (see Apigee Institute KPIs, Conviction, and Competitive Advantage and Three ROI Criteria to Drive Digital Success). Without KPIs, digital programs and the API initiatives intended to enable them often struggle to realize their business value. Gartner, Forrester, McKinsey, Deloitte, MIT and others are now finding that industry leaders are seeking guidance on how to include metrics that accelerate “getting great at” digital.

The use of KPIs in API-powered digital programs can impact the business in profound ways.

Take the car business: the future of self-driving cars is fundamentally changing the definitions of “driving” in ways that turn basic concepts such as liability and ownership upside down. Software is the source of this disruption, and just as software continues to expand its role inside the vehicle, it also permeates the buying, servicing, insuring, and managing value chains around the vehicle.

As a result, several car companies are accelerating development of “digital” capabilities around their vehicles, while others — a dwindling number — appear content to remain manufacturers of increasingly isolated hardware. These fundamental changes will arguably be as consequential as the advent of just-in-time and kanban manufacturing in the eighties, and should, as has often been the case in enterprise paradigm shifts, be driven from the executive suite. Just as Ford has redefined itself to be a “mass mobility” company, other car makers such as Daimler, Toyota, and many others are adding KPIs that prepare the enterprise for a digital future.

What is a digital KPI?

In my experience, working with enterprises over the last five years, it has become clear that without good digital KPIs, transformation efforts can become stuck in one-off projects. However, good KPIs are sometimes not obvious at first glance, and supporting metrics play an important role.

Good KPIs should cause the different operating units of a company to align toward common goals, even though the required changes can be quite diverse. Continuing with the car example, here is what this might look like:

• Financing units can create software-enabled shared ownership models (e.g., Ford Leasing, Subscriptions, Travel on Demand)
• Auto-pilot engineers can invest in the artificial intelligence (AI) necessary to improve the safety and utility of the vehicle
• Vehicle analytics teams can design algorithms that enable new insurance, risk management, and maintenance services
• Marketers can shift messaging platforms and adapt content to appeal to new and more diverse “user” experiences
• Human resources teams can pursue the creative talent needed to pull off these changes

In fact, virtually all executive roles can reshape the way their units work. Even the CEO may spend over 50 percent of her time on transformation (for more, see this excellent article at Harvard Business Review).

Here are some real-world examples of companies shifting their KPIs and business models to digital:

• Humana is increasing interoperability across its partner ecosystem
• Financial Times is moving its revenue entirely to digital channels
• Pitney Bowes targets digital commerce as a core competence

How to avoid bad KPIs

In insolation, API-centric KPIs can be misleading, and the wrong metrics can lead an enterprise astray. If they are not combined with business-level KPIs, simple IT-level metrics — such as the number of APIs produced, the number of developers using APIs, or the number of apps using APIs — can lead a team to emphasize the wrong incentives. Worse, even when teams achieve these targets, they may still come under-fire for “not providing business value.”

Take the case of one major enterprise I worked with. The leadership had set hard and easily observed targets to create as many APIs as possible, across all platforms. At first glance, this appeared to cause the desired API building spree — so how did it lead to enormous waste and throw-away work?

It turned out that to deliver the targets cheaply and quickly, the enterprise’s legacy integration teams simply passed existing web services through the API platform layer, without simplifying or optimizing them for consumption or even consolidating security mechanisms on the platform. As a result, the application developers using these APIs had to continue building expensive and brittle business layers in their applications simply to wrangle the small set of relevant data elements from the large payloads. The huge payloads bogged down communication channels and the processing burned battery life on mobile devices, degrading the customer experience. In the end, the APIs were used only by internal application developers under a mandate; distribution channels found the APIs too difficult to use.

One lesson from this example: while enterprises should revisit their highest level goals and adapt KPIs to be more compatible with digital opportunities, the stronger programs will often proactively shape their own targets to anticipate broader transformation, following some important guidelines:

• Focus on driving growth, breadth, and speed of API adoption by the application programs that depend on them.
• Accelerate the velocity of iterations in not only API and app development, but also the creation of user-facing digital experiences.
• Align the metrics of the API program with the metrics of developers downstream in the digital value chain, such as channel partners using the APIs.
• The program should NOT be a stand-alone P/L function. Otherwise, APIs may be perceived as exotic and apart from the core value creation activities of the organization, which prevents the APIs from creating value for the business.
• Generally, avoid using “number of APIs” produced as a top-line target. Otherwise this is likely to lead to APIs of low value, low quality, and low adoption.
• The program should NOT be governed in scope-budget-schedule terms. This mindset is largely incompatible with creating value in the fast-moving, agile digital economy.

KPIs in the Digital Value Chain

Just like in other business areas, smartly designed KPIs can enable the API program to define its direction, to regularly assess the alignment of its work, and to constantly work towards intended outcomes. But to optimize API program success, the enterprise should also align the rest of the digital value chain around the API program with well-correlated incentives.

Let’s briefly revisit the digital value chain:

• The front-end application software calls APIs from within its code in order to invoke services elsewhere in a network, all to return data or perform some processing. These apps are mobile apps, websites, a partner’s servers, etc., and are the products that actually create value among traditional customers.
• The APIs that receive these calls have to have certain properties in order to be valuable to the apps: good design, good security, real business value, good performance, and good access to back-ends that do the heavy lifting. Because they function as products for developers, particularly valuable APIs can even be monetized for external audiences, becoming direct revenue streams in their own right.
• Finally, the back-ends that do much of the enterprise’s core work should be well connected to the APIs, meaning they trust the APIs for access control, traffic management, security, proper identity of the user, coordination, lightweight orchestration of multiple back-ends, and more.

In order to be effective, an API program’s goals should be aligned with the goals across this value chain. For example, the application teams needs to have the incentives to launch valuable applications rapidly and transparently to avoid building brand new back-ends. Similarly, the back-end teams need to have the incentive to get the services of their systems into the hands of customers, not simply to other back-end servers.

How to use Specific KPIs for API Programs

Here are some effective API program KPIs, along with common pitfalls to look out for. It’s important to remember, the value of a given KPI is highly contextual. All of the following KPIs can be valuable, or they can be deceiving. Successful programs typically define KPIs that align closely with the business, including goals upstream and downstream the value chain, and may include culture elements that help drive success.

• Number of APIs. Often used to drive short-term productivity, this target may often ignore that APIs must also have easy-to-use utility; simply pumping out a plethora of unusable APIs without relevance to apps will likely cause confusion and encourage rejection of the program. Use this metric in a very tactical manner, once good governance for quality and value is in place.
• Number of developers. This target is commonly intended to improve adoption — but APIs must have utility; a singular focus on marketing and onboarding without valuable APIs threatens the program’s momentum and undermines its value for developers. Use this target in combination with other confirmation that the APIs have real business utility, and distinguish between overall developer adoption, and adoption among specific developers who are using APIs in a known business context, such as integrating the applications of existing ecosystem partners.
• Number of customers. Customers don’t experience APIs directly — they only experience the apps that use the APIs. This target is important, but use it together with good API instrumentation and app analytics, a set of core APIs related to identity, and careful systemic alignment with the app teams as well as partners and channels that use the APIs.
• Number of partners. Use this target in order to reach out to partners, drive adoption, and demonstrate success to existing business units. In addition to confirming business value, offer DevJams and similar events to kickstart interest in your API program and drive adoption among partner developers and system architects.
• Number of apps. While this target may be useful to drive reach, if used in isolation, it can ignore that APIs must be relevant to the business. Use this target by segmenting the apps (websites, etc.) of partners and/or internal teams. If the program creates lots of apps that are only used internally and not by customers, it can sometimes feed internal criticism and abandonment of the program. However, don’t substitute this target with “number of app downloads,” which is a particularly poor indicator of adoption or usage.
• Speed to API. In order to enable app teams to rapidly create new customer experiences, API teams should become adept at quickly turning around needed APIs. When this target also segments for APIs that are requested by the business, it becomes a useful measure of time-to-market for needed functionality, regardless of complexity.
• Speed to onboard. The portal by which front-end developers obtain access to your APIs should feature an automated approval process, including self-service onboarding capabilities that let developers register their apps, obtain keys, access dashboards, discover APIs, etc. This initial automated signup should give access to low-risk APIs and sandbox environments that allow developers to be productive right away. Once developers are onboard, the portal can provide upgrade options in which the developer requests access to more sensitive data and business functions. These upgrades often require increased diligence and background checks, some of which may take some to time to clear. To distinguish between these processes, be sure to measure the “speed to onboard” for the initial signup duration separately from the “speed to upgrade.”
• Growth of traffic. This target helps API programs develop a strong DevOps and Runops culture by continuously monitoring, improving, and driving value through APIs. Be sure to couple this target with related metrics up and down the value chain, including reliability and scalability of back-ends.
• Breadth of business. This target enables the API program to build relevance across the business, and to drive reuse of the APIs and thus the back-end assets they connect to. Sometimes, API teams encounter resistance from redundant systems, legacy integration, etc. that are already in use in other business units. This target helps the team escalate these encounters to the proper executive level for resolution. Particularly valuable APIs, such as those that provide access to unique data or proprietary functionality, may become a source of revenue, packaged as products for developers.
• Cost reduction. It can be hard to initially measure cost reduction from APIs, which sometimes foments dissent among managers. But significant cost reductions are usually realized from the rise in reuse of APIs. When APIs are part of a broader internal refactoring of value chains, use this target together with related metrics such as increased utilization of back-ends, increased visibility of usage, etc. The effect is even more pronounced when IT capital investment shifts to a small set of highly capable commercial-off-the-shelf (COTS) platforms. Instead of taking time and money to build open-source platforms, the enterprise teams can focus on creating new business value on top of these platforms at much lower cost and faster time-to-market.
• Direct revenue.** Just like any other “channel,” use this target by capturing the revenue for the sales of core products that are enabled by APIs. With some exceptions, such as APIs that involve high bandwidth overhead or APIs that give developers access to a particularly valuable resource, be cautious about collecting an up-charge specifically for the use of the API; these charges can discourage the use of APIs, limiting the business’s ability to open new markets and reach new customers.
• Net Promoter Score (NPS).*** Use this or a similar target to gauge the application developers who are adopting and calling APIs from within their applications. In addition, though APIs are critical to the creation of apps that improve front-end customer NPS, APIs can’t move this metric by themselves. The entire digital value chain should be coordinated (back-end, APIs, apps) and credit shared for all improvements to front-end customer NPS. For its part, the API program should impact this target with rapid construction and upgrades of high-quality APIs.

** As an exception, there are a few businesses that are purely API businesses, with a subset of APIs that can be directly monetized, e.g., Information feeds, brokerage services, purchase / payment transactions.

*** As an exception, there are partner scenarios where the “customers” of an enterprise are almost exclusively developers, in which case APIs can directly result in NPS improvements.

How KPIs Change over Time

KPIs and metrics are living tools and should be revisited periodically.

For example, to get started, the “number of APIs produced” and the “number of developers signed up” can be effective in focusing the program on improving execution skills of the API teams. During this “crawl” stage, before the program can “walk” or “run,” tracking the “speed-to-API” is also useful, which in turn raises the importance of agile product development as the skills improve.

Once a few APIs are in use, if an API program jumps to business KPIs such as “direct revenue” and “NPS” too quickly, it can stifle its progress before it has learned to “walk.” Instead, API programs should build business value by shifting the focus to “number of apps,” “number of partners,” and/or “number of customers” that are using the newly minted APIs. By doing so, these programs establish the go-to-market strategy for APIs as first class products. This approach should also drive a critical internal discussion about digital business priorities, which in turn reinforces the overall enterprise strategy for APIs. Ideally this results in the correct KPIs for the maturing API management program, and provides clarity about what the expected mid- to long-term business impacts should be.

It is important that these increasingly business-relevant KPIs are not defined by the API product team in isolation, but as part of a broader executive alignment around transformation of the enterprise. Once a good production cadence around APIs is operational and begins to “run,” the API product management team can begin to add more familiar business impact reporting to its dashboard, such as “direct revenue,” “NPS,” “breadth of business,” and “cost reduction,” as agreed to with the rest of the executive team.

Compared to the speed of change in the digital world, business metrics tend to lag and are not always useful in the day-to-day operation of APIs. To maintain a proactive stance in the market, good API management continues to maintain both business metrics and more digitally-focused metrics in parallel. Digital metrics can be tracked in near-real-time, and provide critical insight into the success of the ecosystem as a result of ongoing changes in API libraries, versions, and go-to-market programs. These metrics include “speed to onboard,” “growth of traffic,” effectiveness of campaigns, and all the metrics from the “walk” phase of maturity.

Baseline the KPI Health of the Enterprise

Here is a checklist to self-assess how robustly your enterprise goals and/or KPIs are aligned to support digital transformation. I encourage you to use this information in conjunction with Apigee Compass, a free online tool that measures a business’s digital competitiveness, including its use of APIs, and that provides actionable recommendations for accelerating the organization’s digital transformation. You may use this exercise, and the more wide-ranging diagnosis delivered by Apigee Compass, to detect gaps in accountability across the enterprise and pinpoint the areas that your teams can remedy.

• Name at least one “digital” KPI, or explicit goal, expressed by officers of the company, that requires a digital strategy to deliver.
• Name the most important traditional business KPIs for the enterprise.
• Describe how the digital KPIs are linked to the more traditional KPIs, and how the digital are necessary to achieve the traditional.
• List the funded “digital” initiatives that will directly contribute work specifically targeting the digital KPIs.
• Describe how each of these initiatives contributes to the digital KPIs.
• List the existing business units needed for each digital initiative to succeed.
• For each of these business units, list the primary KPIs or goals for the next 18 months.
• For each of these business unit KPIs, describe how they link to the enterprise digital KPI.
• For each of these business unit KPIs, describe how it is impacted by the digital initiatives.
• For each initiative, list the planned or candidate projects to realize the initiative. There is likely to be overlap, which is fine.
• For the software components of each project, describe the envisioned major groups of application services, or APIs. Again, there may be overlap; various projects typically use very similar or the same APIs.
• For each major group of APIs, describe how it supports the business unit KPIs, and the enterprise digital KPIs. This description should include quantitative metrics, including metrics that can be produced by the instrumentation of the APIs, and/or the API platform.

While I believe the pace of change continues to accelerate, API programs are emerging to be increasingly central to most forms of business success. As you consider integrating KPIs more deeply to benefit your enterprise or the organization you are advising, be sure to formulate them as core elements of a strategic plan that reflects your specific market conditions and organizational constraints.