I ran the 2022 API Governance Survey between February and March this year to understand API governance practices across organisations. First the bad news. I didn’t get as many respondents as I hoped. A total of 16 respondents completed the survey (6 from the UK, 5 from the USA, 2 from France, 2 from India and 1 from Germany). Clearly the total survey sample size of 16 is too small to draw conclusive inferences from or categorise and benchmark teams as originally planned. One lesson for future surveys is to work on getting a bigger sample size. By the way, one incentive to complete this survey was an offer to make a donation to the respondent’s suggested charity, but only two respondents took up this offer (see beneficiary charities here).
Given the small sample size, for anyone still interested in working with the data, here are some conclusions I have drawn from the survey results (which have been published on Github for open access. Go on, have a look).
Point 1: API style guides should be better
Having an API style guide is good, but the style guide needs to be good enough to meet the team’s needs: it should be comprehensive, clear, actionable and enforceable.
Survey data: Only 43% of respondents were satisfied or very satisfied with their organisation’s style guide. 49% of respondents where neither satisfied or dissatisfied, or were dissatisfied or strongly dissatisfied with their API style guides.
Point 2: API discovery is a challenge in the enterprise.
Providing great internal API discovery experience should be a goal for the API governance function.
Survey data: Only 19% of respondents were satisfied that they could find all of their organisations internal, private, or public APIs they needed to consume, extend or use to make a decision. This is in line with the October 2021 Forrester report that stated that a technology led approach to APIs is resulting in developers not finding the APIs they need. When asked how their API assets (i.e API specification and metadata) were stored 33% reported that they were scattered across different systems, wikis, documents and API catalogues. And 13% reported they didn’t manage their API assets different from code – the API assets are the code itself.
Point 3: More API design feedback required
- More teams are embracing API-design-first, but a key benefit of that approach is the ability to get early feedback on the API design from consumers and other stakeholders. It’s important to engage consumers early and often to iterate on and improve the design. Feedback should not be restricted to just other API designers.
- But feedback from other stakeholders should also include feedback on the resource model described in business language. More teams should be documenting their resource models.
- Feedback from automated specification checks should include more than just style guide linting. Should include breaking change checks, text/prose checks and security checks.
Survey data: 32% of respondents said they get most of their API design feedback before the API is implemented (i.e. API design first) and 25% said they get most of their feedback after (i.e code first). Interestingly only 14% said they got feedback from consumers and stakeholders, suggesting that a lot of the feedback they are getting is internal to their teams. And in regard to the speed of the feedback, 25% stated they got fast feedback. Only 33% of respondents say they maintain a business language (not API specification) description of their resource model. Regarding automated checks, 7% of respondents have breaking change checks, 18% text linting checks and only 25% have security and privacy checks as part of their automated checks on the API specification designs.
Point 4: More clarity on value proposition and KPIs required
Clear product ownership of APIs is great, but that has to continue to product leadership of the API proposition. API product managers need to work on clarifying and communicating the value proposition, capabilities and KPIs of their APIs to teams. Need product leadership in building the right thing (not just building it right).
Survey data: 63% of respondents said some or all of their important APIs had recognised API product managers or had a central team responsible for managing the API as a product. But 50% where neither satisfied or dissatisfied, or were dissatisfied or very dissatisfied that enough research was being done by the product manager and business analysts to understand the user of the API, the value proposition and the KPIs. Only 37% agreed or strongly agreed that their APIs had clearly defined KPIs.