Enterprises are interesting entities. I am very keen on understanding more about the how and why they operate, but I am also very keen at avoiding getting ground down by the churn of enterprise gears. I enjoy mapping the business, technology, and people landscape that exists across enterprises in different industries. I enjoy hearing stories about what matters to business and engineering stakeholders across different enterprises. I enjoy crafting strategy, programs, platforms, policies, lifecycles, rules, and supporting evangelism across enterprises. I do not enjoy the games and drama that exists within enterprises, which end up coating everything that exists across the API lifecycle, and oozing out via API portals with partners and consumers. The API journey is entirely defined by the enterprise landscape, policies, and the games people play, and I am determined to shape all of this with my API Evangelist Contracts approach to governance as a service.
I have mixed emotions about the role platformication and the centralization of API governance in the enterprise. I agree that some things should be centralized and standardized for teams to take advantage of when producing APIs. Power accumulates on centralized infrastructure, in good and bad ways. Complexity accumulates on federated infrastructure. I am keen on taking this all into consideration when it comes to crafting strategy, program, platform, policies, lifecycle, rules, and evangelism as part of API governance. I am trying to be pragmatic when it comes to what actually influences the way things are, and what are the realities I need to craft API policy and rules, and hang on a well-defined API lifecycle, allowing for the standardization across the enterprise, but also for adjusting to meet the needs within specific domains. Some things need centralization. Some things need federation. Some things need locations. I am interested in understanding and having conversations about why.
Orthogonal to the centralization vs. federation conversation is a conversation I am keen to have about inside-out vs. outside-in API governance. It represents another dimension I am keen to have conversations around. How much of API governance needs to come from within an organization vs. from outside influences will vary from industry to industry, and enterprise to enterprise. But, a certain amount of API change that occurs will always be outside because of industry regulations, standards, markets, and the influence of API consumers. This is why I love APIs. This has shaped my view on API contracts, the solutions they provide, as well as the API governance services I will be offering. API Evangelist Contracts can be initiated by an API consumer, not just an API producer. And API contracts are relative to internal, 1st-party, and 3rd party relationships. I am looking to understand what works and what doesn’t work in different industries when it comes to outside-in forces, while also embracing and encouraging inside-out forces. It is about finding the balance that works for each enterprise—there is no perfect formula.
Spinning API governance on another axis, I am really concerned with balancing what I do with top-down vs bottom-up motions. I want to offer strategy and program level guidance and services when enterprise organizations have top-down mandates to govern APIs, but I am also very keen on offering tactical guidance and services for individual teams and lines of business to take advantage of. While I wish there were strong top-down mandates for API-first and API governance investments, I know the reality within many enterprise organizations, and people don’t have the awareness, time, or resources for full-scale API governance, and just need help at the tactical level to get them through this sprint. Bottom-up enterprise API governance and standardization is optimal to a top-down mandate, so this is where I will mostly be investing my time and services, but supporting top-down efforts when they exist will be critical. Like the other two dimensions of API governance scale, it is all about striking the optimal balance when it comes to top-down and bottom-up motions.
In my opinion, API governance change and velocity will primarily come from federated, outside-in, and bottom-up motions. This is where you get the self-service and hands-on engagement across business and engineering teams you need. This is where you get the feedback loops and the right velocity of change required to maintain alignment with API consumers. I just don’t think all enterprises are prepared or equipped for a federated, outside-in, and bottom-up API governance program. I want to be mindful of this. But, I want to change it. I want to help provide the strategy and tactical nutrients that help things move in the right direction. I do not think I can fix enterprise organizations. That isn’t my job. My job is to understand how the enterprise works (and doesn’t) to the best of my ability, and provide guidance for strategy, program, platform, policies, lifecycle, rules, and evangelism that enterprises can use to fight the good fight. It isn’t up to me to decide whether things are federated or centralized, inside-out or outside-in, or top-down or bottom-up. I am hyper focused on governing APIs at scale across different groups within the enterprise.
