Dependability is the actual availability of the API to developers. A useful metric is the downtime, which should be as minimal as possible (relative to a developer’s expectations). An organisation can achieve that by means such as redundancy or spike arresting. Another metric is a quota (with rate limits as internal means) which defines how many API calls can be made by a developer within a certain time frame. A quota protects an API and makes its management more predictable. Also – or more importantly – many API providers’ business models (and price plans) are based on quotas.
Flexibility relates to the options developers have in adopting APIs. This could be manifested in technical options – e.g., different supported protocols (REST, SOAP), different formats (JSON, XML), different tools (various SDKs for popular platforms such as Android, iOS, Web, Windows etc.) – or business options – e.g., the possibility or simplicity of changing between price plans or cancellation. In almost every case, flexibility can be found in releasing API and whether the various releases are compatible between each other and how much effort is required by the developer for adopting new versions or achieve a smooth transition. The internal means is version control and versioning. It should be clear that in general, the more flexibility that is provided the more efforts (and cost) the organisation needs to bear internally.
Quality is the consistent conformance to developers’ expectation and, hence, influences their satisfaction. As such quality is an overarching performance objective which is related to the four other objectives. Conforming to expectations can be achieved by defining and meeting SLAs. Streamlined and purposeful automated processes can improve internal efficiency and contribute positively to quality (and cost reduction).
A specific case related to quality (and expectations) is how an organisation interacts with developers. That is subsumed under the term Developer Experience (DX) and contains means such as developer portals, documentation, tools, testing, support or evangelists (see also my post Developer Experience – because developers are people too).
One important aspect related to the speed objective in API operations is access latency (i.e., the time that elapses between an API call and the receipt of the response). Latency is related to the throughput aspect (i.e., how much communication can be successfully executed). Both latency and throughput are important for a developer and can internally be influenced by means such as throttling or caching. Throttling in particular (like quotas) can also be used for defining an API providers’ business models on top of the APIs. The speed objective is also influenced by the dependability objective’s means of rate limits.
The cost objective is to provide the best value-for-money relation to developers. Internally that means to optimize costs wherever possible without hampering the experience (i.e., perceived value and quality) of customers. Depending on context and implementation, all the other four performance objectives contribute to the cost objective either direct or indirect proportionally.
A special case: developer on-boarding
A special case in API operations is the developer on-boarding phase, which subsumes the process of identifying, targeting, and (hopefully) convincing developers to sign up to an organisation’s API program (i.e., developer marketing). It is thus recommended to differentiate between this phase and the active API usage by developers after on-boarding, which is essentially the donut as I described above. Depending how important and elaborate an organisations developer marketing activity is, it makes sense to construct a separate donut with prioritized performance objectives, metrics and corresponding means. The on-boarding donut depends strongly on the specific context of an organisation. The dependability objective could be about the availability of an online registration and admin portal for a developer. Flexibility could mean whether an organisation provides different variants of developer outreach means targeting different developer segments. With respect to quality, also in the on-boarding phase an organisation should live up to the developers’ expectations. Otherwise developers would not be won over in the first place. Speed is related to how quickly a developer can use an API. A related metric is “time to first API call.” Finally, cost is influenced by all other objectives and should be optimized as much as possible.