This blog looks at key requirements of an API governance framework and some of the approaches companies have successfully used to strike a balance.
The challenge
How do you provide the security and governance that your enterprise demands, with the diversity and sprawl of the infrastructure that currently supports it?
If you are like most companies, you have multiple business units, each with their own development teams that are working independently to deliver digital business initiatives as fast as possible.
But now you, central IT, need to validate compliance to security standards and answer the tough audit questions. So, how do you balance centralized policy enforcement with distributed agile teams?
There is no easy universal answer.
Key API governance framework requirements that need to be addressed
- Reduce security risk that APIs provide. The days where every developer decides how best to secure their API end to end.
- Support developer agility and BU independence. Set the coders free to be agile and achieve results.
- Reduce manual processes and delays through automation. Build the pipelines that take the guess/grunt work out of the build and deployment processes.
- Provide common compliance/audit reporting for the entire organization. Spreadsheets are not the right way to catalog your APIs.
See also: 4 essential components when designing an enterprise-wide API program.
Common approaches to consider
The enforcers: a centralized approval gate where you fill out a ticket and wait in line.
✅ Can enforce standards
❎ Usually introduces delays and bottlenecks that are not well received
The scanners: watch traffic and probe for vulnerabilities.
✅ This is an API governance best practice to help identify problems
❎ It will identify problems, but not fix them
The designers: Build common libraries and security methods that are required at design time by all teams.
✅ Best practice
❎ Hard to implement with independent teams, and there are always exceptions
The automators: Build security and validation processes into CI/CD pipelines where it becomes a part of standard deployment.
✅ Also best practice for an API governance framework
❎ Exceptions have to be addressed
The gateways – use API gateways to define and enforce complex governance rules after the APIs have been created
✅ Great for handling special cases
❎ Maintenance can be a challenge
The proxies – use proxies in front of every API or gateway to enforce standards
✅ Solves some common visibility and management issues
❎ Introduces performance issues and additional point-of-failure risk
A new approach: universal API management
Axway Amplify uses lightweight agents to automate discovery, capture, and validation of all APIs into one registry where they can be managed, monitored, and governed.
This approach to API governance reduces risk through a single control point, without impacting existing development centers. It also consolidates all your APIs across diverse platforms, gateways, and repositories and provides common reporting.
Universal API management: what is it and why should I care?
Next steps to building your API governance framework
So, how to do API governance?
There is no one size fits all, because your approach should be dictated by:
- What your APIs are accessing on the backend and the security risk they pose
- How many teams and the number of APIs you have
- How and where your APIs are deployed and how they are currently secured
- Where you are in your journey to opening APIs to the external world.
One final consideration is the tools of the trade. An API marketplace allows you to create a single registry for all APIs, making it possible to automate discovery, linting checks, deployment processes, and more. That level of automation can be an invaluable partner in a solid API governance plan.
See Amplify in action and discover how it can help you can manage and govern APIs across ecosystems.