When legacy software just keeps on running.
"Open the pod bay door, HAL."
Heading out to NTEN.org's annual Nonprofit Technology Conference, my mind is generally on what's new and useful. Lots of sharing to make the best choices when organizations outgrow their systems, know it, need to figure out what comes next, and how to make it last. And it's interesting times for this, with software and Internet infrastructure evolving so fast now.
Where old systems clash with new strategies or programs, solutions may be complex, but at least everyone knows change has to come.
I also have been thinking about other situations where technology continues to soldier on year after year, meeting important needs with occasional adjustment and improvement. Two strange encounters with the persistence of the old kept me on the edge this week before leaving town.
In one case, I unexpectedly heard from an organization where years ago we programmed a complex integration scenario between their web site and back end data system. Daily work depended on tools which now have not been updated in years, and were no longer well-supported by the vendor. But they kept running and over the years, and we hardly heard from these folks anymore. Major hardware failure and emergency web site upgrade prompted a call back to us for our piece. Nothing like wrestling with detailed configuration documentation last updated in 2002-03 to reconnect everything up.
This conjunction of the NTEN new and some clients' old brings me back to one of the most confusing terms in technology planning -- “legacy system.” I used to think legacy system meant something specific. Like using non-relational databases—don't get me started on that. Now it seems like it can refer to anything that is in place, operating smoothly, yet old and somewhat a mystery. One person’s target of opportunity is someone else's bastion of reliability.
Folks in our position find ourselves urging “no” to the new as often as “yes.” Just because something is old doesn't mean it needs to be replaced. You just don't want to wait too long.
Reflecting on both my fun situations of the week on my way out to NTC, I condensed the kinds of evaluation questions that could go into deciding when that database or web system of yours is not just old or legacy, but genuinely in need of elements of the new. (Again, these are considerations separate from new needs or changing strategy.)
Heading out to NTEN.org's annual Nonprofit Technology Conference, my mind is generally on what's new and useful. Lots of sharing to make the best choices when organizations outgrow their systems, know it, need to figure out what comes next, and how to make it last. And it's interesting times for this, with software and Internet infrastructure evolving so fast now.
Where old systems clash with new strategies or programs, solutions may be complex, but at least everyone knows change has to come.
I also have been thinking about other situations where technology continues to soldier on year after year, meeting important needs with occasional adjustment and improvement. Two strange encounters with the persistence of the old kept me on the edge this week before leaving town.
In one case, I unexpectedly heard from an organization where years ago we programmed a complex integration scenario between their web site and back end data system. Daily work depended on tools which now have not been updated in years, and were no longer well-supported by the vendor. But they kept running and over the years, and we hardly heard from these folks anymore. Major hardware failure and emergency web site upgrade prompted a call back to us for our piece. Nothing like wrestling with detailed configuration documentation last updated in 2002-03 to reconnect everything up.
This conjunction of the NTEN new and some clients' old brings me back to one of the most confusing terms in technology planning -- “legacy system.” I used to think legacy system meant something specific. Like using non-relational databases—don't get me started on that. Now it seems like it can refer to anything that is in place, operating smoothly, yet old and somewhat a mystery. One person’s target of opportunity is someone else's bastion of reliability.
Folks in our position find ourselves urging “no” to the new as often as “yes.” Just because something is old doesn't mean it needs to be replaced. You just don't want to wait too long.
Reflecting on both my fun situations of the week on my way out to NTC, I condensed the kinds of evaluation questions that could go into deciding when that database or web system of yours is not just old or legacy, but genuinely in need of elements of the new. (Again, these are considerations separate from new needs or changing strategy.)
- How well does it integrate into other systems? Today, we want our data to move freely and serve flexible needs. While it has always been possible to get alien systems to talk to each other, newer, lighter weight web services can make a huge difference to organizations in a community network, for supporting researchers and advocates, or closing the loop on registrations, orders and supplies. The more you depend on such things, the more you want the new and fresh and not the obscure and cumbersome.
- How hard or easy is it to get support from the software's creator or vendor or to talented developers who can work on it, either as staff or consultants? This is one differentiator, say, between Microsoft Access and Filemaker Pro, and in the future it will be between emerging web platforms like Salesforce and older networked based databases.
- Does the system require special hardware or software, which may make it hard to maintain. Fundraising software no longer supported on Macs comes to mind, or web software that works better on Windows Server 2000 than on Server 2003 and beyond. Related, as commercial web hosting continues to get cheaper and easier, how portable is your software to the Internet “cloud”? This can be an issue of budgeting, support, not to mention your carbon footprint.
- How much has your software become a “black box”--software for which you have limited technical documentation and few staff with much understanding of what is there. Some customized code may be so complex and obscure that even though it works and even though you have the source code, it might be easier to start over than to embark on learning enough to make changes
- Are you burdened with proprietary licensing and formats that you no longer can have full confidence in. Though not an argument in itself for Open Source, it is one of the advantages offered by well-supported Open Source software, like the CMS projects analyzed in idealware's recent report.

