Software reuse faces barriers in government sector

At one time, the process of creating software was considered "black magic." Today, through the discipline of reuse, software can be assembled from reusable components. The benefits of software reuse in terms of efficiency and savings are self-evident and widely seen in the commercial sector.

But for reuse to make a similar federal impact, the government must make some monumental mindset changes from both a policy and organizational perspective. Agencies, for example, must determine how best to fund reuse programs and how to organize to get the most benefit.

In the past, most federal software reuse discussions focused on such technical issues as object repositories or libraries, where reusable components are stored. But technology has now become a subset of a larger reuse discussion.

"It's bigger than just a repository," said Lt. Col. Mike Paitt, a software engineer at Air Force Headquarters, which has launched a Software Reuse Initiative. "I don't even think about the repository. I think about the organizational development processes."

That's why the Air Force and other services are heavily promoting the concept of a "product line" approach to software reuse. This methodology involves looking for relationships between different systems that can be exploited by applying reusable components.

The product line focus emphasizes critical organizational issues, Paitt said. "We want organizations to look at how they are arranged to design, build and maintain systems," he said.

Within the Pentagon, the Defense Department Software Management Review Council is looking at some of the same issues as part of a larger effort to address software management problems in DOD.

The council has created a process action team that is looking at ways to ensure Defense agencies take full advantage of the reuse approach, said Cynthia Rand, principal director for information management in the Office of the Assistant Secretary of Defense for Command, Control, Communications and Intelligence.

"When it comes to reuse, we are in a project-oriented or systems-oriented environment," Rand said, but reuse must be much more widespread "in order for reuse to return the kind of investment we are looking for."

Unfortunately, program managers are working with program specifications and budgets that take a more traditional approach to software engineering. "How do we change the overall structure that is already in place?" Rand asked.

A Call for Change

Indeed, reuse experts identified project funding as a key area in which change is needed. Congress and top agency officials, they said, must turn from favored line-item funding methods to the product line approach. In the past, Congress has funded agency-specific, top-to-bottom systems. This practice, however, defeats the purpose of reuse, which is to share common software elements among multiple systems under construction within

agencies.

In addition, midlevel managers must be willing to spend more dollars up front in order to save money later in the software life cycle. Reuse, for example, calls for considerable planning and coordination as well as the creation of specialized reuse repositories.

The reuse challenge has gained high visibility within DOD, which is light years ahead of civilian agencies in this field. DOD's Software Reuse Initiative, launched in 1992, stated its vision as "driving the DOD software community from its current 'reinvent the software' cycle to a process-driven, domain-specific, architecture-centric, library-based way of describing software."

This is the essence of the product line approach that reuse proponents advocate. The product line method is actually a byproduct of both the re-engineering movement and changes in the software industry. "Software development as an industry started as black magic, where you would stick someone in a back room and they would come out with something," said Lorraine Martin, director of advanced information systems for Lockheed Martin Corp. "Now we are starting to realize that it is an engineering field."

Lockheed is the prime contractor on two large DOD reuse initiatives: the Defense Advanced Research Projects Agency's Software Technology for Advanced Reliable Systems (STARS) and the Air Force's Comprehensive Approach to Reusable Defense Software (CARDS).

Within the federal government and industry, however, software engineering still retains remnants of its former mystique, Martin said. "We need to learn how to treat software as an engineering process and not pretend that each time we build something, it's revolutionary," she said.

Martin, however, spoke of pockets of enlightened software developers within the government who have adopted the product line approach.

But for the government, adopting a product line approach to developing software-intensive systems involves painful cultural change, particularly in an era of tight budgets.

For reuse to be successful, a project "needs up-front work in systematic reuse requirements and extra resources," said Lt. Col. Gene Glasser, director of the Army Reuse Center. "It takes time and money to do this type of thing. You need to have money to make money."

Reuse is costly because it is complex and involves introspection at many levels. Developers must first look extensively at existing systems within a particular domain - for example, simulation or medical systems - before embarking on new efforts that incorporate reuse.

"If you are looking at legacy systems, you are not likely to pick up something and be able to reuse it in a system that was not built for it to be reused in," explained Beverly Kitaoka, group senior vice president for Science Applications International Corp.'s Applied Software Systems Engineering Technology. "First, you would have to untangle it and rewrite it."

"In reusable design and code, one of the big issues is how to know if you've got something that is reusable," added Tani Hague, chief executive officer of SQL Software Inc. Making that determination can require a lot of work.

Then there is the issue of containing and/or distributing reusable software. The task of building libraries of reusable software code could also result in a significant up-front expenditure. "Most folks believe that for effective software reuse, you need a library of components. It is a fact of life in the world of software reuse," said Jim Moore, chairman of the Reuse Library Interoperability Group. The group encourages organizations with reuse repositories to interoperate so that users can tap software assets without having to know in which specific library those assets reside.

Reuse Obstacles

These are just some of the headaches and expenses surrounding a commitment to reuse. They are compounded by the fact that previous stabs at reuse programs have been less than breathtaking.

"In software reuse, there has been more promise than reality," said Fred Fath, vice president of technology at Boeing Information Services. "It was initially thought that there would be software reuse libraries and subroutines integrated into software applications. To a degree this has happened - but very little. What's happened is that certain entities have developed their own pieces instead of standardized components."

That is precisely what happened to the Naval Surface Warfare Center, within the Fleet Combat Training Center in Virginia Beach, Va. "Reuse has not been centralized, and that is unfortunate," said Ray Gluck, library/program control officer at the center, which undertook an extensive reuse exercise in the late 1970s.

"We kind of took a narrow look at it and developed a product in-house and hoped that it would catch on with others, but it didn't," Gluck said. The endeavor involved software reuse in combat systems residing on board Navy ships.

But the Naval Surface Warfare Center was still able to reap the benefits of reuse. "We got to the point in developing the system where we had a 70 to 90 percent reuse rate." Those returns did not come without cost. "Our projects cost 7 to 15 percent more to get started," Gluck said. "That doesn't sound like much, but it is when you are talking millions of dollars." But he added that the investment was worth it, despite limited reuse outside the center.

One of the most important lessons to emulate from his center's exercise in reuse involves the importance of top-level support, Gluck said. "In terms of management commitment, it must occur in the upper level," he said. "It will cost more to get started, but you will have savings in the end."

The stovepiping of systems within agencies and the blatant lack of intra-agency collaboration on systems are also standing in the way of widespread federal reuse, said Randy Scott, director of business development at the Software Productivity Consortium.

"Barriers from the government side are clear," he said. "One is that to do successful reuse, you've got to plan it up front and make investments. DOD and the government's approach is to hold program managers accountable for only their own systems. There is little to no systems or technology that cuts across to other systems."

The turf issues that would have to be addressed before such collaboration could occur may indeed be paramount to the start-up costs surrounding software reuse. As more reuse libraries and repositories become available and new methods of locating reusable elements evolve, those systems relying heavily on reuse will become less expensive - or so the theory goes.

"Cost avoidance and saving resources - man-hours and other resources - is our final goal," the Army's Glasser said. "But it is difficult to predict [the savings associated with] something like that up front." Glasser and his staff are examining individual program executive offices to determine the extent of existing or potential reuse. "We are trying to identify commonalities across domains and incorporate these into an Army reuse implementation plan."

Getting to the kind of savings Glasser and others are seeking, however, involves unheard-of collaboration at the midlevel stage of system development. A broad base of reuse requires an initial plunge on the part of some program managers, who are willing to ask for additional resources that may result in savings not for themselves but for a subsequent colleague.

"Program executive officers...right now don't have all of the leeway they should have," Glasser said. "For instance, if you have 30 programs and discover commonalities, one program may have to spend more money so others can benefit from it. If you are one of the [subsequent] PEOs, it makes sense. If you are the first program manager, it doesn't."

In this sense, the midlevel barriers to reuse are tougher than those at the top, Glasser said. "The higher you go, the more reuse makes sense."

There are challenges to reuse in the procurement system. Said David Kriegman, vice president and Umbrella III program manager at SRA International Inc., "The incentive should be obvious - to build systems faster and cheaper - but [government contractors] are not always incentivized that way. Frankly, a company may be incentivized or think they are incentivized to build a system. If they build it off-the-shelf in a short amount of time, they may not be paid a lot." SRA is working on Army reuse efforts under the Umbrella III contract, awarded in 1995.

To promote software reuse, the government must make fundamental management changes.

"The federal government must learn how to reward people, regardless of whether they are writing code or reusing code and taking the rest of the day off," Moore said. "It needs to compensate not for the effort but for the result."

**

Jones is a free-lance writer based in Arlington, Va.