“In order to achieve API success, you need to make sure your APIs are discoverable, collaborative, governed, and well-documented.”
—Brian Otten, VP of Digital Transformation Catalysts, North America Axway.
This week on the API Intersection podcast, we interviewed Brian Otten, Vice President of Digital Transformation Catalysts for North America at Axway. Axway is an organization devoted to helping customers with their API management and digital transformation journey. Brian’s team provides strategic consulting services to large enterprise customers and helps customers get active in their API journey.
Brian’s team focuses on advising customers on how to avoid API duplication, self-service for APIs, and packaging API products for other integration purposes. Here are some of the most common challenges he helps advise teams through, and you might recognize some of these challenges on your own API team!
1. Maintaining Close Collaboration Between the Tech and the Business
“In order to make sure that API strategy is a success, it has to really link to the business. It has to be business driven at the heart in order to perform well truly,” shares Brian.
I sat down with Brian to better understand how we can arm our API teams to serve both the technical and nontechnical stakeholders best. As we see more and more “API product manager” titles popping up across the space, we’re seeing an increase in product managers designing APIs from scratch without having a technical background.
He emphasized how critical collaboration between business and technology teams is to work out the API value proposition, pain points, gains, and how that can inform the API design together. All necessary stakeholders should remain in close communication throughout the API development process, especially during the design stage. The more eyes, the better to ensure your API will provide a great developer experience and provide the needed business capability. Include all relevant stakeholders in your API design review to ensure you don’t miss this critical step.
When the purpose of the API doesn’t align with business goals or hasn’t been vetted by the nontechnical stakeholders involved, that’s where Brian often sees his customers falling into a pattern that’s difficult to escape. Encouraging a design-first or API-first approach company-wide can help keep that collaboration top of mind and avoid misalignment down the line.
2. Not Getting DRY Enough and Building for Reuse
“Avoid building APIs that are only suitable for one consumer and instead aim to create reusable components and products,” shares Brian, “The need for reusable APIs that fit into the bigger portfolio and roadmap of the organization is a must for larger teams.”
This is another common problem that Brian sees when advising his customers. When not building for reuse, duplicative efforts can quickly arise, and extra tech debt is created. So instead, Brian advises building for reuse in your APIs wherever possible.
Many developers will recognize this as the DRY method (Don’t Repeat Yourself), meaning that one should reduce the repetition of patterns and code duplication in favor of abstractions and avoid redundancy where possible. In layman’s terms–the more APIs and API components you have that can be reused, means less time you have to spend repeatedly building out that component down the road.
For example, I always like to use the metaphor of building standard-shaped Lego blocks rather than licensed branded ones that only work on a specific level. The standard shapes (components) will get you much further in terms of consistency, repeatability, and scalability for your API program.
3. Establishing Governance Measures, Especially at Scale
“Let’s face it, no CIO or CTO wants to pay for governance; they just think it’s something you should be doing anyways. So, having those tools that already have the specifications and the standards in place can help you streamline a lot of that,” Brian shares.
I know it sometimes seems like we’re beating a dead horse when it comes to the “governance” talk, but there’s a reason almost every podcast guest brings it up! I can recall over a decade ago when I was a practitioner at PayPal, I had to write crazy standards that no one ever read, and boy has the landscape changed significantly since then. Developers are hungry for standardization, and they’re in need of it now more than ever.
As APIs proliferate further and companies have an increasing need for them, there is still an immaturity in governance, rules, and style guides for API design and development across the board to keep up with that demand. Brian encourages that using a strong design tooling platform will help solve that governance issue by providing guardrails and making it easy for development teams to ensure quality and consistency.
Brian also mentioned how critical establishing standards and guidelines for your API program are because it will make a world of difference when scaling. He sees many clients who are struggling to keep up with the pace of scaling. Introducing a strong governance program allows them to design and develop APIs quickly, with the assurance that standards are in place to deliver only the highest quality APIs.
For those who are struggling with getting their governance program off the ground, Brian’s found that training workshops to enable developers on why those standards are important often helps. In my days at PayPal and Expedia Group, we found that training sessions on API standards were the best way to build community and find the most knowledgeable and passionate developers to recruit to our cause. He also emphasizes having an API guild or team that can help onboard new folks and ensure all are following the guidelines and standards can help with that transition.
In the end, the common issues that Brian’s team consults on aren’t isolated. These are some of the most common pitfalls we see across the board for API teams, big and small. I appreciate Brian’s insights, and for more advice from industry leaders, check out the API Intersection podcast.
