News Stay informed about the latest enterprise technology news and product updates.

A world without legacy systems

How frustrating is it to be one of the little guys without the resources to bear for big projects. Well, those frustrations may actually be easier to deal with than the alternative: Being a large company entrenched in legacy systems.

I came across a blog post recently by Scott Adams, describing a fantasy world where countries weren’t so paralyzed by legacy systems that they couldn’t move forward. Older systems have too many vested interests, making it difficult to change because “anything that has been around for a while is a complicated and inconvenient mess compared to what its ideal form could be,” Adams wrote.

This got me thinking about the real legacy systems holding back IT: The projects that never go anywhere, not because the project itself is bad, but because the change would overwhelm the systems, strategies, processes and workflows that may not integrate with the change. How, too often, the need for agility is acknowledged, but never addressed. And, more importantly here, how the bigger you are, the more difficult it is to change.

So here’s to all the small IT shops out there, where each member of the staff wears multiple hats and puts in the extra hours because, let’s face it, who else will? Being smaller means you’re closer to the top, closer to making a difference. Yes, your budget is probably smaller and you can’t get to all the things you know you need to tackle, but there are also far fewer hoops to jump through and approval signatures to get.

If you take all of that into consideration, maybe the grass is greener on this side: You can quickly adopt new technologies and there is less red tape. And you probably aren’t so buried in legacy systems that every infrastructure change requires duct tape and a sprinkle of IT magic to get it working.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Kristen, I second this completely. I spent a good portion of my previous life with big consulting firms helping customers to jump from legacy apps to new systems all the time; only to find out a year later that the "new" system had become a legacy itself. Fierce M&A activities in mid-90s and Oracle shopping spree definitely fueled this practice for years. Some consulting companies built their practices around converting legacy apps. I think the two main issue remains to be solved before the legacy problem and vendor dependency in general can be addressed: that is data portability with universal access. Open source software never completely addressed this problem because they focused on the application themselves and not on the underlying data. The new solution which emerged recently, I believe, can actually address the vendor dependency and legacy upgrade treadmill by making access to the legacy data universal: its called data virtualization (DV). DV can actually "unleash" enterprise data from being locked in silos and application repositories, without the need to go costly and length data warehouse route or in fact having to move the legacy data anywhere. Once you solve the data dependency and data lock in problems - you are not dependent on the legacy anymore as the data becomes portable to any application. In fact, the value of the apps becomes de-emphasized while portability of the data, universal secure data access and metadata catalog creation including secure access permissions becomes the king. Don't mean to plug anybody in here but take a look at the pioneers in this space which will go far, like a Sunnyvale start up [A href=""]Queplix[/A], or Composite or Denodo.
The proper definition of a legacy system is “one that works.” As soon as the whiz bang new system you’re contrasting with some bad old “legacy” system goes into production, it becomes a legacy system too; and someone will start complaining about it immediately.
Robin, while I agree with your comment in practical terms, I find it rather funny :) Since this is a CIO forum and being one myself, i think I look at the way CIOs define legacy apps: legacy app is the one whose vendor had been acquired, the product has been decommissioned or has limited to no support options and no future upgrades with limited migration path. I do agree that a lot of the "black boxed" CRM systems for example become legacies the moment they are deployed in production. This is actually done by design and achieved through vendor lock in and most importantly by jailing your data in proprietary formats without any portability or providing a secure and universal access to the information from the outside (other apps). This is a real problem which applies to both stand alone applications and application development platforms.