Some of today's modernization tools can leverage legacy applications right where they sit, without changing them directly. You can use these tools for a range of modernization needs, from adding a new graphical interface to breaking down the legacy application into reusable services. The best solutions actually provide these capabilities as middleware platforms that front-end your existing applications; they "look" into your applications, append to them, or parse them into reusable building blocks.
Not necessarily. The number of services and the complexity of the application are the determining factors. Some of today's legacy modernization tools can automatically generate a simple graphical interface in as little as a few hours. Service enablement can take longer. A full services approach typically requires middleware tools that can map the legacy application into subcomponents. (Remember that modernization tools with a graphical user interface make the task much simpler.) Once the application is mapped, you can delineate your needed operations. Because these operations are essentially your reusable components, they should be small units of work; simple components can become powerful when composed into larger, more business-focused entities. So, although the services approach is more involved, it can often be accomplished in days or weeks (compared to the months or years it takes to modify legacy applications directly).
Many projects try to account for everything in one shot—current needs, possible needs, future needs, and more. The easiest way to speed up a project is to make it smaller and more specific to the need at hand. A services approach lets you keep the solution focused on the pertinent aspects of a project, without limiting your ability to change the way it operates later. Services are by their nature continuously recomposable, so you can keep your individual project timeframes short. Furthermore, by using an inherently extensible architectural approach, SOA, you will have an easy avenue to modify and extend the work you have done across the enterprise.
One popular method, often used for batch update solutions, is to directly access the data from the host application. Although a large number of tools use this straightforward method, it has some significant drawbacks (e.g., data updates that originate outside the legacy application). Because you cannot rely upon direct data access for timely and accurate updates to the host system, it is best used for read-only applications. Otherwise, it will require extensive coding efforts within the middleware system.
You can also directly access the logic of the host application. When using this process, you call the "methods" or "transactions" within the application itself. As with direct data access, the safe use of direct transaction access must be planned out and carefully executed because you will be manipulating the application in ways it was not written to expect. The benefits of this access method can be high in terms of performance and reliability, but the cost and risk are clearly higher than the other methods. Direct transaction access offers little control over the process and falls the closest to actually rebuilding the legacy application.
Another popular method, which has been used for a long time, is to programmatically run the legacy application as if the middleware were a user of it. This method, often called screen access or screen "scraping," has evolved greatly over the years. While not always considered the most robust method, its popularity stems from its low risk and rapid timeframes. It can safely be used for both read and write access. Newer tools let this method run reliably and, unlike data transaction access, give most mid-tier-savvy workers control over the legacy application. This highly scalable method has also overcome the performance issues that plagued its earliest days. Screen access is often chosen when cost and timeframes are critical.
The least popular method is one that specifically targets CICS applications. While exclusivity to CICS is clearly limiting, this method is noteworthy given the large majority of host applications actually running in CICS. BMS Map access, the newest method of the four, is best thought of as a hybrid between direct transaction access and screen access. Its performance benefits are similar to direct transactions, but its implementation ease and risk reduction are similar to screen access. Essentially, this method talks directly to the CICS logic, but gives the middleware a virtual screen for building and controlling application access. This method is best used with CICS applications, especially when you want to avoid the costs and risks associated with transactional access or rebuilding.
Legacy middleware tools have shown their usefulness in extending enterprise applications to customer web interfaces for partner networks, end user self-service applications, and new internal applications (like CRM systems with direct access to enterprise information). You can leverage those proven middleware service enablement and web enablement procedures—now, for giving mobile users controlled access to pertinent information. Mobile devices simply represent a new set of computing platforms, albeit platforms that have an uncommon level of end-user enthusiasm.
Web enablement of legacy applications is a well-established practice. The good news is that there's no shortage of products to help you do it. The bad news is that some of those products are really dated. First and foremost, look for a solution that leverages the latest web technologies and does not force you to work in a proprietary environment. Web technologies move fast, so be sure your solution can move with them. The tools providing the greatest flexibility over time are the ones that handle the specifics of host communication and then leverage web technologies to render a graphical interface. The right tools will let you use the web technologies that make sense for your IT environment, without worrying about potential challenges in making them talk to a mainframe.
Many solutions, while appealing in theory, take too long to implement. Others are so invasive to the involved applications that they require a huge set of stakeholders to move forward. So be sure to look for a product that minimizes impact to existing systems and lessens the expertise needed for the service enablement process. The ideal solution combines a noninvasive process with drag-and-drop service-creation tools, so you can get rapid-to-market results.
