The data and services made available via your APIs are consumed by your employees (B2E), your customers (B2C), or other businesses (B2B).
How does a business go about building an API strategy? Is your business seeking to connect with customers, or digitize and streamline internal business processes, or create new channels to work with partners? An understanding of the different kinds of API models, and which one is right for your business, is critical.
This understanding is aided by exploring the “digital value chain” that exists within a digital business and links enterprise data all the way through to the apps and consumers that benefit from it
The digital value chain: from back-end to app-end
Much like a physical value chain, where a series of actions takes place to deliver a product to market, the digital value chain connects users to apps to developers to APIs (and API teams) to enterprise data and services in the backend.
The API team is like an internal “partner team,” working with an enterprise’s distributors and resellers, and managing which products are available. In the digital value chain, your distributors and resellers are developers, who build your digital presence (your “storefronts”) in the form of apps.
These developers might be within your company, work at a partner organization, or might operate independently in the outside world. Regardless of where they are innovating, developers represent a new channel, and the better their product (the app), the better the engagement with your end users.
The digital value chain: from app-end to back-end
Traditionally, enterprise APIs have been associated with “exposure,” which describes the transformation of existing backend capabilities, resources, and data into APIs. But the focus of APIs in the modern enterprise has been expanded to include “consumption,” which grants developers access to those same resources so they can build and deploy apps. Imagine developers being able to explore API, to subscribe, to read statistics data.
Data connects the value chain end to end—in both directions. APIs don’t just enable an enterprise to expose or project data. They are no longer just the sockets through which transactions pass; they create a conduit for data to flow back to the enterprise and today are the primary tools for data collection and analysis.
Internal, partner, customer, and open strategies
Several flavors of API initiative support the digital economy. Many successful API initiatives are done in stages. With each stage, businesses can build on previous projects, assume more risk, and invest in larger projects more easily. The type of initiative you launch—internal, partner, or open—depends upon whether the app developer resides within your business, within a partner’s company, or works independently (“in the wild”).
Companies might be inclined to start with an open API, using Twitter, Foursquare, or Facebook as an archetype. This approach isn’t necessarily the right way to get started. Rather, an open strategy should generally be undertaken after a business has learned lessons and mitigated risks by executing an internal or partner model first.
A internal API initiative is one that focuses on building an app-enabled business: As companies become larger and more complex, many are deferring to API ecosystems to minimize the amount of development effort to support multi-channel enablement. Developers are within the company, building the apps by consuming the APIs, and giving the feedback to API teams. For example developers could be asked to build android app for HR department by consuming corporate API.
A partner API initiative is one that focuses first on collaboration with strategic partners. Those partners create applications, add-ons, or integrations with the API. At this stage the API gets hardened and because the API is used across organizational boundaries, the API team will learn a new set of lessons including support, documentation, authentication schemes and so on. How many times we have lost potential partners because of this missing chanel?
A customer API initiative is mostly used in one of two scenarios. The first is when offering software as a service (SaaS). (Look at Salesforce as an example where customers demand an API.) The second is when the customer of your business is another business (a B2B scenario).
This is the case for innovation by leveraging the creativity and know-how of 100s of 1000s of developers around the world using your API to create cool apps and make big breakthroughs.
If you target an Open API initiative, chances are that your internal or partner strategies will go well too. It is important to be careful about setting expectations. A lot of things need to go right to get huge numbers of developers successfully creating apps on your APIs.
Business strategy is about identifying your business objectives and deciding where to invest to best achieve those objectives. For example, moving from a direct sales model (your own sales force selling directly to customers) to an online sales model (your customers buy from your site) is a business strategy. Deciding whether to charge for your services (api) with subscriptions or transactions fees or whether you have an advertising-based revenue model is a business strategy. Deciding to move into an adjacent market is a business strategy. Deciding to charge your services (API), with free option of 2500 API calls per month.
Moreover, while the business may believe something is a great business opportunity, you don’t yet know if your company can successfully deliver on this opportunity. Maybe it will cost too much to build. Maybe customers won’t value it enough to pay for it. Maybe it’ll be too complicated for users to deal with. This is where api(product) strategy and especially product discovery come into play to find out answers to this questions.
The product strategy speaks to how you hope to deliver on the business strategy.