Technical Debt and Lifecycle Management Q&A

Ken: Tell us a bit about the concept of “technical debt” and why enterprises need to put so much due diligence behind managing this risk.

Damian: Technical debt was originally a concept applied to software and at a high level described the cost to rework or maintain that software over time. Today we can look at technical debt in broader terms as the implied costs to refresh technology components to current standards within an organization – each company will drive that desired state through their business and IT strategy. In a modern large organization, these components can cover a large number of areas beyond the original narrow definition of software such as servers, networks, storage, and middleware.

Dealing with technical debt is important for a company for a multitude of reasons – expense, lack of support, excessive management overhead, inability to cope with the demands of digital transformation, lack of scalability or resiliency. This in turn adds risk to the technology space within an organization and beyond … technical debt can make it hard for an organization to adapt to changing market forces.  

Ken: So, for these large enterprises, it is a pretty complex undertaking to manage the lifecycle of their physical IT assets. Can you give us an idea about the real-world due diligence that is required to pull this off?

Damian: Yes. This can be pretty complex. Over time there tends to be a collection of just about every type of technology imaginable that has been deployed and needs lifecycle management.  On top of that, big companies tend to be risk-averse for their production systems, so the amount of due diligence to ensure that there are no mistakes with tech upgrades is tremendous. 

Our view is that the key to success is strong governance, change control, and the right toolset. We developed our own tool to work alongside industry-standard tools such as Microsoft Project to allow us to track dozens of projects simultaneously and also manage the excruciating level of detail required to ensure positive outcomes to complex migrations of critical systems.  

Working in multiple regions, with a multitude of technologies does present a challenge but the technology landscape is always changing as we know. 

Ken: And here’s where things get really interesting. We are likely to pine for the days when lifecycle management was this simple. Enterprise IT is now getting more complex as companies are moving workload to the public cloud and creating hybrid cloud and multi-cloud architectures. Depending on the cloud deployment model, lifecycle management (LCM) is still a big factor to be dealt with. If you are deploying Infrastructure-as-a-Service (IaaS) as part of your digital transformation journey, you still have lifecycle management concerns and risks to deal with, right?

Damian: That’s right.  If you are deploying Software-as-a-Service products only, then lifecycle management is not your problem. That is one of the major benefits of SaaS. When you use Infrastructure as a Service, as a good many enterprises do, at least in part – then you are essentially renting someone else’s computer.  You are still responsible to manage the risk of technical debt when things like instance types are scheduled to go End of Life or the operating systems are End of Service Life. 

Ken: The other big issue is organizational rather than technical. In a big enterprise, when a new public cloud direction is adopted, is the tendency to use the same people that are managing your on-prem assets, or to use entirely new people in a “cloud” organization?

Damian: The likelihood is that there will be an entirely different set of people responsible for LCM of the public cloud assets vs. the on-prem assets. In fact, because of outsourcing deals, it may be an entirely different company that is responsible. Then you wind up losing integrated visibility and responsibility regarding LCM risk, and you are going down a bad path.

Ken: One of the things that we believe in at PTS is that a fully integrated approach to lifecycle management is the way to go. We are working with a partner right now on development of software that allows for asset and LCM risk management across all on-prem, private cloud, and public cloud Infrastructure as a Sevice resources. This will bring in data not only from systems of record but from a variety of real-time collectors. There will also be an application view to assemble topologies of these assets at an app level, right?

Damian: Yes, this could then let you assess risk and make better data-driven decisions, even if your org bifurcates into different responsibilities because the important LCM data is in the same place.

Ken: But it would still be best to also have all of the complex operational details of production LCM changes handled by the same organization – whether on-prem or cloud, wouldn’t you say?

Damian: Yes, absolutely. If that is where you are heading, that should be your goal.