CASE STUDY

Mainframe to the AWS GovCloud Cloud One

COBOL to Java
US Air Force AFLCMC SBSS ILS-S 5.0 Modernization


Client

US Air Force


Software

ILS-S SBSS 5.0 


Language Pairing

COBOL to Java


Time to Completion

10 months

History


The Software Revolution, Inc. (TSRI) was contracted by Array Information Technology, Inc. (ARRAY, now CGI Federal) under the NETCENTS-2 contract vehicle to help modernize the Standard Base Supply System (SBSS) Integrated Logistics Systems-Supply (ILS-S). The ILS-S is the quintessence of a mission-critical system. More than 20,000 users at 250 U.S. Air Force, Air Force Reserve, and Air National Guard fixed operating bases and forward operating locations utilize ILS-S to provide daily supply and equipment support for wartime flying missions.

Part of the ILS-S was a modern Java/Oracle® application, but the Standard Base Supply System (SBSS, an aged but key portion of the ILS-S system) consisted of a legacy back-end system running on Unisys® mainframe computers. The latter system provides the core business logic and authoritative data to ensure the availability of base-level management of supplies and equipment for warfighting missions. This modernization targeted the AWS GovCloud in the U.S. to address stringent security and compliance requirements, such as U.S. citizenship, set forth by the U.S. Air Force.

The core requirements that define the goals of this project included modernizing the SBSS application needed to exhibit performance and functionality equivalent to or better than the legacy system. The USAF selected AWS GovCloud (US) as its target environment because the provider aligned with the future technical direction of ILS-S, including cybersecurity, DevOps, and AWS’ native automated continuous integration and delivery tools. SBSS is a widely used critical production system, there was little to no tolerance for code freeze.

Finally, after 50 years of development and maintenance, the code needed comprehensive documentation to elucidate the system's structure and processes.

Highlights

99.9982% Automation

Lowest Technical Risk

On-Time Delivery

Lowest Bid Project & Under Budget

More Efficient Code Base

Code & Database Modernization

Code-Level Documentation

Secure Transformation

The Team


Team ARRAY started developing the ILS-S SM-RP solution by reviewing options that included a total rewrite, a re-architecture solution, a COBOL-to-Micro-Focus-COBOL migration solution, and an automated code conversion. The total rewrite and re-architecture solutions failed to meet the program time constraints, had historically low success rates, and were too costly.

The COBOL-to-Micro-Focus-COBOL migration solution was a stopgap measure that failed to reach the Red Hat Enterprise Linux (RHEL)/Java/Oracle architectural future state. Team ARRAY selected the automated code conversion solution because it had the highest probability for success in a cloud-native environment and the lowest cost.
Next, the team selected the right code conversion tool. Team ARRAY initially reviewed 12 code conversion tool vendors. Team ARRAY conducted a competition with four down-selected tool vendors: Semantic Designs, Dell, EvolveWare, and TSRI.

Each vendor submitted a written proposal outlining their technical approach, project schedule, risk/mitigation strategy, total cost, expected level of effort from the government, and past performance for similar size, scope, and technology projects.

Team ARRAY selected TSRI based on the following:

For Program Executive Officer (PEO) Air Force Business and Enterprise Systems (BES) Reliability and Maintainability Information System (REMIS), TSRI successfully converted 300,000 lines of COBOL code into objectoriented C++ and Java/JEE, which resulted in the prime contractor naming TSRI “Small Business of the Year.”

TSRI offered an automated code roll tool capable of converting 95% of the legacy SBSS code, which minimized costs and allowed Team ARRAY to focus on overall conversion quality instead of manual code conversion; TSRI also provided the highest probability of meeting the 25-month schedule.

The TSRI solution had the lowest total price of the tools assessed.

TSRI offered an automatically generated blueprint capability that provided the direct 1-to-1 COBOL-to-Java traceability and accountability required to confirm that all software capabilities in the “as-is” system migrate into the “to-be” system and automatically identify any Unisys operating system gaps as a result.

Team ARRAY’s goal from the outset was to assist PEO BES successfully launch a high-confidence information technology (IT) program. Enhancing the probability of success required due diligence and commitment by both government and industry.

Collectively, government and industry invested the time and resources to fully understand the requirements, risks, and timelines to ensure the ILS-S re-platform program was delivered as promised.

TSRI Technology and Past Performance


At the core of TSRI’s technology is JANUS Studio®, an artificial intelligence-based, model-driven transformation engine. Rather than simply transliterating “source” code to “target” code, the JANUS Studio® engine executes a mature translation/transformation to modern architectures by first constructing a comprehensive model of the legacy system in an intermediate language.

This model-driven approach allows for fully automated refactoring between any practical combination of source and target languages, as well as production of code-level documentation, and automated refactoring of systems.

The final requirement was the production of code-level documentation. TSRI uses the JANUS Studio® engine to quickly generate comprehensive UML-based code-level blueprints: the Application Blueprint® and the Transformation Blueprint®.

These allow developers to understand both the as-is source code (COBOL, for ILS-S), as well as the transformed target code (in this case Java), in side-by-side hyperlinking format.

The artifacts and graphs produced include Control Flow, Data Flow, Cause-Effect, Complexity Analysis, State Transition Tables, and other analyses of the structure and flow of the application.

This approach has now been used in over 150 major modernization projects, including:

The extraction of business rules for an assessment project on the Air Force CAMS.

Modernization of the Air Force MEMSIZE and NEWSCAN applications from Fortran to C++.

Assessment and Transformation of Air Force F-16 Data Entry Cockpit Interface Set (DECIS) Up Front Display System from Jovial to C++.

Modernization of the Air Force Weather Data Architecture Capability (WDAC) from Fortran to Java.

Modernization of portions of the Air Force Command and Control System-Consolidated (CCS-C) program.

Two modernizations of the Air Force REMIS System—first from COBOL to C++ and again from COBOL and C++ to Java.

Modernization of the Air Force Weapons System Cost Retrieval System (WSCRS) from COBOL to C++.

Modernization of Air Force Joint Mission Planning System (JMPS) from VB6 to C#.

Modernization of the Air Force Electronic Systems Center Ballistic Missile Early Warning System (BMEWS), which migrated Ada and Fortran to Java and C++.

Other projects, including avionics modernization, for the F-16, P-3C Orion, and E-2C aircraft, air traffic control systems, radar and electronics systems, and many others.


SBSS Modernization


In the case of SBSS, the source application was a Unisys/COBOL system comprising 1,260,679 lines of COBOL code and 10,078 lines of C code. The SBSS has been in existence for over 54 years and the Air Force had tried several times to modernize away from Unisys.

They failed each time due to the seemingly overwhelming complexity of the task. In fact, SBSS modernization was regarded as such a difficult task that the book Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices introduced referred to the project in chapter 2 as “The Beast.”

After SBSS was modeled within JANUS Studio® engine (intermediate model construction), TSRI’s modernization engineers began an iterative process of applying rules and tuning to the engine to output the transformed system in the target language from the intermediate language according to the Air Force’s specifications.

The target, as defined by the customer, was a mid-tier Java environment, including Unix Shell Scripting, Red Hat Enterprise Linux® operating system, Apache web servers, JBoss, and Oracle RDBMS on the AWS GovCloud (US).

During the project, the Unisys COBOL network database code was transformed to 1.7 million lines of COBOL with SQL. TSRI then transformed this COBOL/SQL code to a Java target on AWS along with the rest of the application code.

The SBSS transformation resulted in 7.9 million total lines of Java code—a large expansion from the original 3 million lines of COBOL (1.3 million source lines of code and 1.7 million lines of code from the database transformation). This is a common result for a first-pass transformation due to the expansion of copybooks and other cut-and-paste portions of the application. TSRI used its proprietary automated refactoring capability to reduce the size of output code through the following refactoring methods:

SBSS AWS Target Architecture

Identical Record Consolidation

DAO Method Consolidation

Unused Definition Removal


TSRI considers a system like SBSS to be of medium size and medium complexity. As a result, although TSRI can undertake code transformation using a “spiral” development model, which parcels the code into units conducive to rapid, progressive delivery, integration, and testing, the relatively small size allowed TSRI to regenerate the entire code base with each iteration. With each new improvement, TSRI delivered the code to the ARRAY development team to integrate and test as compiling, integration-ready Java.

TSRI’s transformation left external calls stubbed out; the ARRAY team completed the work of reintegrating items like schedulers and other utilities, testing the initial spiral of code, and providing TSRI with defects via Bugzilla. In response to each spiral delivery evaluation, TSRI adapted its transformation rules and regenerated improved iterations of the spiral code according to internal evaluation and ARRAY’s requests.

TSRI proceeded through spirals sequentially until all 1.3 million lines of source code were transformed. These techniques, along with the improved method synthesis algorithm mentioned above, brought the code size down to
5.2 million lines of Java.


Application Testing


TSRI and ARRAY also collaborated on application testing of the output product. The NTT DATA Services solution architect chaired daily meetings during the testing phase to coordinate synchronization of the involved teams.

TSRI used its automated toolset to inject telemetry into the legacy COBOL system, which was then placed back into production. Telemetry allowed the team to capture data put into the system, and data generated back out, so they could compare that data with the same inputs and outputs of the modernized system. When the data streams from the legacy system were compared with data streams from the modernized application, discrepancies were identified by ARRAY and fed back into TSRI’s toolset. This automated approach allowed for more rapid debugging and proof of functional equivalence. As of today, this automated telemetry approach has been used by TSRI for a number of customers, including the U.S. Navy, and results in relatively efficient and accurate testing as compared to less automated methods.

After testing, the following issues were identified. Often, when undertaking transformation work, TSRI’s process uncovers bugs latent in the original source code, e.g., 43 original COBOL and 48 Unisys COBOL/SQL issues. In the entire 1.3 million lines of code, only 62 transformation issues were identified: one defect per 21,000 lines of code transformed. These results compare very favorably with validated industry standards of 15-50 defects per 1,000 lines of code written manually:

290
Issues Total

0
Issues with original COBOL
0
Issues with Unisys COBOL/SQL
0
Necessitated enhancements
0
Framework issues
0
Telemetry related issues
0
Transformation issues

Lessons Learned

ILS-S's original COBOL took advantage of many features of the COBOL language as yet undefined in JANUS Studio®. TSRI’s toolset was extended to systematically handle these features by conducting COBOL-language experiments on the original mainframe to arrive at a sophisticated characterization of the behaviors in question. TSRI’s frameworks were then updated accordingly.

In the ILS-S codebase, control flow proved to be particularly tricky. The application contained numerous GOTOs jumping out of perform ranges, never to return. To resolve this, TSRI extended its method synthesis algorithms and GOTO elimination strategies. However, this resulted in some code expansion and duplication in the transformed code. Addressing these by-products was not within the project's scope, and didn't have a functional impact, but TSRI has since identified strategies to further improve handling of similarly convoluted control flow patterns, which will be pursued to reduce or completely eliminate the code expansion observed in the current solution.

Result


Following the first two phases of this project in which TSRI modernized COBOL to Java, then used automated refactoring to develop an optimized version of the Java code, the project partners were able to deploy the transformed application to the AWS GovCloud in the U.S. The project was considered highly successful, and the Air Force received an end-to-end solution for a mission-critical legacy application in a very low-risk and efficient development, testing, and deployment environment.

The TSRI/ARRAY/NTT DATA Services team not only modernized and implemented “The Beast,” but also in parallel delivered three major FIAR releases, deployed to the AWS GovCloud, migrated into big data, and embarked on a DoD-leading mobile implementation.

Now that TSRI has a JANUS Studio® instance tuned specifically to the SBSS target code and architecture, future modernization projects for the Air Force with similar source code and a similar target architecture in the cloud will enjoy the advantages of schedule and effort reduction.

The automated JANUS Studio® toolset learns with each project, and the code transformation rules created have been automatically reused in subsequent projects. This has major implications for other large Air Force systems written in COBOL and may be targeting similar Java implementations to the cloud.

Both ARRAY & NTT DATA Services have also learned how to rapidly take TSRI’s outputs and evaluate, test, and return information for retransformation. Together, our team is prepared to tackle larger modernization projects and deliver them successfully, whether to the AWS Government Cloud or other target architectures.

Here is what the customer had to say:
"The system is a modern, elastic, secure, U.S. Air Force Cloud One Amazon Web Services (AWS) GovCloud application with 120 interface agreements with 46 systems to support 18,000 end users and over 100,000 consumers of ILS-S information at 250 military installations. ILS-S tracks over 35 million assets valued at $18 billion—assets that are optimally distributed and stored across 1.7 million warehouse locations. ILS-S also provides inventory control of 230,000 assets in deployable air transportable containers to support contingencies and special operations." 

Source: Defense Logistics Agency (DLA) - https://www.dla.mil/AboutDLA/News/NewsArticleView/Article/2890067/system-tracks-every-item-in-the-air-force-inventory/