Why we’re automating API governance

Published: 01 April 2020

While no single style is perfect, automation is key to scaling Application Programming Interfaces in a large global organisation, says John K Phenix.

As API numbers rise, so does the challenge of maintaining their quality and maximising reuse. That’s where governance is critical; we don’t want to build duplicate APIs and we want to ensure our APIs are secure, resilient, scalable and meet performance requirements.

Good governance is about making the right thing to do, the easiest thing to do. It’s an accelerator. Easier to use APIs means more reuse.

Within HSBC we’ve tried three API governance styles – Centralised, Federated and Automated. No single style is perfect and what you adopt depends on the maturity and scale of your organisation.

In my opinion, automation is key to scaling governance in a large global organisation by removing as many manual reviews as possible.

Centralised governance

Centralised works when you are kick-starting a process, or when the change volume is small but the issue is scalability. When the amount of change increases the central team can quickly become a bottleneck, frustrating developers who may then bypass or game the system.

Another unintentional byproduct is API producers don’t get early feedback if their API is below standard. They don’t intend to do the wrong thing, but they just aren’t clear on what right looks like.

Federated governance

We built a community of ‘API Champions’ from across HSBC to understand standards, apply them locally to their teams and escalate issues or gaps.

However, not all API Champions were equally experienced, so we still needed a sizeable central team to ensure consistency.

Automated governance

With automation, reviews are far more consistent and visibility is greatly improved. API developers can run automation scripts as soon as they start to design their APIs and this shift left gives instant feedback and prevents delays later on.

Automated tests can form part of DevOps pipelines, ensuring tests are built into the regular build, test and release cycles. This stops people trying to game the governance process and ensures higher coverage of API reviews.

Not all checks can be automated, but a large percentage can. For example, a computer can answer “Have you built this API right?” but only a person can judge “Have you built the right API?”

For a relatively small investment, a large gain can be made in consistency, completeness and visibility. That’s important as API development continues to increase.

Join us