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.
For distributed operations, take a look at the following topics in more detail.
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!
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.
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.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |