Proliferation of APIs, API sprawl, multi-vendor API management landscape… These terms are often mentioned, proving that organizations are all-in on APIs. So many APIs are being created and made available it is becoming harder to keep track, manage, and secure all of them. That’s why API governance is making a comeback with the hope of putting some structure around all these APIs and making it easier to manage them.
Unfortunately, mentioning API governance doesn’t evoke pleasant feelings. It’s one of those things that IT professionals dread having to deal with. However, this bad reaction arises from a misunderstanding of governance as bureaucracy. Let’s use the proper definition of API governance because no one, especially no software engineer, likes having to constantly deal with rules and approvals to do their job.
API governance is about guiding API users, both providers and consumers, to create APIs or applications that are secure, discoverable, composable, and self-servicing. The goal is to encourage efficiency and reusability. Therefore, API governance is in fact the opposite of bureaucracy in the sense that it aims to eliminate back-and-forth, analogue discussions by providing guidance on the spot.
This on-the-spot nature of governance is also emphasized with some popular trends that you may have heard here and there. Shift left, federated governance, and adaptive governance are all best practices that aim to create a flexible API governance structure that is actionable as early in the API lifecycle as possible. Let’s demystify these trends to see how they can be valuable in your organization.
Shift Left generally means to move certain tasks earlier in a process so that the necessary actions or corrections can be done without wasting any cycles. It naturally applies to API governance.
APIs go through various lifecycle stages including design, development, security, testing, deployment, versioning, and end of life. By presenting recommendations or enforcing rules at the earliest stage that recommendation or rule is relevant, you can save a rogue API from moving through different stages if it will only be rejected or never used while wasting everyone’s time. That’s why shifting API governance left tremendously helps with organizational efficiency and you should use tools that help you apply governance where it’s first applicable.
Federated governance means that the rules and standards that apply in an organization are decided centrally. However, as the experts of their own domain, different business units have independence to decide what governance standards and exceptions should be enforced on what APIs in their domain.
Federated governance introduces efficiencies by assigning a central team whose responsibility is to communicate with different teams, analyze requirements, and identify commonalities. Without this central team, siloed business units would come up with their own rules, there would be communication headaches, and some efficiencies that the whole organization could benefit from would remain hidden.
With this central view, reporting tools, design time rules policies, CI/CD enforcements, and metadata requirements are decided and presented to business units. The independence provided to the business units ensures that these central, and sometimes overly general rules, are not enforced top-down without nuanced considerations. The business units take the central team’s guidance and adapt these rules to their use cases and API landscapes.
By structuring your API governance tools to provide central guidance while giving domain independence ensures that the central team discovers efficiencies across the organization and does not introduce new inefficiencies by enforcing the same rules on everyone.
Business requirements change, the number of API types increase, new regulations are introduced, and organizations evolve. In this constantly moving space, you cannot expect API governance challenges to stay constant.
Adaptive governance represents a culture of staying flexible in this environment. It is about introducing rules, roles, structures, and processes with the expectation that business requirements and regulations change, and governance applications should continuously strive to adapt. This can only be achieved by scaling, redesigning, and modifying the previously introduced rules based on changes.
When thinking about governance in your organization, flexibility should be top of mind. When a new requirement emerges, you should quickly be able to modify your guidance and rules to respond. Your organizational culture will be the biggest enabler of achieving this and your adaptable API governance solution will be your means.
API Governance is usually mistreated as a necessary evil that no one wants to deal with. In fact, it should be treated as your guardian angel. It prevents your IT professionals from wasting time and resources, gives your business units independence to make their own decisions with central guidance, and protects your organization in changing environments. By correcting this mistreatment and communicating its benefits within your organization, you will uncover tremendous efficiencies in your API landscape that will reflect on your bottom line.