Mapping the API landscape across an enterprise should always include the mapping of team boundaries. The outcomes of your API governance will be shaped by these boundaries, resulting in many API governance efforts looking to overcome and flatten team boundaries, when you should be understanding and embracing these boundaries. There are many ways you can introduce standardization across many different teams as part of API governance, but if you are looking to bend teams to your central API governance, rather than shaping and adapting your API governance to these team boundaries, you will have a very tough road ahead. As part of the ongoing mapping of the enterprise API landscape I recommend understanding the following alongside the APIs you are profiling and looking to govern.
- Teams - Any information you can gather about the makeup, personality, and incentives of a team who are producing or even consuming APIs.
- Domains - Working to understand the surrounding domain, organizational structure, and vocabulary in use by a team producing or consuming APIs.
- Tooling - Spend the time to learn what tools teams are already using, as well as how and why they are using them, before you introduce new tools.
- Motivation - Do the work to understand a team from their perspective and learn what motivates them and will get them contributing to governance.
- Turnover - Look at what the turnover and change looks like with a team and understand how you can help influence and work with this team change.
Before you ever move to try and direct or change a team, you better be doing the work to understand their boundaries. Obviously not all boundaries should be accepted and included as part of API governance, but teams operate the way they do for a reason, and the boundaries that exist are there for reasons—both good and bad. I have seen a number of centralized API governance groups do the good work on guidance, policies, and rules, only to come up agains friction when you hit known and unknown team boundaries. Mapping the API landscape should always include both APIs and the teams producing them, but also the teams who are consuming them. You’ll find more success and less friction when you embrace team boundaries rather than just looking to overcome them, get them out of the way, or flatten them—teams often see that as a threat.
