whitepaper - modern systems: legacy modernization...

DON’T KICK THE CAN DOWN A CRUMBLING ROADHOW AUTOMATED CONVERSION CAN HELP FIX THE US GOVERNMENT’S COBOL PROBLEM

WHITEPAPER

Recently, the US Government Accountability Office (GAO) released an eye-opening report which found that roughly 75% of the government’s $80 billion IT budget goes to keep aging technology running, and the increasing cost is shortchanging modernization. The report illustrates how kicking the legacy modernization can down the road costs significantly more every year, and has resulted in a $7.3 billion decline from 2010 to 2017 in development, modernization, and enhancement activities. While many of the findings in the report are astonishing, such as the revelation that the Defense Department’s Strategic Automated Command and Control System, which is used to send and receive emergency action messages to U.S. nuclear forces still uses 8-inch floppy disks for storage, the vast majority of the legacy upkeep falls into the COBOL realm. Among the available mitigation options, we assert that automated conversion is the fastest, most cost-effective, and safest way to alleviate reliance on legacy infrastructure, databases, and the application code that supports them.

Introduction

Vintage Is In, But Restoration Has Its Limits

To some, it is difficult to understand why the government and many businesses continue to use such ancient and costly technology for so many critical applications. The reason is quite simple; the legacy systems are robust. They perform satisfactorily and continue to meet the functional requirements around which they were originally built. The Social Security Administration determines eligibility and calculates benefits the same way it has for decades. Insurance companies gather, calculate, and store policy information in basically the same way they have since long before IT technology was around. Transportation Department’s Hazardous Materials system tracks incidents exactly as it did the year The Muppet Show was first released (1976). The fact is they’ll probably continue these methods in similar ways going forward no matter what technology evolves next. Therefore, if the business rules at work in the legacy system rarely change, why mess with it?

page - 02 | WHITEPAPER: DON’T KICK THE CAN DOWN A CRUMBLING ROAD

Cost is certainly a factor. In early June of 2016, Federal Chief Information Officer Tony Scott underlined the importance of timeliness in addressing the legacy modernization goliath the US Government faces, warning of catastrophe if the strategy remains unchanged. Over the next three years, Scott said more than $3 billionworth of federal IT systems will reach end-of-life,adding to the tens of billions alreadyspent maintaining outdatedtechnology each year, and carving more budget dollars away from modernizing and developing newer alternatives.

However, the problems leading organizations to the eventual modernization of legacy systemsgo much deeper.


The Trouble with Retaining Legacy Systems

Consider this from a 2013 Computerworld Survey:

A Diminishing Talent PoolThe evolution of software development from procedural and fourth-generation languages to object-oriented design in the past few decades has opened a rift between the skills required to maintain legacy systems using languages such as COBOL, and the skills being taught to and utilized by today’s developers in the design and implementation of modern software.

Employees with skillsets focused on legacy code have dedicated significant time and effort to the growth and development of legacy systems and the business as a whole. The knowledge, value, and understanding that these resources possess with respect to the legacy environment they manage is unmatched. As these employees retire or leave their positions, modernization is sometimes forced because there are fewer developers with the skills to maintain the ancient code, and the present

Doing Nothing is Extremely RiskyThe older a system is, the higher the security risk it poses. This is especially true when systems reach the end of their support lives with their manufacturer. As scary as it is knowing that US nuclear defenses rely on 8” floppy disks, there are so many more systems that protect critical information that have aged out long ago. Among other findings, Scott saidthat when looking at the US government’s IT portfolio he was tasked with managing, he found original Sun Microsystems SPARC servers, which he had helped develop back in the 1990s. End of life support for them was in the early 2000s. In short, the federal government’s reliance on kicking the can down the road instead of upgrading and replacing systems that have reached end of life is not only costly, it puts national security at risk.

ComputerWorld’s IT Survey identified a massive resource gap

facing the mainframe world. Moving to a distributed system mitigates risk around increasingly rare legacy system resources.

46%

50%

22%

64%

nearly 75%

said age of average COBOL staffer is over 45

said the age is 55 or older

said COBOL represents more than half of all internal business application code

said their organizations still use COBOL- more than any modern

language except for Java/JavaScript and Visual Basic

are noticing a COBOL programmer shortage

... meaning that you can buy for the same dollar, often double the capacity, every three years or so. This means that over a 10 year period you’ve lost 4X if you’re just sitting on the old stuff and not upgrading.

I know that if I spend a dollar on IT, it’s going to cost me 15 cents a year to maintain that. So if I wait 10 years I’m still paying the 15 cents per dollar spend, but I’ve missed 4X in terms of capacity or compute power that I could be getting.

We should be upgrading, we should be replacing this stuff. It gets even worse if you look at network. It gets worse if you look at storage. In essence, by sitting out on our hands for all these years, the Federal government has missed out on multiple generations of opportunity for higher performance, better bang for the buck, but we are locked into that 15 cents. And the bad news is that that 15 cents gets higher and higher and higher the older the stuff gets.

“

”Tony Scott, US Federal Chief Information Officer

generation of application designers and programmers are completely unfamiliar with it.

Exploding Maintenance & Infrastructure CostsMainframe usage fees make up a significant component in the overall cost of ownership, nearly 10% to 40% of an organization’s IT budget depending on the size of the mainframe footprint, according to a study commissioned by Infosys. Of course, running computer software costs money on every computing platform, but for legacy systems running COBOL, the incurred costs are especially high. Plus, IT industry analysts estimate that most large organizations utilizing these systems should expect their systems’ CPU resource consumption to increase by 15–20% annually.

Federal Chief Information Officer Tony Scott expressed his take on the matter during his keynote at the 2016 ICIT Critical Infrastructure Forum recently:


Identifying the Problem is Easy. Fixing it is Another Story

So where is the best place to start? There are a number of different options the government and other organizations face when looking at legacy modernization, each with their own advantages and disadvantages. The key to success with any modernization project is to approach it in a strategic and planned manner rather than as a tactical project. The following are the choices companies and governments have for modernizing their systems.

Status QuoThe first choice for any scenario is always to do nothing, to “let it play out”. The sole benefit to ignoring the problems of your legacy systems is saving money in the very short-term. As time passes, dealing with legacy systems is more and more difficult. There’s less available expertise, more application development backlog, and more money is thrown away that could be spent on projects to improve IT efficiency. Doing nothing to improve your legacy system drives up costs in recurring license fees, hardware maintenance, facilities costs, opportunity costs, and staffing costs.

Third Party “Off the Shelf” Solutions (COTS)This approach focuses on replacing legacy application functionality with packages and components available from third party vendors. The positives of this approach include reduced maintenance of source code, as the vendor is responsible for fixing production bugs and implementing new functional enhancements. However, commercial packages offer standard domain business processes that often end up being far more expensive

than other modernization options. Additionally, once vendor code is changed it is no longer supported by the vendor and fixes/enhancements from the vendor become more complicated to apply and test.

67%

of respondents

reported they need a

solution with more industry-

specific functionality than their

COTS solution gave

them

In a 2013 Panorama Consulting Survey:

Application Re-EngineeringKnown as the “big bang approach”, re-engineering, while sometimes necessary, is the most expensive and risky solution for modernization. It includes requirements capturing, coding, debugging, testing, and refining. To recreate the legacy solution’s wealth of functionality with newly written applications requires significant time and effort. Impact on end users and their adjustment cycle is also a major factor. Many analysts consider the failure rate of these projects to fall between 70-80%. The cost, time and risk involved with re-engineering are so high, few organizations choose to embark on large-scale rewrite projects.

ReplatformingReplatforming (sometimes referred to as “rehosting”) provides an environment that runs on distributed platforms which emulates the legacy operating environment. This emulation capability minimizes the amount of change that occurs when migrating legacy systems to a distributed platform. Replatforming solutions provide a relatively low-cost and low-risk way to reduce operating costs and maintain the business value existing business rules provide. However, replatforming retains the legacy code as-is, which doesn’t address the massive shortage of COBOL developers capable of working with the applications, a key driver for modernizing in the first place.

The cost of doing nothing Source: GAO analysis of agency data | GAO-16-696T


The automated conversion approach preserves the benefits of the legacy environment while empowering organizations to leverage the advantages of newer platforms. Modern Systems’ automated conversion technology guarantees 100% like-for-like functionality and generates fully maintainable Java or C# code. This means once the legacy application and database is converted, developers can extend application functionality directly without having to navigate COBOL to do it. Precious business logic from the legacy system is preserved, while enabling deeper integration and customization to meet business requirements. It also opens up a whole new world of scalable resources for systems support. Many code transformation solutions create structurally similar programs in the new language, but then need an additional re-engineering effort to yield desired results. Our solution is completely automated, removing the risk associated with the tweaking that goes into other solutions that produce “spaghetti code” in a line-for-line format that is difficult to maintain and resource heavy.

There’s A Better Way: Automated COBOL Conversion

Tools of the TradeModern Systems employs a number of proprietary tools and techniques, honed by over 30 years of modernization experience to transform Mainframe-based legacy applications from COBOL to Java/C#, producing object oriented code that can be easily maintained and efficiently integrated with other Java/C# applications. The tools we use support the full environment of the Mainframe-based COBOL application, including databases (DB2, IDMS, IMS, and VSAM), TP monitors (e.g., CICS), JCL, utilities (e.g., IDCAMS), and SORT.

The conversion service is a fully automated solution that captures the entire source base of the application and automatically migrates it. The resulting code has the exact functionality of the original legacy application and can easily be tested and implemented in production. Translating a procedural language such as COBOL to object oriented Java or C# presents many challenges. As such, Modern Systems’ automated conversion process was designed with the following requirements in mind:

• The resulting application should work exactly the same as the original application and produce exactly the same results• The resulting application should be maintainable and follow the object oriented concepts and paradigms: Encapsulation, abstraction, modularization, loose coupling, etc.• The resulting application should perform as well, or better than, the original application on the open systems platform

PRODUCES “JOBOL”

- Line-by-line - Automated conversion- Cost-effective- Fast

TRANSCODING

3-STAGE CONVERSION

- High quality converted code- Cost-Effective- Active tool development- Auto refactoring during conversion- Battle-Tested

MODERN SYSTEMS

MANUAL & COSTLY

- Potentially high quality code- Long project timelines- High risk- Substantial manual effort

MANUAL REWRITE

Converted code presents serious maintenance and performance challenges

Automated Conversion produces maintainable and efficient code

Produces blocks of code that require manual assembly and

compilation

LOW COSTLOW QUALITY

LOW MAINTAINABILITY

HIGH COSTLONG TIMELINESNO AUTOMATION

Automated Conversion: The Process


The AssessmentThe assessment is a complete research and analysis project that outlines all legacy application and database conversion candidates. This step is vital to the automated conversion process and to successful modernization in general. Most organizations are surprised to find at the conclusion of the assessment phase, their legacy environments present themselves quite differently and are more complex than originally assumed.

During this stage, components are classified and listed in detail, while notes are attached to components requiring special attention. All application components are inventoried, classified by language, and cross-referenced, ensuring all missing components are collected and added to the inventory. The assessment phase results in a complete understanding of the legacy processing environment.

This phase also includes discussing and reviewing the overall system test strategy and the division of converted code into work packets.

Modern Systems defines a set of topics during the assessment phase that must be addressed prior to beginning the conversion process. In order to speed the modernization process, these topics are be addressed by team members who are best suited to understand the topic, the solution options, and any changes or activities that are required to address the “Areas of Concentration”. Once the areas of concentration are identified, Modern Systems works in lock-step with customer teams to address the areas about which they are most knowledgeable and for which they are best suited to implement a solution. Any additional areas of concentration that are identified during the course of the project are addressed and assigned in the same manner, to the most appropriate team.

Database ConversionAfter the assessment is complete and a strategy for moving ahead is established, the automated conversion work is done; it spans both the application and data tier. First, the database is converted from the pre-relational to a relational format such as Oracle, SQL Server, or DB2. It includes the tasks required for unloading, transformation, and loading of data from the legacy database to the target environment. During the assessment, a data migration specification was created based on the structure of the existing data model and the database mapping rules. To accomplish this, Modern Systems generates programs/scripts to be used for the customer’s testing and migration of production data. Highlights of the data migration phase include:

• Non-relational database modeling utilizes a one-to-one default mapping approach into the new relational data model• Deliverables include scripts/programs necessary for extract/transform/load (ETL) of data from the source environment to the target environment, as well as DDL for defining the target data model in the relational model, pre-delivery tested on customer-supplied test data, and data verification software• Migration of data for on-site testing and production data

Automated Conversion: The Process


Application ConversionWhile the database conversion takes place, COBOL code is loaded into our proprietary tools for conversion. At this stage, code included in the areas of concentration identified during assessment are handled with special care. Once complete, converted, functionally equivalent application code is delivered to the customer in a series of work packets, based on milestones determined during the assessment. Automated COBOL Conversion covers online applications, batch programs, and JCL members. Modern Systems tests the converted code for functional equivalence, then delivers it along with any required frameworks to the customer for installation and on-site testing.

Automated Conversion Process

Test, Refresh, DeployModern Systems tests a subset of the converted code using a test plan with documented test scenarios provided by the customer. The customer writes the tests and runs them on the existing system to capture and record the expected results. Modern Systems then runs the tests against the same data on the converted system, identifies, investigates, and fixes discrepancies in the expected behavior of the modernized application. Pre-delivery testing consists of test cases picked from all available functional test cases in order to be representative of different parts of the applications.

The automated conversion process does not require code freezes, which is a major risk reducer for customers, however, it is necessary to bring the new codebase up-to-date, therefore once pre-delivery testing is complete and any discrepancies in application behavior are resolved, Modern Systems performs a code refresh to ensure that any changes that took place in the legacy application environment during the conversion process are accounted for, converted into the target language and environment, and tested.

The Modern Systems teams work closely with customer teams to ensure a smooth and error-free transition night or weekend. Our teams also provide any required assistance during the 90-day warranty period following the deployment as well as post-conversion support of the modernized application, available at a fixed rate or in hourly buckets purchased as needed by the customer.


New York Metropolitan Transit AuthorityThe MTA is a New York public authority and public benefit corporation that provides transportation services in the NY Metropolitan region through its operating agencies, namely New York City Transit, bridges and tunnels, regional railways, and the MTA bus company.

Background

The MTA was running an IBM mainframe. Part of their overall IT strategy for reducing cost and risk included moving critical applications off of the legacy mainframe environment to newer, more flexible, and cost-effective platforms. The first selected for modernization was called IMPACT (Integrated Management of Payment Accounting and Capital Tracking), a batch process application. IMPACT is built in COBOL, leveraging VSAM as the data tier.

Source System:

• COBOL, VSAM, JCL

Target System:

• Java, Oracle Database

The Solution

MTA considered the option to re-host the IMPACT application in a COBOL container on a newer platform, but preferred the alternative of converting the IMPACT application from COBOL to Java for improved future maintainability, flexibility, cost-effectiveness, and support. The converted environment enhanced MTA’s position to provide improved, cost-effective services to its customers. The data tier was converted from VSAM to Oracle Database.

Going from COBOL to Java isn’t a trivial undertaking. Understanding all levels of functionality and relationships is essential for success. Modern Systems started by leveraging our tools and technology to assess the application’s technical inventory and risk factors. Then, we worked with MTA to finalize test strategies and critical factors to validate equivalent functionality between the source and target systems.

Since our COBOL conversion solution is 100% automated, a testing approach which tests all major items at a high level and then some specific items at a much lower level was optimal. Making sure the test scripts that are used cover the right scenarios is a vital part of the project’s success and problem-free migrated applications. In the end, MTA’s mainframe application portfolio ran exactly the same as it always has without any visible or impactful change for users. However, by moving IMPACT off the mainframe, MTA achieved its cost-savings goals and began to validate their organizational approach for modernization.

Conclusion

Organizations such as the US government are struggling with aging applications and the rusty infrastructure they call home. CIOs understand the inevitability of migration to modern languages and platforms, but these systems and the resources supporting them are complex and highly intertwined with core business operations and processes. As a result, IT leadership often chooses to “kick the can” of modernization down the road, assuming that the risks of doing anything are greater than the risks of fiddling with these integral systems at all.

The reality however, is that the risk of doing nothing far outweighs the risk associated with optimizing or modernizing the existing environment through informed decision-making. These systems are ticking time-bombs, poised to explode at any given moment with unforeseen impact due to lack of understanding, visibility, and a skilled resource pool to clean up the mess.

Through automated conversion, organizations are able to retain the business rules and look and feel of a legacy system while extricating themselves from procedural code very few people understand and infrastructure that costs more every year to keep in operation. However, not all conversions are created equal. When choosing a modernization provider, it is important that the tools and services they have at their disposal meet the needs of the organization and supporting resources in the future.


About Modern Systems

Modern Systems is the leading provider of legacy language and database modernization. Leveraging over 30 years of best-practice domain expertise, Modern Systems works closely with its customers to minimize risk and provide a clear path from legacy platforms like COBOL, Natural/Adabas and others to modern solutions like SQL, DB2, Java, C#, and more. Modern Systems has completed massive projects for the US Department of Energy, US Department of Agriculture, the US Postal Service, and many more government agencies in the US and across the globe. Modern Systems has offices in the USA, UK, Italy, Romania, and Israel.

Visit http://modernsystems.com to learn more.

whitepaper - modern systems: legacy modernization...

Documents