In my last post “Private cloud, redefined” I mentioned that technical debt is a challenge that senior IT executives have been dealing with for many years.
Put simply, it seeks to identify the risks and harmful consequences that might result from currently employed technology that is outdated, has become ill suited, or serves as potential security (or miscellaneous other) risk through its continued use. Not confined merely to software, this debt could be anywhere in the infrastructure on which the organisation relies. Indeed, in some instances, it may not relate directly to the technology itself, but in the availability of skills to patch and otherwise support it should issues occur - whether they be from within the IT team, or via a support contract with a third party.
Just for clarity, not all technical debt is necessarily ”bad”, at least in the short term. It may be worth taking on the risk (and debt) of a hastily put together product or application that cuts corners in the testing phase if it proves a concept or meets an immediate need. Like any debt, however, “interest” will start to accrue, and if that product somehow then becomes a long term solution, that debt - with accrued interest, will likely come due at some point in the future.
How big a problem is technical debt?
In a recently released landmark study by the DXC Leading Edge team within SoftIron partner DXC Technology, we finally get a quantifiable answer to this, and the numbers don’t make for comfortable reading. In fact, 46% of the 750 respondents to their study indicated that technical debt was directly impeding their ability to pursue digital transformation and growth.
They further refine the model and identify six areas within which this debt can occur:
Image credit: DXC Leading Edge
- Infrastructure debt - from outdated, unsupported and/or end of life infrastructure.
- Application debt - from poorly suited and/or unsupported applications.
- UX debt - where user experience is negatively impacting the organisation.
- Data debt - poor data management resulting in inconsistent, corrupt or false data.
- Process debt - inefficiency and point automations resulting in waste in workflows.
- Knowledge debt - knowledge loss from the impact of technical debt.
In fact in most large organisations following internationally recognised standards, such as those championed by NIST, this debt will be identified and listed on (at least one, if not more than one) risk register. This will then be reported at the board level, typically by the CIO, CSO and/or CISO. Of those 750 respondents, in fact, only five did not reference technical debt within their risk register.
How does HyperCloud help address technical debt?
As I talked about in my last post “Private Cloud, redefined”, we believe that past attempts to build private clouds were flawed. Focused almost entirely on architectures designed to deliver just the software layers required to run cloud native applications, making almost all made no real attempt to bring the cloud experience to applications and workloads that might, in fact, never be cloud native. More than that, these architectures glossed over the plain fact that running your own private cloud requires that you run your own infrastructure. And without reinventing the experience of owning that, you really haven’t got a true cloud.
HyperCloud as a point of consolidation - infrastructure debt
HyperCloud includes all the infrastructure needed to build your private cloud in a single, resilient, secure and highly elastic architecture. Managing HyperCloud is, in essence, as simple at 800 nodes of infrastructure as it is at 8 nodes. For example, there’s still just one patch to apply, only once, that addresses every piece of software running your private cloud, from firmware to operating system, right up to the application layer, regardless of how many racks of infrastructure you are running.
That means that every time you are able to retire an ageing, out of support and hard to secure bit of legacy equipment and are able to “lift and shift” it to its virtual equivalent within HyperCloud your data centre gets simpler, safer and more resilient - and you get to wipe one more entry from your risk register.
HyperCloud as a “cloud native bridge” - application, process and UX debt
HyperCloud provides the perfect platform to bridge between data and workloads that will be staying on prem, and the cloud native applications that feed and/or use that data. Using HyperCloud’s powerful templating capabilities, you can build the interface between these on prem. Infrastructure (a mainframe, for example) using whatever mix of skills required, then simply make it available to your “cloud native” application developers within your HyperCloud marketplace. Immediately they have a consistent, tested and approved way to build whatever applications they need to build in a fully cloud native way, to then deploy wherever it makes sense for them to be deployed.
HyperCloud as a way to decouple projects - application and infrastructure debt
However big and powerful your HyperCloud based private cloud becomes, it’s still only one cloud for you to manage. And as you consider new projects and/or as budget cycles permit, it affords you the luxury of decoupling software and hardware projects and investments.
Let’s take an example.
Perhaps some legacy hardware has reached end of life and ITOps want to replace it, but the engineering team aren’t ready to refactor the application that relies upon it. With HyperCloud, you can first review available capacity within your existing private cloud and make a call as to whether you need additional infrastructure or not to “lift and shift” over to HyperCloud. If you don’t, then great. But even if you do, whatever investments you make won’t be wasted, because as soon as the application refactoring is complete, those ephemeral nodes of capacity can be released back into the pool of resources for other projects to consume. Equally, they could be used to support the refactored application if some or all of it remains on prem.
HyperCloud to improve your security posture - data debt
HyperCloud is a new way to build private cloud. Its unique design means that the state of every piece of infrastructure from which it is built is known and kept uniform automatically, and by design. Every known vulnerability in the CVE program, is identified and remediated.
It frees your security team to worry less about obscure and obfuscated issues deep in the infrastructure, and instead focus on application, user and data centric security controls that rely on that infrastructure. And, in the context of reducing technical debt, it enables older systems that have fallen out of contract and/or are no longer being patched, to be retired.
The outcome - a life free from the burden of debt
I’m not pretending that HyperCloud is a panacea to all the technical debt you will find in your IT infrastructure, but executed correctly, its unique ability to provide a strategic platform based on the delivery of a true private cloud does offer significant benefits over a broad range of issues which may previously have been relegated to the “too hard” list. At the same time, HyperCloud provides that cloud native platform for the future - wherever that might be.
You may not end up “debt free” (who really is in this life?), but we may well be able to help you get out from under its burden and accelerate those projects that have been held back because of it.
If you’d like to discuss the particular issues that you are facing, do reach out. We’d be happy to help.
