API Lifecycle Governance Best Practices
The way a company builds APIs is a reflection of its organization. If a company is siloed, then the APIs produced by that company will be as equally fragmented; those items from one group will have little resemblance in form or function to the work produced from a different group. It is the goal for any API lifecycle governance effort to promote consistency and cohesiveness for better program efficiency.
In this interview, Matthew Reinbold, Senior Manager of Digital Product and API Platform at Capital One, sheds some light on best practices for API lifecycles and governance.
Tell us about the system of governance that’s in place at Capital One for APIs and what’s working well about that system.
It’s the job of governance to ensure consistency and cohesiveness. We have to make sure that everything across Capital One behaves in the same way. As a metaphor, let’s talk about salt and pepper. If you have a design that is cohesive but lacks the consistency of the interface, that would be like if you were handed a salt shaker and peppercorns at a meal. There’s no consistency to that interface. You have a shaker, and then you have to somehow smash the peppercorns — it’s weird and not at all user friendly. But it’s cohesive because you would expect salt and pepper at a meal. If you have the consistency of the interface but things aren’t cohesive, that’s like salt spray and pepper spray. In that example you have a consistency of the interface; they’re both sprays. But they’re not at all cohesive; they don’t work together. When you have both consistent interfaces and cohesive interfaces, that’s the salt and pepper shaker set.
It is the responsibility of governance to ensure that we have both consistency and cohesiveness for our API interfaces. In doing that we can have developers who have experience using one and leverage that experience when using another. It accelerates development ability.
What has it been like launching DevExchange as a team?
The effort to bring the DevExchange to fruition has been absolutely exhausting, BUT, I have never worked with a team that I am more excited about working with. The people that are here at Capital One have re-energized my excitement about what a platform can be. I’m really excited about what we have and will produce together.
Would you say that working together as a team in this way makes a better product?
Oh absolutely. Having a team that is so deeply invested and aligned toward a vision is one thing. But when they are also enthusiastic about what they do shows up in the work. It means that people will go the extra mile and debate even that ridiculously weird edge case because they’re passionate about it.
What advice would you have for someone who’s just getting into API design governance?
It’s OK to not know everything when starting. It is OK to iterate and get better at it. One can never hope to account for every edge case and nuanced wrinkle from the onset.
API design governance is not about having a massive tome of standards to beat developers over the head with. Even if it was possible to write the perfect policy for today, it may not be the perfect guidance for tomorrow. It is more important to create systems to support change. Accept that the policy may need to evolve as new requirements or business realities are discovered. Then put the effort into creating those dynamic systems. The list of rules that API developers need to adhere to is not the end goal. Policy is a byproduct of a dynamic, healthy process, not the destination.
In conclusion…
The better all departments work together using the same language and mission, the more efficient work can become. To learn more about the Capital One approach to APIs, explore this DevExchange website including the API Products page.
For more on APIs, open source, community events, and developer culture at Capital One, visit DevExchange, our one-stop developer portal. https://developer.capitalone.com/
