3 Comments

Yesterday I shared a brief explanation of what a service blueprint is to an API dev team. They are surrounded by technical architecture schemes that clarify the "how", but we need to map the "what" and the "why" too. The language of on the side of product/business is not aligned to the language of the dev team and this is causing a lack of clarity.

We are in the process of hunting down how many existing, client-facing "productivised" digital services are out there (52, and probably counting...) in order to design the best API architecture, treating the API platform itself as a product (also, we have of course to deal with legacy systems).

We really need something like a service blueprint to get through it.

Expand full comment