Last week, while on client site, I used a term used by many Architects, a term which should in itself speak volumes and one that is often used to highlight possible future costs during the post design / deployment stages of the project life cycle. The term I refer to is “Technology Debt”

Technology Debt, like all other forms of debt, grows and incurs interest the longer it is left to linger.

So what is Technology Debt?

Most references on the web to Technical or technology Debt refer to future downstream issues associated with the creation, maintenance and upgrade of systems that are either incomplete, have an untested code base or have a poor customisation and upgrade of software packages. However not much reference is made to other associated Technology Debt i.e. connectivity, infrastructure, integration or even the results of technical challenges associated with organisational mergers and acquisitions.

Technology Debt, in essence, is the accumulation of intangible ICT debt associated with outstanding incomplete tasks such as testing, upgrades, bug fixes, patches etc. i.e. the accumulation of all works requiring completion or during the life of a system.

If this debt is not provisioned for or repaid it will continue to accumulate technical interest resulting in extra costs as and when functional requirements change exposing the organisation to a risk.

Two recent examples I’ve encountered on consultancy engagements i.e. real world examples are briefly highlighted  below, both are on the opposite ends of the cost spectrum but highlight creation and implications of technical debt;

• Oil & Gas Company with operations across the globe – delayed its upgrade of the central Document Management System (DMS).The DMS was customised to meet regional requirements and several bespoke code workarounds were created to accommodate legal requirements. This ongoing customisation of a COTs product and lack of any upgrades over several years resulted in the accumulation of technical debt, this materialised when the core product architecture was modified by the supplier and an upgrade forced upon the organisation by the supplier – the resulting cost in excess of $1.5 Million was for the organisation to upgrade the software and the associated developed workarounds.
• Solution Provider with 6500 users – neglected to upgrade both the Microsoft Server Software stack and Intel hardware for several years. This resulted in hardware which was no longer supported and a year of support life for the software stack. The crown jewels of the organisation i.e. the Active Directory services are deployed on Windows 2003 Operating system (O/S). The organisation decided to redeploy (lift & shift) the software onto new resilient hardware leaving the software as it is. Unfortunately the new hardware did not support 2003 (hardware drivers not available etc.). Two choices were presented to the client

1. Take the hit and upgrade all components now or
2. Install a virtualised 2012 server with 2003 virtualised containers allowing for no further software upgrades for a year – this would fix the immediate problem but will create ‘technical debt’ as when Windows Server 2003 goes out of support a full upgrade will be required

Why is Technical Debt Important?

Any debt in the technology eco system of an organisation can be compared to a tumour in the body, in that, unless managed and treated the cells multiply in an abnormal uncontrollable way and eventually affect overall demise of health and functionality of the body.

So the real question is not “why is technical debt important” but “should the organisation absorb the financial cost now, or live with the technology tumour and push the cost / effort to a future financial year”.

Unlike financial debt, technology debt has unique variables such as the skills time stamp which lapse over time e.g. programs written in COBOL on the mainframes in the late 90’s are still operational, however the skills to maintain the codebase is fast evaporating, as developers prefer to learn the latest Object Orientated languages

The skills time stamp is usually faced by larger banks with legacy systems from the 80’s & 90’s who in recent years have executed major transformation programmes to re-engineer their core systems.

Potential factors that result in technical debt.

There are many factors that can contribute to the creation or inheritance of technical debt, some of these are listed below;

1. Incomplete Business functional requirements
2. Incomplete code requiring refactoring i.e. restructuring so that the internal code base meets the desired behavioural outcome
3. Hard wired  variables e.g. static IP Addresses in code resulting in software inflexibility
4. Poor Documentation not only for production deployment but also at the design layer.
5. Infrastructure – All hardware has a shelf life which must be managed
6. Poor Enterprise Architecture e.g. the absence of Enterprise Master Data Management (MDM) which can result in silo based data repositories with replicated information.

All of the above can add to possible technical debt, however, there are many other factors which may create technical debt e.g. organisational mergers and acquisitions, which in most cases will create duplicated technology which post integration will result in some form of debt to either organisation (one for another blog!)

The goal of any analyst or architect must be to minimise, during the design stage, any impact and cost of future technology states.

Can you avoid technical debt?

There are many ways to reduce technology risk, a primary example is at the Enterprise level , where one should ensure that adopted products have ‘road maps’ in which minor and major changes together with the underlying infrastructure costs supporting these systems is aligned to future portfolios and budgets.

When designing a system the Architect must ensure that the design considers factors beyond the life of the system and ensure best practices are adopted in the construction and deployment of the system.

Architectural Governance must be in place to ensure that the technology landscape is managed and system best practices are followed both at the design and deployment stages,  with any architectural waivers managed to align to a future technology state.

However, the dynamic nature of business often results in system requirements evolving, which means the underlying technology will always require enhancing, modification or upgrade, hence the answer is probably not. If the answer is no, then the focus must move to the management of this debt as discussed below

How can you manage (repay) the debt

Taking control of Technology debt has 5 key phases which are highlighted below and these are

• Identification – This is the hardest phase as this requires detailed analysis of the technology estate and requires a detailed level of systems understanding
• Classification – the method an organisation adopts to classify the debt should align with the portfolio of project priority, a simple Red, Amber Green classification would not suffice.
• Mitigation – this should be run in parallel with phase one as the output of phase one should indicate initial mitigation tasks
• Fix – This is the actual project tasks that define the steps to remediate the debt
• Manage – this is the ongoing activities which should encapsulate all of the above

Technology debt is an area that is often over looked during the planning cycle and in many cases ‘creeps’ up without warning – Management must be an ongoing activity within the Enterprise function and contribute directly into the annual portfolio planning cycle.

Inherited debt must be managed, new debt must be avoided and unknown debt should be provisioned for!

 — oOo —