TMCnet News
API Management Deployment Patterns and MonetizationMore enterprises are going beyond the implementation of APIs to looking at how they can be monetized internally, externally, or both. In this article let’s look at different monetization strategies and how they will affect which deployment model will be most effective in your enterprise: on-premises, in the cloud, or a hybrid approach. Indirect Monetization Often companies are not looking to charge for API use per se. Rather, wider use of APIs simply brings more customers and transactions to their core business. A great example is StubHub, a leading seller of event tickets. One goal of its API program is to enable the ecosystem (https://www.youtube.com/watch?v=TRrvVouTksE) of travel companies, hotels, and others in the hospitality sector to upsell event tickets to their customers. Anytime a hotel customer uses the StubHub API from the hotel’s website, StubHub makes money. Indirect monetization is a good option when APIs serve to make your customers and partners more effective at bringing you more business or help to extend the ecosystem. This is typically the case when your real customers are end users, and APIs enable the ecosystem to serve these users better or bring them to your platform. For this kind of monetization, you do not need a billing system, since it is the core business that is bringing in the revenue. What you need is an effective developer/partner program in which your partners can sign up or be given API access, and get the proper documentation and support, while you have the ability to invite companies to participate and/or vet them. You also will want to use analytics to understand how the program is doing, which APIs are in use, and how well your developer portal interacts with partners and manages them. Internal Direct Monetization There are two types of direct monetization. Internally, direct monetization usually takes the form of one department billing back another for the use of particular APIs. Because funds are allocated internally by corporate accounting, there is no actual credit card change or wire transfer. However, organizations do need some key functions to support billing. These include: ? Reporting to track usage ? Invoicing ? Usage plans and metering ? Extensibility or APIs to integrate the solution with your internal accounting systems ? Some sort of approval processes so business units can control their usage and costs This internal application of direct monetization often results in on-premises deployments so the system operates within the same network as the internal customers, internal service providers, and accounting system. External Direct Monetization In an external direct monetization scenario, you sell a service, your customers are external businesses whose solutions are enhanced by your APIs, and it is their business that interacts with users rather than yours. For example, Twilio sells APIs that let Uber offer text messaging and phone calls from within Uber’s mobile app. End-users of the app are Uber’s paying customers. Uber in turn is Twilio’s customer, benefitting from the use of Twilio services instead of having to develop and maintain the technical capabilities itself. To support an external direct API monetization model, you will need a solution with a full-fledged billing engine and likely even a payment gateway. Additionally, applying direct monetization to external users comes with a special requirement: compliance with the Payment Card Industry Data Security Standard (PCI DSS). The basic concept behind PCI DSS boils down to, “You don’t want to touch credit card numbers.” Cloud-based solutions typically work best because they already have PCI-compliant billing, which occurs on someone else’s servers, freeing your organization from having to care about compliance or certifications. This means that, even if most of the API management deployment is on-premises, the billing part will likely be outsourced to a cloud service, making it a hybrid solution. Universal Deployment Issues There are two other key deployment considerations that enterprises will need to address regardless of whether they monetize APIs internally or externally: the scale of operations and time to market. Scale of operations: Is your market concentrated in a specific region or spread around the globe? Some cloud solutions have options to host gateways in various regions of the world thus enabling you to reach customers in a specific region or even have multiple endpoints serving subscribers based on their location. This can solve both the performance and compliance requirements of your target markets. Cloud services are also dynamic by nature. This can help you scale up as API usage grows. Additionally, external API programs are by definition less predictable than those for internal use. So using the cloud to scale up or down on-demand and keep your quality of service high—while using only the resources needed—comes in handy. The opposite is also true. Whether you lead a startup or a department within an enterprise willing to start small on a small-scale proof-of-concept pilot, the cloud can be your friend letting you begin with the lowest tier available and upgrading when the program becomes a success. Time to market: Modern business is moving fast, and early leaders get disproportionate advantages and mindshare. Cloud typically implies a software-as-a-service (SaaS) application that is almost ready to use. So in many cases, going with the cloud means the ability to get your APIs and developer program launched in days rather than months. Significantly, many new businesses are going straight to a 100% cloud deployment because it gives them an affordable, fast ramp into the market. Meanwhile established businesses with existing functionality to expose as APIs can start with a hybrid approach by quickly subscribing to the missing pieces, such as an API gateway and developer portal in the cloud, and hooking them up to existing on-premises systems. Then as the offering matures and gains acceptance, they can evaluate whether it makes sense to move any existing infrastructure onto either a public or private cloud or conversely to move the whole system on-premises. To maximize your flexibility, consider API management solutions and supporting functionality that can be deployed both on-premises and in the cloud. In doing so, you can ensure that your deployment decisions will be driven by your business objectives rather than any technology limitations. About the Author Dmitry Sotnikov is the vice president of cloud solutions at WSO2 (http://wso2.com). With nearly two decades of management and technology experience, he is a featured speaker at industry events including Microsoft TechEd, VMware VMWorld, Parallels Summit, Quest Innovate, and Technology Experts Conference (TEC). As a community-building service, TMCnet allows user submitted content which is not always proofed by TMCnet editors. If you feel this entry is of inferior quality or wish to report it for some reason, please forward the URL to "webedit [AT] tmcnet [DOT] com" with your comments. |