New Views on Integrating Legacy Systems


Whatever shall we do with legacy systems?


It's an IT conundrum. They're big, bulky and stuffed with useful data-and, try as you might, legacy systems just won't play well with modern applications and systems.


An oft-cited statistic is that 75 percent of the world's business data is processed on mainframes-and in Cobol, no less. According to this CIO blog post on integrating mainframes, around 30 plus billion transactions are processed on worldwide mainframes each day.


Is it any wonder there's a lot of stress over legacy integration?


It's one of the major reasons why SOA continues to be of interest to organizations, despite its fallen status in the hype cycle. In fact, legacy application integration is one of the main drivers for SOA, according to a recent TechTarget survey, which found that 32 percent of companies cited this particular benefit as one goal they hoped to accomplish with SOA. Integration in general turned out to be a big factor in SOA projects, with 32 percent also hoping to improve data integration and 23 percent hoping to integrate disparate department applications.


I've written before about how SOA can be applied to legacy integration, but lately I've seen several articles on how to integrate legacy systems, and I've noticed a trend to focus more on integrating mainframes without service-enabling them or attempting to actually migrate away from the legacy system.


The first time I saw this idea of leaving legacy systems well-enough alone was this CXO Today Q&A with Shailender Kumar, vice president, Oracle Fusion Middleware of Oracle India. Usually, when people talk about SOA, they talk about service-enabling, but Kumar made the rather unusual observation that you don't have to service-enable everything:


"There is, however, a myth associated with this technology that unless one has a service-enabled application, one can't do SOA - which is not true. ... For example, if you have an application that is service-enabled, and a whole bunch of applications that are not service-enabled, you can still connect these by deploying adapters. Once they realize that, they start to see where SOA can fit in bringing connectivity between diverse transaction engines."


Joe McKendrick also wrote a post on this interview, specifically pointing out that you can have legacy systems, modern systems, middleware and message brokering mixed in with service-enabled systems, noting that even the most advanced SOA-savvy companies only have 20 percent of their portfolio SOA-ready.


Finally, I found the CIO.com post I mentioned earlier. It's written by Niroj Pradhan, who lists his areas of expertise as mainframe, design and architecture. I wish I could tell you more about Pradhan, but I couldn't track him down and he didn't have e-mails enabled on his CIO.com contact information.


Regardless of his credentials, his post is good fodder for thought. He contends that IT would be better off focusing on mashups, SOA and Web 2.0 as a better option for integrating with mainframes and legacy systems.


"Organizations have successfully integrated the legacy system with other platforms and web, but most of them have used the conventional integration techniques. Most of them use non-open standard protocols. The contract breaks when there is a change either on the host side or on the interface side. ... The point to point connections increase complexity of integration when the number of application increases. "


But are mashups and other Web 2.0 tools enough? I'd love to hear your take. Feel free to e-mail me or post below.