| | AUGUST 20249CIOReview· 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.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. 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
<
Page 8 |
Page 10 >