Contact us

If you’ve got a story or event for the GPSJ website, e-mail Stuart Littleford at editor@gpsj.co.uk

April 2021
M T W T F S S
« Mar    
 1234
567891011
12131415161718
19202122232425
2627282930  

Archives

How to Tackle Technical Debt

Sascha Giese, Head Geek™, SolarWinds

By Sascha Giese, Head Geek at SolarWinds

Most public sector organisations and their IT teams will be familiar with the challenge of balancing time between implementing new technologies against the need to keep existing systems running effectively. In some cases, organisations can do little more than focus on the latter, as budget constraints or a lack of resources mean they have to do their best with what’s available.

Among the many challenges this situation can create is one of technical debt, where organisations opt for an easy or quick solution instead of using a better approach that might take longer or cost more. The “debt” builds up when the problems this approach creates have to be addressed later, particularly when something breaks.

Like financial debt, many people consider this isn’t inherently a bad thing. IT teams everywhere work within limited budgets and are used to carefully managing some level of perennial technical debt. Problems arise, however, if the debt becomes too large and its impact becomes too challenging to manage and reduce.

When an organisation is in technical debt, it will often manage with what it has available until it breaks. In this situation, some compound the problem with workarounds and stopgap solutions. But when these are layered on the top of several other stopgaps, the technical debt gets larger and the process becomes cyclical.

Ideally, public sector IT teams need to be given the resources to understand and manage their technical debt to keep it within their own acceptable boundaries of risk. But how can organisations assess their levels of technical debt, focus on buying the right technology, and learn to let go of old systems?

Bringing Chaos to Order

 In many of today’s complex IT environments where legacy technology integrates with newer strategic and point solutions, understanding the size and focus of technical debt can be a barrier to change. This is where chaos engineering can help by implementing programmes such as a ‘chaos monkey,’ which is designed to randomly turn systems off or delete them, so teams can identify weaknesses in their infrastructure and understand how to quickly remediate issues, including those caused by technical debt.

By creating problems on purpose, this approach can test software, equipment, and the internal processes in use across an organisation. In doing so, it can shed light on issues, from products that aren’t running well, to those not performing as promised or not communicating with other technologies.

Optimising Technology Procurement 

Ideally, each element of a modern technology strategy must work together to create a coherent approach with minimal technical debt, and this process starts with procurement. Providing the right set of tools—as opposed to purely focusing on the newest—is essential to effective integration and longevity.

A key requirement of any effort to purchase future-proofed technology infrastructure is each component within the environment should integrate effectively with every other product, system, and service running alongside it. For instance, the people and technologies in accounting must work with the IT security team, who must work with the network team and the developers—and so on.

As many tech teams will know, piecemeal procurement is often unavoidable, but unless there’s no option, decisions should be made with at least one eye on long-term impact and whether choices are increasing the technical debt burden or not.

Leaving The Legacy 

Most public sector organisations operate with some degree of legacy technology as part of their infrastructure, contributing to its wider technical debt. For example, this might mean using outdated versions of Windows that have gone “end of life” and no longer receive updates, because it’s the only version legacy applications will run on. In these circumstances, the technical debt might not just be functional or reduce compatibility, it might require major remedial expenditure and effort if an outdated platform becomes the source for a serious security breach.

Sometimes the justification is, so much money was spent on the technology in question that leadership wants to get as much use out of it as possible, even if it has long outlived its usefulness. Granted, it’s completely unrealistic to be constantly renewing, but future-proofing calls for a delicate balance between finding the best technology to solve bona fide technology problems and getting the biggest bang for your buck.

In the real world of fast-moving technology environments, limited budgets, and changing priorities, operating with zero technical debt is—for the most part—unrealistic. But paying down technical debt to a manageable level, where infrastructure can operate at peak efficiency without being at the mercy of its most inefficient components, is essential to maintaining solutions and services that meet organisational needs.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

This site uses Akismet to reduce spam. Learn how your comment data is processed.