Questioning how I see the technology, business, and politics of APIs is the foundation of API Evangelist. I’ve changed my opinions on a lot of things over the years, as my awareness expands on different topics. Right now I am questioning how I see and approach API governance. In an attempt to try and apply what we’ve built at Naftiko to the problem of API governance, I find myself question a lot of what I’ve been writing about when it comes to API governance. IDK, maybe I am over thinking it. Let’s see.
Let’s start with, what is API governance? Well, in is current form, API governance is about coming up with a set of design rules (Spectral / Vacuum), which are used to “lint” or “validate” the design of your API, the paths you use, the summary, description, and identifier for you operations, and the schema you pass back and forth between APIs and their applications. This “design of your API” is usually expressed as an OpenAPI or AsyncAPI, which can be “listed” or “validated” when designing in your IDE or other editor, at the CI/CD pipeline when an API being deployed at any stage, as well as at the gateway when be used by any application. API governance generally means you are going to establish these rules, publish them to a central style guide, and the design of any new APIs will be “governed” at design, build, or runtime.
The theory (and practice) is that API governance will change the behavior of teams, producing standardized APIs across teams and domains. That we will be able to agree on a common set of “rules” governing a standardized set of design patterns, and effectively “govern” all of these across different domains and teams who are using different tools and process. This belief system often leaves me wondering if what we are setting out to do is even possible, and if we could do it today, would it solve all of the problems we think it would? I believe the path forward involves everyone who is producing APIs at enterprise get the training they need to deliver many different types of APIs that are suited for different purposes, but it is something I’ve been pushing for now since 2010, and haven’t achieved so I need to find other ways.
OK, so with governance. We want to ensure that all APIs have standard design patterns, such as path names and parameters. Clearly there are plenty of other patterns, but for simplicity let’s focus on just two of the most API governance rules and design patterns out there, and we’ll let our imagination apply to all the other patterns. For this story I’ve generated Naftiko Capability that consumes three different APIs from three different teams who each have their own design patterns, to which I expose as consistent paths and parameters, transforming what exists into what I envision in an governed API world. So, why haven’t we just done this before? I can even use a set of spectral rules to guide the generation of the Naftiko Capability I am using to “govern” or “standardize this API. I can publish newer, cleaner, documentation, mock servers, and SDKs. I can deliver all the things the consumers will need.
I wanted to explore this at scale. I did it to all of the Palo Alto Networks API I had crawled. It is one of the top service used by companies in my Naftiko Signals work, making it a prime target for exploration. When you look at Palo Alto Networks you see what you see across any enterprise organization–APIs that have come to life and evolved over the years. Built for different purposes, for different reasons, and by different teams with different skills. Are we going to change this behavior? At this point in my career it seems unlikely. I’m not saying that you should stop doing API governance. I am just questioning the reality that has accumulated around it to date. The design patterns we are governing are just one aspect of API governance I am looking to question in this moment.
Another dimension of our shared API governance reality I have been questioning for the last year is its almost exclusive focus on producing APIs. API governance is rarely apply to the API we consume. Why is this? IDK, but I do know that the lack of API governance across APIs we produce involves less risk than with APIs we are consuming—meaning the lack of API governance with APIs you consume is where your big headaches will comes from in coming months and years. API governance kind of feels like a house of cards right now, without a lot of discipline, possessing lots of shadows, is in need of alignment with the rest of security, compliance, as well as other business groups, and domains where APIs being produce and consumed.
The reason that API contains so many shadows is that it primarily lives in the engineering realm, while attempting to govern some very downstream business outcomes. There is a pretty big scope issue when it comes to API governance, meaning the scope of governance today is focused on rules applied to HTTP, TCP, MQTT, and handful of other types of APIs as defined using OpenAPI or AsyncAPI. This isn’t aligned with runtime policies using OPA, Cedar, and other formats, and there are very few other experience of operational notions of API governance ensuring there is consistent documentation, mock servers, testing, SDKs, and other things that matter. We don’t have a common API governance vocabulary to govern the entire factory floor, let along the entire supply chain.
The other aspect of API governance that I think has been hostile API governance being as easy as I illustrate above, is the platformification and centralization that has been occurring some time now. I mean, why hasn’t the gateway just be doing what I am proposing with the Naftiko Framework? There is a lot of power and myth accumulated at the platformitized, centralized, and gateway. In my experience this loss of agency by teams through centralization, which happens in different ways within different companies. I guess, what I am trying to say, is I don’t believe that centralization and platformificaiton is always the answer. I think shared resources and common policies, operating within agreed upon boundaries, makes sense, but default centralization does not always seem logical to me without proper policy debate.
In closing, I don’t think we need every API to be governed via the same set of rules. I think there are more political and business reasons preventing us from ever achieving the current API governance reality we have in our heads. In the end I am guessing that it is all a much more diverse reality than we could ever possibly imagine. I think we should commons sets of policies and rules by industry and domains within the enterprise. I think we should allow teams to produce and consume the APIs they need, and that we can afford. I think we should transform and apply these many different APIs we produce and consume in meaningful ways that are aligned with our business operations. This is when I think that API governance will grow up and mature. When it aligns with business outcomes. When it is seen by both business and engineer stakeholders. When they both have the ability to configure and negotiation what their teams should be capable of. This is what we are building at Naftiko.
