The Trials of Migrating to a Web-Enabled Environment

These days, IT has evolved into a tangle of mainframe, mid-range and client/server systems. This confusing array of platforms, operating systems, applications, and databases adds a massive burden to IT that acts as a roadblock to corporate growth.

Non-relational databases, for instance, rarely integrate well with the enterprise reporting systems implemented by top management. Typically, such databases require extensive middleware projects to achieve some kind of interoperability. Similarly, legacy
client/server systems require a steady stream of expensive upgrades and updates to keep them functioning. Unfortunately, such fixes don’t produce an environment that is flexible or agile enough to cope with the demands of E-Commerce.

Compounding matters is the steadily diminishing supply of talent.

Programmers skilled in old 4GL languages (ADSO, Natural, IDEAL, and Mantis), for example,
have become a rarity. Even Database Administrators (DBAs) for non-relational database
platforms, such as IDMS, Datacom, and ADABAS, are few and far between.

That’s why many enterprises are moving from non-relational databases and legacy applications to modern high-performance systems.

”These old applications and databases are now reaching the end of their life cycle,” says Sue Clarke, an analyst at the Butler Group. ”In many cases, support is no longer offered for databases, and to convert to an up-to-date version would require major changes to the database structure and also the application code.”

That said, some companies have been hesitant to move to a Web-enabled environment. Migrating legacy applications and non-relational databases, after all, is no small matter. Done incorrectly, the costs can quickly outweigh the benefits. Additionally, aging systems may contain business logic that is irreplaceable. This logic must be treated with the care it deserves and fully preserved in any migration or conversion initiative.

This is definitely the case with many legacy applications running on a mainframe. The
business logic is sound and it offers the company a competitive advantage. It has performed well over the years. However, licensing fees are increasing and the number of staff to support this platform is steadily dwindling. On top of that, you can’t easily add functionality without greatly complicating the system.

Because of all of this, for many years the question of migration versus delay was answered by careful financial analysis. In some cases it proved more expensive to convert
applications to modern platforms, while in other cases the economic advantages of migration were apparent.

But e-commerce has shifted that balance.

These days, an enormous amount of business is being conducted online. As a result, many
processes have to be Web-enabled in order to satisfy customers, partners and suppliers.
Sticking with legacy platforms, therefore, has not only become more difficult to justify
financially, it is often a competitive liability.

It’s further compounded by mushrooming licensing costs, as well as worsening support for
some legacy databases and applications. Due to mergers, acquisitions, and business
fatalities, some vendors no longer support these systems. Others are charging exorbitant
fees, even though they have long since ceased to upgrade their product.

But all of this hasn’t changed the fact that web-enabling legacy applications and databases is far from a simple matter. Witness the sheer number of legacy systems still in operation today.

”If it was easy to get off these systems, most CIO’s would have done it already,” said
Dale Vecchio, research director of applications development for Gartner Group.

Options for the Web

According to Elan Barram, a database consultant and software developer for Glendale,
CA-based BarramSoft, there are several possible ways of shifting from a legacy platform to a Web-enabled application platform. They include retirement — buying an off-the-shelf
software package — manual code reengineering/rewriting — cookbook rewriting — dynamic
call translation — and conversion automation.

”While retirement or buying off-the-shelf may work in isolated cases, manual code
reengineering/rewriting is more broadly applicable but demands time and availability of
skilled resources,” says Barram.

One alternative is cookbook rewriting.

Like traditional code rewriting, the cookbook approach involves manual rewriting of code
line by line. To get around any lack of veteran programmers and engineers, it uses less
skilled labor who base their code modification decisions on a document that provides
detailed conversion instructions. Taking this route,though, is only as good as its cookbook, and there are many inadequate cookbooks out there.

As a result, human error is likely to significantly affect accuracy.

Dynamic call translation involves the use of an interface that intercepts data management
calls from the legacy system as they are executed. It then analyzes each call for content, and dynamically builds and issues a functionally equivalent SQL statement. The advantage here is that the existing code base is untouched. The disadvantage is the overhead.

It can take too much time to analyze calls and construct their equivalent. And performance suffers badly.

Automated conversion is another approach — an attempt to minimize the cost of conversion by using automated code to convert programs rapidly. Instead of manual rewrites, code-parsing routines replace source code automatically with an SQL equivalent.

This approach saves a lot of time compared to the alternatives and is much less demanding in terms of labor resources. However, most conversion tools fail to leverage the full power of modern SQL, and performance can suffer dramatically compared to the original legacy system. Hybrid approaches also have evolved, combining the accuracy of manual code rewriting with the speed and cost advantages of automated conversion.

To accomplish conversion/migration and Web-enablement, a variety of tools exist.

These include Jacada, MicroFocus EnterpriseLink, RescueWare, Seagull, BlueZone/TRansidiom/TTT/WinJa), SEEC Mosaic Studio, MSSC WorX and WebSphere.

WebSphere Case Study
Some have successfully navigated the difficult waters of a migration from a non-relational platform to a relational platform using IBM WebSphere.

This set of tools makes it possible to Web-enable legacy applications without losing any
functionality embedded within current business processes. By centralizing on a relational
database platform and Web-enabling existing applications, operating costs can be
dramatically reduced. Further, by eliminating architectural complexity, you gain greater
business agility to respond to marketplace shifts.

At times, however, alternative solutions may be more appropriate.

These options range from screen scraper and host-to-host to complete conversion to a Web target like Java integrated with WebSphere.

Milwaukee, WI.-based Grede Foundries Web-enabled many of its applications recently,
consolidating multiple servers and systems around one mainframe running Linux for s/390.
Many legacy applications also were ported to this platform with the company’s entire Web
presence now running on Linux for s/390.

”In addition to network utilities, such as DNS, e-mail and network monitoring, which Grede runs on its Linux for s/390 mainframe implementation, the company also has implemented DB2 Universal Database (UDB) and WebSphere Application Server (WAS) on the platform,” according to Rich Smrcina, who handles technical support at systems integrator Sytek Services, Inc., based in Bellingham, WA.

IBM’s HTTP Server, WAS, which is based on Apache,functions as the front end, providing logic and delivering Java Server Pages. DB2 UDB provides backend data storage. Data residing on UDB is either replicated from the VSE/ESA environment or maintained as part of Grede’s Web applications.

In addition, Grede has deployed three WebSphere virtual machines: a production server, a
quality assurance test server and a development server. The company also has implemented two DB2 UDB machines. One machine is for production data and another for test data.