Introduction to Re-Host based Modernization Using Tuxedo
By jasonw on Jul 08, 2010
I published an article with Tom and Mark late early 2009 around using Tuxedo. With the recent release of Tuxedo ART for mainframe rehosting, i thought it would be good to revisit this article.
It is actually an excerpt from the book on Modernization that Tom and I published in 2008. Stay tuned two more coming out in 2011 around Data Integration and Migration as well at Tuxedo.
The re-architecture approach reduces the mainframe costs and legacy risks by migrating the application off the mainframe and re-structuring it using all the modern software tools and capabilities at our disposal. However, this very process of re-structuring the application, and essentially re-building it using knowledge and business rules mined from existing code, introduces certain risks. How can we ensure that the new application maintains functional equivalence, and operational characteristics of the original? Can we meet the performance and scalability requirements not only of the current environment, but future growth needs as well? Can we deliver the new application within the time and budget constraints agreed to at the beginning of the project? The older the application, the larger its scope and volume of code, and the fewer original developers available, the higher these risks may be.
This article by Jason Williamson, Tom Laszewski and Mark Rakhmilevich, takes a look at an alternative approach that attempts to balance these risks in a different way. Re-host-based modernization approach is focused on migrating the application off the mainframe to a compatible software stack on an open-systems platform, preserving the language and middleware services on which the application has been built. It protects legacy investment by relying on a mainframe-compatible software stack to minimize any changes in the core application, and preserve the application's business logic intact, while running it on an open-system platform using more flexible and less expensive system infrastructure. It keeps open the customer's options for SOA enablement and re-architecture, by using an SOA-ready middleware stack to support Web services and ESB interfaces for re-hosted components. And using an extensible platform with transparent integration to J2EE components, BPM-based processes, and other key tools of the re-architecture approach means you can start to re-architect selected components at will, without requiring changes to the re-hosted services running the remainder of the business logic.
SOA enablement wraps key application interfaces in services, and integrates it into the SOA. This largely leaves the existing application logic intact, minimizing changes and adding risk only to those components that needed restructuring work to become SOA-ready. While the interfaces are modernized, without subjecting the core application components to a lot of change, the high costs and the various legacy risks associated with the mainframe platform remain. In addition, the performance and scalability of the new interfaces needs to be well-specified and tested, and the additional load they place on the system should be included in any planned capacity upgrades, potentially increasing the overall costs.
Reducing or eliminating the legacy mainframe costs and risks via re-host based modernization also helps customers to fund SOA enablement, and the re-architecture phases of legacy modernization, and lay the groundwork for these steps. SOA-enabling a re-hosted application is a much easier process on an open-systems-based, SOA-ready software stack, and a more efficient one as well in terms of system resource utilization and cost. Re-architecting selected components of a re-hosted application based on specific business needs is a lower risk approach than re-architecting the entire applications en masse, and the risk can be further reduced by ensuring that target re-hosting stack provides rugged and transparent integration between re-hosted services and new components.