Middleware in Action

• 07/19/1999

Special Report: Middleware

During the past two years, middleware has evolved from an esoteric, under-the-covers programming tool to a strategic technology that helps NT sites bridge the gaps from legacy systems to client/server, from host machines to the Web and from internal networks to e-commerce systems. Middleware may sit "in the middle" of connected applications, but it is on the leading edge of NT connectivity and enhancing competitive advantage.

Yet, as with many hot technologies, the marketing buzz often differs from the realities of implementing and optimizing a solution under real-world conditions.

ENT interviewed the managers of three NT sites to find out how and why they implemented middleware technology, where they experienced difficulties, what they learned and what benefits their organizations derived from using middleware.

At the University of Tennessee in Knoxville (UTK, www.utk.edu), student information on 19,000 undergraduate and 7,000 graduate students resides on numerous discrete DB2 databases on mainframes from IBM Corp. Various departments within the university track student identification numbers, along with demographic, biographic and billing information.

For students, this system required any data changes -- such as a new address or phone number -- to be submitted to each department tracking the data. For the university, the unconnected databases meant some information was current and some was incomplete or inaccurate, potentially jeopardizing state funding for minorities or veterans.

The university's Division of Information Infrastructure (DII), which has the responsibility for developing business applications for each university department, was charged with finding a way to coordinate the DB2 data and make the data accurate, centralized and available to all departments. The unit was also charged with investigating the potential for allowing students to enter their own updates using PCs or the Web.

The business-critical nature of the mainframe data, however, made DII personnel leery of allowing all departments and students direct data access. To ensure security and integrity of the mainframe data, DII needed a safe access method. The solution was to use middleware to replicate some of the data to SQL Servers, then allow broader access to those servers, explains David C. Stinnett, senior systems analyst and team leader with DII.

UTK connected the IBM mainframes to NT servers using Microsoft Corp.'s SNA Server. The DB2 data was replicated to SQL Server databases hosted on NT servers using StarQuest Data Replicator from StarQuest Software Inc. (www.starquest.com). The StarQuest product provides bidirectional snapshot replication between UTK’s DB2 databases.

With the new system, changes can be entered into any of the connected university databases. The changed data in the distributed databases is replicated daily and sent to the central database. The central database applies the changes, replicates the updated data, and feeds it back to the distributed databases at a rate of up to 90 KBps.

The StarQuest application replicates between 1 million and 2 million rows of data daily from the mainframe to the NT servers. The process is creating a more accurate centralized database with higher integrity and improved departmental efficiencies, Stinnett says. "This way we centralize the trouble and distribute the successes."

Through the new system, students can change their address, check invoice information and access the teacher certification system. Students cannot directly change data, and all data is checked before being committed to protect data integrity.

UTK also developed a Web interface to the database using Microsoft’s Internet Information Server (IIS). The interface allows students to validate identification numbers and apply to graduate school. Additional functionality -- including the possibility of an independent study system -- is developing as needs are identified.

Including new hardware and software purchases, UTK spent about $20,000 to solve the problem, Stinnett calculates.

"Now we can report accurately on our minority and veteran population. How do you put a price on that? It’s huge to us," he says.

The only difficulty in applying the middleware solution was nontechnical; it was gathering the right university personnel and making the business process decisions to support the new solution. Stinnett says UTK’s database problems and the solution required leveraging the talents of staffers with mainframe, DB2 and NT experience. "The hardest part can be getting people to work together," he says.

Corporations that create intranets for business partners can quickly find themselves positioned as technology experts. This is especially true when the intranet is driven by the corporation and its partners’ expertise lies outside of IT.

For Central Insurance Companies (www.central-insurance.com), a provider of commercial insurance products, implementing an intranet that its 600 agents could use to connect to the company’s host systems was a challenge on several levels.

Agents nationwide wanted the advantage of being able to quote a prospective customer a rate for insurance within moments of submitting a request for coverage. Yet few of Central Insurance’s agents had significant computer experience: Only 35 had Internet access.

Commercial insurance companies rarely offer this kind of database access, which has prevented the company from building on existing experience. Two years ago, when Central Insurance first began investigating the available middleware technology that could connect its legacy databases to agents’ computers, few vendors had proven products.

"Our business plan was to offer a connection between independent agents representing Central and our IBM host systems. The Internet provided network availability that we needed to make the connection with our agencies. But we needed middleware to connect the browser and host system. The market was limited," explains Gary Corcoran, assistant vice president at Central Insurance.

The company chose Amazon, a legacy-to-Web integration middleware product from Intelligent Environments Inc. (www.ieinc.com). Running on NT servers, Amazon provides a transparent connection to the company’s 3270-based forms.

Developers at Central Insurance spent three months creating Amazon-enabled applications that allowed agents to log onto the insurance company’s Web site. The first application enabled agents to complete a dynamic quote application form.

Amazon uses a 3270 emulator to interpret and extract data from the completed form. It then collects information from the host system and assembles a rating and a premium for the prospective customer.

With the old paper-based system, a quote forwarded to Central Insurance was typically returned to the customer in five to seven working days. The new system returns a quote in about five minutes. It also faxes the agent a copy of the information and sends updated quotes and premiums when a policy is due for renewal.

The most difficult part of the implementation was supporting the technology needs of the agents. An Internet services group traveled to agencies nationwide to train agents on how to use the system, helping them get connected to the Internet and to the display forms, explains Larry Streets, senior programmer analyst at the company's Internet/intranet group. "As soon as they displayed the first form, we backed away from the PC" to watch how they used it and where they had difficulty.

In retrospect, Streets says the developers could have saved time by soliciting additional input from internal users and agents. Requests for changes to the form caused the developers to revise it several times. With the new form, "the training time for agents is zip," Streets says.

Currently, more than 100 agents have Internet-based access to the host system, a number the company expects to grow. Also expanding is the number of applications run on the middleware-based system. The company recently implemented an application that accepts first notice of loss for automotive policies and is working on applications to modify quotations and provide access to billing records.

For Bank Handlowy, the largest commercial bank in Poland, finely tuned IT support has become a competitive advantage.

The $1 billion institution has automated its paper-based dealer system, in which the bank’s dealers recorded transactions such as foreign exchange swaps, spots, forwards, and money market loans and deposits. Under the old system, dealers recorded the transactions on deal tickets, which were entered into an AS/400 DB2 database as a separate administrative function.

To enable the dealers to enter their own trades into the system, the bank implemented the Kondor+ front office system from Reuters Group P.L.C., which runs on a Sun Unix platform and uses a Sybase relational database. But the bank still wanted the information entered into the AS/400-based general ledger system, called IBIS/AS.

Middleware software was needed to process and reformat the Kondor+ data and insert it into the IBIS/AS system. When the search began nearly two years ago, online middleware solutions were scarce.

The bank issued a request for information and drew 10 responses from middleware vendors. A proof of concept workshop for the message-driven tools cut the list down to three prospective solutions, explains Maria Piotrowicz, director of money and capital and market systems bureau in the bank's IT department.

The three vendors were given a list of specifications and asked to build a solution within two days. "Only HIE was able to build the system in two days," she says. Its Cloverleaf finance product supports different protocols and can read and write both to and from the database -- critical features for the banking industry, Piotrowicz says.

The bank installed Cloverleaf finance on an NT server and built the complete solution within one month, says Slawek Lokaj, IT specialist at Bank Handlowy.

The new system uses ODBC to collect information from the Kondor+ database system. Cloverleaf finance checks Kondor+ every 10 minutes, translating any new information and writing it to the IBIS/AS system within moments. Helping with the coordination of data between the two systems is a data reconciliation interface that was also built using Cloverleaf finance.

Since the initial implementation, the bank has built several additional interfaces using Cloverleaf finance and has also enhanced the original interface. "We like that we can still control the system," Lokaj says. "We don’t have to rely on the vendor for every change. And that is very important to us."

The bank is satisfied with the connectivity Cloverleaf finance provides between the additional applications and the main banking system. "It’s quite easy to do and also quite powerful," he says.

The bank plans to continue using Cloverleaf finance for future middleware-based integration projects. The biggest one may come if the bank merges with another financial institution, always a possibility in today’s European banking community.

"We are experienced now in middleware technology," Piotrowicz says. "If a merger happens, it will be easier to integrate the systems and have a completely integrated environment."