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.
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.