The net result of the as is strategy has been a constant increase in the following inventory costs of legacy applications:
Inefficiency costs -- those costs incurred as the failure to proactively upgrade causes crisis-mode, costly application fixes; periodic directives to move to a new platform; and wasted time and effort on flawed or failed major software improvement projects.
These costs often feed on themselves in a vicious circle. Choosing to maintain instead of improve an application means that the application continues to age, thus not only increasing maintenance, opportunity, and inefficiency costs, but also increasing the gap between the legacy application and current technologies. This age gap, in turn makes improvement more costly -- which in turn makes the organization more likely to choose the "as is" strategy.
Now consider the replace strategy. Superficially, this seems more attractive than ever, with an ever wider array of packaged applications to choose from and with ever greater benefits from the new technologies such as Web services baked into the new applications.
However, because the application to be replaced is mission-critical, the new application must at least support the features of the old, and preferably the old business processes. Meanwhile, the old application, because of decades of the "as is" strategy, lacks documentation, experts, and cultural willingness to move forward. As a result, replacement by a new application can involve loss of features, inadequate support for business processes, and cultural resistance that will prevent implementation -- and when the application is business-critical, its replacement can be business-threatening.
Moving the application to a new platform by regeneration or migration, can offer clear advantages. Research by Infostructure Associates personnel shows that some medium-scale IT shops that have migrated their applications from mainframes to Wintel platforms are seeing TCO savings of up to 67%, plus significant increases in price/performance and flexibility. These improvements are primarily due to lower acquisition and software license costs of the Wintel.
Migration, in particular, also offers extensive, automated tools for handling conversion of COBOL, FORTRAN, and DB2-based applications -- although CICS and assembler-based applications are less well supported.
However, the risks and costs of moving key mainframe applications to Unix or Windows can be large. Mainframe applications, especially those highly tuned for performance, are often so customized for the mainframe that they cannot simply be copied from one machine to another; instead, those migrating the application must have a deep understanding of the application's code and purpose. In some cases, migraters must rewrite much of the code in the application to run and deliver optimum performance on a very different type of computer -- which could take months or even years. As a result, performance-critical applications may not perform adequately even after tuning; and new errors may creep in during the process, making the resultant application unusable.
Often, the application's documentation, or IT's knowledge of the application, has been lost or is inadequate. While automated migration tools can handle some of these cases, these tools fall short in many cases.
Regeneration, likewise, is hard pressed to abstract to a design in cases where structured programming techniques were not followed in the first place (a common flaw of mainframe programs) and where no documentation exists to deduce the underlying design.
For mainframe applications sharing a common data store, migration or regeneration is even harder, if not impossible. If the data for one application is moved to a new platform and database -- perhaps to integrate with applications on the new platform -- then the applications remaining on the mainframe will need modifications in order to access their data from the new database, or application code must be written to keep the two databases in sync.
Scaling the migrated application likewise is often difficult. Today's application servers, although superficially similar to traditional mainframe TP (transaction processing) monitors, aim at load balancing across application code, not transactions. As a result, mainframe applications that scale well using mainframe TP monitors, such as IBM's CICS and Unisys' COMS, will usually require extensive adaptation to scale on Linux/Unix using Apache or JBoss, or in Windows using Microsoft's application server.
Typically, regeneration is used much less than migration, because the process requires greater application knowledge and regeneration is perceived to be applicable to fewer applications.
Upgrade in place makes sense
The key watershed in showing that upgrade in place is feasible was Y2K. Implementation of Y2K made it clear that even mainframe applications hitherto thought untouchable could indeed be modified successfully at a very low level in the code.
Moreover, upgrading mainframe applications in place is more feasible than ever before, because upgrade tools are better.
A side effect of vendors' Y2K efforts has been an extensive set of field-proven tools to upgrade mainframe applications. Middleware such as Unisys' ClearPath MCP solution and IBM's application modernization or enterprise transformation offerings, and Web-servicization tools such as those provided by IBM, allow connectivity from the Web to the mainframe and permit users to create application veneers that add e-business functionality, such as Web services provider code and/or composite-application business-process support for supply chain and customer relationship management.
As a result, a large number of mainframe applications have been Web-servicized, or are in the process of being Web-servicized. In other words, the attractiveness of upgrade in place by Web-servicization is being proved in the real world.
Click here for Part III of this three part series. Kernochan outlines the potential of Web services for the mainframe.
About the author: Kernochan is president of Infostructure Associates.
');
// -->