With a dodgy economy keeping capital projects on hold, one way to squeeze more juice out of existing IT infrastructure is using the data stored in legacy systems to feed and drive other applications.
And creating the availability of data across disparate systems and heterogeneous environments – from creaky CMS mainframes to COBOL-based applications – is a middleware issue, said Alister Sutherland director of software with analyst firm IDC Canada.
“When we talk about enterprise application integration we are really talking about middleware. So as new technologies take hold, for example Java has a big head of steam right now, you add this new superstructure on top of the infrastructure that already exists,” Sutherland said.
With something like 70 per cent of mission critical data and processes residing in so-called legacy and host-based systems, virtually all of the middleware and integration vendors claim seamless and easy legacy integration, said Gordon Benett, senior analyst with the Aberdeen Group in Boston.
However, there are several important considerations for leveraging legacy systems, he said.
The first is access, which has been largely solved by vendors who have created a sea of adapters that make systems that were never designed to play together open their silos and talk to a standard bus, Benett said.
Secondly, Benett said, is the interoperability problem that includes such components as host systems using non-ASCII character sets, different binary file formats and the names of data.
“What’s called a client or a customer in your host system may not be the same thing that you want your middleware bus to pipe into Siebel and SAP, so that’s more of a semantic, or data transformation problem,” he said.
A final issue that is not easily addressed by software or standards is transaction integrity, Benett said. This means ensuring that live data in a host system is at a point in the autonomous transaction where it is safe to be used. For example, ensuring that financial data is not being pulled into another application in the middle of a customer’s instant teller withdrawal.
“This issue tends to require detailed process management and it’s one of the reasons why integration is such a thorny problem and doesn’t go away no matter how much technology and how many standards organizations weigh in,” Benett said.
Although IDC’s Sutherland said that all the leading Java vendors are in the middleware business, with IBM’s MQ for WebSphere leading the way, there are also numerous specialized vendors. One such specialist is the Miami-based ClientSoft Inc., which specializes in legacy integration tools for S/390 and AS/400.
For example, the company’s ClientBuilder is a distributed platform that allows users to create and re-engineer new applications using the transactions and information that already resides in an AS/400 or mainframe, said Hugh Raiford, ClentSoft’s Atlanta-based vice-president of marketing.
Raiford said that one client, Allstate Insurance Company, which has one of the largest AS/400 server farms in North America, came to ClientSoft when they wanted to sell insurance on the Web without rebuilding all of their quoting systems and policy data in a client-server based environment.
“They were able to reuse and redeploy the technology and the business logic that already existed by using our tools to build an ASP front end using XML and the existing AS/400s as their transaction system, Raiford explained.
Another product, ClientSoft Tanit Object (CTO), is a development platform and runtime environment for IBM CICS and IMS integration on the S/390 platform, Raiford said.
“This actually performs component generation and Web services generation from within the mainframe – there’s no middle-tier transaction processor or middle-tier server. We actually generate a COBOL program as a CICS transaction that generates a Java Beans, EJB or a COM component, so that those can then be reused or part of an overall development rollout,” he said.
The functional areas of many large organizations grew up at different times, and were computerized at different times, often using the best technology available at that time, said Sutherland. All these COBOL-based or Fortran-based systems did what they were supposed to do very well, but they usually only did a few things.
Since no one wants to rip and replace, and populate new systems with existing data, the concept of using middleware to make many of these systems talk to each other is making it a big concern for the enterprise, and a big driver in the market right now, he said.
