API Management and the Measurement of Value Exchanged
API Management and the Measurement of Value Exchanged
API management and value need to be rethought and reworked so that it's about the value exchanged rather than about revenue earned.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
The concept of API management has been around for a decade now and is something that is now part of the fabric of the cloud with services like AWS API Gateway. API management is about requiring all consumers of any API resource to sign up for any API access, obtain a set of keys that identify who they are, and pass these keys in with each API call they make from any application. Since every API call is logged, and every API call possesses these keys, it opens up the ability to understand exactly how your APIs are being used through reporting and analytics packages which come with all modern API management available today. This is the fundamentals of API management, allowing us to understand who is accessing our digital resources, and how they are putting them to use–in real time.
The security of API management comes in with this balance of opening up access, being aware of who is accessing what, and being able to throttle or shut down the access of bad actors–more than ever it is about authentication and requiring keys for all API calls. If you want access to any digital resources from a company, organization, institution, or government agency in a machine-readable format, for use in any other web, mobile, or device application–you use the API. This allows ALL digital assets to be made available internally, to trusted partners, and even to the public, while still maintaining control over who has access to what, and what types of applications they are able to use them in. APIs introduce more control over our digital resources, not less–which is a persistent myth when it comes to web APIs.
API management allows us to limit who has access to which APIs by putting each API into one or many “plans.” The concept of software as a service (SaaS) has dominated this discussion around plan access, establishing tiers of API access such as free, pro, and enterprise, or maybe bronze, silver, and platinum. Giving users different levels of access to APIs, oftentimes depending on how much they are paying, or possibly depending upon the level of trust (i.e. partners get access to more APIs, as well as higher rate limits). While this approach still persists, much of what we see lacks imagination, due to the rules of the road dictated by many API startup VC investors pulling the strings behind the scenes. When crafting API access plans you want to incentivize consumer behavior, but, honestly, startup culture and VC dominance has limited API provider’s vision, and stagnated many of the conversations around what is possible with API management after a decade.
When you are trying to scale a startup fast you need a narrow offering of API products. If you are operating a “real” business, or organization, institution, or government agency, your API plans will look much different, and you shouldn’t be emulating the startup world. We should be more concerned with value exchange between internal groups, with our partners, and potentially with 3rd party public developers. We should create API plans that incentivize, but not limit access, encouraging developers to innovate, while still generating sensible revenue around our digital resources we are making available. The reason many existing companies are struggling with their API programs is they are emulating startups, and not thinking bigger than the table Silicon Valley has set for us. API management is about measuring and rewarding value exchange, not rapidly growing your company so you can inflate your numbers, and sell your business to the highest bidder. That is so 2012!
When you see API management being used to measure value exchange to its fullest you see all the HTTP verbs being used and measured. Providers aren’t just providing GETs, measuring and charging for access. They are allowing for POST, PUT, and DELETE, and measuring that as well. If they are really progressive, they reward internal groups, partners, and 3rd party developers for the POSTs, PUTs, and DELETEs made. Incentivizing and then rewarding for desired behavior around valuable resources. POSTed a blog post? We’ll pay you $50.00. PUT 100 records, cleaning up addresses, we’ll pay you 50 cents per update. All you do is GET, GET, GET, well, we’ll charge you accordingly, but if you also POST, and PUT, we’ll charge you a lower rate for your GETs, as well as apply credits to your account. API management shouldn’t be about three plans, and generating revenue, it should be about measuring the value exchange around ALL the data, content, media, and algorithmic exchanges that occur on a daily basis.
API management has done amazing things for allowing companies, organizations, institutions, and government agencies to develop an awareness around who is accessing their resources. Look at what the Census has done with their API, what Capital One is doing with their API program, and Oxford Dictionaries are doing with their API program. Notice I didn’t mention any startups or tech rockstars? API management isn’t just about revenue generation. Don’t let the limited imagination of the startup space dictate otherwise. Now that API management is part of the fabric of the cloud, let’s begin to realize its full potential. Let’s not restrict ourselves to just a handful of plans. Let’s use it to broadly measure the value exchange around all the digital resources we are publishing to the web, making them available internally, to our partners, and the public in a machine-readable way, so that they can be used in any web, mobile, or device application.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.