How Federal Agencies Can Identify and Deal with Technical Debt
In the early stages of the coronavirus pandemic, many federal agencies quickly deployed endpoint and remote collaboration solutions to meet the needs of the day.
While these solutions were essential for enabling officials to work from home and maintain their missions, they were deployed with little forethought due to the demands of the pandemic.
As the situation evolves and agencies envision a hybrid working future, agency and IT leaders need to think long-term about their technology investments. Now is the time to tackle technical debt – the cost and investment required to upgrade existing systems to meet today’s demands – and try to get out of it.
RELATED: How is the Technological Modernization Fund developing?
Understanding where technical debt comes from
The General Services Administration warned agencies against technical debt as early as 2015, noting that it refers to the “hidden” costs associated with the architecture and code base of a system (for example, requirements changes addressed with a “quick fix”, bugs deferred in favor of new developments, design weaknesses or aging third-party libraries). Technical debt, notes the GSA, can “make software resilient and expensive to modify, and prone to failures, intermittent failures and even security breaches.”
Technical debt is a somewhat controversial topic, and IT managers and software developers have different views on its origin, origin and causes. Yet it is essential that agencies respond to them.
Often, IT managers don’t think about the long-term costs of deploying new software, for example. The leaders want to solve the problems of the mission areas of their agencies. However, if they are stuck in firefighting mode, they cannot take a more methodical approach and ensure that they are on the right track with a clear, long term strategy for maintenance and upgrading. software update.
For example, if agencies have a mandate to move applications to the cloud, executives can choose to simply migrate everything without optimizing or modifying much. This can lead to problems later, especially from a security point of view. In addition to applications, agencies can end up with lax security protocols, such as granting access to too many administrators or not having a policy of deleting user accounts.
Software developer and author Martin Fowler created a matrix to determine how technical debt is created, including whether debt is reckless or prudent, and whether it is deliberate or unintentional. These facts can help agencies deal with debt in the most productive way.
How agencies can best identify technical debt
The best way to think about technical debt is to treat it the same way as financial debt. There is no simple answer to determining whether it is good or bad. Instead, agencies can try to determine what are some of the indicators of their origin. This can help ensure that agencies monitor and plan better.
This applies not only to software, but also to other computer elements. For example, imagine an agency is setting up a new data center. The agency’s IT managers may be planning electricity, heating, and air conditioning, but may not know they have to drill a wall to access uninterruptible power. They also may not know that the wall they placed the equipment next to cannot be pierced.
Take the example of an IT manager at an agency who just got approval from agency management to take a zero-trust approach to their networking. The IT manager got 2% more in his budget to do so, but didn’t factor in the cost of maintaining new technology or systems and how they might develop over time.
The IEEE document “Towards an ontology of terms on technical debt” identifies 13 types of technical debt and a set of key indicators for each, including debts related to architecture, code, documentation, infrastructure and requirements.
It is essential to identify technical debt so that it can be dealt with. However, this can only really happen if IT managers stop acting as firefighters and think strategically about their investments.
TO EXPLORE: What will be the long-term effects of the responses to the pandemic on federal IT?
Addressing government technical debt
Often, to effectively deal with technical debt, IT managers need to triage. CIOs and their teams should interview mission units and program managers to identify the 10 most critical applications or systems they operate. Then ask a simple yes or no question: can I remove this?
If it’s a mission-critical, modern app like Office 365, the answer is probably no. If this is a less critical application, the answer could be yes. For those the agency is going to withdraw, the next question is whether the agency will actually withdraw or refactor it.
The biggest step IT managers can take is to get out of firefighting mode and become more proactive than reactive.
IT managers in one agency can’t drag their feet to settle technical debt in the hopes that other agencies will figure things out and take over. If IT leaders across government don’t work together to fix the problem, common issues will be ignored and best practices will not be identified. Now is the time to start paying down technical debt and start thinking strategically.
This article is part of FedTechCapITal blog series. Please join the discussion on Twitter using the #FedIT hashtag.