We’ve developed an API-as-Product Assessment Framework that we’re using to assess public APIs. We’re sharing this framework because you will likely find it to be a useful tool for understanding your own API as a product or set of products. The API-as-Product Assessment Framework has evolved through a combination of years of experience working with others’ APIs and developing APIs ourselves as well as a , and more in-depth analysis of a handful of APIs (e.g. and ). It looks at an API from multiple perspectives, like through the lens of product management, and not just the technical implementation. recent high-level market scan Xero the bank NAB This framework is purposefully trying to move beyond slideware from vendors to a practical understanding of what makes a great API, grounded in real-world data. It’s also trying to bridge the gap between technical best practice and product best practice to create a holistic view of your API. The framework has been designed so that you can take it and assess how great your organisation’s API is (or not) in a more thoughtful and considered manner. Overview The API-as-Product Assessment Framework is broken down into the following key areas: - the ease and speed with which you can get started using the API Onboarding - the information available to help you understand the API Documentation - the technical design of the API itself API Design - how the API fits with product disciplines API as Product - how users are engaged together around the API and documentation Community - anything that doesn’t fit into the above, or its own key area, but is deemed important. Other Key Area 1: Onboarding Onboarding is usually the first area that any user of your API will touch. They will need to get onboarded to access documentation, run test queries and begin developing against your services. At best, a great onboarding process can be a source of growth for an API and a business. In many cases, it isn’t this extreme, but a smooth onboarding will assist with productivity and reduce support costs. At worst, a poor onboarding experience will mean developers choose other providers or create friction in your relationship with them. Registration This is the part of onboarding where you get an account and/or access. Getting Started Help The guidance and assistance provided to make first time use straightforward. Getting to Your First Query This is a measure of how quickly a developer can run their first query. Time from registration has been included because for some APIs it is the registration process that requires background checks and other activities. Getting to Production This is a measure of how quickly a developer can get a query to the API running against the APIs production data/systems. Key Area 2: Documentation After someone has onboarded, they are going to need to start working with your API, which is where the documentation comes in. Strong documentation will mean little to no human interaction is required. Poor documentation will result in high support costs and developer frustration. Key Area 3: API Design This key area looks at the technical implementation and design of the API itself. Key Area 4: As a Product Great APIs are developed as products. Key Area 5: Community Great APIs have engaged communities. Engaged communities assist each other with solutions and help drive the API forward in the best way possible. Community members will often become evangelists that help promote the API to others. Key Area 6: Other This area is reserved for capturing any other information that is relevant while assessing that hasn’t been captured elsewhere. Over time, as we develop this assessment framework, we expect to merge common-themes from this area into the other key areas or new key areas. In doing the assessments we have done so far, this section has been a useful placeholder. Notes on Using the Framework Why are some evaluations able to be left as blank? When doing the assessment of some criteria (like time to register) the evaluator can leave it as blank. Leaving as blank might be necessary if the criteria is too hard to evaluate in a commercially reasonable timeframe. Also published at https://terem.tech/blog/the-37-dimension-api-as-product-assessment-framework/

2022 - HackerNoon Contributor of the Year - Agile

2022 - HackerNoon Contributor of the Year - Agile Software Development

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

The 37 Dimensions of the API-as-Product Assessment Framework

Too Long; Didn't Read

Company Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The 37 Dimensions of the API-as-Product Assessment Framework

Too Long; Didn't Read

Company Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES