Tech Debt as a Cloud driver

Technical Debt in infrastructure (not to be confused with code debt) refers to outdated software or hardware that are no longer supported by their vendor. One of the most significant challenges is that those outdated technologies still in use are supporting critical business services within organisations creating a mounting risk to BAU as well as the wider data security of the company. 

Technical Debt often arises when companies fail to invest beyond the normal maintenance of their IT systems (being applicative or infrastructure) over the course of several years.  Eventually, Technical Debt reaches a size where companies must remediate it by investing in large projects to update their IT estate. The cost associated to this kind of transformation project is most of the time inordinate in the face of just “keeping the lights on”, making it difficult for organisation to prioritise corrective actions. 

There are a number of ways to avoid costly, and resource-straining Technical Debt remediation programmes: implementing new technologies, tools, or ways of working can be harnessed to diminish Technical Debt.  

Cloud technology is one of the most significant ways to alleviate Tech Debt as Cloud is designed to take care of the problem of Technical Debt on a core level. It indeed facilitates smoother transition to up-to-date technology, avoiding unnecessary IT costs through the reduction in hardware costs and in costs related to keeping the lights on. It can also allow to become more competitive, through the use of more up to date Cloud systems and software.  

Additionally, the consistent problem of replacing hardware and upgrading applications vanishes because the Cloud is built in such a way that it is upgraded regularly. The provider itself is responsible for the maintenance of any Cloud-based asset and will deal with any end of support / end of life issues that may emerge.  

There are some considerations to take onboard before moving to the Cloud. What was once an irregular CAPEX cost in hardware and technology for a company becomes an OPEX cost, as a regular spend on maintaining a company’s Cloud presence. It is important to build a business case prior to the migration to ensure those recurring costs are justified in comparison with the costs of maintaining an outdated infrastructure. It may not always be cheaper on paper, but it will most definitely allow for IT engineers to focus on more value-added tasks, rather than dealing with the infrastructure’s obsolescence.  

Alongside this, company applications that are not Cloud native or those that are taken on in the Cloud will still need to be used and managed by company – retaining some degree of responsibility and cost. 

There are also security considerations, as well as the impact of your provider’s success and failures on the business to take into account. For instance, a security breach of the Cloud providers servers could mean a significant impact upon a business’s BAU and reputation, should important client data be lost or applications become non-functional. Similarly, should the Cloud provider go bust or be acquired by a larger provider, a company may be left in limbo if a detailed Cloud exit plan was not defined ahead of moving to the Cloud. 

With regard to strategy, a Cloud Now/Cloud First policy is relatively common amongst firms looking to move their infrastructure into the Cloud space and sets out the organisations strategy towards their Tech Debt. This is often in the form of digitalisation programmes, concerned with removing Technical Debt by transforming legacy technology onto Cloud Services – (I.e., shifting old Windows XP servers onto Microsoft Azure).  

Maintaining BAU, transferring data and applications and ensuring SLAs are met by the new provider require a Cloud policy that is both robust and well-strategized. To have such a strong policy, and running their subsequent programmes, requires a good deal of investment but gives no guarantee of absolute success, as not everything can easily migrate onto the Cloud and certain legacy systems and servers may require to be entirely replaced. Luckily, Microsoft, Google, Amazon et al – well-established and arguably trustworthy providers usually provide robust SLA’s. 

In the BAU space, applications moved onto the Cloud are often functional and where not, a Cloud service replacement application is likely available. Cloud native is not for all however, as not all companies can commit the budget, time, or resource to such a shift. In these situations, taking a piecemeal approach to a Cloud shift for the highest risk elements or adopting a hybrid Cloud-local vision may be the best way forward. 

There is no one-size-fits-all solution to Tech Debt. Moving to the Cloud may hold the key to mitigating some of Tech Debts worst excesses, but it cannot eliminate Tech Debt entirely. That is not to downplay the impact of Cloud however: Cloud services can drastically change a company’s architecture, have significant positive impact on BAU operations efficiency and allow for the increasing cost of maintaining aging technology to be vastly reduced – as major elements of Tech Debt shift out of the companies’ hands to those of Cloud providers. Companies should consider their position and level of Tech Debt carefully before moving to the Cloud. For some, a complete shift is seamless and cost effective, but for others a more piecemeal approach should be taken – taking the best Cloud has to offer to solve the worst elements of their Technical Debt.   

Wavestone is happy to discuss your Technical Debt questions and queries – please click the link below to get in touch our experts.