There's been a lot of hoopla over Generation Y and their wish for-nay, demand for-Web 2.0 functions in business. "They'll expect it," we've been warned.
Yeah, well I'm Generation X, the generation that brought foosball to work not so much because we wanted to play as we moved into our offices and never left. I'm still expecting my 40-hour work week, guaranteed retirement and a flying car; you can guess how far that's gotten me.
As it turns out, the workplace has its own expectations, and I suspect more than a few Gen Yers will be disappointed to learn this one: Boomers are handing over the maintenance of legacy applications to Gen Y before shuffling off to Florida for their retirement. (And slamming the retirement door shut behind them, I might add.)
Sometimes, these legacy applications are being offloaded to outsourcers, but again, as the ComputerWorld column notes, it's still young engineers doing the support.
The piece is written by Unisys' CTO for Application Services business Ravi Karanam and the Vice President for Application Services business, Cem Tanyel, both of whom outline how they've managed to support these legacy applications without the traditional knowledge transfers, such as interviews or documentation.
This issue of maintaining systems when the engineers and developers who built them are retiring is just another facet of the problems companies face when it comes to legacy applications. Legacy systems are also unquestionably expensive to maintain, although just how expensive is a bit difficult to calculate.
But there are other ways to cope with legacy applications besides outsourcing, or burdening Generation Y. Recently, I've run across several items about how to cope with or eliminate legacy systems. This isn't meant to be a comprehensive list, but fodder for thought.
One option: Retire the system. This may seem obvious, but sometimes, the legacy system are maintained because of concerns about the information the application maintains, rather than the actual application. Although it's a bit self-serving, Open Text, an enterprise content management company, recently offered a free white paper about best practices for archiving data contained in legacy systems.
"Archiving is a means of managing the lifecycle requirements for legacy data rather than continuing to support and maintain the source business system," the paper explains. "For that reason, this best practices paper refers to archiving as a potential supporting mechanism for application decommissioning."
If you're holding onto a legacy systems just to meet reporting and compliance requirements, you might want to read this free paper to learn how archiving can support decommissioning legacy apps.
A second option: Cut costs on supporting legacy systems by standardizing your data integration approach across enterprise applications.
A recent Business Standard article cites a Ventana Research report stating systems older than 10 years old can "drive more than one-third of underlying business processes," but your IT operating budget is taking a hit from maintaining all of those point-to-point integrations. Standardizing on a data integration approach can reduce your costs, allowing you to cut the number of IT staffers required to support these integrations. Certainly, that would reduce costs, although the estimated cost savings of $800,000 in the first year and $1 million in the second year seems a bit high.
The article also discusses how you can cut costs by automating data archiving using data integration technologies. This saves money by eliminating custom interfaces. Ventana estimates you can save as much as $1 million annually in specialized labor and archiving tools just by cutting six custom interfaces.
The full report, which actually was released in October, includes other examples of how information lifecycle management and standardizing on data integration can save you money. It's available for free download on Informatica's site, with the usual information requirements.
Option three: SOA. I've written about how SOA can help with legacy integration previously, including "Four ways to use SOA to integrate legacy systems" and "Legacy Integration a Good 'First Step' for SOA." The Coast Guard is one example of an organization that used SOA to update it's legacy systems.
Companies have also used SOA as a means of retiring legacy systems, as this recent Network World article shows. For 40 years, Union Pacific Railroad relied on an IBM mainframe running 11 million lines of macro assembler code for its transportation control system. As you can imagine, support had become a bit of a challenge, and it wasn't exactly what you'd call an easily customized, agile system.
The new service-oriented system is being introduced in phases, but-and this should surprise no one-it seems to be paying off in ways large and small. For instance, it used to take 10 weeks to train a customer service rep, reports Network World, but Union Pacific thinks it'll shave off four weeks, thanks to a more intuitive interface.
It does make me a bit sad, though, realizing a whole generation will be raised on the easy interfaces of Facebook and iPhones and will never experience the unearthly green glow of a mainframe interface.