SHARE: GAO’s Mainframe Risk Claims Debunked

pexels-photo-825262.jpeg 

The Government Accountability Office’s (GAO) 2018 report, “Information Technology: IRS Needs to Take Additional Actions to Address Significant Risks to Tax Processing,” calls into question the viability of the mainframe as the system of record for governmental systems. It also cites a shortage of human resources with critical skills. (View the brief of the GAO report here.) This article highlights a few issues with the report and its assumptions about the mainframe’s viability, and offers some insights into how the government agency’s problems are tied to poor management and could be remedied without transitioning away from their proven reliable and the lowest Total Cost of Ownership (TCO) mainframe architecture when compared to any other platform.

 

Time-Tested Programming Languages Are a Major Advantage

The GAO report’s premise that the systems face “significant risks due to their reliance on legacy programming languages” (Assembler and COBOL) is nonsense, according to one individual SHARE spoke with. Every programming language produces the same thing:  machine code. The business logic encapsulated in the programs is the real critical business value, and it has been developed and evolved over decades to improve capability and adjust for changes in policy.

While it’s true that some mainframe Assembler language instruction sets were defined in the 1950s, many of the business essential aspects of the mainframe architectures from that period have survived and evolved. IBM’s stated commitment is to ensure bridges from existing mainframe applications are never burned – a path for efficiently moving forward with the evolving architecture will always be provided. The successor architecture in use today is the “z/Architecture,” with the current product example being the z14 series of processor, which is as modern as any other processor architecture in use today. The z/Architecture Assembler language instruction set has been continually updated on an 18- to 24-month cycle over the past six decades.

In parallel, the COBOL programming language has been continuously updated since it was standardized in the 1960s, and is very much capable of supporting any of today’s developers’ requirements. One of its key features, and a major part of its value proposition, is to minimize the disruption (necessary rewriting) to bring existing code forward from one release to the next. In terms of risk, choosing any other programming language will be riskier than continuing with COBOL, even as new languages are devised fairly often. Replacing a language wholesale is (1) a monumental task, (2) one that almost always takes longer and costs much more than planned, (3) causes major problems due to errors, and (4) introduces a new set of risks for quality of service attributes – reliability, availability, and serviceability.

 

Hardware Management Is Essential

The GAO suggests that outdated hardware is expensive to maintain past warranty and leaves the systems vulnerable to equipment failure. Of course, choosing not to upgrade equipment with regularity is what leads to more expensive maintenance. Today’s mainframes are released on 18- to 24-month hardware upgrade cycles, with each successive generation typically costing less per unit of compute power required per any defined business unit of work including memory, disks and tapes storage, and connectivity fabric. Increased costs aren’t due to the IBM mainframe being an out-of-date technology, but are driven by poor decision making. Upgrading mainframe hardware often also saves money because newer hardware is cheaper to maintain, with lower recurring maintenance costs, requiring less power, cooling, and floor space.

Any competently managed IBM mainframe configuration delivers a lower TCO than any of the other competing architectures capable of the same scalability to meet critical business requirements.

A 30-year veteran of maintaining the assembler language code (ALC) of the IRS mainframe, who works on the Individual Master File, explains that ALC is fast and efficient. This is critical in the age of ever growing record sizes, new projects, and more, all operating on the same machine. The IRS runs this processing daily and processes millions of records each day without fail, he says.

Rather than “throwing out the baby with the bath water,” the IRS should consider a phased strategic and tactical approach to going from ALC to one of the modern higher level languages, such as C, C++ and Java. These languages have a continuous stream of candidates trained today in every major academic venue, starting in high schools and threading through colleges with a technical curriculum. Beyond these avenues, additional academic initiatives exist to create new enterprise-ready developers at the grassroots level, including organizations such as the IBM Academic Initiative, the Enterprise Computing Community, and IT-oLogy.

 

Talent Management Is Required

Like any good employer, government agencies must assess their future workforce needs, but the GAO report suggests that the mainframe is to blame for the agency’s poor planning. The IRS, according to the report, experienced the “attrition of developers skilled in legacy programming languages,” which the GAO says could lead to significant financial risks for taxpayers.

Managing for unplanned attrition is a management responsibility for any computer architecture or even any other service delivery organization. Workforce planning is an issue for all job descriptions in any company or agency. It is good practice to recognize when you need to backfill and train new talent to be prepared for retirements or transfers. In fact, the IRS issues refunds in a timely manner because it trains its own ALC programmers, and current programmers train new programmers. The workforce talent problem is solvable without switching platforms. Competent programmers can learn these legacy programming languages. As mentioned earlier, the IRS should have plans for use of programming languages for current application’s enhancements and new development that can meet their needs into the foreseeable future.

A reimplementation of any application would involve new staff, use different languages, and attempt to duplicate existing business logic. It is now public information that the Corporate Account Data Engine (CADE) project failed in its attempt to completely update the IRS tax filing system by rewriting the IMF Assembler code into C++ and rehosting the data in a Db2 database. The project was cancelled after eight years and billions of dollars because it was unable to handle the full load of IRS tax returns. Currently, the CADE2 project aims to create a Db2 database from IMF data by rewriting the code line by line in Java, but the effort is going slowly.

During a reimplementation, existing staff will find it more difficult to provide guidance and knowledge transfer because of the different languages than they would if they assisted new staff in learning to work with the existing code base. So long as there are COBOL programmers on the job and available in the job market, a customer or government agency can recruit new and mentor existing IRS programmers (even from other platforms) to design, code, and test.

According to a Reuters report, there are 220 billion lines of COBOL in use today and that 95% of ATM transactions and 80% of in-person transactions rely on this programming language, simply scrapping the mainframe and switching to a different architecture without proper risk assessment seems foolhardy.

 A close read of the GAO report reveals that the architecture itself is not the source of the potential risks at the IRS. The lack of preparation for workforce retirements and transitions is the true root cause. This left IRS’ mainframe environment without the skilled workforce it needs to run properly. It also calls into question the agency’s ability to manage the necessary maintenance and upgrade needs of its systems, regardless of the computer architecture. An independent audit of all IRS computer systems is highly likely to find the same flawed practices in other areas. Businesses know the value of the mainframe and that a realistic risk assessment is necessary for a proper computer-processing needs strategy, an unavoidable requirement before any current mission-critical processing is shifted off the mainframe platform.

A true risk assessment would reveal that the safer, cost-effective path is to upgrade current IBM mainframe systems. This is especially true because, as the GAO report states, the IRS has faced “budgetary reductions limiting travel, moving costs, [and] stipends, which have prevented the agency from continuing its efforts” to recruit and train future developers. Mainframes can perform non-disruptive upgrades, provide additional capacity on demand, and have a proven track record of performance and compatibility. With proper planning, funding, and regular upgrades, the mainframe is better positioned than any other architecture for the agency’s future processing needs.

Recent Stories
A Legacy of Wisdom: The Dr. John Ehrman Interview – Part IV

Advice for Women in IT, From Women in IT

SHARE Pittsburgh Preview: Greg Caliri on Measuring and Monitoring Performance