Technical Debt or Risk Management, which is it? I am wrestling with the definition of what we want to call Technical Debt, but i think it is more about Risk Management for us. I'm not talking about software development, but end to end designs that don't conform to emerging standards. For example, old data stores that we are trying to get decommissioned getting used in new designs. It might be easier to reuse the old data store but its not strategic. This is not so much debt (no one seems to worry about that) but more of a risk I think. The risk being, data quality, business rules could be out of date, data getting out of sync. Does that make sense. I wonder if anyone else sees it the same or has the same process in their organisation. Any tips would be great.
Sort by:
Tech debts are technical/functional gaps, related to business or (software) product development and operations (if ML model embedded to solution, also model related in my mind). They will affect future development and client usage.
Risk management is about how to handling risk (tech risk, or project risk, priority risk, etc.) in your project, it related to project management.
All technical (and application/ architectural/ functional) debt is a risk. Risks must be managed.
> Technical Debt refers to the future cost incurred due to choosing an easy or quick solution now instead of a better approach that would take longer. This often happens in software development when shortcuts are taken to meet deadlines, leading to designs/code/implementations that is harder to maintain or extend in the future. The same counts for “architectural debt” etc.
> However Risk Management involves identifying, assessing, and prioritizing risks followed by coordinated efforts to minimize, monitor, and control the probability or impact of unfortunate events. It is a broader concept that applies to various aspects of a project or organization, not just technical aspects.
For your specific case: reuse of a Configuration Item that the organisation has decided (Architectural Decision) to be decommissioned would need a waiver. (Is very often considered an anti pattern). Yes: "Reuse before buy, before make. But: No reuse of components that have the formal "legacy" status. Otherwise the organisation will stuck with legacy components and be in a high Risk.
My organization gets confused by the definitions as well. I see Technical debt more as an implementation of something that you know later you'll need to refactor but was done despite to expedite a service. While Risk Management is understanding the possible consequences of a certain action but moving forward regardless due to necessity. If this makes any sense.
Where my organization gets confused is they associate Technical Debt with resource allocation. If we do this thing we have to maintain it. Well yeah, that's our job.
What do I know ;)
We have divided IT debt into 3 main categories.
1 – “Technical debt” includes a) Physical devices that need to be replaced (e.g. too old, possibly no longer supported by the vendor) and b) Software components whose version is too old and will soon no longer be maintained by the publisher, but are still in the internally agreed catalogue.
2 – “Application debt” includes a) Applications that should have been migrated to a newer version of software components, but the business prioritised functional development. b) Applications that need decommissioning because they are no longer in use (e.g. an old version that has been replaced), but technical teams haven’t done it yet, and c) Applications designed and developed in-house for functions that could be handled by off-the-shelf software.
3 – "Functional debt", which is entirely the responsibility of the business; for example, a piece of software that is no longer used because a newer application now covers its functionality, but which is part of a larger application and the code still exists.
The words "Technical Debt" are misleading I feel, the phrase "Legacy Debt" is more precise as it covers all issues that cause indebtedness. "Technical Debt" conjures images of technology only - and that is a subset of the wider debt that can result from other things such as lack of investment, poor processes etc.
So ultimately each business entity defines "Tech Debt" differently and frequently become confused by the term - so for me anyway "Legacy Debt" gives that broader definition that then encompasses all debt that can impact the business.