There are many ways teams producing APIs talk past each other. Is this an internal, 1st-party, or 3rd-party API, because what needs to be discussed will vary widely. Is this an existing API or a new API, because the conversation will be very different. Is this a code-first or design-first approach, because the conversation will shift dramatically. Another way that in which people tend to talk past each other is within the centralized vs. federated conversation, where teams are talking at different scopes of the API work happening, but lumping it all into a single philosophical debate about whether it happens centrally or it will be federated.
- Planning - Will the planning going into a new API or version of an API be done centrally or federated across teams.
- Development - Will the development going into a new API or version of an API be done centrally or federated across teams.
- Platform - How are common and shared resources being made available to teams centrally or federated across domains.
- Gateway - Is the gateway an API being published to a centrally managed gateway or will be federated across domains.
- Governance - How is governance (guidance) being provided to teams, but then also enforced in centrally or federated ways.
It is important that the centralized vs. federated debate center around a) centralized and federated conversation, b) precision in the scope of what part of API work is being centralized or federated. Rarely will this conversation be a one-size fits all approach and some things will need centralization and others needing federation—with the occasional element shifting between those modes based upon learnings and business shifts. The centralized and federated conversation is an important one for enterprises to be having, and it is something that will overlap between governance and platform efforts which are both often centralized, but also the place where discussions around what should and should not be federated need to be occurring.
