Introduction
It's been more than a decade since the rise of the Service Oriented Architecture (SOA) movement, and the industry is still struggling with API Governance. If companies have learned anything from the early days of SOA, it's how not to implement API Governance.
This article covers eight fallacies around API Governance that may prevent your company from implementing a comprehensive API strategy that lets you take advantage of the full promise of APIs.
Turning a paradigm on its head
Over the past 20 years, I've seen the pendulum move from centralized computing to the other distributed end of the spectrum. While thinking through this oscillation with regards to organizational and architectural topologies, I can't help but see parallels between the Fallacies of Distributed Computing and what I would call the Fallacies of API Governance. Both have forged new digital paradigms: one in the past and the other in the present, one in the computing paradigm and the other in the aspects of people, process, and technology.
I believe the industry is now at a similar critical moment. Its struggle to adopt a new digital mindset is real - not only on the distributed computing level, but also as this mindset relates to the people, processes, and technologies in an organization. Let's explore how these fallacies are interwoven in today's digital transformation journey, where scaled and distributed teams and architecture topologies must be approached with a clear understanding of similar misconceptions that occur in API Governance.
Fallacy 1: Center of Excellence (COE) knowledge is reliable
The first fallacy of API Governance is that you can rely on the knowledge of a few API experts to govern APIs for your entire company. Under the influence of this fallacy, companies governing APIs through a Center of Excellence (COE) may treat API management as a niche skill, without realizing it. Often COEs devolve from their intended purpose and instead are seen as non-collaborative ivory towers that contain tribal knowledge which is not shared, democratized, or evolved with the wider developer community. This can lead to the COE itself being seen as not credible.
Modern governance is not only about gates and enforcement, but also about creating the teaching and learning mechanisms that upskill the engineering community. The expectation should be that all developers are well-versed in API skills and enabled to evolve a standardized, collaborative way of working with APIs.
If developers don’t have the right skills and don't share their knowledge, the governance process will be overwhelmed with bad designs and overrun with numerous exceptions. A modern governance approach is good at open community management and cross-pollination of knowledge. They will be, in effect, more of an attestation body than an enforcement body.
During the first stages of SOA, the focus was on enforcing standards rather than creating the mechanism to teach and learn them; this resulted in governance processes that are hard to scale. Modern governance is shifting the focus to teaching and upskilling the engineering community.
In modern API Governance, teaching and learning is the main course, not the side dish. An open source, collaborative approach where the community drives the solutions is a great recipe for the meal.
Fallacy 2: Latency is zero
We need to govern APIs at the speed of the business. If the speed doesn't match customer demand, there is a problem.
Latency is zero is the second fallacy, where we ignore the impact of adding manual steps, questions, prerequisites, and other checks to ensure APIs can run at the speed of business.
In this situation, programs often add too many requirements for committee approvals—a committee here to review API design, a committee there for security review, another for change management, and so on.
Gates and checks are absolute necessities—but how many times do we underestimate the latency factor? Or accept the manual steps without questioning their effectiveness? Or agree to live with manual gates that could be automated?
Fallacy 3: Bandwidth is infinite
On paper, we all understand that no team can handle an infinite number of requests at any given time. As obviously incorrect as that assumption might look, it's surprising how many teams fall victim to the infinite bandwidth fallacy.
An explosion in the quantity of APIs and microservices can easily flood and overwhelm any governance program that is not carefully administered or does not understand the increased demand for managing APIs at scale.
While a central API Governance team could handle a few APIs, that is no longer the case in most organizations. Instead, business and technical teams alike are increasingly reliant on self-service APIs and require access to or ownership of APIs to meet their demands. The result is that, in most organizations, every team is API-enabled.
With this type of scale, if an API Governance program tries to manage all these with limited bandwidth, instead of adding value, the process could quickly become a painful choke point to the organization.
Fallacy 4: Runtime plane is secure
At the inception of the SOA, security was an afterthought. WS-Security anyone? Moreover, early SOA implementations focused on API runtime registry (that is, the runtime plane) with no real focus on an API catalog or design time inventory (or, the management plane).
The popularity of API gateways and portals might make you think this is no longer a fallacy. Unfortunately, that’s not the case--and not because the runtime is now secure. The fallacy persists because of how the management plane is implemented and because of the assumption that you can rely on the runtime only.
Some of the confusion is caused by new API vendor and security products that are trying to capitalize on API security opportunities. They bring a slew of overlapping capabilities, driven by multiple self-serving aims not by an overall API Governance strategy. An example where you can easily find this happening is if your organization has APIs in the different runtimes that are not governed by the Management Plane.
Security should be multi-layered. APIs are expected to run in multiple runtimes and platforms, each with its own control plane and runtime-level security capabilities. A modern API security governance must sit at the highest layer outside of the specific runtime.
Everyone knows that APIs must be secured. What remains relevant to this fallacy is the awareness of the importance of building security into the API governance across all stages of the lifecycle. For example, you can’t separate the API Management plane from the multiple runtime planes. In other words, having an API portal (established management plane) is not sufficient unless, for security purposes, the API portal is treated as the single source of truth for API access control policies across all runtime planes.
Fallacy 5: Standards don't change
This might be the most subtle of all fallacies. You may say: What do you mean that standards don't change? That's right, they won't change as long as the company stops innovating or stops growing.
Despite the stability that exists in certain low-level areas of standardization, this fallacy has been made more pervasive by the speed of technology advancements and the number of disrupting technologies in other areas.
Yesterday's best practices are today's anti-patterns. We need to design governance programs to recognize this reality. This adoption cycle is shortening dramatically. Think about the last time you asked your developers to follow a certain standard tool, library, or method - and by the time it was adopted, a better way emerged, or some of the constraints no longer existed, revealing more ways to do the same thing in a much better way?
A modern governance process must shorten the adoption cycle, recognizing the reality that the environment is constantly changing. There should be a systemic mechanism to continuously evolve the standards and shorten the adoption cycle to rapidly respond to changes. (This fallacy goes hand in hand with Fallacy 7.)
Fallacy 6: Developers don't care
For the "developers-don't-care" fallacy to be true, API governance would always deal with developers the way good-cops/bad-cops deal with law-breaking. You might think developers don't care, but, in reality, they're driven by attempts to either avoid pain or to meet deadlines.
This fallacy assumes that there's only one team that cares about standards. However, in most cases, developers want to do the right thing. They simply want standards that make sense. Standards make developers’ lives easier by taking away the need for making another decision. It’s fair to say that:
- 80% of engineers will follow the standards if they know it. You can annoy them by installing a gate late in the game without clearly publishing or teaching them the standards.
- 20% of engineers will question the standards that don't make sense. You can drive them crazy by not explaining the rationale behind the standard or by not accepting their contributions which would improve the standard and increase innovation.
(Some may argue the ratio is 98/2% not 80/20% - which could also be true - as ratio variations are relative to culture and to the measurement criteria applied.)
Fallacy 7: Governance cost is zero
I don't imagine programs being easily tricked into an assumption that governance cost is really zero. But this fallacy is not as much about the cost of governance as it is about the cost of governing everything. Hence, this might also be labeled the everything is worth governing fallacy.
Over the years, I have learned that what to standardize is just as important—if not more so—then how to standardize.
To focus on every aspect of the lifecycle—building automation, embedding rules, inserting stages in the pipelines, handling exceptions workflows, developing teaching materials, and conducting all the maintenance of these activities—could have a diminished return on the investment if the target value wasn't worth it.
When was the last time you've seen governance programs with assessment tools covering too many areas? Or you are given a long list of best practices that is unclear which ones are nice to have and which ones are problematic to ignore?
Governance programs must have the courage to govern the things that matter, the serenity to be flexible with the things that don't, and the wisdom to know the difference.
Fallacy 8: There's one technology stack
Although most architects today are not so naïve as to assume this one-stack fallacy in its entirety, they tend to gravitate toward one major stack while ignoring others.
For example, a program might focus on an existing stack, while new additions or parallels are being added somewhere with little attention until an issue raises awareness of governance—or the lack thereof. An opposite example might be to gravitate toward trendy stacks while ignoring the less exciting areas.
Since much focus and depth are needed to govern effectively, particularly given the pressure to go hybrid and engage with many new tools—it's important to stay ahead of the different stacks, to account for different platforms, diverse languages and tools, and to engage them with clear guidance and intentional value-driven investment.
Conclusion
All predictions point to APIs playing a crucial role in business growth and digital product offerings. Considering the numbers and scale of APIs in each organization and the struggle to manage the complexity of the multidisciplinary programs at scale, there's an increased demand for higher levels of mastery in API Governance to realize the intended business values.
While some refer to this topic as API enablement or API management instead of API governance, it’s important to note that API governance is not a single discipline or organization. Instead, it's an inner-source multidisciplinary program that multiple groups and organizations need to be responsible for.
Thanks for considering this rundown of lessons-learned about how not to go about API Governance. I'm interested to hear what has worked in your organization.
