The Tyk LEAP 2.0 API Governance conference yesterday brought together an interesting mix of people to talk about the heart of what API governance is—people and business, with a little tech sprawl mixed in. I was happy to hear the stories that were mostly 75% people and business and about 25% technology. Technology — it’s made of people!!! Most of all I love being a bookend with my buddy James Higgenbotham, who has been along for this ride as long as I have. James’ view of API governance reflects the natural transition of enterprise API management into enterprise API governance. While I adore James and would recommend more enterprises choose him for help than me, I enjoy even more the difference between our views of the landscape—-let’s see if I can explain.
James is capital G Governance. Jame’s view can trace its lineage back to API management and back to SOA. It is top down capital G Governance with a belief that if you have a strategy and a strong set of diagrams, beliefs, and mandate—you can get this done. And you can, if you operate within certain organizations, operate from a top-down leadership position, and see governance as a set of strategies, policies, and rules that require everyone to get in line. I would say that this approach to governance reflects how enterprise leadership sees the world, and how many people see the governance of a country. Governance through command and control and clarity in the vision, coupled with an expectation that everyone needs to get on board, and this will work. I get why that vision appeals to enterprise leadership and the politically conservative around the globe. But, the world is just a bit more messy and diverse than that in my experience.
While I don’t think I properly articulate this yesterday, but my talk about governance in contrast to James is lowercase g governance. My approach acknowledges that there is no single way to govern APIs across the enterprise. There is no right or wrong way. There is no one set of diagrams that can help answer all the questions you are going to encounter while addressing governance at scale in the enterprise. Like governing a country you are going to need an educated, literate, and engaged constituent base. My approach to schema, APIs, governance, operations, changes, and evangelism is all about this. I am just looking to equip architects, designers, product people, engineers, and anyone else who happens to find themselves working with APIs. I am looking to just help people learn to learn, collaborate, and adapt, and use standardized artifacts to help align every along the way. I’ve seen too many enterprises to think there is one way to get this done, and that there is one service, tool, or even strategy to fix all of this. You have to develop internal capacity, educate teams, and give them the autonomy and agency to get the work done.
I am not saying Jame’s approach doesn’t have some of these elements—-it does. I am even on board with his belief that we should still use the word governance. But I approach from a more bottom-up and outside-in, while he is coming at it from top-down and inside-out. James is also more conservative in his approach where mine is more anarchy. Part of this is our personalities, but also our world view and experiences. Honestly James’ view of things is probably a more sensible approach to enterprise leadership looking to govern their API operations. However, my approach is better for people who are on the ground floor in an enterprise trying to govern enterprise APIs without a top-down mandate, where they are just trying to survive and even thrive. I am a big fan of Jame’s work even though I disagree with the approach and belief that it will work. But, it does generate a nice paycheck. I also know that I drive Jame’s nuts, like I do many other folks in the space. I’m OK with that. I strongly believe that both of our approaches are necessary, and I’m thankful to have James in the space to differentiate and contrast my approach. In the end it comes down to what you are actually governing, and whether or not a capital G or lowercase g is required.
