API operations and donuts

API operations really is about making sure that APIs are accessible and deliver according to developers’ expectations. As such it has two functions: internally the processes need to be streamlined and efficient to reduce cost; externally API operations need to be effective in meeting developers’ expectations. Or in the words of the authors of the “APIs — A Strategy Guide” book, it’s about “making sure that users of the API have a positive experience and are happy with the API’s performance. This positive experience will ultimately carry on to your end users, generating greater value to your business.” In this post, I would like to summarise some considerations relevant for managing API operations.

What the operations text books say

In the Operations Management book (2007) the authors Slack, Chambers and Johnston argue that there are three main functions in an organisation:

  1. Research & Development to create new and modify existing products.
  2. Marketing (including Sales) to bring the right products to the right customers in the right way.
  3. Operations to constantly deliver the products as expected by the customers.

Slack defines operation's management as:

The activities, decisions and responsibilities of managing the production and delivery of products and services.

Generally there are five accepted key performance objectives along which operations can be managed. This is a model that should help to improve efficiency and effectiveness and align the operations strategy to the overall business strategy. These objectives are:

  1. Dependability
  2. Flexibility
  3. Quality
  4. Speed
  5. Cost

The figure below is an illustration used in Slack's book – also referred to as the donut model. The inner circle shows the organisation internal effects; the blue ring holds the five performance objectives and everything outside of that embodies the external effects (to customers or any other external stakeholders).

Source: Operations Management book (2007) by Slack, Chambers and Johnston

This is a general operations management model and can be applied to any operations aspect of an organisation regardless if it delivers a product or a service or which industry it serves. The metrics and means will surely differ, but the concept stays the same.

The role of an operations strategy is to understand the dependencies between the five performance objectives based on the organisations specific context (type of products or services, markets, customers, competitors etc.), to prioritize objectives in line with the business strategy and to define metrics and means accordingly.

The operations donut and APIs

The operations donut model with the same performance objectives can be applied to API operations, too. The donut can be used to define operations tactics to achieve an organisation’s API strategy (see also my earlier post about Leveraging APIs as Part of Digital Strategy). I re-created Slack et al’s donut illustration with API specific means. The inner circle remains a representation of organisation internal activities and effects; same is true for everything outside of the ring as external effects. I changed the arrows in the inner circle to indicate means an organisation can deploy to achieve the various performance objectives.

Let’s have a look at all the five objectives in turn:

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.

API gateways

A meaningful way of implementing API operations is by using an API gateway, which could encapsulate most of the necessary functions and processes (i.e., the internal means depicted in the inner circle of the donut). It is an elegant way of separation of concerns from an organisation’s backend servers into dedicated entities. In addition to the means of the API operations donut (e.g., rate limiting, spike arresting, versioning, automation, DX, caching or throttling), an API gateway can perform tasks related to mapping or translating between technologies and formats, aggregating or splitting up API calls, or handle security. API gateways could be hosted on premise or in the cloud.

Currently popular API gateway solution providers include 3scale, ApiAxle, Apigee, APISpark, Axway/Vordel, Layer7, Mashery, MuleSoft, SOA, or TIBCO.


API operations is all about delivering an API product to developers and as such needs to satisfy the potential value established by R&D and the promise communicated by marketing. The operations management donut is a useful model to break an API operations tactic up into the five distinct but interdependent performance objectives: dependability, flexibility, quality, speed, and cost.

The selected metrics and means are dependent on an organisations specific context and in line with the API and business strategy. It makes sense to break API operations up into various phases – such as developer on-boarding and active API usage. API gateways (hosted on premise or in the cloud) are a meaningful way to implement API operations as it allows a better separation of concerns and thus increases manageability and maintainability.

This post was originally published on Manfred’s Mobile Apps Stuff blog and is re-published here with minor modifications. @Manfred writes about API strategy, developer evangelism and personal efficiency and curates topics at the API Magazine.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.