I had an interesting inquiry with a client that began with this question - "What is the definition 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:
- The app was written some time ago, its original authors moved on taking knowledge with them (lost knowledge).
- Subsequent authors changed the application based on insufficient / lost knowledge, introducing bugs and de-stabilizing it.
- The app is now brittle, and people are reluctant to change it for fear of breaking it.
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:
- App can't be extended due to the lack of / waning 3rd party vendor support - perhaps APL, PL/I, VB 6.0 are examples.
- App won't scale based on deficiency in original technology choice - app written as a throw-together temporary app, now needs to scale to meet public-Internet traffic volumes and security protocols
- Long-standing poor coding techniques, "patching it fast" rather than "doing it right" over a long period of years for example
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?