Where do you hold your Technical Debt catalogue?
Technical debt is the implied cost of additional rework caused by choosing an easy or limited solution now instead of using a better approach that would take longer or cost more. Technical debt is critical to being managed by an IT organisation and by the architecture disciplines. To focus the organisation on the long-term implications of design decisions. In the short term to prevent the organisation from accepting too much debt. Over the long term bring down the level of technical debt.
I’ve always used an IT Design Authority board made up of the different IT disciplines to identify debt and agree on design decisions. The debt may be rejected, along with the design decision and pushed back onto the project to resolve now. The debt may be accepted for a period of time, and action applied to the project to resolve in a second phase. The debt may be accepted, with a longer-term intention to resolve, but no plan in place to do so yet.
The catalogue of debt decisions often becomes an Excel document brought out for a dust-down every quarter at the Design Authority board meeting. The plan to resolve the debts will be part of the IT Roadmap planning process annually.
Is there a better way to hold this catalogue of debt? Could we make this part of our agile backlog, without losing visibility of items which may be on the list for years? How would manage the technical debt catalogue?
