The desire to centralize API gateways and platforms is a powerful one. Like mono vs micro, federated vs. centralized comes with its technical, business, but also peopel and political tradeoffs. The answer to whether or not you should be centralizing or federating your API platform will be the classic architect answer — it depends. The official API Evangelist answer to this question is—yes, you should do both. There are significant challenges to federating and centralizing your API efforts, but let’s explore the headwinds for what the centralization of your API gateway and platform are within your average enterprise organization, the areas that are often overlooked as teams do the work to get the technical details in order.
- Power - You just haven’t accumulated enough power in your bureaucratic portfolio to force teams to centralize.
- Tribal - Your centralization plan just does not take into consideration the legacy of your enterprise tribal boundaries.
- Agency - There isn’t enough agency for teams who are producing APIs available via a centralized location.
- Education - You do not have a centralized educational apparatus to properly train and educate everyone to prepare.
- Resources - Your central team is just too small and short of resources to actually get the job done properly.
It is common for centralized API platforms and governance teams to enjoy a top-down mandate that centralization is where everything need to go, but those mandates do not always come with the resources, education, and political capital necessary to move all the people towards a centralized way of doing businesses. In these cases centralized efforts just become a bottleneck, real or perceived, and depending on the tone set with other domains and teams charged with shifting towards a centralized approach to APIs, you are likely to spend most of your time doing things that aren’t API related. So make sure you are evaluating the technical, but also the political ramifications of centralization before setting things in motion.
