Reducing technical debt in Cloud
What's the impact of Technical Debt?
According to a recent report published by Deloitte, Technical debt has a stagnating financial cost on an organisation. They identified that around $3.61 of technical debt exists per line of code, equating to roughly more than $1 million per system. This technical debt has led Gartner to estimate that the total global IT debt in 2015 was around $1 trillion, and for large public sector agencies to have an average technical debt of more than $200 million.
Technical debt constrains a business's ability to innovate and shift digital channels, reducing their competitiveness, market share and customer retention. A build-up of technical debt will also reduce efficiency, impacting profitability and time to market.
Technical Debt is formed in three common areas:
Architecture is often overlooked as a contributing factor to technical debt but it has a significant impact. This includes rushed, ill-considered designs that don’t meet requirements, poor or missing governance on design work and lastly, duplicating design effort.
In some cases, over engineered designs and overly burdensome governance processes can also have a detrimental outcome. Adopting and adapting an architectural framework, best practices and ensuring the processes are effective and not negatively effecting an organisations agility, is an interesting balancing act. In some cases, traditional architectural frameworks can often 'get in the way'. The Scaled Agile Framework (SAFe) takes many of these proven architectural methods and aligns them with lean and agile principles, ensuring teams can collaborate effectively at scale
This is referring to debt that has arisen through poorly written, poorly commented, and untested code. These are all practical factors that contribute to technical debt in software engineering. Other influences include more human ones, where a development team may be forced to write a piece of code to expedite the delivery of some functionality, that then needs to be refactored later. All of these lead to inefficiency, in the end-to-end delivery pipeline and hinder business software development objectives. Ultimately, developers spend more time ‘fixing’, than delivering innovation and service enhancements.
Public Cloud itself is a huge enabler when it comes to reducing infrastructure debt, as in all cases the heavy lifting of hardware management and support is removed by the Cloud provider, such as cabling, HVAC, power and security. Important factors such as Infrastructure as Code (IaC) are native in Cloud and are crucial in improving operational processes, as you no longer need to worry about capacity, or concern yourself about hardware support contracts and CAPEX investments for your data centre. This allows IT teams to focus on innovation and the development of services, rather than repetitive and time-consuming hardware management tasks.
In terms of a wider cloud transformation journey, technical debt can still be found. For example, an application that consists mainly of VMs for it's compute requirements, would arguably accommodate more technical debt than a cloud native application that uses loosely coupled microservices, operating on event driven serverless compute. In this scenario, IT only concern themselves with the code, as there's no scaling groups, patching or operating systems to manage.