Most people acknowledge that Managing APIs is more than API design. Still, a common myth in parts of the API community is that governance bogs everything down. But governance is about making good decisions — making sure that the right people make the right decisions at the right time and for the right reasons, based on the right information. So if an API is important to your organization, you want to make good decisions about it. As an API provider or an API consumer, you have several decisions to make about APIs.

This API governance is a different kind of governance from the type that’s routinely applied as part of a software delivery life cycle; nevertheless, it’s important.

API provider decisionsDeciding who can use the API under which business terms and conditions is the job of the API business owner. This business operational decision applies to all APIs, whether they’re the APIs that your mobile development team uses to build mobile apps, the APIs that you use to integrate systems across various lines of business, or the APIs used by external consumers, so you probably want to make different decisions for each of these audiences in terms of what APIs they may use under which conditions.

IT operations also needs to make appropriate API provider decisions — typically, in the form of security and traffic policies — to protect the infrastructure from misuse or overload.

The governance regime needs to be very lightweight, and the decisions must be operational in nature as opposed to the typical life-cycle decisions made during a software delivery life cycle.

If the right decisions can’t be made and enforced easily, the open and dynamic nature of APIs is compromised (in my opinion good API implementations are configurations, not code, see API platforms are different from just another ESB). Business and IT decisions are both part of good API management discipline and should be supported by the chosen API platform.

API consumer decisionsAPI consumers also need to make good decisions. In particular, they need to decide which APIs they’re willing to use for what purposes and then ask the following questions about each API:

- What is the payment model for using the API and is that acceptable for your purpose?

- Will you need a corporate proxy in front of the API to handle licenses, payment, and the like, or will every developer register independently?

- Is the API secure and reliable for mission-critical purposes? Any historical records about how the API has behaved over time may add to consumer confidence in using it.

When the APIs being consumed are your own, these decisions are pretty straightforward, being mainly about overall business design. When the APIs are third-party APIs, the decisions become more complicated. Ultimately, the end-user experience and responsibility for maintaining business integrity can’t be delegated. You need someone in your own organization to be responsible for the end-user experience and to make the right decisions about which APIs it’s appropriate to consume as part of your delivery model.

Connect with me on @ClausTorpJensen or read my earlier blogs. You can also subscribe to the blog list here