« Modernize the IT Infrastructure - a real look | Main | Sybase Migrations with Oracle SQL Developer »

Mainframe and Legacy Re-Architecture (Part 3)

I have been looking over my blog entries and realized that I have a few unpublished for the Re-arch series.

So...let's pick back up in our legacy modernization deep dive on mainframe re-architecture (or re-engineering...etc . It goes by many names)
We cover this a lot in the book

If you need a review click here for Mainframe and Legacy Modernization Part 1 and Part 2

Technical Considerations for a Legacy Modernization Re-architecture Effort
As with any project there are considerations that must be made that drive how the project will be structured and executed. These depend upon the system requirements and resources available. Below are a few things that we've found are key technical considerations in a modernization

Subject Matter Experts "Don't Try This at Home
Access to SMEs from the legacy system can be one of the single largest factors contributing to success or failure of a modernization project. Many tool vendors provide understanding tools that can map data and logic, but these tools cannot always reveal context, user processing, business rules and other intangibles. Often there is no documentation to assist in the uncovering of business rules and the SME can provide valuable insight into where this knowledge is hidden.

If the team does not have access to a Legacy SME, it is critical that test harnesses are carefully crafted so that testing can happen early and often during the modernization process. Its critical to engage end users early and maintain the engagement through the development, validation, deployment process in order to ensure the new system being implemented meets the needs.

Risk of Modernization
A key issue of large scale modernization of a system that is an integral part of the business is to manage the risk of modernization on the current day to day operations. Many business that rely on their computing infrastructure for day-to-day operations have very low tolerance of disruptions to business as a result of downtime, data integrity issues or customer service issues. A rigorous modernization strategy involving validation, insertion and recovery actions for potential failures is necessary. Key stake holders within the company, who are impacted by the modernization, should be engaged in defining the validation and modernization strategy. For projects involving large scale system modernizations, phased modernization strategies, where business functions are transitioned from the legacy system to the newer system in phased manner, provide the best risk mitigation strategy. However, this may require some upfront investment in creating insulation middleware - such as web-services enabled Enterprise Application Integration (EAI) layer - to hide the back-end systems from the end user visible user interfaces.

System Performance
A key risk of change is impact on reliability, availability and performance of the capabilities provided by the system. Modern systems based on mainstream operating systems (Linux/Windows) are designed with distributed component models with an extensible, customizable framework as the core engine, and typically partitioned with 3 or more tiers (User Interface (UI), Business Logic, Data Base (DB)) . Performance of such a system is very dependent on data cardinality (amount of data objects stored in the system) and work load (number of concurrent users, type of usage). A detailed end user usage profile (data cardinality, users, and transaction types) should be analyzed and validated, and the system should be tuned to meet required performance specifications. A successful implementation requires upfront rigor in defining key usage patterns and performance targets service level agreements (SLA), and ensuring the system is tuned to meet these targets prior to deployment.

Usability/Training

While a modernization project is usually driven by goals to achieve cost reductions and performance, the end users that interact with the system are the final judges of the success of the implementation. Users that have deep entrenched knowledge of how the current legacy system behaves would need to have upfront training on mapping their usage (how to get the job done) with the new system. In the case of a system deployed to a large number of users, upfront usability studies must be done to ensure that the new system user interface meets the efficiency goals of the users (number mouse clicks, key board touches) to perform a task when compared to the existing system.

Next entry will be a look at Re-Hosting vs Re-Architecture

TrackBack

TrackBack URL for this entry:
http://blogs.oracle.com/mt/mt-tb.cgi/12044

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)