Mainframe Application Modernization
For over a decade, mainframe applications have been criticized for spiraling maintenance costs, the result of a vicious circle of lack of documentation inability to upgrade, leading to higher costs for maintenance or upgrades right now.
Whether you’re developing new business solutions or maintaining current systems, you have to support rapidly changing business needs. Today, the kind of support that’s required frequently involves mainframe modernization.
The mainframe once held an unquestionable lead in reliability, availability, serviceability and security, therefore, it made sense as an investment. But these benefits are no longer unique to the mainframe, and other platforms have surpassed it in terms of flexibility, efficiency and innovation. More importantly, mainframe data center costs continue to rise beyond expectations while open-standard platforms are lowering their costs.
Two major external pressures are driving the need to modernize a mainframe application:
1. Market pressures: Businesses need to be able to rapidly respond to any changes in the business environment or risk losing customers. Older applications may need updating to support that need.
2. Regulatory pressures: A need to comply with the Health Insurance Portability and Accountability Act (HIPAA) and Sarbanes-Oxley Act (SOX), among other regulations, is causing companies to consider software changes.
The modernization problem usually is not about the core functionality. Where modernization is needed is in how users and other applications get to mainframe functionality and data and what they can do with it when they get it. That means integration and adding capabilities that extend the mainframe, like SOA or Web 2.0 or BI or cross-platform management.
The first big problem is that legacy code has typically evolved a great deal over the decades. Legacy applications often have been “fixed” whenever things have gone wrong or hardware has been replaced. Minor upgrades have been “bolted on” to the original code. The result is probably a poorly documented piece of code that makes maintenance quite difficult.
A second problem can be the use of older technology with a particular application. As technology has advanced, numerous devices and standards have come and gone. New devices don’t always easily support old technology (consider Microsoft’s difficulties with Vista, for example); it can become error-prone, or too expensive to continue using. There may be some ancient device used only by this single application.
There’s also the problem of complex interrelationships and cross-application dependencies between one application and perhaps many others, which may not be obvious or properly documented.
Another problem is that many older applications are batch jobs originally designed to run in their own time and eventually produce results when they finished. This is no longer possible in a situation where application users require near-real-time responses. Another problem occurs if the application can’t run continuously. Typically, it was never designed for that and must stop while, perhaps, another application runs against the database. Users expect to be able to work anytime.
Also problematic is finding talented COBOL or Assembler programmers to maintain legacy applications.
When it comes to modernizing mainframe applications, the GUI has emerged as the litmus test for the modernized z application. Sure, experienced users swear that command line interfaces are faster but the GUI makes it easier for less skilled people to re-use and re-purpose existing mainframe application code, especially in support of SOA implementations. Turns out that the lowly GUI is where you start mainframe modernization.
For Mainframes Online training please log on to http://www.revanthtechnologies.com