What Is Technical Debt?
Technical debt can be measured in many ways. “There’s the need for modernization or replacement of IT capabilities or IT systems,” National Association of Counties CIO Rita Reynolds says of technical debt.
“State and local governments accumulate debt when they’re not able to regularly invest in major maintenance of their IT capabilities. Maybe the application or software is not supported any longer, but you keep running it because it works,” she says.
Government can build up such debt in a number of ways. It happens “when you quickly develop something, or you develop something to fix a hole, or you develop technology, but it might not meet all of the specifications,” says Afua Bruce, adjunct professor at Carnegie Mellon University’s Heinz College.
“Even though it may work to stop a gap, it may work in the moment, at some point you will have to invest time to fix it or to develop something new. That’s putting off for tomorrow what you didn’t do today,” she says.
Debt ultimately translates into budget effects. “The need for additional resources — individuals, staffing, consulting — that’s also going to cost money,” Reynolds says. “It can also be strategic debt: Am I growing my knowledge and making good strategic decisions? You could have retirements, where the individual who knows how to operate or update these the older technologies is no longer is available.”
Do Shared Databases Pose Technical Debt Challenges?
Government has turned to shared databases as a means to enhance collaboration and improve citizen services. But this strategy can also add to the load of technical debt. “There’s potential for any type of tool or solution, or database in this case, to create technical debt,” Bruce says.
At the state and local government level, “people really want to get it right,” she says. “But because of time pressure or budget constraints, or the perceived importance of a specific shared database, shortcuts can be taken. Instead of spending all the time needed to accurately design what that shared database might look like, having enough time to define all of the fields, you start with some minimum viable product. That’s where you get the technical debt.”
Operational issues around the use of shared databases can potentially compound the debt problem. “There are questions about who owns which data within those shared databases, who is going to maintain the database overall and also the components of it,” Reynolds says.
Say you have a unified case management system in the criminal justice sector. “You might not have a staff on board or the resources, like consulting services, to continue to grow it,” she says. “You’ve got the shared database in place, but now you’ve got technical debt around it because you need to maintain it over the long term. You also have to be very careful about who can see what, and if that’s not addressed properly, that is another form of technical debt.”
If you don’t have the resources or staffing in place to support a shared database, “then you’ve got huge technical debt,” Reynolds says. “That definitely should not be a hindrance for shared databases. In the long term, you can address the technical debt a lot better with a shared database than with individual stand-alone databases.”