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

[mleppitsch]

One of the biggest traps we currently see across enterprises, is that the developers of back-end systems are not aware of the features that are already provided out-of-the-box in the API platform, and bloat their code with unnecessary rework. We're talking about security, caching, traffic management, identity, message routing, analytics - all critical functions that have already been solved at internet-grade in the API platform. Adding these features from scratch to the functional code of the back-ends introduces significant risks to the projects, and robs the architecture of adaptability.

The costs in dollars and time are hidden because the enterprise has never experienced the speed and efficiency of API-first development, and the benefits of the API platform investment are not realized, not in the projects, and not across the enterprise.

This problem arises most commonly in distributed API programs. Here are related posts on that topic:

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?

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

[#2]

As API development starts happening across distributed teams; following aspects require attention in the same priority orders:

1. Consistency across APIs is key for an enterprise when exposing APIs to the outside world as they see an enterprise as a single entity rather than multiple teams / BUs / LoBs. Without any doubt, an API contract should follow consistent guidelines.

2. Naming of API is important to communicate its capability. It's quite probable that different teams may develop APIs have same / similar names but different functionalities. These names may be acceptable from the perspective of an individual group, but as an enterprise may be conflicting.

3. Violation of "DRY" principle. IMHO, this is fine as long as the effort required to develop such functionalities is a couple of days.

[mleppitsch]

Right, @rdoda, these aspects are the result of a relentless "outside-in" culture, which the API team must champion. Some enterprises profess "outside-in" culture when thinking about their customers, which is great, but not sufficient for APIs.

What is different here is that the "outside-in" culture extends to the "developer who works for a customer / partner," who does not have a contract to build a solution for the enterprise, but is simply building solutions for THEIR customers and employees, that happens to call your APIs. This a new actor, and a new "outside-in" customer of APIs.