Roadmap to mainframe application modernization |
 |
By Wayne Kernochan, Contributor
03 May 2006 | SearchDataCenter.com |
|
|
In a three-part series, Infostructure Associates president Wayne Kernochan outlines a modernization path for business-critical applications in an existing mainframe environment.
Mainframe applications have been criticized for spiraling maintenance costs, the result of a vicious circle of lack of documentation and lack of ability to upgrade, leading to higher costs of maintenance or upgrade right now. At the same time, most enterprises recognize that their existing mainframe applications are business-critical but old, and therefore cannot be leveraged as much as the business would like. Thus, these applications need to be modernized.
Modernization means revising existing legacy apps so that they can leverage today's new software technologies as part of an enterprise architecture. Once these applications are modernized, they should offer the flexibility, robustness, programmer productivity, and access from across and outside the enterprise that today's new applications typically provide.
One technology offers particular hope for modernizing cost-effectively across all enterprise platforms: Web services. However users who are prototyping Web services implementations must pick the right targets, because there is no money to waste on failed or long-running projects.
The answer is to target existing mainframe business-critical applications first. Modernizing an existing mainframe enterprise resource planning (ERP) or order-entry application maximizes the positive impact on the bottom line, while minimizing the costs of providing new e-business features. Web-servicizing these applications simplifies the existing e-business architecture, cutting administrative and development costs.
Where possible, these applications should be upgraded in place -- modified on the mainframe rather than migrating them to a new platform.
Choosing the right approach
Today's enterprises typically consider four strategies for integrating new technologies with their existing mainframe application suites:
Upgrade in place. The program and its data are kept on the mainframe, and the developer applies mainframe tools that integrate the new technologies with the mainframe application.
Migrate. The program's source or binary code is moved to another platform with little or no change, and the developer applies tools on the new platform to add the new technologies. Note that the application's data may be moved to the new platform as well, or may remain on the mainframe.
Regenerate. The program is first reverse engineered, a process that creates an abstracted design model of the application. The application is then regenerated from the design model on the new platform. The new technologies are either embedded as a result of the regeneration process or added once the application is up and running on the new platform (again, the data may remain on the mainframe or can be moved to the new platform).
Replace. IT discards the existing application and writes an entirely new one, on the mainframe or a new platform. The new technologies are "designed in" to the new application. The new application supposedly incorporates at least the same functionality as the old.
In the past, enterprises tended to choose a replacement strategy if a new technology had to be added; otherwise, they simply left the application as is -- the risks of changing a business-critical application in any way were seen as so great, and the difficulties of changing it so daunting, that anything was preferable to touching it at all.
However, over the last five years, three new trends have become apparent that have changed the relative merits of these four choices significantly:
Tools for migration have become applicable to so many mainframe applications that the majority of these applications are now migrateable.
The total cost of ownership savings and business benefits of both non-mainframe platforms and Web-servicized mainframe platforms have increased, making the idea of leaving mainframe applications "as is" less and less tenable.
The tools, middleware, and services necessary for upgrading in place, and especially for Web-servicizing on the mainframe, are now available and field-proven.
Click here for part 2.
|
|
|
|
