Application Integration in Action

• 04/07/1999

The technical possibilities for application integration can be intimidating. After all, a task as critical as establishing communications between discrete applications presents nearly as many risks as rewards.

Yet numerous Windows NT sites have overcome their hesitation and implemented application integration solutions. Some purchased off-the-shelf solutions; others developed homegrown technology to wrap around commercial products. But all seem to be achieving measurable benefits from their efforts.

Users of application integration solutions are often sites with legacy systems or IT networks that communicate with the diverse systems of internal or external customers. As a result, NT is not commonly the residence of applications required to communicate. Instead, these sites use NT as the server that hosts application integration technology. For some, application integration solutions improve efficiencies. Others expect to save money and generate additional business as their implementations are launched onto production systems.

The implementation of application integration technology is growing across the marketplace. IT managers in government, as well as the finance, transportation, field service, insurance and pharmaceuticals industries commented on the trend. For each of these managers, the applications involved are less important than the need for intra- and inter-enterprise communication. The three studies below highlight some of the application integration strategies being pursued.

Sharing data across discrete divisions or departments of an organization may be the least complex application integration scenario -- but that is not to say it is simple.

A few years ago, the Information Technology Division (ITD) of the Commonwealth of Massachusetts began investigating a strategy that would allow statewide agencies to communicate and share data among IT systems. Certain data exchanges were mandatory to fulfill an agency’s mission, while others offered potential benefits for departments, state residents and the state budget, explains Anna dos Santos, director of the enterprise applications bureau.

Because the need for integration was a widespread issue, a central IT solution was mandated. The ITD hired a vendor to help evaluate needs, products and technology options. Together they selected the MQSeries from IBM Corp. to act as a message broker among the discrete applications.

As a pilot application, instituted about a year ago, ITD wanted to transfer data between the Department of Transitional Assistance (DTA) and the Department of Revenues (DoR). The application, called "wage matching," provides the wage data reported to the DoR by welfare recipients to the DTA, which uses the information to check if a recipient is eligible for benefits.

In the old system, tapes were physically transported between the agencies, which are located in different towns. It was a process that took days to complete, dos Santos says.

Both departments were eager to implement an online, real-time solution, but the DoR did not want to expose its Unisys mainframe to access by MQSeries. ITD solved the problem by installing an NT-based front end to process the DTA data before sending it to the mainframe.

ITD wrote the front end -- a communications bridge that it calls "Commbridge" -- as an API to MQSeries. ITD developers now write to Commbridge, which resides primarily on NT servers as well as the Unisys and IBM machines, rather than to MQSeries.

"Developers can write a file of data and send it. They don’t need to understand all of the options of MQSeries or the communications protocols," dos Santos says. In addition, the department incorporated some additional functionality into Commbridge, such as server lookups, that help the application integration process run more smoothly.

ITD has not calculated the final ROI for the project, but dos Santos says the benefits are obvious. The multiday transfer process has been reduced to minutes, producing faster decisions and simpler fraud detection. As a result, the MQSeries/Commbridge solution is being rolled out to other departments.

The solution was not without difficulty, dos Santos says. Initially IT managers attempted to connect to the IBM mainframe via APPC. "I’d never try that again," she says, noting that they eventually implemented TCP/IP on the mainframe.

Firewall issues on the DoR system also made for a rocky start. In the end, they implemented a security product on the NT server that encrypts and decrypts sensitive files as they pass from one system to another.

After a year of effort, the pilot is a success. "We were lucky enough to pick a vendor with the experience and breadth of understanding to make this work," dos Santos says. "The developers can’t believe how easy it is."

Many NT sites implementing application integration solutions are using IBM’s MQSeries, not only because of legacy IBM systems on site, but also because the product was one of the first on the market.

One MQSeries user in the financial sector is Capital Bank, a Bank of Scotland Group company operating in Chester, England. Like the Commonwealth of Massachusetts, Capital Bank recognized the need for application integration after a comprehensive business systems review.

IT managers determined that seamless integration -- with both internal systems and external customers -- was necessary to fulfill the company’s vision for future applications and to create a forward-reaching technical architecture. Middleware was the linchpin of this vision, and Capital Bank selected MQSeries as a message broker and Copernicus from VIE Systems Inc. (www.viesystems.com) to extract and convert data using reusable code-based methods.

The bank’s pilot implementation of the technology was applied to its financing of automobile leases and purchases. In the United Kingdom, automobile dealers who want to secure financing for customers have access to multiple financial houses. Dealers request financing terms from different financiers, and the bank that responds first usually gets the business, explains John Callan, general manager of systems development at Capital Bank.

Each group of automobile dealers uses different network access mechanisms and data types, making integration a time-consuming, complex process. In the pilot project, Capital Bank used Copernicus as a front end to MQSeries. Copernicus uses prepackaged communications adapters to convert the input from dealers into a format that the existing host applications can handle.

The Copernicus-MQSeries solution reduced turnaround time from two minutes to 30 seconds, which is "likely to be a major benefit for us," Callan says.

As the bank continues to grow and work with an expanding network of dealers, the ability to bring new partners into the network is one of the biggest benefits of Copernicus, Callan adds. "It doesn’t matter what protocol or message format they use. We can handle it," he says.

Copernicus is marketed as a GUI-driven tool that minimizes the amount of coding that must be written by developers. But the need for programming is inevitable. "You must leave time to perform a certain amount of customization," Callan says.

The pilot program for automobile financing will go live in June. Callan expects to see immediate benefits in efficiency, as well as the generation of additional business opportunities. In the near future, Capital Bank will extend the application integration technology to additional projects, he says.

Perhaps the most challenging application integration task is creating a communications path between an internal corporate application and external customer applications. When a critical customer asked for this type of integration, Grumman Systems Support Corp. (www.northgrum.com/gssc), a division of Northrup Grumman, was determined to say yes.

Grumman is an independent IT service organization that provides field service for desktop and midrange systems. Most of its customers are large systems integrators and customers with mission-critical service requirements.

Grumman has a call center where customers can report problems. The call center issues work orders to field representatives by keying in the telephoned data. But one Grumman client wanted an automatic, electronic, real-time Internet connection to Grumman’s call center to speed repair time and enhance efficiency.

Grumman uses an application from Astea International (www.astea.com) called Dispatch-1 to generate work orders. The application is based on proprietary technology, but there are few published APIs that could enable integration with other applications, according to Mitchell Portnoy, director of customer service at Grumman.

What was needed, Portnoy says, was an open solution that could work with both Dispatch-1 and any customer's call center applications, regardless of whether the customer connected using the Internet, a dial-up connection or a private access service. Enter Mitsubishi Electronics America (www.mitsubishi.com).

Mitsubishi’s solution is based on a middleware product called Concordia, which uses agents to extract information from discrete sources and present it in forms-based screens, primarily for mobile users working on laptops. Upon Concordia, Mitsubishi built the Melba software suite, which uses Java mobile agent technology to connect applications across the Internet.

The solution built for Grumman's pilot implementation allows the customer and Grumman to pass messages about trouble reports, service calls and status reports across the Internet. The server hosting the application is an NT machine in Colorado.

The most difficult part of the process was creating an engine to communicate with the Dispatch-1 application, Portnoy says. Now that the engine is complete, Grumman and the client are focusing on getting the databases to "jive," he says.

For example, one company’s system may reference a service call, while the other uses the terms work order or ticket. Each reference to a system component or issue must have a matching reference in the opposite system for the two to communicate, Portnoy explains.

Then there is the issue of how to handle exceptions -- the most time-consuming aspect of the project. If a model or serial number for a system part does not match the listing in the partner’s system, should the system attempt to make a match? How should that time be billed? Or should the system return the request to the sender?

Answering questions like these required Grumman service managers to work extensively with developers in both organizations. "You must work out the business process," Portnoy says. "This came as a surprise to us, that it wasn’t just a simple technical solution."

Grumman is planning to go live with the technology soon. Portnoy says the new system will eliminate the need for manual monitoring and manual updates to the files, saving the company enough money to achieve an ROI within six months.

The company has three additional application integration projects in the queue for other customers, he adds. Because the major portion of the interface is developed, the work for the new partners is expected to take much less time, yet provide similar savings.