Transforming Technology Debt into Innovation

Peter Hogan, Senior Vice President of Information Technology at Compana Pet Brands

Peter Hogan, Senior Vice President of Information Technology at Compana Pet Brands

You may be asking yourself what technology debt has to do with driving business innovation. The answer is related to using the work others have done as ‘late’ adopters’ advantage to skip the traditional risks when moving to innovative technology as a closer follower. To explain this better, we will explore both types of tech debt, infrastructure and application, to understand how these can be leveraged to help create an innovative technology outcome to better position your business outcomes.

Let us start with infrastructure tech debt, defined as old servers, physical data storage, security, or networking hardware that has reached the end of support life (or beyond). As the most common is server and data storage, we will focus mostly on these. There are two types of tech debt models here:

● Physical Server/Storage your company owns (or your service provider owns) where the applications and data exist directly on this physical gear.

● Virtual Server/Storage where there is physical gear supporting multiple virtual server and storage instances. Do not confuse this with cloud servers/storage, as I am referencing the scenario where you (or your service provider) own this gear, and it has aged out.

In either case above, you have unsupported hardware that needs to be replaced as it will fail at some point and will no longer have security patching available to protect it. Given the advancements in true cloud data center models, you have the opportunity to remove this IT burden (that adds no value to your organization) to one of the various cloud providers (Azure, AWS, Google, etc.). The advantage of this move usually can be summarized across:

● No upfront capital expense.

● Reduced IT support and complexity to manage these devices (OS patching, BIOS updates, etc.).

● More IT focus can and should be diverted to business technology initiatives vs. keeping the servers running.

● Easier to find support for any of the main cloud platforms.

● Better disaster recovery functionality as you can have geographic regions baked in. On this note, you may think you have good DR if you have a local hosting provider and are on a Virtual Server that has another Virtual Server failover on the farm with it. Ask yourself, what happens if the Data Center itself goes away for recovery time/effort (a true cloud model considers this upfront and allows for geographic locations for DR).

● Unlimited horsepower to scale as needed (or retracted if needed).

● Multiple data storage options for speed and cost.

There is a great deal of planning to do as you look to remove this technology debt, such as planning the connectivity, defining the security model, and finding the right partner to help you design and deploy the model to start and turn over if desired. However, once there, you will find you have a more predictable cost model with less labor support and, in most cases, far better uptime.

‘When focusing on technology debt, you have an opportunity not to just replace or upgrade what exists today to keep the business running, but to find the elusive better, faster, cheaper models that others have spent years improving so that you can walk right and get better deals on better technology to deliver better business outcomes.’

Now, let us discuss application tech debt. Again, I would break this into two types:

● Home Grown Applications – those that were custom developed for or by you that have technology used to create them, such as .NET, JAVA, or even Cobol that is out (usually far out) of vendor support.

● Purchased Applications – those where the version has aged past a point of vendor support.

For home grown applications there are a few approaches. First, ensure you create an application inventory to define what each application does, any dependencies it has (database, storage, other applications) and who the business and technical owners are. You will find this harder than it sounds if your organization has lacked the diligence to document over time. So, once you have this inventory (as best as possible), some techniques that have had solid success are:

● Critical/Complex Applications – In these cases, you have the best opportunity to innovate. A proven approach is to work with the business owners to re-image what the application could look like today. How can we use better analytics for the data the application provides? Can we add predictive or generative AI capabilities to it, etc? These application migrations require the most diligence from a business planning and project management approach, so if you can find an application that is a software-as-a-service provider, you'll usually be able to migrate with the best opportunity for minimal business disruption as someone else has already solved this problem and is offering a generalized solution for it. However, if you need to write the application (say it is a unique application to your specific business sector), then ensure you deconstruct the app to review each function it performs to understand how you can integrate newer architecture, analytics, and security features into it.

● Medium/Low Legacy Applications – In these cases, you need to ask, " "What would happen if this application was gone tomorrow?" In many cases, almost nothing, and it has only been around, as people might say, 'because we’ve always done it that way.’ In these cases, you may be able to thin the herd and just retire a few where you cannot follow a similar approach to the above bullet point based on application importance. One thing to note is that usually, these applications are much less complex and could be replaced with a similar SaaS offering.

● Unknown Applications – In the cases where there is little known, and people have left the company, so no history exists, you have a unique opportunity to clean the house. In many cases, legacy applications like these may have been created for a small group of people and have just been left running. If you cannot find an owner, alternative system dependency, or anyone who is using the application, you can do a planned turn-off for a period to see if it generates an issue. I do not recommend this without strong upfront diligence, but in one of my own past lives, this allowed us to retire over a dozen small applications with no impact and no waste of funding to migrate or replace.

For purchased applications, the first step is understanding the effort to upgrade to a supported version. Usually, if you are several versions behind, this effort is like implementing a new product anyway, so in those cases, why not play the field for a lower-cost, more feature-rich platform? In all cases, I recommend creating a simple feature weight chart to compare what you have to what the latest version (or an alternative) looks like. This is where the innovation comes in, as you may be surprised to find what else is baked into similar competitor applications in the market in terms of features, analytics, security, and integrations with other application providers.

In summary, when focusing on technology debt, you have an opportunity not to just replace or upgrade what exists today to keep the business running but to find the elusive better, faster, cheaper models that others have spent years improving so that you can walk right and get better deals on better technology to deliver better business outcomes.

 

Read Also

On-Orbit Computing for Next Generation Space Missions

On-Orbit Computing for Next Generation Space Missions

Mark Broadbent, Sr. Avionics Engineer and Katie Gibas, Marketing Communications Manager, Moog Inc
Hollywood in Your Hand: Shooting for Different Mediums

Hollywood in Your Hand: Shooting for Different Mediums

Robert Jarzen, Group Creative Services Director, Midwest Marketing Team, Audacy, Inc
Implementing Industrial Robots

Implementing Industrial Robots

Laurent Huberty, Manufacturing Technology Team Manager, Husky Technologies
Building Cybersecure Offshore Platforms with Smart Design Strategies

Building Cybersecure Offshore Platforms with Smart Design Strategies

Gabriel Albuquerque, Automation and Instrumentation Design Manager, Petrobras
Ethics & Compliance In A Digital World: Navigating Hcp Engagement In Apac

Ethics & Compliance In A Digital World: Navigating Hcp Engagement In Apac

Sherene Cham, Regional Director, Ethics & Compliance – Apac, Menarini Group
Bridging Innovation, Strategy and Patient Connection

Bridging Innovation, Strategy and Patient Connection

Shigeto Miyamoto, VP of Digital Solutions, APAC, Syneos Health
follow on linkedin
Copyright © 2025 Applied Technology Review.All Rights Reserved
Top