The Benefits of Actively Managing Technical Debt

Most insurers have a business technology ecosystem that has grown and advanced over years and decades. These are combinations of older and newer systems, legacy and modern data stores, and integration points and processes that have gotten more complex over time. The majority of insurers accrue a substantial amount of technical debt as their systems evolve. For much of human history, debt has generally been considered as something best avoided. But modern times have brought the realization that borrowing can be a beneficial financial tool. So it is with technical debt. By understanding what technical debt is, how it arises, and how to manage it, insurers can reduce the burden of their technical debt and use it to their benefit.

Let’s start with some definitions. Some will use the term “technical debt” to refer to any negative aspect of their technical infrastructure, but Ward Cunningham had a more useful analogy in mind when he coined the term “technical debt” in the early 1990s. Cunningham, who is considered the creator of the “wiki” and was an early contributor to object-oriented and agile programming, defined technical debt as the amount of beneficial work avoided or deferred to deliver a business solution earlier or reduce the cost of the system.

In the case of technical debt, the “principal” becomes the amount of work left undone, and the “interest” is the additional work caused over time by this unfinished work. Among the most common sources of technical debt are:

• “Quick and dirty” coding is created instead of modular, structured code
• Applications use ad-hoc data sources or create new and poorly structured sources, rather than taking the time to implement new, well-designed sources
• Functionality is “bolted on” to existing applications without rewriting them
• Functionality is deployed using non-standard technologies
• Documentation is not created to spend more time on coding
• Tests are not created or run to spend more time on coding
• Deferred technology and software version upgrades

Technical debt can be acquired in either a reckless or prudent manner. Reckless technical debt occurs when design or coding shortcuts are taken inadvertently, most often through inexperience or laziness. Prudent technical debt happens when beneficial work is deferred deliberately for a known benefit, such as omitting a less-useful feature or implementing a workable but less elegant solution to deliver a solution earlier.

Whether reckless or prudent, each instance of technical debt created during development and maintenance adds to a virtual balance sheet of principal maintained within the insurers’ technical infrastructure. This principal represents the backlog of work required for the insurer to get full functionality and value from its systems. But often more significant is the interest that the technical debt accrues from its inception. This interest shows itself in various ways: systems and applications that are expensive (budget and resources) to maintain, difficulty implementing and integrating newer systems, increased security exposures and risks, and an overall increase in the risk of system failures. This interest is paid daily over many years until the technical debt is retired by implementing the originally deferred functionality.

So how can a company eliminate technical debt? The bad news is that for all practical purposes, it can’t. The existing balance of technical debt will typically be financially prohibitive to remediate as a project. And the normal course of IT work will introduce new debt continuously. But the good news is that an insurer can reap significant benefits from actively managing its technical debt portfolio. To do this, an insurer must do two things: address the current balance of technical debt, and improve processes to minimize the accrual of new technical debt.

To address current technical debt, key activities include:

• Creating a technical debt catalog to identify areas of debt and ranking their impact on existing processes and practices. This is the “balance sheet” of technical debt.
• Using the catalog as a backlog, pay-down of technical debt by funneling items of “principal” into the company’s existing software delivery streams.
• Reviewing and updating the catalog regularly.

The technical debt catalog can be implemented without any special tools—a table in a text document or spreadsheet makes a satisfactory catalog and can be maintained with little overhead. To populate the catalog initially, gather input from all areas of IT—not just development areas—about where they see friction within the technical infrastructure. Eliminate problems caused by broken processes or human error, leaving those that are truly technical debt. Assign an owner to each item and determine a priority or severity for it. Don’t spend too much time trying to make the initial list complete or over-documenting each case.

The technical debt catalog by itself won’t bring value unless it’s incorporated into the company’s software development and delivery processes. To do this, it’s necessary to assign at least a rough size and complexity to each item in the catalog to determine the best avenue to remedy it.

Items of debt that require a small amount of work and are isolated to a single system can typically be merged into regular maintenance and update delivery cycle for that system. Each system support group should mine the technical debt catalog for items that can be placed into their system enhancement backlog, where they can be prioritized alongside business enhancements and regulatory changes. These debt items are then removed from the catalog as they are addressed.

Items of debt too large to address through regular system enhancement processes should be addressed within projects. Debt items can sometimes be added to current or planned projects if they fit naturally into the project scope and don’t have an excessive impact on timeline or budget. However, if it can’t be broken down into smaller pieces some items of technical debt will require a dedicated project to address. Large items of technical debt like this are often the hardest to retire. Companies are reluctant to allocate precious project resources to what is seen as “clean up” work. But a valid business case can be made by highlighting the real cost of the “interest payments” required by a large piece of technical debt.

In addition to tackling existing technical debt, a company must look at how new debt is created. Not all technical debt can or should be avoided. It can be prudent to accept specific amounts of technical debt when time-to-market takes priority over completeness. But this decision should be made with full consideration of the interest the technical debt is likely to accrue. Reckless technical debt is avoidable, however, and can be reduced through developer training and quality control processes such as architectural reviews.

Companies that tackle technical debt can optimize their effort if they follow a few guiding principles:

• Keep the debt catalog simple to understand and maintain. Aside from giving each item a name, description and rough size, it’s typically sufficient to assign a responsible individual or department, along with the date the item was added to the list.
• Technical debt should not be viewed as the problem of one particular group or department – it needs to be a shared responsibility between IT and business areas.
• Assign responsibility for the catalog to a team that participates in the software and project initiation processes. An Enterprise Architecture team is often a good choice.
• Review and update the list no less than twice a year.
• Don’t restrict the technical debt catalog to software items only. Technical debt can accrue in infrastructure as well, for example where failover or backup capabilities are omitted from initial installation.
• Above all, technical debt cannot be delegated to “when we have spare time” priority – there is never spare time!

Like financial debt, technical debt is not a pleasant issue to grapple with and resolve. It is, however, a critically important issue that if ignored can lead to unhappy consequences like inefficient systems, costly and laborious maintenance cycles, and in, the worst case scenarios, the inability to migrate to modern system platforms. That said, it is possible for insurers to minimize technical debt’s negative impacts with a little proactive planning and follow-through.

Originally published by 
Insurance-Canada.ca
Read the original article here.