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

mleppitsch
Participant I
  1. First of all, it is true that most enterprises are building APIs in the context of also building new back-end services, new front-end applications / apps, or both. The squads are assembled for the projects, with all the skills necessary to deliver sprints or stories, end-to-end "stuff that works." So it is critical that these squads also include individuals with the skills to properly define the need for APIs in their solutions, and know where to get information and collaboration about APIs (see below). They are on the hook to make sure APIs are in line with the enterprise strategic direction to be an API-based digital company. This is not optional.
  2. Of course, to support all the squads, there has to be a portal where all existing APIs are discovered and accessed at design-time, all documentation resides, all front-end developer support happens. This is invaluable obviously for all the front-end developers, who can only access company assets through APIs anyway. They go to the portal first to see if their needs for APIs are met, before submitting requests for new APIs. The portal is also useful for the API developers, to keep an eye on API usage patterns, utilization, feedback, etc. Never skimp on this at any of your clients; without a portal and excellent documentation, you'll burn many millions of your customer's budget just explaining over and over how things work, without producing results. This can really sap morale and commitment to the digital transformation.
  3. Also critical for the squads is visibility into the backlog of APIs that are slated be built. One customer of ours actually hosted this on the portal along with the live APIs. If you logged in as a member of the squads, you saw the backlog of new and revised APIs, with detailed description and a rough schedule. That discovery mechanism allowed squads to collaborate and build APIs to meet shared needs.
  4. Finally, almost all of our customers develop and maintain an API playbook and API standards, which documents the agreements that all API specialists follow. There is an initial effort to set up this playbook, then it has to maintained as the methodologies and maturity of the enterprise evolve. (Warren @wchuei is right on, and I discuss this aspect of API playbook at bit.ly/DTSBlog009).

In addition, here are more posts related to this topic:

Should we centralize or distribute our API team?

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?

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

Thanks for the opportunity to comment!

0 0 446
0 REPLIES 0