What is Technical Debt and where does it live?
Wikipedia defines technical debt as: “the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” A lot of technical debt can be accumulated for unintended reasons. For example, a feature in an application may have been coded in a way that met the original business requirements, but the business has changed and the original implementation is no longer aligned. If technical debt is not addressed, it will accumulate over time and make code changes more and more difficult to implement and test.
A recent article in Forbes noted that the average organization wastes between 23% – 42% of their development time on technical debt. This can balloon into millions of dollars for large enterprises. In fact, one bank in the study estimates their technical debt to cost them over $2 billion.
Most of the technical debt in operational software applications arises from two main sources:
- Changes to user experience and workflow
- Aging technology that requires applications to be modernized or replaced
Changes to user experience and workflow
Production software applications typically have few release cycles per year because of the associated costs and risks of rolling out a change. This means that even if the user experience change is simple, it can be months before it is made and released. Common user experience changes include:
- correcting typos
- adding / removing fields and updating the database
- changing whether fields are visible/editable based on the state of the record/role of the user/business rule
Individually these changes may be relatively simple, but the costs/risks of packaging them up into a release means that the business perceives IT to be slow and unwieldy. Sometimes a simple change can be a lot of effort because considerable amounts of the code need to be refactored and requires extensive regression testing.
Many of the changes that the business needs to make to workflow automation may require changes in multiple applications which slows things down even further.
Aging technology means that applications need to be modernized or replaced
Applications implement functionality by hard-coding against a specific technology. Technology ages and eventually goes out of support, reaching the end of life, and has to be replaced. A good example is that Microsoft is no longer developing the .NET Framework – so all of the applications built on this technology will need to be modernized/replaced in coming years. When a technology hits end-of-life then any applications built on that technology need to be modernized/replaced. A lot of technical debt is incurred by the need to support legacy applications and ultimately replace them.
So how can we permanently reduce technical debt?
A good place to start is to virtualize the user experience functionality (UX and CRUD) instead of hard-coding it into our applications.
The vast majority of the code in our business applications moves data from a database (CRUD) and renders it on a screen for a user (UX). All of this related code can be replaced by a couple of framework services that use configuration data to virtualize the user experience functionality.
- Data is no longer encapsulated by individual applications, it is shared by a framework data agnostic storage service – CRUD.
- User experience is no longer hard-code by an application, it is rendered in real-time by a dynamic page builder on any device – UX.
If we virtualize the UX and CRUD code then making changes to the user experience is simply a matter of changing and publishing an updated configuration file. This means that we no longer need to do an application release, because there isn’t an application to release! We can make changes to the user experience as and when the business needs them.
If we move the workflow automation to microservices and invoke them from our virtualized UX and CRUD functionality, then we only need to build and test the specific functionality we need to create/modify. This eliminates a lot of the costs and risks associated with building workflow into applications and means that we can release new or modified functionality much more frequently.
Best of all, if we virtualize the UX and CRUD and eliminate the application, then we have also eliminated the dependency on a specific technology. This means that our functionality is ever-green.
Virtualizing the UX and CRUD functionality permanently eliminates many of the causes of technical debt and enables IT to be more responsive to rapidly changing business needs.
Like to learn more?
If you would like to schedule a virtual meeting or learn more about trellispark, please contact us and provide a brief description of your interest. Or simply drop us an email at info@greatideaz.com.