ANOTHER VIEW: Herbert Schorr

Research can head off poor systems work

Herbert Schorr

I research computer applications and often focus on software for government agencies. Over the years I have become increasingly concerned with how agencies craft information management products.

There is a better way to develop these products than is commonly done, and I am glad to report that a newly established research center will help agencies begin to use that process.

Government often has special needs that cannot be satisfied by off-the-shelf software unless it is customized. In such cases, the software requirements are typically more severe than even the most demanding commercial applications.

With information security, for example, banks and retailers can and do accept a certain amount of risk of fraud. But unauthorized access to government data such as Social Security or Medicare records is both illegal and politically unacceptable.

Requirements for information systems will become even more stringent when the bulk of the public's dealings with all levels of government occur over the Internet.

Corporations with demanding information technology needs often invest in R&D labs to find the best technology available or invent what they can't find to solve their business or manufacturing problems.

Digital split

In today's federal government there's a kind of digital divide. On one side are agencies such as the Defense and Energy departments and the National Institutes of Health that can access such in-house research facilities. On the other side are federal as well as state and local government agencies that lack access to research.

This divide is a tangible distinction. Agencies without in-house research facilities have far more difficulty getting the software they need than agencies that do.

Making things even more difficult for the have-not agencies is a government procurement process that requires officials to prepare and field proposals with precise descriptions of what they need built. Such a process can work well for commodities, equipment and even buildings. But for software, this method often results in agencies awarding a contract, waiting, receiving the product and finding that although it corresponds to the specifications, it either does not fill the agency's requirements or fills them poorly.

Software for a complex system that will satisfy an agency's need is difficult to design from scratch because users often cannot describe what they need until the system is put into operation and its deficiencies are revealed.

To counter this, agencies write specifications following the kitchen-sink principle: We must live with this system for decades, so let's put everything we think we will need into the specifications.

This approach tends to layer too much cost and complexity on a system while simultaneously missing major requirements that program managers couldn't anticipate.

A better approach would give buyers a clear idea of whether a design, once built, will meet the needs of their constituencies. I call it the iterative approach. An agency solicits bids for a prototype that delivers the minimum function required and put it into limited operation. In follow-on versions it iteratively adds functionality until the prototype succeeds. Then it enlarges the program team and applies standard software engineering methods to the production version.

If the prototype falls far short of the mark, it can be discarded at little cost and some benefit'a failed prototype helps the team determine what it really needs. That knowledge will lead to a better second prototype.

There is an additional benefit: Unlike the task of creating a full-scale, kitchen-sink system, prototyping can be done by a small, highly skilled and motivated team.

Iterative, prototype-based design would result in better software for individual agencies' systems. A larger problem is difficult to solve in the present procurement structure. Each agency justifies its budget according to its own functions and programs. This process is usually carried out independently of the role the agency plays as one part of a large suite of government entities serving the public. And, it results in stovepipe systems.

In such groups or suites of services, responsibility for coordinating the data of the group often falls by the wayside. And when it's not any single agency's responsibility, or in any single agency's budget, the task remains undone.

But for a citizen who needs to develop property, get permits or apply for benefits, stovepipes create a frustrating process of bouncing from agency to agency and requires them to enter the same information repeatedly and suffer other delays and frustrations.

What's required?

Citizens want to know what payments and paperwork are required, and they don't want to ferret out that information by dealing with several agencies at the federal, state and local levels in a bureaucratic shuffle.

Some governments already provide an alternative model. In Norway, for example, starting a business had required obtaining approvals from more than 30 government entities. Recently, the Norwegian government introduced a single online form that an applicant can fill out, with appropriate sections going to each concerned body.

One new effort in the United States is dealing with the stovepipe problem by helping government agencies find better ways to handle their computing needs as they make government more accessible to citizens. The National Science Foundation has embarked on a digital government program, at a modest level, to encourage the academic research community and federal agencies to work together.

The recently chartered Digital Government Research Center is the result of a collaboration between Columbia University and the organization I direct, the Information Sciences Institute of the University of Southern California institution.

The initial effort is small. But even now, the center can play a leading role in improving government's access to the best new technology. It also can play the role that in-house research labs play in institutions such as DOD.

It is outside the single-agency framework, and it has the explicit goal of crossing agency lines to make citizen access to government more efficient and less frustrating. To get more information about its efforts, look
at the center's Web site, at www.dgrc.org.

Herbert Schorr is a member of the President's Information Technology Advisory Council.


inside gcn

  • open doors to cloud (Sergey Nivens/Shutterstock.com)

    New vendors join FedRAMP Connect

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above