UNITED24 - Make a charitable donation in support of Ukraine!



Director, Operational Test & Evaluation
FY97 Annual Report

FY97 Annual Report


Total program cost (TY$) $1.6B*
Life cycle cost (TY$) $5B*
Full-rate production (IOC) 2QFY98

Prime Contractor
Lockheed Martin Federal System


DMS contributes to the information superiority necessary to achieve the Joint Vision 2010 by enabling anyone in DoD to exchange messages with anyone else in DoD by means of a worldwide, secure, accountable, and reliable, reader-to-writer messaging system. Before the year 2,000, DMS is to replace the official "organizational" messaging system, the Automatic Digital Network (AUTODIN), and is to reduce the cost and manpower demands of this legacy system based on 1960s' technology. To accomplish this, DMS must be implemented on over 360,000 desk-top computers at over 7,000 sites worldwide including our tactical forces, allies, to other designated Federal Government users, and defense contractors. Ultimately, DMS should extend to 2,000,000 desktops and provide ordinary email, "individual" messaging, by translating among commercial standards. The DMS program capitalizes on existing and emerging commercial messaging technology employing the international X.400 messaging standard and X.500 directory services standard. However, DMS rides as a value added service on a separate communications backbone ¾ the Defense Information System Network. The National Security Agency has taken responsibility for the security solution based on the Multilevel Information System Security Initiative (MISSI) technology featuring personal encryption cards (called Fortezza) for individual user and support personnel identification and encryption services. By focusing on standards-based architecture, DMS relies almost exclusively on commercial software products that vendors are willing, under contract, to extend to conform to international standards and security protection features.


The DMS program began in 1989 and, by 1992, the Office of the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (OASD(C3I)) issued a policy mandating the transition to, and use of, DMS compliant systems. In March 1995, additional policy guidance imposed a moratorium on acquisition of non-DMS compliant electronic messaging systems.

The Air Force is managing the acquisition of DMS compliant messaging components in accordance with the DMS target architecture developed by the Defense Information Systems Agency (DISA).


From the beginning, the DMS Program has had documented and validated requirements based on replacing AUTODIN capabilities to guide development. Later, the Joint Staff designated some of these as more critical than others and assigned minimum performance levels to all. Given these requirements, test plans were readily written and approved, and were effective in guiding test activity. A DMS Capstone TEMP was approved by DOT&E on April 3, 1995. From December 3 to 13, 1996, the Joint Interoperability Test Command (JITC), DISA's operational evaluator, conducted an Operational Assessment in compliance with the TEMP, which revealed that while many features worked, DMS did not have a stable baseline, was not interoperable with non-DMS systems, needed usability improvements, better documentation, and user training. Subsequently, a TEMP annex on the Sensitive But Unclassified Initial Operational Capability was approved by DOT&E on June 11, 1997. After considerable reworking, the Air Force Operational Test Center (AFOTEC) performed a dry run IOT&E from August 4 to 14, 1997. Also during this time, the Air Force Information Warfare Center (AFIWC) found many critical vulnerabilities in DMS as configured, but they judged these were repairable with some effort. To meet the AUTODIN closure schedule, the Joint Staff deferred these and many other requirements until later releases of DMS. AFOTEC performed IOT&E from August 15 to 29, 1997, in compliance with the DOT&E approved TEMP and prepared an interim summary report to support the fielding decision.


There has been steady and significant progress from the OA through to the IOT&E. The system components are now stable, DMS users can quickly exchange messages among themselves, and users are pleased with the man-machine interface. However, even with some deferred requirements, DMS did not meet the established thresholds for those remaining. Four out of the twelve critical capabilities failed to meet required performance levels. Three of these were to demonstrate a high success rate for completing message exchanges worldwide, with allies, and other organizational users. The fourth critical failure was the inability to effectively recover from unscheduled shutdowns. Most of these problems were due to the poor performance of the component responsible for interoperability with AUTODIN. Other serious problem areas were security related features, operational inflexibility, and the burdens on system support personnel. A majority of the deferments were security related, and security features also caused other operational problems such as a prolonged site outage, the inability of users to read their messages following a Fortezza card failure, and slow processing of personnel transfers to other locations.


An effective interoperability component would greatly improve many of the most critical problems with DMS. However, other problem areas pose difficult trade offs to users and are less likely to have straight forward technical fixes. For example, security and information warfare protections pose demanding constraints on technical capabilities, system configuration, and operational procedures. These, in turn, challenge other desired features such as graceful degradation, easy recovery, reliable processing, access through firewalls, reduced manpower for security and system administration, rapid transfer of addresses, and so forth. To assist DMS users and developers in making tradeoffs of important capabilities and rapidly maturing the system, it is important to gain field experience at Beta test sites and adopt multi-phase operational tests to implement a test-learn-fix-test again process. Due to the severe constraints posed by all of these conditions, users need to review and revise DMS requirements for AUTODIN replacement and target DMS' mission within the scope of AUTODIN replacement.

Join the GlobalSecurity.org mailing list