Why does the sun never set on legacy applications?
Jim Harris in Sponsored Blog Posts tagged Enterprise CIO Forum, HP, IT Thursday, April 28, 2011 at 11:00AM This blog post is sponsored by the Enterprise CIO Forum and HP.
Most information technology (IT) departments split their time between implementing new and maintaining existing technology. On the software side, most of the focus is on applications supporting business processes. A new application is usually intended to replace an outdated (i.e., legacy) application. However, both will typically run in production until the new application is proven, after which the legacy application is obsolesced (i.e., no longer used) and sunset (i.e., no longer maintained, usually removed).
At least, in theory, that is how it is all supposed to work. However, in practice, legacy applications are rarely sunset. Why?
The simple reason most legacy applications do not go gentle into that good night, but instead rage against the dying of their light, is that some users continue using some of the functionality provided by the legacy application to support daily business activities.
Two of the biggest contributors to this IT conundrum are speed and agility—the most common business drivers for implementing new technology. Historically, IT has spent a significant part of their implementation time setting up application environments (i.e., development, test, and parallel production). For traditional enterprise solutions, this meant on-site hardware configuration, followed by software acquisition, installation, configuration, and customization. Therefore, a significant amount of time, effort, and money had to be expended before the development of the new application could even begin.
Legacy applications are typically the antithesis of agility, but they are typically good at doing what they have always done. Although this doesn’t satisfy all of the constantly evolving business needs of the organization, it is often easier to use the legacy application to support the less dynamic business needs, and try to focus new application development on new requirements.
Additionally, the consumerization of IT and the technology trifecta of Cloud, SaaS, and Mobility has both helped and hindered the legacy logjam, since a common characteristic of this new breed of off-premise applications is quickly providing only the features that users currently need, which is often in stark contrast to new on-premise applications that although feature-rich, often remain user-poor because of the slower time to implement—again failing the business requirements of speed and agility.
Therefore, although legacy applications are used less and less, since they continue to support some business needs, they are never sunset. This feature fracture (i.e., technology supporting business needs being splintered across new and legacy applications) often leaves IT departments overburdened with maintaining a lot of technology that is not being used all that much.
The white paper The Mandate to Modernize Aging Applications is a good resource for information about this complex challenge and explains why application modernization must become the enterprise’s information technology prime directive.
IT can not enable the enterprise’s future if they are stuck still supporting its past. If the sun never sets on legacy applications, then a foreboding darkness may fall and the number of successful new days dawning for the organization may quickly dwindle.
This blog post is sponsored by the Enterprise CIO Forum and HP.
Related Posts
A Sadie Hawkins Dance of Business Transformation
Are Applications the La Brea Tar Pits for Data?
The IT Pendulum and the Federated Future of IT
Suburban Flight, Technology Sprawl, and Garage IT
Reader Comments (7)
An excellent point with true business impact. Keeping around tens (and in some case hundreds!) of legacy applications can be a resource drag for many companies. In the case of vendor-provided applications, I've seen companies receive audit findings revealing that the legacy application isn't a currently-supported version or only runs on unsupported systems.
I find many of these legacy applications are kept alive in read-only mode, i.e., purely for occasional query/reporting purposes. Stated differently, the end users often just want to be able to look at the data from time to time.
The last three years we've seen a surge in interest in "Application Retirement" (sometimes called application decommissioning) solutions for those cases. These offers reduce the legacy application costs by moving the data to centrally managed archives for query and reporting purposes. The company is then able to reclaim the legacy application's hardware infrastructure. This approach also reduces the drag on staff skills as IT staff need know how to administer only one supporting infrastructure for all the legacy data. [Disclaimer: my employer (and our competitors) offers application retirement solutions, though that's not a direct part of my role.]
Great and timely post Jim.
Our local chapter of TDWI in Vancouver has a presentation scheduled in June on legacy application migration best practices and I am going to forward your blog to our presenter. The "Mandate to Modernize" looks especially interesting. We expect a good turnout because our TDWI chapter has quite a few large organizations that attend regularly and I'm hoping that this presentation will elicit a good discussion from the people actively trying to extract themselves from the La Brea Tar Pits of legacy maintenance.
Our presenter has a lot of experience with legacy migrations and is going to use the "golden rules" from John Morris' Practical Data Migration as his framework. Morris' admonition to have System Retirement Policies signed off and agreed to before the migration begins dovetails nicely with your main point when he says "...local Legacy Data Stores that can persist in a half-life long after they are ostensibly replaced by the new system, with their data diverging increasingly from the new system."
Your article shows that if an organization does not make the conscious choice to migrate legacy applications, then they will be unconsciously condemning a steadily increasing portion of the IT budget to a demoralized technical team maintaining the isolated functionality. The sad image of a "Dead Application Walking" comes to mind. :(
Great article.
From the LinkedIn Group for Enterprise CIO Forum, Paul Calento commented:
“Organizations have a "set it and forget it" mentality. One of the challenges with application modernization is the (perceived) embarrassment factor. Plus, there will always be "legacy" apps for all but the start-up company.
By updating an application or eliminating it altogether, organizations (and CIOs and their IT department's) are admitting that what they invested in previously doesn't work. By being smart and selective, application modernization needs to be repackaged as a way to enhance existing value and previous investment. In many ways, this may make the exercise more palatable.”
From the LinkedIn Group for Enterprise CIO Forum, Pearl Zhu commented:
“Hi, Jim, thank you for sharing this, legacy applications are probably one of the obstacles for many larger organizations to transform their IT and business value propositional delivery effectively.
1. As Paul pointed out, the mentality: the habit to do the things we always do, inertia to change or improve, or lack of the right culture to encourage the changes.
2. The right PM practice: now, agile, scrum, lean, and cloud., etc, but how to execute them with the right roadmap, open culture, governance, risk control, and measurement, etc.
3. Break the functional silos, when IT gets more engaged with the business, connect legacy applications with BPM/EA/SOA/BI, etc. It may stimulate better transformation.”
Great post, Jim. This will serve as a starting point for one of my future @ECIOForum blog posts.
From the LinkedIn Group for Enterprise CIO Forum, Andrew Karpie commented:
“What about a legacy beast that continues to consume some resources while still satisfying core needs, it is not a simple evaluation/decision; I'm not sure if there are any frameworks that can help managers with such evaluations/decisions. Even "application modernization" seems to remain an elusive, fuzzy concept which can mean a host of things.
Having recently worked with a company that struggled (really struggled) with an application modernization decision -- and having just now briefly checked out what is written up in CIO (all a bit generic)-- I'm left wondering if there is any existing overview statistical study of the outcomes of different types of applications modernization projects (from first evaluation of alternatives to terminus). It would be nice see empirical case studies (including financial dimensions) of different projects with different outcomes. Finally, I wonder how the "modernization business case" varies according to different conditions or states (something particular I wonder about is if the case for/against modernization is the same for an internal application owned by the enterprise vs. that of a SaaS application provider that supplies a range of enterprises).”
And Pearl Zhu responded:
“Hi, Andrew and Jim, I think there are quite a few reasons for applications to become legacy, such as:
(1) It's not fitting in the purpose of the organization now, or not prioritized in current market condition
(2) Technology is out of date, it's cheaper and faster if modernizing it or transforming it into the Cloud
(3) Some legacy applications have reached a point in their life cycle where it could be too costly to modernize, especially for some struggling organizations and industries
After recognizing and prioritizing the projects that need be modernized, you need the long term perspective from executive sponsorship on how to transform it successfully via the strategic/technological partners, change management, culture, etc.
Here is an interesting blog discussing Application Transformation: ALM and App Trans Blog
In summary, I think about people, process, and technology, in order to leverage the long term growth within budget limits, and to inspire the people, and to accelerate the right process. Thanks.”
From the LinkedIn Group for Enterprise CIO Forum, Corinna Martinez commented:
“Legacy is not a bad word. Even in IT we need to review the past and honor what has worked while updating.
Any application that goes into production . . . is now legacy.
The Systems Development Life Cycle (SDLC) shows how we (IT) should be caring for and nurturing applications from cradle to grave. Unfortunately, people tend to keep systems on life support longer than necessary to squeeze the last little bit of productivity out of it . . . while wasting boat loads of cash in the process.
Any application that includes information that the business needs and uses is legacy and necessary to be continued and/or transformed, which requires another IT project to make that happen.
If the prior project to get the now legacy application to come to life was traumatic - cost time, money, people - blood, sweat and tears - then don't blame the organization for not rushing to sign up for more. We, the technologists and implementers, have to get better at transformation before the organization will.
Any organization that thinks by relabeling their applications they have transformed them, also calls a face lift and some cream the Fountain of Youth. Paul is correct that the "set it and forget it" mentality needs to change to embrace a periodic review of applications and truly follow the SDLC. This includes culling those applications that are no longer needed, costly to keep running as is or on obsolete platforms. Port the data onto something new, expand information if needed, increase usability and reporting while attending to the human factors of training and using the application.”
And Pearl Zhu responded:
“Hi, Corinna, I enjoyed your comment. Yes, Legacy, most of the time, is a great heritage, like many legacy industries are the backbone of our economy, the legacy applications could also be the cornerstone of IT.
Well, predictive analytics methodology could be taken to analyze the SDLC, with guideline of Gartner's hype cycle to decide, or actually to better predict the future of the application. I also enjoyed your metaphor, last, but not least, always consider the people's mojo or attitude, to embrace the change and initiate the transformation.”