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.
We will see, we just started working together (we are at sprint 2...). Next week I'm going to nudge them a bit about it.
I'm worried about the seemingly staggering number of client-facing services (52), they've already spotted a series of serious issues (e.g. some service-level features have been hard-coded into store procedures, so in order to "bring back" those to the level of API services they're going to be forced to reverse engineer them).
I know it doesn't sound sexy as making UX choices, but it's basically feature creep, only at the architectural level: hidden but extremely costly, especially on these kind of services (let's just say that if something doesn't work, people don't get their money...).
I wish we could use the service blueprint to create independent vertical slices so that the team can focus the effort on a single service (or sub-service) for each iteration.
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.
Damn. Sounds tough. Thanks for sharing.
How has the service blueprint landed with the dev team? Is it something they are helping them? Or is it not landing as well as you’d like?
We will see, we just started working together (we are at sprint 2...). Next week I'm going to nudge them a bit about it.
I'm worried about the seemingly staggering number of client-facing services (52), they've already spotted a series of serious issues (e.g. some service-level features have been hard-coded into store procedures, so in order to "bring back" those to the level of API services they're going to be forced to reverse engineer them).
I know it doesn't sound sexy as making UX choices, but it's basically feature creep, only at the architectural level: hidden but extremely costly, especially on these kind of services (let's just say that if something doesn't work, people don't get their money...).
I wish we could use the service blueprint to create independent vertical slices so that the team can focus the effort on a single service (or sub-service) for each iteration.