When does a system become legacy? Last time we were interested in understanding a bit more about the state of our IT systems, and whether we were being held back by what we could loosely term 'legacy'. Perhaps a trickier question to answer however, is how we decide whether a system is legacy or not. In the ideal world, when we built IT systems, we'd do so with …
I work at banks - and a system can usually be described as legacy on the day it is delivered.
In reality though, legacy is just defined as something that someone wants to replace. If it's a happy mainframe app that's been doing its thang for 30 years and is ticking along fine, doing everything it is supposed to do nobody will want to replace it and it therefore will not be legacy!
I don't play video games, so I have the same computer that I built back in 2001, and it is still giving me a lot of what I need. So when I see someone buying a new computer, it makes me wonder whether they're buying a new computer because they actually need the computer, or because the old computer is running slowly. And of course, the frequent cause of a slow computer is because it's filled with viruses and spyware.
Serious question.
Old stuff isn't inherently bad. If it still performs the job it was intended to do, let it. If it doesn't, replace it. You DO have an upgrade path planned and budgeted for, right? No? Then I submit that it isn't an equipment problem, but rather it is a management problem.
I commented on my 30 year old greenhouse management software last time. This time, let's talk telephones. Palo Alto, that hot-bed of high-tech, still had analog switches in a couple of the local exchanges ... in 1998! They still worked for voice, and that was all the customers contracts paid for, so why change 'em? It wasn't until customers started getting upset that they couldn't connect to AOL at 28,800 "like my neighbor" that they switched to digital. The 326 exchange was the last to be changed over. If it wasn't for AOL, it would probably still be analog ... and some of THAT gear was installed in the late 1940s! (I was a NOC-monkey, lurking under Bryant Street and on Fabian(RIP) ... I'm probably going to have nightmares tonight over the memories ...)
Or consider TCP/IP. You use it every single day. Virtually everyone connecting to the Internet uses it for nearly every pointy-clicky intratubes delight. When was it first implemented? (See RFC 675 if you don't know the answer). It's a third of a century old, fer chrissake! Do you consider TCP/IP old, dusty, and in need of replacement? (Cue IPv6 fanbois ...).
Or how about the basic UNIX API?
Old stuff is NOT inherently bad, although there are bad installations. Bad installs are not the equipment's fault, rather they are the fault of the people controlling the purse strings.
We generally develop a set of criteria, both business and IT to rate our systems. We rate them every two years or so. Plot the scores on a 2x2 matrix and conclude:
High business and High technology = retain
High business and Low technology = reengineer
Low business and High technology = invest
Low business and Low Technology = replace
Regluar attention and managing systems a portfolio of assets is generally a useful thing to do.
- Jww
Loved the matrices but might I suggest:
HH High business and High technology = retain but expect it to migrate to LH
HL High business and Low technology = retain even more so than the High/High - it is costing the business less - or is the point of the matrix to identify more opportunities for IT specialists to gain employment lol
LH Low business and High technology = dump
LL Low business and Low Technology = invest to move it to HL
Good to see asset management being conducted, too many organisations 'fire and forget'
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
