Reboot Your API Team!
Reboot Your API Team!
With an API team that works purely in ticket mode, what are the benefits of more ambitious governance?
Join the DZone community and get the full member experience.Join For Free
I regularly meet companies that do API Management but without real governance. With an API team that works purely in ticket mode, what are the benefits of more ambitious governance?
What Could Be Improved?
And I have to admit that it annoys me and makes me particularly tired. How do you want to benefit from the API Management concept if you consider your API as a mere cost center? And why did you take an API Management?
A few reminders about several gains that can be observed with API Management.
For many people, API Management serves no other purpose than to secure application exchanges. If I had to add a ladle of sarcasm, it's also a way of saying that you're in the spirit of the times, digital, emerging, chooseYourFavoriteBuzzWord. In short, we did what we had to do so that new technology would end up becoming old-fashioned one day or another because it wasn't going to bring anything to projects and jobs other than constraints and killed deadlines.
Whereas there is much more to bring thanks to API Management. You can share your APIs, communicate on them, make APIs oriented according to the target audience, make canonical formats to manage several backends, in short, you can do a lot of things that require transversality and ideally even a strategic vision of your API. How many times have I seen the "ObjectFromSAP" API or things like that?
Good Governance to Work Well
To operate the strategic objectives given to its API Management, there are, in my opinion, two main families of governance that can be put in place.
- The first one, which is fairly classic, is what I call the Competency Center. Having a single team that manages APIs from end to end, whether on the functional, technical, or development aspects. Its skills can be limited to the scope of the API Manager or extended to the entire technical integration stack, or even work a little on the backends. This is perhaps the most natural organization for many companies. However, it should not become a request ticket management service. You have to know how to accompany projects early on, work in concert with stakeholders (business lines, developers, architects, project managers), and above all be part of the project process to bring value.
- The second is to be a sort of control tower. In a way, it's about managing APIs as one would manage a large Open Source project. The API team is there primarily to provide framework and facilitation, but not necessarily to do, at least not to do everything. It defines and shares its processes, communicates on best practices, integrates into the company's CI/CD chain, checks the quality and relevance of the APIs developed by the developers. This organization has the merit of being particularly scalable because if the tooling, communication, best practices, and processes have been well defined, doing 4 APIs per month or doing 40 will not require an API team 10 times bigger.
In short, governance and organization are the real keys to the success of an API Management project. Making an API is very simple. Doing a lot with a lot of people, and doing it well can quickly become complex. So don't hesitate to think about your governance!
Opinions expressed by DZone contributors are their own.