What do you do when customers demand access to information that's housed in legacy systems that are decidedly not ready for prime-time viewing?
If you're Kevin Roden, you integrate.
Roden, the CIO at Iron Mountain Inc., a Boston-based data protection and records management company, used Web services to tie his core legacy applications -- including records management and transportation scheduling software -- to a data warehouse with a Web-based front end. Now, customers can access their information, and Roden can continue using his custom applications in peace.
"We had to figure out how to preserve the legacy applications, which still run quite well, while addressing the new needs of our customers, who want access to information," he said. "We invested a lot of time and money into those applications, and we didn't want to have to rip them apart."
But by integrating an extraction layer with the core applications, Roden can have his cake and eat it, too.
Roden is not alone in his dilemma. CIOs across the country must wrestle with integration issues involving legacy systems and new applications. Even in a wintry economic climate marked by flat-lining technology budgets, legacy system integration remains on the "spend" list. In fact, a recent study of more than 200 IT executives by Mercator Software Inc. and research firm DRG Group found that the top integration spending priority was legacy systems integration. AMR Research in Boston said that large companies spent an average of about $3 million on integration projects last year, while midsized organizations tossed about $1.1 million into the integration pot.
With that much money at stake, it makes sense for CIOs to protect their investments, and a little research can help. After all, there are many types of integration, just as there are many business drivers behind these projects. The following steps to success can help the wise CIO maximize the chances for success.
First, verify the need
It may be that a legacy system integration isn't necessary at all. Shutting down the system altogether and switching to a new application might be the solution. AMR Research Inc.'s Kimberly Knickle said there are two schools of thought on this: "Some people want to avoid integration at all costs and really just want to shut off the old application." Others, she said, want to keep the data and keep integrating as they add new applications.
What makes people choose one or the other? Cost is a big factor -- it's expensive to integrate and to maintain legacy systems.
"If a legacy system is poorly built to begin with, sometimes it's throwing good money after bad to keep them going," Roden said. "You need to understand the costs of building a new system from scratch, including retooling the entire operation if you choose not to keep the legacy environment."
Sometimes, companies' hands are forced, Knickle said. Vendors upgrade platforms and systems and stop supporting the old ones, so CIOs should consider the long-term viability of a legacy system before they spend money to integrate it.
Fit the integration type to the business driver
There are different types of integration, and they all come at varying price points. Real-time integration, for example, which changes and upgrades the information throughout integrated systems the instant a change is made, is the most complex -- and therefore the most expensive. But there are other levels of integration that are less costly, although they aren't as comprehensive. "The level of integration must be driven by business needs. You don't always need real-time integration," Knickle pointed out. "Sometimes you can just kick data into a central database where you can analyze it."
The key is to fit the integration type to the particular business need that underlies the project. "Build a business case first," said Andrew Efstathiou, program manager at the technology management strategy group of Yankee Group, a Boston-based research company. "Once you do that, you can start architecting a solution that spells out the different components and what type of integration the business case requires."
Kevin RodenCIO, Iron Mountain Inc.
For example, certain systems at a hospital, such as those needed to order X-rays, need to work in real time, since a patient's health is at stake. But a system like billing can easily survive on batch updates.
Efstathiou said that the architecture plan should also take into account what legacy system integration plan would be least disruptive to the existing environment, and what types will allow further development. "It should be like a road map to the future," he said.
What should it not be? Tech for technology's sake. "You really need to make sure you're building something that the customers need, and not something that the technology people think is slick," Roden said.
Make sure the data is clean
One of the big issues of integrating systems is what Knickle calls "data semantics": "You have to make sure that things are defined the same way -- that an order means the same thing to both systems, for example."
The data must also be scrubbed to make sure that things like redundant records and typing errors are eliminated. "It's a lot of work that involves really meticulous cleansing processes," Knickle said.
Watch out for system overlaps
Chances are, new packaged applications will contain some functionality that the legacy system already has. If this is the case, CIOs need to decide which system will run that particular function.
Some things to consider: Is there something unique about the old system that makes its functionality superior? How much customizing will the new application require? The modular nature of new software makes this a little easier to deal with, Efstathiou said. "It means that you have to disrupt a much smaller part of the legacy system," he said.
Clearly, integration isn't going anywhere as long as legacy systems are with us. And when you consider that today's cutting-edge systems are tomorrow's legacy dinosaurs, it's not hard to figure out that integration will be with us for a long, long time. Smart CIOs will figure out how best to use integration techniques for the creation of systems that meet their companies' needs.
Carol Hildebrand is a contributing writer based in Wellesley, Mass. Let us know what you think about the story; email firstname.lastname@example.org.
Brush up on top eight data integration buzzwords