I had the opportunity recently to make some minor changes to reports originally created in the late 80’s. The application is a character-based app running on an “old” version of SCO Unix, and hardware that has been kept alive by some clever mix and match combination of “old” components taken from servers long ago taken out of service. To say this is out-of-date is being kind – let’s say it owes nothing.
My first thought when I posed the question “What keeps an out-of-date application in place?” was that of course — it’s money! While that jumped into my mind immediately, I began also to consider what else would be keeping the app alive. For one thing, there is the fact that it is basic, lean and mean (read that fast response), and works well for what it was designed to do. The issue here is that it wasn’t designed to do much of what the modern business requires it to do in 2008. It is also difficult to support, although it doesn’t require significant support.
So what else might be keeping it going if money isn’t the real issue? How about fear? With any new implementation there is always a fear factor that has to be overcome. What if the wrong application has been chosen? What if it doesn’t fit as expected? What if, what if, what if??? You can probably think of dozens of scenarios which might cause an organization to avoid replacing an application, but none of them would exist on any of the “best practices” lists.
It just so happens that in the history of this company there was a failed implementation of software which at the time was thought to be a good “upgrade” for the company. Many thousands of dollars were spent on equipment, software, support and consulting fees for the project which never got completed. It seems that the business processes that needed to change in order to get the desired results from the software were just too much. The company was sold during this time. Go figure!
(…although I don’t remember the year that took place, I’m pretty sure it was over 10 years ago