Should we centralize or distribute our API team?

[mleppitsch]

The first key to building APIs that achieve reuse, avoid hard-coding, stay loosely coupled, are scalable and manageable, is to build it on a designated enterprise API platform (Apigee, of course 🙂 ). In terms of software development processes, there is nothing that special about APIs; most agile paradigms lend themselves to include this API construction work. Important here is that the CI/CD, testing, release, code and test data repositories, tooling, etc. for APIs is highly automated. The release cycles of APIs should be well coordinated with those of the front-ends. Also, when a back-end is renewed or replaced, that project must include the effort to connect it to the API platform, and the effort to revise the APIs on the platform that depend on them.

So now the question, is this work of building APIs best centralized, or is it best distributed? There are a couple of models that appear to work.

1. Centralize the API skill sets into an API team (or API factory), and route all API work to this team to implement. In this case, the needs for APIs from all projects converge on this team. They design and build all APIs, maintain the backlog of requests (visible to everyone), and manage the prioritization of APIs to the benefit of all the projects. You can quickly see that for enterprises of any size, this can become a bottleneck. If schedules are important, the best way to relieve this seems to be to carefully coordinate the various epics driving the projects, and align delivery schedules to utilize this team. The benefits of this model is that it tends to achieve good reusability, quality, scalability, and reduced costs. But generally it only works for smaller enterprises (we do have some amazing exceptions to this, though!).
2. Distribute the API skill sets among the squads. We already mentioned that all squads must be able to properly include APIs in the solution architecture of their project. In this model, all squads also include the ability to design APIs, configure the API platform, build APIs on the platform using its built-in feature sets, and complete the develop - integrate - test - release process using the common tooling and automation. You can quickly see that without coordination, the pressure of project delivery causes a lot of divergent API designs, conflicting functionality, crappy reuse; even the common processes and tooling fragment over time, and we've seen some portal languish because noone really owns it.

For distributed operations, take a look at the following topics in more detail.

How do I reconcile individual projects doing their own thing with the need for a common library of A...

How do we distribute our API construction without losing the benefits of an enterprise API platform?

As we distribute API development among the projects, what is the biggest problem we should avoid?

Thanks for the opportunity to comment!

[#2]

This really depends on technical maturity of an enterprise on designing and building APIs. Most probably, enterprises may have limited / low knowledge when they are starting their APIs journey.

In such context, an enterprise could start with a centralize API team, however, having the goal of distributed API teams. IMO, the end goal is critical and should be communicated clearly from day one.

The centralize API team should be available for the initial couple of API programs only or better, fixed timeline like 6-12 months. Towards the end, the centralize API team should be dissolved and members could become part of new programs as an APIs' practitioner.

The centralize API team plays a critical role in moulding enterprise to have API based thinking. Delivering an initial API program successfully should not be the only goal of this team. This team should build a formation for the future by:

1. Measuring APIs success along with delivering APIs for the initial program

2. Define best practices as applicable to their enterprise's context.

3. Evangelize APIs based design into the whole enterprise.

[mleppitsch]

Thanks @rdoda, indeed, many API programs start as a centralized team in order to get the initial workflows defined, demonstrate success (what should we measure?) and how the "new way of working" works (agile, devops, etc.), and write the first playbook and standards for the enterprise. All this is best done by actually DOING, not defining in an ivory tower.

Then these foundations have a better chance of staying consistent as the practices are replicated across multiple squads, and the API guild emerges.