Digital Transformation in Government Should Start with Low-Code and No-Code Development

The views expressed are those of the author and do not necessarily reflect the views of ASPA as an organization.

By Bill Brantley
May 9, 2020

On April 10, 2020, IBM and the Linux Foundation launched initiatives to help American state governments find COBOL programmers. Unemployment claims have skyrocketed because of the coronavirus pandemic, and the state unemployment systems are straining under the load, mainly because most of the state unemployment systems are COBOL mainframes. The current crisis reminds me of the last time the United States dealt with the COBOL mainframe problem.

I’ve written before about my experiences as a Presidential Management Intern (now Presidential Management Fellow) working on the Y2K Date Change Project at the U.S. General Services Administration. Back then, the problem was that the COBOL programs were not designed to handle a four-character year. Not surprising because COBOL was created in 1959 as a stopgap until a better programming language was created.

However, the Department of Defense helped promote the adoption of COBOL, and the rest is history. For its time, COBOL was the best data processing language designed for mainframes. Mainframes ruled the 60s and 70s, and it wasn’t until the 80s that the client-server model made inroads into business offices for knowledge workers.

At first, office workers would smuggle in the hobbyist personal computers that ran the killer app – spreadsheets. As more personal computers were brought into the office, they were networked into client-server networks. So, for a while, offices had both mainframes and client-server systems. It wasn’t a natural marriage between the two technologies, and it grew even more complicated when the commercial Internet took off in the 90s.

What Did We Learn from Y2K?

Except for a few minor hiccups, January 1, 2000, went smoothly. It took a significant effort on behalf of governments around the world and a coordinated federal and state government response to transition the COBOL programs to a four-digit year. I was on the General Services Administration’s public outreach effort and remember setting up publicity campaigns to explain the Y2K situation to different non-technical audiences. There was lots of interest before the event but, on January 2, 2000, people’s attention quickly shifted away. The problem was “solved” and the focus soon shifted. Meanwhile, COBOL mainframes still operated and formed the core of many essential services.

Twenty Years after Y2K

After Y2K, technologies built on the Internet exploded. Websites became more like software applications, mobile apps became an essential part of people’s lives, and cloud computing gave people unprecedented access to computing power. When I left the federal government in 1999, my work computer and network technology were superior to my home computer with its dial-up access. After returning to the government in 2008, my laptop was more powerful than my work computer, and I had better Internet at home. My personal Office 360 and Adobe Creative Suite subscriptions give me more tools than work provides.

The COBOL Mainframe Strikes Back

During my brief tenure at the U.S. Department of Agriculture, I was a Human Resources Information Systems Branch Manager. I inherited a new department with some old technology. The person before me had to create reports based on the information provided by a COBOL database that held the personnel and payroll information for several major federal agencies. His solution was to have the COBOL mainframe create a bi-weekly text file he then put into a Microsoft Access database. He had many queries and macros he used to create reports in Excel. It was slow and hard to change for ad-hoc reporting. He also didn’t document his work. I spent many frustrating hours trying to understand his code.

And I am not the only government worker who has to use home-built spreadsheets and databases to help in my work. You can often tell who the office’s Excel expert is by the number of people hovering around their door. Why not encourage this ingenuity and innovation?

The Low-Code and No-Code Revolution

Low-code and no-code arose because of three reasons:

1. Lack of software developers.

2. Drag-and-drop programming.

3. The rise of the application program interfaces (APIs) that are hooked together like LEGO® blocks into working software.

Here is one example: a government worker can build a SharePoint list that holds data. The data can be automatically updated using Microsoft Flow and presented as a mobile app that was designed and programmed by the same government worker—All with minimal coding (just by writing an Excel-like formula). The SharePoint site goes from idea to working mobile app in a few hours versus days or even months of traditional software development.

Governments may still have COBOL mainframes for another twenty years as governments finally realize the power of digital transformation that has energized the private sector. During this transition, wouldn’t it make sense to encourage the innovation of government workers by giving them low-code and no-code tools? A government digital transformation starting from the grassroots may be the best way to transform government.

---

Author: Bill Brantley teaches at the University of Louisville and the University of Maryland. He also works as a Federal employee for the U.S. Patent and Trademark Office. All opinions are his own and do not reflect the views of his employers. You can reach him at http://billbrantley.com.

(2 votes, average: 5.00 out of 5)
Loading...