API sprawl is the latest truth of the enterprise that API vendors are selling to, and us analysts and storytellers are spinning yarns around. APIs are everywhere!!! Littered across the web, the enterprises, our cars, homes, and in our pockets. This is why API governance is the latest wave to get investment and sell solutions for–I am riding it baby!! I point a lot of fingers in this API hustle, but when it comes down to it I am no different than others in the space, I just have an unorthodox and theatrical way of acting out my hustle than others do. When it comes to API sprawl, I don’t see it as something bad, and something that needs taming–I see API sprawl as something that is good, which should be embraced, leveraged, and made sense of in any given moment, as you make your way to wherever it is you desire to go as an enterprise.
When you look out at the physical world, do you say, “boy, this is surely sprawling and chaotic—-I should tame this!”? Some might. I don’t. When I look out at the sprawling enterprise landscape I see many APIs that exist because someone decides it should. Oftentimes I don’t agree with the reason why that API exists or the shape and purpose of the API, but I wasn’t there at the moment in time, and standing in that person’s shoes. There are many, many, many things going on across an enterprise that I do not understand or are aligned with-—this is fine. This is the legacy of the enterprise, and who am I to just assume it should all change, and god forbid, that it should all be standardized and homogenized. With that said, I am sure there are many things that could use improving, modernizing, or just go away all together. The real trick with API governance is to 1) map this landscape, 2) do your best to quantify and understand, and 3) pick meaningful areas in which you can evolve or empower others to evolve.
Why do we look at API sprawl and assume it is chaos? Because it is complex and we don’t understand it. Why do you look out at API sprawl and assume it should be tamed? Because of the reasons Internet exists in the first-place, colonization. Internet technology comes out of the military and evolved during the Cold War. Command and control is in its DNA. It’s what we do. I’d also add that it is very white male to think that we can and should tame the chaos and plant uniformed lawns everywhere. I don’t think all APIs should be HTTP APIs, but it is the dominant pattern. I also don’t think all HTTP APIs should be REST. I think there is a lot of diversity available to us within the HTTP API paradigm. I also think that we should be empowered to say that API is a bad idea and we shouldn’t do it in the first place or we should deprecate it. I also strongly believe that there isn’t always a “right way” to do APIs, and understanding the space an API operates within, and who its consumers are, is critical to defining what the “right way” should be.
API governance (guidance) for me is about mapping the API landscape as it exists, establishing a baseline of business policies and technical rules that can help define what matters across the landscape. Once you have this, you get to work establishing feedback loops with teams who are producing APIs, solicit the assistance of architects, platform, and governance teams, while extending those feedback loops to consumers of an API—-giving everyone a voice. Then you iterate. You iterate on APIs, as well as the policies and rules governing (guiding) their evolution. And you move in the collective direction that matters to the enterprise, teams producing APIs, the platform teams stabilizing API operations, and the internal or external consumers of those APIs. API sprawl is good. It exists for a reason. API governance is here to help teams make sense of this sprawl and guide them through it. Governance defines which parts should exist and which parts shouldn’t exist, and where new APIs should or could be delivered. Los Angeles is sprawl. Is it bad? Should it go away? Or should we understand it, improve it, and work with people who live and work there to make things better? API sprawl and API chaos are fun phrases to use-—I use them a lot. They make for great storytelling. However, we should also be honest about what they are—-vendor and analyst stories to convince people in the enterprise they should be buying the latest techno solution (aka, tomorrow’s sprawl).
