Bridge Technology: Packaging the API As A Product
When developing a full-fledged API strategy, it’s best to think of your API is as a product. This thinking sets a chain of events and processes in motion that are necessary for success—everything from the resources devoted to it to the rigor applied.
But there’s another factor in this equation. Products are typically what companies sell—they’re market-facing offerings, with a price tag and anticipated profit margin built in. In other words, they’re meant for the world outside the office.
First, like the strategy behind every product, there needs to be a discussion regarding relevance and market need. This in turns scales to a broader market analysis, along with a specific marketing plan to roll out the new product, settling on a lifecycle and even evaluating the ROI. Yes, given the size of the investment, there should be a quantitatively verifiable return. Moving forward, other concerns will become evident—how to manage the inevitable complexity, if/when/how to introduce upgrades, etc. These are all valid issues, and they deserve attention.
Along the way, think of the multiple functions and constituencies within the organization that will become involved in the process. It might start with the party most affected by the eventual release—say, business strategy or marketing—then begin development with design and engineering, bring in sales and/or operations, and be approved by QA and customer service. In effect, the API as a product plays a key role in bridging diverse disciplines and interest groups to serve a common goal.
There’s one more interesting aspect to this. Identifying each API as a product means targeting it at a particular audience with particular needs, which in turn entails setting priorities and limits. What’s needed is not an all-purpose offering but the ability to package it for specific goals.
This is what makes Mashery’s API Packager so valuable. While serving as a bridge between the technology and business sides of the business, it also enables users to benefit from a unique level of customization. Tier 1 partners—those paying a premium to access the data—can get a higher limit of calls per day (maybe 500,000 for mass-market purposes) and pick and choose their services right down to the resource and method level. Meanwhile, those with a basic plan and narrower needs can get restricted access and perhaps 5,000 calls per day.
None of this, incidentally, requires enhanced coding skills—the team behind the product can adjust throttle or quota controls as market needs change or the pricing level rises. This provides exactly the kind of flexibility and faster time to market that every product development team in every business craves.
It’s easy to see an API as a technology product that serves business needs—and it clearly is that. But going just one level deeper, it becomes obvious that the process of developing an API as a product, and doing it with the right strategy, united diverse competencies within the organization to serve a common need.