Delivering on the promise of 'plug and play'

When the Defense Department in 1993 began to search for a replacement to the antiquated World Wide Military Command and Control System, there was no system capable of meeting all the requirements for commanding military forces on a global scale.

But officials soon realized that a cross section of the best features from the best systems might be enough to develop a cutting-edge prototype command and control system capable of replacing WWMCCS. That system is known today as the Global Command and Control System.

The search for GCCS did more than simply find a suitable replacement for WWMCCS. It spawned a new era in software development for DOD, characterized by a collection of reusable software components and common data standards that cut across all of the military services and their missions. This new era is the age of the Defense Information Infrastructure Common Operating Environment.

The DII COE offers system developers and programmers a blueprint depicting a stable baseline of programming code that can be used to develop applications that rely on common data exchange tools and thus eliminate interoperability problems.

The "reference" computing platforms that serve as starting points for application development and testing include Microsoft Corp.'s Windows NT, Hewlett-Packard Co.'s HP-UX Unix, Sun Microsystems Inc.'s Solaris and, most recently, Compaq Computer Corp.'s Tru64 Unix.

Although the original idea of establishing a common operating environment focused primarily on the command, control, communications and intelligence community, the DII COE has matured greatly during the past five years and is beginning to reap benefits for information technology programs throughout the Defense Department.

Because of the standards that systems must adhere to under the DII COE, military commanders in the field can view information from different - and sometimes service-specific - applications using a single workstation.

DOD and industry representatives say the idea is a good one and is helping DOD overcome the age-old computer challenge of interoperability.

"We've made remarkable progress," said Dawn Hartley, chief technology officer at the Defense Information Systems Agency, the agency responsible for overseeing the COE effort. "It has definitely impacted the command and control community in terms of interoperability," she said.

In fact, "we see folks like Air Force Materiel Command, the Defense Finance and Account-ing Service and other organizations embracing the COE as the basis for all of their future infrastructure work," Hartley said.

Marv Langston, DOD's deputy chief information officer, said the current strategy is to grow the COE effort beyond the C2 community so that other IT programs throughout DOD can take advantage of it.

The issue, according to Langston, is simple. "If you don't put the same computer software module on both sides of a computer interface, it's almost impossible to make it work," he said. "We also know that if you modify commercial off-the-shelf programs to support your own special needs, you get yourself into trouble," Langston said. "The [COE development] work we've done in C2 and combat support has helped us learn a lot."

At What Cost COE Compliance?

For the DII COE, interoperability is measured in terms of the level of integration achieved by the vendor's product with the standards set forth by the COE. The eight levels of compliance, with Level 5 being the minimal compliance level that all vendors must shoot for, help DOD determine the quality of a software product's development and code architecture.

At Level 5, applications running on the COE appear integrated to the user, but full interoperability cannot be guaranteed. (For compliance level descriptions, see box, Page 22.)

"Don't come see me if you're not Level 5-compliant," said Army Brig. Gen. Steve Boutelle, program executive officer for command, control and communications systems at Fort Monmouth, N.J., during the recent Milcom '99 conference. "Level 7 takes a lot of money, and I've never seen a Level 8 system," he said, adding that a lot of work remains to be done throughout DOD on standardizing data.

Although Level 5 compliance is the goal, Dave Hale, branch chief at the DII Air Force organization at the Standard Systems Group's Infrastructure Support Division, said new programs are targeting COE Level 6 compliance, which brings more integration and better security. In addition, the policy put in place by the Electronic Systems Center, SSG's parent unit, establishes Level 6 as the mandatory compliance level starting in January 2002.

Vendors understand Boutelle's commitment to Level 5 compliance and agree the COE effort is having a practical impact on systems interoperability, but some say the certification process could be easier on vendors, particularly their wallets.

Steve Sundman, manager at The Santa Cruz Operation Inc.'s Government Systems Division, which plans to submit its UnixWare7 operating system for compliance certification in the next two weeks, said the "significant" cost associated with porting and testing an application for COE compliance favors Windows NT, HP-UX and Solaris-based vendors because the government paid for the initial certification of those platforms.

"Today, COE is about either you have an Intel [Corp.] box that runs NT or you have a Unix box that runs proprietary applications," Sundman said. "The only way it's accomplished commonality so far is through designation and that's not open standards to me. As long as we're still in a reference platform basis, we're still in a situation where the government has established a COE that locks out certain competitors. [That is] unfair."

Sid Mair, national manager for Government Programs at SGI Federal Systems, whose Irix 6.5 operating system is in the kernel certification process, said he too would like to see all vendors on a more equal footing. The cost of testing and certification "affects the ability of vendors, other than the primary reference vendors, to compete," Mair said. "It costs industry a great deal of money, and we have to do it."

But Hartley said DISA plans to release an automated testing tool that vendors will be able to use on their own to test their products and then simply submit a report to DOD with the results. Officials said they expect that the use of an automated tool will significantly cut down on the amount of time and money it takes to certify products.

The Future Is Now

The latest version of the COE kernel is Version 4.1, released in October. The kernel is the minimum set of software (operating system, windowing environment and other features) that the COE requires be loaded on every computing platform regardless of how that platform will be used.

A beta release of Version 5.0 is in development. Version 5.0 of the COE kernel is expected to slim down the kernel and offers administrators a choice of components to install. It also focuses more on object-oriented and World Wide Web-based technologies. Although each COE reference platform may share a small set of common COE services, each will contain subsets of services that remain platform-specific. And then, of course, there's Java.

Much of Release 4.1 is based on Java, a cross-platform operating system developed by Sun Microsystems. Although a final decision has not been made, indications are that Java will be the main operating language for Version 5.0 of the COE.

"They've raised their sights a lot over the last few years, such as with the adoption of Java," said Doug Johnson, principal systems architect for Sun Microsystems Federal. In fact, "they want to migrate the entire kernel to Java," he said. "Primarily, they're after cross-platform interoperability," Johnson said, which is Java's strong selling point.

But like any successful brew, Java comes in different flavors, leaving vendors waiting for DOD to make a decision. "We hope not to decide unless one of the big OS vendors forces us to decide," Hartley said. "We have a fairly significant investment in Java today, [but] we're waiting to see how the competing mobile frameworks pan out," she said, adding that a decision should be forthcoming in 18 to 24 months. "We're watching that with interest, but were trying to be platform neutral."

An endeavor like the COE is "in-depth computer work" that takes time, Hale said. "It's a significant education curve for those used to Cobol and Fortran [programming]," he said. "It's doable, but it's going to take some time and different programs are going to get there at different times."

Vendors Agree: It's Worth It

Sun's Johnson said although the COE is at a point where program officials are trying to execute on what has been promised, the COE effort is just getting to the point where significant software reuse is starting to happen. "The program is mature enough that everybody has weighed in," Johnson said. "I find no one that says this is a brain-dead idea."

Tivoli Systems Inc.'s DOD sales manager, David Donovan, agrees. Having a standard set of application programming interfaces "is extremely valuable and very much needed," said Donovan, adding that standards help DOD avoid having to reinvent the wheel. "The COE will allow those APIs to remain stable and cut down on the amount of code that is out there."

But with any type of change, there's resistance, Donovan said. "There's always been a reluctance to share data within the services. It's been a learning process for people to really understand the return on investment," he said. "But there's a lot of momentum now for people to do it."

John Menkart, director of government sales for Netscape Communications Corp., said he sees a broad adoption of the COE across all areas of DOD.

"The [electronic-commerce] community has been using DII COE as a basis for their deployment, and the command and control environment has been using it from the beginning. And now we're seeing adoption down [at] the grass roots," Menkart said. Organizations are beginning to recognize that "the DII COE guarantees their application's interoperability," he said.

***

The lineup of compliance levels

Level 1: Standards Compliance

A superficial level in which the proposed capabilities share only a common set of COTS standards.

Level 2: Network Compliance

Two capabilities coexist on the same local-area network but on different central processing units. Limited data sharing is possible.

Level 3: Platform ComplianceEnvironmental conflicts have been resolved so that two applications may reside on the same LAN, share data and coexist on the same platform.

Level 4: Bootstrap Compliance

All applications are in segment format and share the COE kernel. A segment is a self-contained software unit and is the most basic building block of the COE.

Level 5: Minimal DII Compliance

All segments share the same COE kernel. Although applications appear integrated to the user, there may be duplication of functionality, and full interoperability is not guaranteed.

Level 6: Intermediate DII Compliance

Segments reuse one or more COE-component segments. Substantial security requirements are imposed upon segments at this level.

Level 7: Interoperable Compliance

Segments reuse COE component segments to ensure interoperability, including communications interfaces, message parsers, database segments and logistics services. Segments do not duplicate any functionality.

Level 8: Full DII Compliance

Proposed new functionality is completely integrated into the system. Segments use only published public application programming interfaces. No duplication of functionality among segments.

Source: DII COE Integration and Runtime Specification Version 4.0; dated Oct. 25, 1999