Imagine trying to find a short circuit in the telephone wiring of your building and in the process of searching for the guilty wire you discover that two to three sets of old wiring have been left behind from the last two wiring jobs. You either have to find and remove the unused wiring or test all of the wires, knowing that much of it is not even being used. This is the situation many systems engineers find themselves in when they set about to upgrade or modernize a COBOL application.

Managing complex COBOL applications can be extremely challenging. Having unused (dead) programs or code in a large application only makes migrating or upgrading it more time consuming and costly.

Recently, I spoke with a senior IT person at a large enterprise who was seeking help to modernize a large COBOL application. I suggested that a thorough analysis of these 1,400+ programs would be the best first step. Our automated analysis tool found that only 485 of these COBOL programs were being used. Through this process, the project scope was reduced by about 60%. This reduced the overall project timeframe, maintenance overhead and the number of team members assigned to the modernization project. While this particular example is somewhat dramatic, it is quite common to find COBOL programs that are unused in enterprise applications.

Given the increasing shortage of COBOL programmers and system architects, the need to integrate legacy applications with more modern systems is a growing concern. This first, and most crucial, step in all modernization projects is the understanding, or analysis phase. After all, it's hard to make changes to things you don't fully understand. So, whether you're simply trying to maintain an existing COBOL system more efficiently or seeking to modernize it, it makes good sense to analyze code and databases to gain an understanding at the coding level and to determine what code is required and what can be eliminated.

Dead Code Identification

Before discussing dead code identification, it is important to point out a very important fact: this type of analysis cannot be done manually. An automated tool or product must be used to help determine the "dead weight" in the application. Attempting this process manually will result in an incomplete analysis at a large resource cost, and an inability to reproduce the results in a timely manner.

There are varying levels of dead code and artifact removal. Below is a description of several areas/topics where this analysis should be conducted. These areas are organized according to their level of granularity.

- Identify unused load modules

- Identify files/database tables that are not accessed

- Identify programs that are not used

- Identify copy books that are never used

- Identify sections of the code that cannot be reached

- Identify variables that are never accessed

The amount of analysis required will be directly related to the project at hand. A finer level of analysis will require more time and a greater testing effort. Removing unused load modules and programs provides a low risk/high reward in reducing application inventory. This type of analysis is good for projects where the goal is to change the application platform. Removing dead code, on the other hand, requires a finer level of detail. This type of analysis is ideal when an application is going to be reengineered.

If you have selected the proper tool, it is not necessary to analyze your entire application portfolio. The analysis can be broken up into smaller sub-systems or clusters. It is best to approach the artifact reduction at a high level, then work your way down to the more granular analysis. After the dead code and artifact analysis is complete, your projects can move forward without including the unneeded weight of "garbage" in the application.

Why Take the Time to Find Unused Code?

I often hear, "My team does not have the time to spend on sifting through COBOL applications. Why should we do this?" That's a fair question. Most large enterprises are faced with the challenge of modernizing older systems and applications in order to address changing business requirements. Software technologies such as the Internet, e-commerce, new languages and operating systems, and new hardware and communications systems have changed the concept of information technology. IT departments are being forced to interact more closely with business units and the revenue side to provide the agility needed to conduct worldwide business. There is, therefore, a high incentive for continual renewal, modification and updating of software systems in order to keep them in line with mainstream developments in IT technology.

In the case of legacy systems, there are additional reasons that make application renewal necessary:

• Because of their architecture, they do not integrate well into modern-day IT environments.
• The present generation of application designers and programmers are often not familiar with the technologies and methods that were used for legacy system development. Legacy systems are thus difficult to understand and maintain, modify, and adapt to changing needs.
• Documentation is often not available, or is not up to date.

While the renewal of business legacy systems is clearly needed, the fact remains that for the most part they perform satisfactorily and continue to meet the functional requirements for which they were originally developed. The main reason for this is that the functional requirements, which embody the rules and methods of business transactions for the domain of interest, have often not changed appreciably. Consequently, legacy systems are unique in containing a vast amount of valuable business knowledge and procedures that need to be retained with any renewal or modernization project.

Extracting this information and converting it to the requirements of the new system is, however, not a trivial matter. The design methods and architectures of legacy applications is such that the code for performing a particular business function is often spread over many parts of the application. Threads of program code intertwine with each other and intermix with technology-like old unused wiring-and it is difficult to separate them into coherent functional units, each in its own module, object, or class, as would be required by modern program design.

This situation is clearly seen in the world of mainframe legacy applications. It is estimated that 70% of mainframe software is implemented in legacy environments such as COBOL programs, CICS transactions, VSAM files, etc. Due to their proven stability and reliability, they have supported the core business applications of major organizations over many years. On the other hand, it is clear that they cannot support many of the developments that have already taken place in the IT world and others that are still unfolding as the IT revolution progresses.

As suggested earlier, many legacy applications (maybe 70% to 80%) are composed of business rules that are "wrapped" and supported by obsolete legacy technology. Complex business rules are intertwined in the existing application structure. Since these business rules comprise the core of an organization's competitiveness, their logic should be kept intact and reused in a new technological environment once they are identified and extracted.

Companies in the financial sector, such as banks and insurance companies, provide a prime illustration. A close look at these business processes reveals that their core business procedures have not changed substantially, if at all, because of the Internet or information revolution. Banks still loan money to their customers and still calculate interest rates. They were doing so long before IT technology was available and will be doing so 100 years from now. Insurance companies still provide insurance to customers and gather, calculate and store policy information according to each customer's specific needs and demands. In all these cases, the calculations, from the simplest to the most complex, are essential to new or renovated applications. They are the business rules embodied in the applications.

Given the prevalence of COBOL legacy systems, conversion to modern applications is an expensive and time-consuming undertaking. While various attempts have been made to develop tools to perform direct language-to-language conversions automatically, high success rates are usually limited to 4th generation language conversions. In most cases, a direct conversion of COBOL code to (for example) Java or C# is not a satisfactory solution. This is because the source and target environments are often based on substantially different architectural concepts. In almost all cases, "spaghetti" COBOL is merely converted to "spaghetti" Java or C# that is even more difficult to understand and maintain than the original.

In order to develop well-designed applications from legacy systems, software tools are required to analyze the legacy system and aid in generating new programs that are architecturally sound and utilize modern design methods. Furthermore, they must capitalize on the fact that, for the most part, the business processing functions of the legacy system-the business rules-will still be valid for the new application. Thus, they should serve as an aid to identifying and extracting-mining-the business rules from the original code and be able to incorporate them into the new application.

Any modernization plan should begin with a thorough analysis that should include finding and eliminating unused modules, programs, copybooks and code. Doing so will reduce the scope of the modernization project and make the modernized application easier to maintain. In addition, it will take fewer resources so that your organization will have incremental gains for the life of the application.

Modernizing Applications

Once you've done the initial analysis and rid yourself of unused code, now is the perfect opportunity to modernize the applications. Here are the three ways to do so:

-Wrapping/Face-lifting

-Automated Migration

-Redevelopment

Wrapping/Face-lifting

Wrapping solutions partially modernize a legacy system by concentrating on the interface to the outside world. The system is enclosed in a software shell that intercepts all input/output activity and enables interaction with the outside world by means of modern methods and equipment. Wrapping methods can be effective in three areas:

• Data input and display that is more user friendly than the mainframe green screens
• Data storage using modern database technologies
• Data communications by means of modern communications technologies and the Internet

While these measures can have beneficial results in terms of user ease-of-use and improved performance with respect to transaction throughput and data storage, the core functionality of the application is not changed and, therefore, it remains difficult to maintain, modify and extend.

Nonetheless wrapping can be a first step toward such things as a Services Oriented Architecture (SOA), by wrapping existing functionality in the form of services. In such a case, for example, you'll need a tool with analysis capabilities to identify the potential SOA interfaces.

Automated Migration

Transforming applications to more modern languages in a tool-driven, automated fashion is a powerful approach to modernization. Eliminating the need to retain legacy skill sets while migrating applications to new environments such as J2EE or .NET that are easy to use and more cost effective can help eliminate many costs.

However, not all languages can be easily migrated. Fourth generation languages are particularly suitable for using automated techniques, since as 4GLs they are already more "abstract" and contain less reliance on a given technical architecture. Third generation languages, on the other hand, can be difficult to migrate due to architectural issues such as their reliance on teleprocessing monitors such as CICS or IMS/DC, and assembly level languages are essentially impossible to migrate. The closer the language is to a given technology, the greater the difference between it and today's technologies-and therefore the harder it will be to migrate.

Fortunately, there are tools on the market that can help an organization make the appropriate decisions regarding automated migration. They analyze the suitability of an application for automated migration by determining the application's reliance on environments such as CICS or IMS/DC, performing complexity and quality analysis on the code, determining reliance of the code on legacy file systems such as VSAM or DL/I, and identifying those components such as operating system calls that may need special attention.

Redevelopment

The third modernization alternative is to refactor or redevelop the application. Redevelopment involves the transformation of an application to a completely new architecture such as Object Orientation (OO), full Services Oriented Architecture, or full Process Driven Architecture.

The redevelopment process is still a migration in that the process begins with the existing application; however, it uses the existing application as a known set of requirements and then follows a redevelopment approach involving:

- Taking a current platform dependent application that contains a mix of business logic and platform specific technical code and extracting from it the business content including both business data and business logic.

- Refactoring the platform independent business content into new architectures more representative of modern analysis and design techniques. This is of necessity a manually assisted process.

- Regenerating the code which causes the now refactored platform-independent business content to be transformed into a platform-dependent application for a chosen technical platform.

Although this approach is more complex than either wrapping or automated migration, it does allow for complex changes to architecture. Some available tools support the necessary analysis capabilities to support the first of the steps in the refactoring approach: analyzing existing applications in order to determine and separate business content from technical content, and can be used in a stand-alone fashion for this purpose.

Summary

Identifying and ridding your enterprise of dead programs or code provides benefits in and of itself and can mitigate the risks and costs associated with modernization. Use automated tools to identify the code, then determine which modernization approach suits your needs best. Following this approach will ensure the optimum chance of success in your modernization project and increase your organization's efficiency and effectiveness.

Thomas O'Connell is vice president of research and development for BluePhoenix Solutions (www.bphx.com).

Forward this page to a friend

Your Email: *

Your Name: *

Send To: *

Enter multiple addresses on separate lines or separate them with commas.

Message Subject: (Your Name) has forwarded a page to you from NaSPA.com

Message Body: (Your Name) thought you would like to see this page from the NaSPA web site.

Your Personal Message: *

Your vote:

1

2

3

4

5

Average: 5 (1 vote)