In this post I explore the concept of Technology or Technical Debt and how best to manage it, using my experience in the wealth management sector. I’ll also provide Solitaire Consulting’s advice on how to deal with technology debt and how best to minimise it.
In its purest form Technical Debt is a concept in software development that reflects the potential cost of additional rework caused by choosing an easy (limited) solution now, instead of using a better approach that would take longer. However, in practical terms the concept of technology debt often expands to include debt arising from failure to maintain and upgrade both infrastructure and line of business software applications.
As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes. Unaddressed technical debt increases over time and can make it increasingly difficult to address. Similar to monetary debt, technical debt is not always a bad thing, and sometimes can be beneficial to move projects forward or quickly get a new project or business to market.
Common Causes of Technical Debt
Common causes of technical debt include:
- Poor technological leadership, where poorly thought out commands are handed down the chain of command.
- Failure to upgrade supported systems to latest release levels, results in a restricted ability to take advantage of new functionality.
- Last minute specification changes, these have potential to percolate throughout a project but no time or budget to see them through with documentation and checks.
- Insufficient up-front definition, where requirements are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.
- Business pressures, where the business considers getting something released sooner before the necessary changes are complete, builds up technical debt comprising those uncompleted changes.
- Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.
- Tightly-coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
- Lack of a test suite, which encourages quick and potentially risky bug fixes.
- Lack of documentation, where code is created without supporting documentation. The work to create documentation represents debt.
- Lack of collaboration, where knowledge isn’t shared around the organization and business efficiency suffers, or junior developers are not properly mentored.
- Parallel development on multiple branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.
- Lack of knowledge, when the developer doesn’t know how to write efficient code.
- Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.
Impact of unmanaged Technical Debt
If not properly addressed, technical debt will result in increased complexity as more of your IT budget goes to support the complexity in the IT environment. Consequently less resources are available to spend on improvements and projects. In other words your ability to Change the Business (CTB) is compromised by the disproportionate cost of Running the Business (RTB).
This is shown in the diagram below where, over time, a similar level of resource available to the IT team will be diverted to RTB rather than CTB.
Examples of Technical Debt
In this section I am going to take two examples in the Trust & Corporate Services industry where I have come across situations of where Technical Debt has got too high and impacted on the businesses ability to implement new solutions.
Example 1: In-house software development
This business had implemented a standard administration & accounting system from a niche software vendor. Over time their requirements changed but the vendor was not willing to develop their product in the direction the client wanted to go. Rather than select a new product, the client negotiated with the software vendor to purchase the source code and take responsibility for their own software development.
After five years or so the impact of changes to the regulatory environment meant that the internal development team were spending all their time dealing with mandatory software changes and the development backlog had got out of hand. Web-based, quick to deploy standalone solutions were developed in an effort to satisfy the business demand for automation and functional improvements. This increased the complexity of the IT landscape and further exacerbated the problems with the core administration system.
The solution was to initiate a major project to replace the in-house systems with a configurable off the shelf system. This required significant investment to repay the technical debt and transform both the business and the IT team.
Example 2: Outsourced infrastructure
This business had a long-standing successful relationship with an IT managed service provider. A new highly-resilient network was implemented which was designed to future proof the business. Before the project was completed, the business acquired a number of other businesses and the decision was taken to delay the network project whilst the acquisitions were integrated into the business. The new network eventually went live 2 years later by which time most infrastructure components needed operating system upgrades and service packs.
The technical debt within the system resulted in significant risk of components failing when applying critical security patches. Servers crashing not only impacted the business but resulted in significant IT time being diverted away from CTB projects. Escalating issues to vendors often required upgrades to latest service packs before the vendor would support or acknowledge the issues.
The business had delegated too much responsibility to their managed service provider and hadn’t appreciated the technical debt they were carrying. The solution was to implement a new managed service contract which adequately addressed the need to reduce and manage technical debt, resulting in a more reliable service for end-users.
Managing Technical Debt
Note the heading above is ‘managing’ technical debt, rather than eliminating it completely. Although I made a comparison with financial debt above, unlike financial debt, technical debt cannot be eliminated completely. As soon as you have implemented a new technology or system you will have a backlog. We just need to be able to manage this better.
Here are my 4 top tips for managing Technical Debt:
1. Be Aware
Before you can control anything you need to be aware. If you hadn’t come across the concept of Technical Debt before you read this article you are part way there. However, there is a lot more to know than I can cover in this introduction to the subject.
Knowing your own environment is important as the level of technical debt you should be carrying will be different to other organisations with different systems.
Also think about the proportion of your annual IT budget you spend on RTB vs CTB. A good indicator is that you should be spending no more that 60% – 80% of your IT budget on RTB, with 20% – 40% being maintained for change and transformation activities. This will obviously vary depending on the type of business and investment cycle.
2. Keep up to date
It is good practice to keep as up to date as possible with software upgrades and service packs. Not only does this mean your business is better able to take advantage of new functionality (which you have probably already paid for as part of your maintenance and support plan) but each upgrade represents a smaller incremental change in the code base. This results in a reduced risk to the business and should involve less testing.
Keeping up to date also reduces the risk that an operating system security patch will result in unexpected system behaviour. If you do suffer an issue following patching, you are more likely to get vendor support if you are on the latest version of software.
3. Build a knowledge base
It is very easy to implement changes without properly documenting them. We have all done it., but we know it is bad practice. A documented system will be easier to maintain, so make sure you embed a culture of always completing the documentation as part of the change process. In fact, I’d go as far as advocating that no change should be made to a production system unless evidence has been provided of the documentation.
It goes without saying that the documentation must be accessible. This means it needs to be made available to everyone with responsibility for maintaining and supporting the systems, in a readily searchable format.
4. Cloud first
My final tip is to always consider cloud based solutions before implementing on-premise. With any cloud based solution you have immediately taken the worry of maintaining infrastructure out of the technical debt equation. If you are using software-as-a-service solutions then the upgrades of your software are also largely taken care of by your vendor. This leaves the IT team with a much reduced IT footprint and will therefore reduce opportunities for technical debt to become a problem.
Conclusions
Hopefully this article has given you more of an appreciation of the causes of Technical Debt and what you can do to manage it.
If you are worried about the potential for Technical Debt in your business or have concerns about how it is being managed then please get in touch. Our team are coming across this all the time and are helping all sizes of business get to grips with the problem by helping them put in place processes and procedures to mitigate the risks of technical debt. Get in touch using the form below or the link at the top of the page.
