APIs are all about measuring the value exchange that occurs between internal groups, with partners, and occasionally the public when it makes sense. API management is where you start this conversation. It has been used for a decade to measure, limit, and quantify the value being exchanged at the API level. Now that API management has been baked into the cloud, we are starting to see the approach being scaled to deliver at a marketplace level. With over ten years of experience with delivering, quantifying, metering and billing at the API level, Amazon is the best example of this monetization approach in action, with two distinct ways of quantifying the business of APIs.
– AWS Marketplace Metering Service – SaaS style billing model which provides a consumption monetization model in which customers are charged only for the number of resources they use–the best known cloud model.
– AWS Contract Service – Billing customers in advance for the use of software, providing an entitlement monetization model in which customers pay in advance for a certain amount of usage, which could be used to deliver certain amount of storage per month for a year, or a certain amount of end-user licenses for some amount of time.
This provides a framework for thinking about how the business of microservices can be delivered. Within these buckets, AWS provides a handful of common dimensions for thinking through the nuts and bolts of these approaches, quantifying how APIs can be monetized, in nine distinct areas:
– Users – One AWS customer can represent an organization with many internal users. Your SaaS application can meter for the number of users signed in or provisioned at a given hour. This category is appropriate for software in which a customer’s users connect to the software directly (for example, with customer-relationship management or business intelligence reporting).
– Hosts – Any server, node, instance, endpoint, or other part of a computing system. This category is appropriate for software 
– Data – Storage or information, measured in MB, GB, or TB. This category is appropriate for software that manages stored data or processes data in batches. Your application can meter for the amount of data processed in a given hour or how much data is stored in a given hour.
– Bandwidth – Your application can bill customers for an allocation of bandwidth that your application provides, measured in Mbps or Gbps. This category is appropriate for content distribution or network interfaces. Your application can meter for the amount of bandwidth provisioned for a given hour or the highest amount of bandwidth consumed in a given hour.
– Request – Your application can bill customers for the number of requests they make. This category is appropriate for query-based or API-based solutions. Your application can meter for the number of requests made in a given hour.
– Tiers – Your application can bill customers for a bundle of features or for providing a suite of dimensions below a certain threshold. This is sometimes referred to as a feature pack.
– Units – Whereas each of the above is designed to be specific, the dimension of Unit is intended to be generic to permit greater flexibility in how you price your software. For example, an IoT product which integrates with device sensors can interpret dimension “Units” as “sensors”. Your application can also use units to make multiple dimensions available in a single product.
These dimensions reflect the majority of API services being sold out there today, we don’t find ourselves in a rut with measuring value, like just paying per API call. Allowing Lighthouse API plans to possess one or more dimensions, beyond any single use case.
– Single Dimension – This is the simplest pricing option. Customers pay a single price per resource unit per hour, regardless of size or volume (for example, $0.014 per user per hour, or $0.070 per host per hour).
– Multiple Dimensions – Use this pricing option for resources that vary by size or capacity. For example, for host monitoring, a different price could be set depending on the size of the host. Or, for user-based pricing, a different price could be set based on the type of user (admin, power user, and read-only user). Your service can be priced on up to eight dimensions. If you are using tier-based pricing, you should use one dimension for each tier.
This provides a framework that any company, institution, or government agency can provide to 3rd party developers, allowing them to operate their services within a variety of business models. Derived from many of the hard costs they face, and providing additional volume based revenue, based upon how may API calls of any particular service receives. Beyond this basic monetization framework, I’d add in an incentive framework that would dovetail with the business models proposed, but then provide different pricing levels depending on how well the services perform, and deliver on the agreed upon API contract. There are a handful of bullets I’d consider here.
– Design – How well does a service meet API design guidelines set forth in governance guidance.
– Monitoring – Has a service consistently met its monitoring goals, delivering against an agreed upon service level agreement (SLA).
– Testing – Beyond monitoring, are APIs meeting granular interface testing, along a regular testing & monitoring schedule.
– Communication – Are service owners meeting expectations around communication around a service operations.
– Support – Does a service meet required support metrics, making sure it is responsive and helpful.
– Ratings – Provide a basic set of metrics, with accompanying ratings for each service.
– Certification – Allowing service providers to get certified, receiving better access, revenue, and priority.
All of the incentive framework is defined and enforced via the API governance strategy for the platform it serves. Making sure all microservices, and their owners meet a base set of expectations. When you take the results and apply weekly, monthly, and quarterly against the business framework, you can quickly begin to see some different pricing levels, and revenue opportunities around all microservices emerge. You deliver consistent, reliable, highly ranked microservices, you get paid higher percentages, enjoy greater access to resources, and prioritization in different ways via the platform–if you don’t, you get paid less, and operate fewer services.
This model is already visible on the AWS platform. All the pieces are there to make it happen for any existing platform, operating on top of the AWS platform. The marketplace, billing, and AWS API Gateway connection to API plans exists. The model isn’t something new, and has been being pushed forward by one of the most notable API pioneers. All the elements already exist for enterprise groups to begin measuring and quantifying the value being exchanged between business units and lines of business. API management isn’t just about public APIs, and selling your APIs. It is something that becomes even more valuable when you begin putting it to use quantifying the value exchanged each minute within the enterprise, and maximizing the interactions between existing groups doing business on the ground each day.
