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

mleppitsch
Participant I

The patterns that are working at some customers using the distributed model include the following:

  1. An API guild, of which all API developers, designers, and architects are members. This guild spends up to one day a week (!) working together to solve each others problems, detect overlap, coordinate tooling and automation issues, develop and revise the enterprise API standards and playbook.
  2. An API design authority, which is responsible for good and interoperable design of all APIs. This is a subset of the API guild, and it is a tough job. Members of this authority are often embedded in the squads as API specialists, acting as solution architects, or even as API developers. Some companies rotate these specialists through the squads each sprint, to make sure they don't become too beholden to the interests of one project or organization.
  3. A core API team led by an enterprise API product manager. This team is dedicated to the portal, to documentation, to maintaining and grooming the backlog (even though it is feeding multiple squads!). It maintains the playbook, resolves conflicts, evolves the API standards, and runs all API guild, marketing, and evangelization activities (more on that below). By working with the guild, it drives the funding and implementation of tooling, processes, automation, integration, scaling and updating of the API platform, and other technical work that provides the cohesion across the enterprise and all projects.
  4. A mandate to host all APIs on the enterprise platform. This mandate has to be accompanied by clear charter with the benefits that the enterprise expects to achieve with the mandate, and the benefits that the projects can expect. It is also the mechanism by which to secure the dedicated allocation out of the transformation budget (see below).
  5. Permanent and highly regular API "marketing and evangelization" activity, that refreshes the message of the mandate and its benefits, teaches program managers and developers about the technology, and listens to the problems and barriers that come up. This activity aims toward the adoption of APIs by the front-end developers, but even more relevant, aims to integrate APIs and the benefits of the platform into the development of back-end systems.
  6. Direct and distinct funding for all API skillsets in the enterprise transformation budget. This means that the individual projects are not burdened with the costs of the API program, and also do not have direct control over what these individuals can be tasked to deliver. The API specialists "charge" their time specifically to this budget weekly, and describe which APIs they were working on and what they spend their time doing. This alignment of funding and benefits is superior, because the benefit to each individual project can seem small compared to the investment in changing the way the squads work. The benefits really accrue to the enterprise in later projects, in unexpected innovation, in new partnerships and faster delivery once the catalog of APIs begins to mature.

Related posts on this topic are:

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

Should we centralize or distribute our API team?

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

0 0 639
0 REPLIES 0