Middleware Goes Mainstream
The expansion of middleware can help your company Web-enable its applications for e-commerce and other Internet-related functions.
Middleware, that catch-all term within the enterprise, is seeing a resurgence as enterprises work to connect new Web-based systems with diverse legacy back-ends. And although the need for a middleware connection layer is widely apparent, many companies have yet to fully incorporate middleware technology—mostly because it can be complex and expensive.
Middleware has been used within the enterprise for several years to connect similar databases to different types of systems. Today, companies need technologies that will Web-enable their applications to take advantage of e-commerce and other Internet-related functionality. That might mean integrating WAP or TCP/IP with C++, COBOL, and many other languages and technologies.
According to Forrester Research, 72 percent of big businesses realize that successful e-commerce depends on integrating both internal and external applications and systems. Yet, only one quarter of these businesses have actually taken the necessary steps toward integration. The primary reasons? Cost and complexity.
During the height of the Internet economy obsession, most
companies focused on business-to-consumer interactions. "Last year, everyone was focused on having the slickest, easiest-to-use Web sites," explains John Sheaffer, CEO of Sysix Technologies. "Now, the focus is on business-to-business e-commerce. Businesses buy online to save time, but they also want to make sure that these [front-end purchasing] systems work with their back-end systems."
No single middleware product can do everything. Most companies will need to implement multiple types of middleware, each for particular applications. "Good middleware for some users may not be good middleware for other situations," says Dan Foody, chief technical officer for Actional Corp. "Some [programs] have good reliability but slow throughput, while other middleware is much faster but less reliable."
Companies need to remember that "middleware is just a means to an end, not an end in itself," Foody cautions. "Just because it works in one area of a company doesn't mean the company should use only one [middleware technology] throughout the company. In fact, I can't think of a single large company that is standardized on only one middleware package."
The key is to select the most flexible, scalable and adaptable system. For example, political news providers thought their systems would need to support high volumes only until the November 4, 2000 presidential elections. But with the disputed Florida votes, theyand their middlewarehad to scale to support as much news during the weeks after Election Day as before it.
P.B. & T.M.
Moving B-to-C to B-to-B
Many dotcoms built their technology from the ground up. Integration with other systems wasn't a concern, because the systemslike the companieswere brand-new. Surviving companies have refocused on traditional business principles. They want to make sure that disparate front- and back-end technologies work together seamlessly. They need to extract the most efficiency from their internal systems and provide greater economies throughout the business supply chain.
Companies are moving middleware beyond the core of their own computing infrastructures to encompass more aspects of the network and, in some instances, to include suppliers, vendors, customers and others outside of the company. "Companies are implementing e-business models across multiple systems," says Assaf Kedem, director of product marketing for Intercomp. "Companies need to tie everything together to operate as a whole."
A major barrier to cross-company integration isn't technology, however, it's people. Unless both sides perceive value in the integration, it will be nearly impossible to implement. Adam Griessman, CEO of Universal Data Interface Corp. (UDICo) agrees. "The hardest thing to do is to change a customer's behavior."
Adding XML to the Mix
The introduction of eXtensible Markup Language (XML) has helped bring middleware technology to the Web. "A year ago, most companies were developing their XML strategies," explains Hugh Tamassia, chief technology officer for middleware provider ESPS. "Now, they are starting to implement those strategies."
Enterprise Java Beans and J2EE (the second version of Java Enterprise Edition) are also being used in conjunction with XML to provide better connectivity between disparate systems. "Prior to XML, trying to get Microsoft's COM applications to communicate with Java was a nightmare," Tamassia adds.
UDICo created an XML-based middleware technology that maps non-XML information to the XML format. Using this technology, companies can gather information from disparate back-end systems and display it on their Web storefronts, WAP phones or handheld devices.
The need to connect mixed programs was also one of the driving forces behind Simple Object Access Protocol (SOAP), developed by IBM to permit better communication between various programming objects.
As Middleware Matures
As middleware continues to mature, some business-to-business exchanges will merge or fade away. For example, as companies adopt eXtensible Markup Language (XML) and other Web-based standards, procurement will become more automated. This will reduce the need for companies to go through third-party exchanges.
Although XML is a Web-based middleware enabler, it's a relatively recent technology that's still evolving to meet some of its promises. The protocol is still somewhat slow, and it has yet to reach the efficiency level that companies need in middleware.
Another XML drawback is that it doesn't guarantee delivery of the communication. Expect to see further integration of XML and Java 2 Enterprise Edition (J2EE). This would enhance the sharing of business programming objects and better communications between systems from different vendors.
As XML evolves, future middleware will help companies integrate and distribute applications with business partners. The next generation of middleware will better support distributed corporate architectures and offer more processing capabilities and inherent intelligence.
P.B. & T.M.
Merging Companies and Systems
Company mergers and acquisitions also drive the need to connect disparate systems arises not only from the acquisition of new technology but also from company mergers and acquisitions. Corporations must either link the technology of the pre-merger firms or rebuild everything from the ground up, which is an expensive solution.
Nowhere is this more true than in the financial services area, where the more than 12,000 U.S. banks of just a few years ago have shrunk to approximately 8,000 today, with further consolidation expected. The remaining companies must merge their formerly separate hardware and software while pushing everything online, where the most profitable customers are.
The financial services arena uses its own version of XML, called XFS, to communicate from internal banking systems to customers and employees using browsers to access data.
"The use of middleware reduces the integration time of the disparate technologies and cuts the development time of new [applications]," explains Steven Lund, vice president of worldwide sales for Nexus Software Inc., a software provider specializing in open retail banking solutions. "Financial institutions are using XFS to Web-enable non-traditional products (items other than basic checking and deposit products) and to provide one-to-one marketing capabilities," Lund adds.
Middleware in Action: Anglo Irish Bank Corp.
Anglo Irish Bank Corp. Plc, a major European bank traded on the London and Dublin stock exchanges, was facing a challenge in upgrading its legacy COBOL applications. Over the years, these applications had simply become outmoded.
They were written in ACUCOBOL, an outdated dialect of COBOL that few programmers know. The data tier was based on the heritage Indexed Sequential Access Method (ISAM) for organizing and retrieving the bank's data. This method simply could not perform at the required level.
The age and complexity of the bank's applications posed maintenance problems for the staff, most of whom lacked the necessary understanding and knowledge to address system overhaul initiatives.
The bank decided to install an application based on a more common dialect than ACUCOBOL. It would offer more functionality able to interact with other programs and tiers and ease the software maintenance and development burden on the staff.
The bank also decided to transform and restructure its existing ISAM-based data systems into a relational-type database schema. This would increase database efficiency and performance, while overcoming the current system's scalability limitations and record-locking problems.
Finally, Anglo Irish Bank decided to centralize its data to enable easier access from various sources, such as FTP and messaging. After analyzing its options, the bank decided to work with Intercomp.
The first task was to analyze the bank's 2.5 million lines of code within five weeks. Intercomp also had to convert the bank's business rules from the ACUCOBOL dialect of COBOL to the MERANT Micro Focus dialect of COBOL. Finally, Intercomp set about migrating the existing DBS to DB2.
The bank used Intercomp's AnalyzeIT tool to survey the legacy application and its environment and provide a detailed analysis and documentation of the program code. This automated process saved the bank the time and expense of manual analysis, and it documented the flow of data between applications. In addition, AnalyzeIT helped the bank examine the impact of changes on its software and assess the COBOL dialect transition initiative.
Next, the bank used Intercomp's MineIT tool to identify and extract the business rules that defined the bank's operations and functions. MineIT was also able to zoom in on the business rules of the code, which are arguably the most critical. In the process, MineIT also facilitated the improvement of the bank's code semantics, coherence, readability and structure, for creating more manageable source. Finally, the bank used MineIT to regenerate ACUCOBOL in Micro Focus COBOL.
With the initial project completed, Anglo Irish Bank has begun leveraging the DB2 database for extracting and querying data, reporting and other tasks. The bank is considering modernizing its presentation layer for Internet/intranet deployment and may also redesign its overall architecture to create a more distributed computing infrastructure.
P.B. & T.M.
Levels of Integration
Some of the middleware in use today does only part of the job, according to Kedem. While one middleware system might take a back-end application and map it to a graphical user interface (GUI), it may not be able to go to the next step of recognizing multiple GUIs that share the same context and tying them together.
For example, a customer applying for insurance online may have to click through several screens to complete all of the necessary information, because different parts of the application come from different back-end resources. A truly efficient middleware solution would tie together these back-end engines and show the user a seamless GUI on the front-end.
"What it would do is take the data from the legacy layer and refine the layout structure before presenting the information to a front-end device," Kedem explains. "Without this step, middleware is often a bottleneck rather than a facilitator of end-to-end efficiency."
Similarly, some middleware follows a "one-to-one" approach, connecting one type of front-end to one backend. Other middleware applications can make different front-end programs look alike to the back-end, or make various back-end software appear similar on the front-end, but, again, only on a one-to-one basis.
Middleware is still evolving to address the ever-wider range of user requirements. "Middleware technology will have a powerful impact when it gets fully integrated," says Collazo. "But, it's only a tool, and like any other tool, it has to perform within the business to give the enterprise the edge."