When legacy apps attack: Lessons from GSA's Lotus Notes hiccup
In the days of computing yore, public-service agencies that were trying to move away from stovepipe systems to a distributed computing environment, or to connect everyone via an intranet, ran into a problem with legacy applications. They were a big problem then because programs running on a mainframe had to be modified or eliminated in favor of desktop versions.
Now the opposite is happening, as government tries to move everything into the cloud.
I hope I’m not stating the obvious here, but lots of people think the cloud is some magical place where programs go to live forever. The truth of the cloud is that, in a lot of ways, it’s just like the mainframes of yesteryear. Programs that exist “in the cloud” reside on servers somewhere in the world (though probably not down the hall from you) and are able to serve themselves to your personal desktops or laptops or tablets as needed, which again reminds me of the dummy terminal and mainframe relationship of days gone by.
Yes, cloud applications are distributed and redundant so that if one cloud server goes down, users can still access all their information and programs. You don’t get a day off work anymore if “the mainframe crashes.” But at some level, the cloud is a return to the way programs worked in the past, when the actual code wasn’t stored locally.
So it was little surprising to find a report showing that the General Services Administration was bogged down in its move to a cloud-based e-mail system by thousands of legacy applications.
GSA’s problem specifically is with Lotus Notes, which lets users create applications for their own ends. In that sense, Notes was an excellent tool for the distributed computing environment. If users needed to process payroll information every week, they could create a Notes application to help. It needed only to work on a local machine or a few local computers, and life was good.
But over the years, numerous offices within GSA had developed thousands of Notes applications. And that creates problems when an agency moves its files and programs into the cloud, which isn’t a perfect process.
Take, for example, my own experience in the GCN Lab. When we moved our e-mail server to the cloud, we simply replicated the whole thing. What was funny was that the machine it was running on had this odd quirk that only when it was rebooted – but not when it was shutdown fully and then brought back up ¬– a certain service would not automatically activate, which caused the e-mail not to function. It was no big deal. When our e-mail stopped working, we simply went into the menu and started that service manually, which happened whenever patches were applied that forced a reboot, or during a power failure.
Once we got into the cloud, we found that we had replicated that same quirk. Even though our system was running on brand new hardware off in cloud land, it still maintained the same problems as before. And we picked up a few new ones, specifically with drivers for applications tied directly to the mail service. In our case, we actually got off lucky. We didn’t need the extra programs, so they were deactivated. And we were used to dealing with the quirky server, so not much changed overall.
But that doesn’t always happen. The biggest problem is that a lot of individual files like print drivers don’t work right unless optimized for the cloud. And that is likely the biggest hang-up for GSA, which a recent audit found had overstated the cost savings for its cloud plan. I guess finding out that thousands of Notes applications no longer work can be an expensive revelation.
So what is an agency to do with legacy apps? There are few options. They can be reprogrammed to work in the cloud, of course, but that could be a pretty big undertaking. Or they can be sent to the cloud to let users take their chances.
However, GSA, and anyone in a similar spot, might also try a program like VMware ThinApp. That program can isolate legacy applications within the cloud and trick them into running independently on end-user machines.
We tested it with an application written for Windows XP that did not work on Windows 7. Running it though ThinApp first, we were able to get it to run fine on Windows 7 systems.
A Citrix Metaframe server also could do the trick if your agency is familiar with how they work.
The Notes applications in the GSA example should benefit from either of those programs. But in the future, every agency should carefully audit its applications to make sure everything can move safely into the cloud the first time.
It’s a lot easier to catch problems before a move than to try and troubleshoot them afterwards, and probably a lot cheaper too.