This article was originally published on 26 April 2023.
You can read the original article on the 6point6 website here.
Jason Beange, Managing Enterprise Architect at 6point6 shares practical steps on how organisations can address technical debt.
With technology advancing at an ever-faster rate, operating within defined IT budgets can become a real challenge and running on an ever-widening fiscal deficit to incorporate these advancements starts to become unsustainable. However, it is not only in financial terms that attention should be paid to debt accrual. On-going IT developments, enhancements and system amendments can cause technical debt to accrue over time.
If not managed well, technical debt can seriously affect everyone, impacting departmental spend, interrupting and disrupting service delivery, and even damaging reputations.
What is technical debt?
Technical Debt can most simply be understood as the gap between the technology solution that should ideally have been commissioned… versus what is really in operation.
Just as fiscal debt accrues interest, technical debt accrues risk. In a financial sense, the longer you hold debt, the more interest you accrue and the more it compounds. With technical debt the longer the risk is held, the greater the possibility of an incident.
Technical Debt is accrued in multiple scenarios, for example:
- when a decision is taken to deviate from an architectural plan
- when architectures (incl. applications/code) are matured at different speeds and with different degrees of attention to patching, upgrades and support
- when deviations are made to develop something at speed for reasons of business need and these deviations are not monitored sufficiently closely
- when there is an absence of desirable resilience, supportability, scalability or accessibility.
It is not necessarily the case that older technology solutions and infrastructure are where you are most likely to find technical debt. Even recently developed technology capabilities that were deployed at speed, or poorly managed implementations might fall victim to expedited delivery pressure resulting in an accrual of technical debt.
Why type of technical debt might you be holding?
There are many ways and many reasons for accruing debt. As a result, technical debt can manifest itself in a variety of ways.
- Service Level – perhaps shortcuts were taken in code or in product development for speed of deployment, with the long-forgotten intention of returning to address the problem “when there is more time. This is usually relatively straightforward to address if time is allocated
- Delivery – often the roadmap for upgrade or future product release is running behind a business need, so tactical deployments are undertaken. These appear to work and so remain in place as other priorities come to the fore
- Portfolio – service complexity often results in applications or products being delivered by multiple teams on different initiatives. This can result in a duplicated development with differing functionality, different development roadmaps and a contradictory and confusing user experience. Attending to technical debt is therefore far more than technology housekeeping. Addressing it will enable the business to adopt new technologies, respond to strategic or operational requests and innovate far more quickly and adaptably than if the debt is left unpaid.
What are the biggest challenges of repaying technical debt?
One of the biggest challenges of technical debt is that it can remain hidden, with systems operating normally right up until additional capacity is required, or until some other increased load or change is placed upon the infrastructure. At other times its impact is felt immediately by service users as front-end development takes place, without recognition of the development required in underlying infrastructure, supporting applications or code.
But challenges are not only technical. Problems with resolving technical debt can manifest themselves in a variety of ways as the below examples illustrate.
- The business doesn’t see the cost on a balance sheet or in day to day operations and therefore doesn’t recognise the value. Huge proportions of IT change budget can be absorbed just servicing the technical debt without reducing the deficit.
- The drive for improved user experience and new features overrides the desire to find and fix technical debt. The problem can be exacerbated by building more functionality and a richer user experience on top of existing applications with inherent technical debt.
- The demand and resource capacity imbalance that led to the debt accruing in the first place makes addressing the debt difficult. This is particularly true if the cost of the debt is not recognised and not understood by leadership outside of IT.
- Constructing a case for addressing debt which can be understood outside of the technical leadership group e.g. by Finance and departmental/business leaders.
- Concern over the knock-on implications of changes to workarounds and other tactical fixes that are working at the present moment.
- Difficulty and complexity in approaching portfolio wide technical debt or dependencies. Multiple departments, stakeholders and priorities complicate the decision-making landscape.
How 6point6 can help guide you through technical debt repayment
Although there are challenges to reducing technical debt it is possible to pay it down if you adopt a methodical and disciplined approach.
Education – start with creating a shared understanding of what technical debt is and why it is important. Engage your board and non-technical leaders by converting this to business-friendly impacts. For example, increased operational and technology costs, increased time to respond to business requirements, raised probability of service interruption and greater likelihood of reputational damage.
Documenting in common form – Classify and report on the technical debt in a common format. Identify the reason for the debt, the products or services affected by each instance of debt, the risks associated with it alongside the benefit of addressing it. This will help to better track and prioritise addressing the debt in a way that everyone can understand. Label the debt according to impact, probability and type e.g. regulatory, security, usability or performance.
Assigning responsibility and accountability – Addressing technical debt requires tenacity and discipline. Successful remediation depends on accountability and responsibility. Nominating a senior leader for steering a programme of technical debt repayment, brings a drive and sponsorship for technical debt remedy, ensuring that it doesn’t get ignored. Reporting on their progress should occur at the highest departmental or business boards.
Obtaining business buy-in – Attribute the costs of and track the risks of technical debt to the department or team that owns them. Enable business leaders to fully understand the risk and cost they are carrying if action is not taken. The strategic importance of the technical debt repayment needs to be stressed and linking remediation to strategic objectives such as risk management and cost reduction helps to ensure that it becomes a shared imperative and isn’t just seen as somebody else’s problem.
Budgeting for remediation – It is imperative that technical debt repayment is budgeted for, to avoid it being lost in the demands for change, improvement, expansion, and innovation that all technical teams face. Resources need to be allocated and ring fenced.
Governing the remediation process – Once you have a complete view of your technical debt you need to formalise the approach you will take to addressing it. Bring your leadership team together to agree common priorities, an approach and reporting.
Designing for future technical debt – By increasing awareness of technical debt across the organisation, you can have better informed, more strategically and culturally aligned conversations about technology investments and provisioning. Agreeing how you tolerate or remediate Technical Debt will help inform on-going conversations and decision making in the future.
Approaching strategically – Develop a strategic technical debt repayment plan and methodically work through the process of eliminating all that you can. Don’t miss the opportunity to rethink your estate as you undertake this work. For example, are there areas that could be retired entirely? Are there new ways of doing things that will avoid costly remediation? If your technical debt is particularly high, it may be time to consider a completely new approach to managing your environment. Whatever you decide to do, think about the value you’re releasing back into the business, not just the technology you’re fixing.
Monitoring – Having managed your existing technology debt and agreed plans to manage it down, it is imperative that you maintain transparency and open lines of communication across the business to ensure you continue to make progress. By identifying recurring themes that create technical debt, you can mitigate against its continued accrual. Maintain open communications by planning for and discussing technical debt regularly and involve your board in celebrating progress.
Acquiring technical debt is part of managing any large, complex and fast changing environment. As with fiscal debt, when it is well managed and controlled it can enable you to move more quickly, take opportunities and balance competing priorities. If it gets out of control, it can be incredibly difficult to reign in and repay.
Step one is always to gain clarity on the current position. If you’d like to speak with us about our approach to helping organisations identify, manage, and repay their technical debt then please do not hesitate to contact us.
Jason Beange, Managing Enterprise Architect
Expertise: Digital Transformation and Enterprise Architecture
From his early career in software development to his role specialising in the creation of architecture models at an enterprise level, Jason’s 20-year career brings a breadth and depth of experience across all architectural domains to envision and implement an effective strategy. Accompanied with an expert approach to stakeholder engagement at all levels, he can provide confidence that target architectures are well understood, along with the rationale for the prescribed approach.
