Alvaro Navarro

Alvaro Navarro
Effective API Governance: Lessons Learnt

Biography

Alvaro started to code in BASIC when there was no Stack Overflow. Software Engineer and open source lover, he has been working more than a decade developing distributed and real-time systems for Airbus in Spain and Germany.

He is currently working as Developer Advocate in Amadeus for Developers, an open innovation program aimed at facilitating connectivity between the innovation ecosystem and Amadeus, to accelerate the exploration and implementation of new business ideas. One of his main tasks is to help developers to implement that idea they have in their heads, by building prototypes using APIs, writing documentation, tutorials or even going to events to talk or learn about new trends in technology, languages or methodologies.

In addition, he combines everything mentioned above with the titanic task of raising two children and keeping his comic collection up to date.

Talk description

Have you ever wondered how big companies deal with large amount of APIs? How do they keep consistency among the catalogue? Either if you are already running an internal API governance or you are thinking about start a new one, this talk will share our do’s and don’ts with the rest of the community.

You can’t drive as fast as you want any time you want, you can’t just park anywhere you want to and you can’t drive on whatever side of the road you want to drive on. If you follow some guidelines when driving, why not when designing and documenting APIs? You might think everyone could simply get up and do whatever they want to during the API design phase. But instead of working in a friendly-peaceful-full-of-rainbow-unicorns environment you would be in one without rules that would be chaotic.

The talk will share our experience running and contributing to the API Governance defined at Amadeus: the motivation behind it, the benefits of having an internal governance, what kind of activities we do, the roles and responsibilities of the members and -why not- sharing the existing pain points we have detected.