I’m going to suggest something controversial here: the real solution to tech debt comes from within, not from without. But wait, what about the technology vendors, cloud vendors, system integrators and consultants who help you with tech debt? There’s a common theme:
- Technology vendors can’t ‘solve’ your tech debt, they can only mitigate existing instances of it.
- Cloud vendors can’t ‘solve’ your tech debt, they can only mitigate existing instances of it.
- System integrators can’t ‘solve’ your tech debt, they can only mitigate existing instances of it.
- Consultants can’t ‘solve’ your tech debt, they can only mitigate existing instances of it.
The thrust is this: there is a significant difference between addressing tech debt that has already occurred within a business, and preventing that tech debt from occurring in the first place. Anyone can help you with the former. Only one company can help you with the latter.
And that company is your own company.
The only way of achieving it is to embrace a whole service lifecycle.
You see, tech debt arises from one thing, and one thing only: a service goes into production without a view on when the service will be modernised, or when the service will be decommissioned. And how much that will cost.
Not if. When.
Nothing lasts forever, and IT proves this on a daily basis. That customer relationship management system you’ve just migrated to, or deployed? It’ll eventually disappear. That order tracking system you’ve just migrated to, or deployed? It’ll eventually disappear. That HR management system you’ve just migrated to, or deployed? It’ll eventually disappear. That operating system you’ve just finished upgrading your platforms to? It’ll eventually disappear. That email platform you’ve just finished migrating to? It’ll eventually disappear.
Not if. When.
Tech debt arises from exactly one situation: you’ve got some business function that relies on some technology and it’s deemed too expensive to modernise or replace that technology.
And why is it too expensive to modernise or replace that technology? When it was deployed, it wasn’t deployed with the simple vision that one day it will be undeployed.
Going into a deployment or implementation without that plan means you’re planning to have tech debt. And not just plan, but design in that undeployment as part of the architecture of the platform or system(s) providing that service. Planning isn’t just about acknowledging that you’ll one day need to replace that system – it’s also:
- Placing end-of-life (EOL) guardrails on the service:
- How long does the business intend to actively support it?
- What are the likely trigger points for replacing the service?
- What are the the expected run-costs over time, vs revenue the service will generate over the same time? Where do they cross over?
- What will be the evaluation process for replacing the service?
- Who (role) will be responsible for signing off on the evaluation process?
- Who (role) will be responsible for signing off on keeping the service (i.e., delaying the EOL process)?
- Who (role) will be responsible for signing off on replacing the service (i.e., after the evaluation process has been completed)?
- Determining how you’ll get the data out of the system
- Associating a cost for getting the data out
- Factoring that cost into the cost of the project
- Providing a view of long-term technical strategies that may represent the next-generation approach (after this one).
Does this mean you must have the replacements planned and costed in order to deploy a new service? No – sometimes that isn’t a possibility. And that’s OK – with one caveat. Someone needs to sign off against that risk. Because that’s exactly what it is: a risk. There is a definite risk in deploying a service or new technology associated with a service without some sort of exit or EOL plan, and the business should acknowledge that risk.
If you’ve got existing tech debt, you still have to find ways to resolve it, regardless of whether that’s an internal project, or to look for external help. That doesn’t change. Eliminating tech debt — truly eliminating it — starts only with the projects or platforms you haven’t yet deployed.