- Forrester Councils
- Councils Overview
- log in
Posted by Phil Murphy on September 28, 2009
I had an interesting inquiry with a client that began with this question - "What is the defniition of a legacy application?" Yikes, I thought - this will be one of those long-ranging, rhetorical discussions that - at the end of the day - lacks the kind of decisive answer clients typically seek during inquiries. The client actually had a good reason for wanting an externally published, formal definition - an external entity was attempting to measure the company's risk by quantifying its exposure to "legacy."
Why repeat the question here? It's not that I don't have published opinion on the matter - I've written a number of pieces on modernization options and defined the term for those purposes, and I get tons of inquiry around "legacy skills" and the how, whether and when to "modernize" legacy applications. Those conversations follow a familiar path, and tend to end up at these points of agreement:
In the above context, note that the underlying technology that people usually use to define legacy (mainframe COBOL, iSeries AS400, VB 6.0) has little or nothing to do with the symptoms. In fact the the symptoms could describe 5 year old Java, C# or .Net applications just as well as a 30 year old COBOL application.
Past experiences have taught me why focusing wholly on technology as being the cause of "obsolete" can be problematic. In this case, I'd advised in a Webinar that PowerBuilder was a legacy language from which folks should move ahead. No offense to PowerBuilder - I could have cited many other languages as obsolete. In the Q&A section of the Webinar, one attendee asked - "But all of my applications are written in PowerBuilder." Ooops, scratch that generic advice.
Clearly, my proclamation of "obsolete" required the context of this client's situation as a litmus test. Therefore, I submit that we can't rely (solely) on technology as an indicator. But we can't ignore technology either, because it can contribute to the desire to shed an application if:
A succinct definition of a "legacy application" is more difficult than it seems, but perhaps that's the point - this isn't a simple matter. Deciding the fate of an application needs more than over-simplified terms like "legacy." Perhaps we should take more of a potfolio view, and replace the entire question with a more appropriate test such as "When is an application no longer suitable for the business?"
Now that I've presented my opinion above, I'd really like to hear from you folks in the blogosphere and the Twitterati - How do you define a legacy app?
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »