How healthcare organizations can ‘pay off’ technical debt
In the rush to get systems up and running, cutting corners may be a tradeoff that all HIT executives will have to eventually pay back.
Technical Debt—also known as Design Debt or Code Debt—is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Most healthcare organizations 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. Often, these issues prevent healthcare organizations from upgrading or replacing systems promptly and cost time, money and resources when leadership does decide to upgrade or replace systems.
The accrual over time of all of these technical issues is called technical debt. 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, healthcare organizations can reduce the burden of their technical debt and use it to their benefit.
Ward Cunningham, 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 to 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:
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 occurs 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 organization’s technical infrastructure. This principal represents the backlog of work required for the organization 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 manifests itself in healthcare organizations in myriad ways. Some of the most common healthcare examples are 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 healthcare organization 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 organization can reap significant benefits from actively managing its technical debt portfolio. To do this, an organization 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:
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 healthcare organization’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. Healthcare organizations 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, healthcare organizations must look at how new debt is created. Not all technical debt can or should be avoided. It can be prudent to accept certain 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.
Healthcare organizations that tackle technical debt can optimize their effort if they follow a few guiding principles:
Like financial debt, technical debt is not a pleasant issue to grapple with and resolve. It is, however, a critically important issue that ignored can lead to harsh 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 healthcare organizations to minimize technical debt’s negative impacts with a little proactive planning and follow-through.
Most healthcare organizations 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. Often, these issues prevent healthcare organizations from upgrading or replacing systems promptly and cost time, money and resources when leadership does decide to upgrade or replace systems.
The accrual over time of all of these technical issues is called technical debt. 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, healthcare organizations can reduce the burden of their technical debt and use it to their benefit.
Ward Cunningham, 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 to 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 occurs 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 organization’s technical infrastructure. This principal represents the backlog of work required for the organization 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 manifests itself in healthcare organizations in myriad ways. Some of the most common healthcare examples are 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 healthcare organization 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 organization can reap significant benefits from actively managing its technical debt portfolio. To do this, an organization 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” for technical debt.
- Using the catalog as a backlog, pay-down of technical debt by funneling items of “principal” into the organization’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 healthcare organization’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. Healthcare organizations 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, healthcare organizations must look at how new debt is created. Not all technical debt can or should be avoided. It can be prudent to accept certain 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.
Healthcare organizations 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 ignored can lead to harsh 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 healthcare organizations to minimize technical debt’s negative impacts with a little proactive planning and follow-through.
More for you
Loading data for hdm_tax_topic #better-outcomes...