As a financial services IT solutions provider, Cognizant combines deep domain expertise, proprietary intellectual property and the onsite/offshore delivery model to solve critical insurance industry problems. To help pinpoint their approach and experience in mainframe migration, we talked with Sanjiv Gossain, their vice president of technology for Europe. With over 15 years of IT consulting and systems development experience in the US and Europe, he’s author of “Object Modeling and Design Strategies: Tips and Techniques” (Cambridge University Press, 1998) plus over 40 articles on technology and architecture.
Define for us, if you will, just what legacy modernization is.
At its heart, it is simply about gaining the advantages offered by a new modern distributed architecture that provides a more flexible, extensible environment while maintaining a lower TCO. A move to a Windows Server 2003-based infrastructure in a distributed environment promises significant cost savings. I also believe that the use of .NET as a key development technology and architectural framework will bring benefits in maintainability and extensibility.
Let’s talk first about motivation. What has changed for migration to be considered a realistic alternative?
Although the bulk of corporate computing still takes place on the mainframe and will continue to do so, it’s not surprising that with every year that goes by there’s erosion of vendor support services and loss of the core support skills. As you know, there are several reasons to migrate sooner rather than later.
Cost is foremost. Annual licenses and maintenance costs can be large enough to make businesses uncompetitive. Right behind comes the issue of maintainability. It’s often difficult to change mainframe-based code in response to new requirements.
Why is that?
The lack of documentation for the existing code base. At the same time, the paucity of new design and development on mainframe-based environments means most developers lack the benefits of innovation and best practices enjoyed by their counterparts on the more current technology stack.
The primary skill set of mainframe developers tends to be maintenance of older systems. When combined with the lack of documentation on many of these systems, this can create unreasonable dependencies on specific staff members. Similarly, mainframe development and debugging environments lag the productivity enhancements in the newer stack of technologies like .NET. This can cause typically longer fault detection and turnaround cycles. Plus, it’s proving hard to find new programmers who are knowledgeable in some of the mainframe programming languages.
The issue of extensibility also looms large.
Why so?
It can be difficult to modify and extend mainframe applications. They usually have been written as high-performance code without any careful segmentation or separation of concerns. While functionality may have been added over time, it’s typically achieved with careful workarounds and short cuts. The complex intertwined code means that mainframes typically have less support for new functions, services, or devices than do environments such as .NET or Java, which encourage modular construction.
Mainframe environments also need substantial work to hook into cross-platform services or functionality. It is typically not easy to expose useful mainframe functionality to other systems that may want to consume it.
Additionally, time-to-deploy is bogging down. The issues associated with extensibility and maintainability of the code base mean more time is needed to ramp up the team and knowledge transition periods and implementation cycles are longer.
However, don’t you agree that there are a few associated business and technical challenges?
Very much so. Some of the principal challenges are around user training and education. Most organizations don’t do enough to plan and organize for this, ensuring non-functional requirements are planned for and met. Nevertheless, there is one that can sometimes be overlooked.
Which is?
Business logic extraction. Since many legacy systems are poorly documented, developed in complex ways and devoid of domain/application experts, this is especially challenging.
So how do you do it? Mainframes are beasts.
Well, there are two major assets we’ve focused on to make sure we minimize the risk for our customers to help them move from the mainframe to .NET. The first is a structured proven methodology for mainframe migration. The approach is designed to address the modernization challenges and provide an optimal migration trajectory. It comprises four major phases: analysis, definition, execution and go-live, all designed to balance speed with minimum risk.
The second is an architecture framework built by our Microsoft .NET Center of Excellence for next-generation applications and systems that are designed in a service-oriented paradigm. Our reusable framework, developed on top of .NET building blocks, provides some significant productivity and quality advantages for developers. We call it CAFÉ .NET.
In a typical .NET architecture, the Microsoft .NET Framework and Microsoft application blocks are further extended by Cognizant’s frameworks to provide an enterprise-ready framework for building browser-based OLTP applications. This architecture leverages Cognizant’s reusable components and frameworks, its .NET foundation services and its productivity enhancement tools and technologies.
What are some of the advantages?
First, there’s reliability, in that components have been used in several scenarios and have been well tested and improved upon. Second, flexibility and reusability. Here, components have been designed to be generic, which makes them easily pluggable for most scenarios. Last, integration and interoperability, where the framework’s been used in many scenarios where there are legacy applications, heterogeneous systems and diverse user interfaces consuming their services. To handle such frequent changes, generic frameworks have been developed which can integrate and interoperate with diverse systems and external partners.
No doubt, there are pitfalls.
Yes, actually. Some of the bigger ones include ensuring you carefully consider how to run the new system in parallel with the old. The legacy system will not be switched overnight, so you need to plan to run in parallel with some functionality on one, some on the other, with the ratio changing over time lets you do more on the .NET system and less on the mainframe. This is a complex and challenging task.
A second major pitfall is not looking carefully at all the programs on the legacy system to understand their inter-dependencies and their impact on the order of migration. These inter-dependencies are not always obvious. There are more, but overall the real ‘gotchas’ can be avoided through careful and meticulous planning and execution.
Summing it up, what is the one overriding reason to migrate?
Two years ago, one of the leading industry analyst firms noted that by 2006, fully 30% of mainframe software products, predominantly those inherited from acquisitions will lack adequate vendor support services. That realization adds urgency to the array of strong reasons, many of which my colleagues at other firms you’re interviewing no doubt have clearly delineated, to move soon off your mainframes.
For more information, please visit www.cognizant.com.