How about using this rubric to decide when to invest in updating legacy APIs to meet new governance models? Ive been working with an organisation on a two-track API governance model where new APIs are built to meet recently-introduced standards/style guides/best practices whereas existing/legacy APIs are updated by being defined using a specification file and added to the internal catalogue but otherwise left alone to avoid breaking changes, etc. any further thoughts on whether this rubric could be used to help decide when to invest in updating legacy APIs to the new standards and when to just leave them as they are?
definitely a possible help in deciding what investments in change will make sense.
Something missing from this Rubric (EASE) is any OKR/KPI values that justify the API in the first place. My rubric assumes that work (justifying the APIs existence -- the "work to be done") has already taken place.
Esp. when it comes to updating lagacy APIs, i think it is important to (re)visit the _reason_ for the API. I'd want a clear indication that the API is still delivering value before investing in additional changes.
also, it make sense to use OKR/KPI (including usage, traffic, ROI, etc.) when deciding whether to retain, update, or deprecate an API.
BTW - would love to learn more about your two-track governance model, too.
How about using this rubric to decide when to invest in updating legacy APIs to meet new governance models? Ive been working with an organisation on a two-track API governance model where new APIs are built to meet recently-introduced standards/style guides/best practices whereas existing/legacy APIs are updated by being defined using a specification file and added to the internal catalogue but otherwise left alone to avoid breaking changes, etc. any further thoughts on whether this rubric could be used to help decide when to invest in updating legacy APIs to the new standards and when to just leave them as they are?
definitely a possible help in deciding what investments in change will make sense.
Something missing from this Rubric (EASE) is any OKR/KPI values that justify the API in the first place. My rubric assumes that work (justifying the APIs existence -- the "work to be done") has already taken place.
Esp. when it comes to updating lagacy APIs, i think it is important to (re)visit the _reason_ for the API. I'd want a clear indication that the API is still delivering value before investing in additional changes.
also, it make sense to use OKR/KPI (including usage, traffic, ROI, etc.) when deciding whether to retain, update, or deprecate an API.
BTW - would love to learn more about your two-track governance model, too.