Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Interoperability among complex defense computer -based systems: The Navy case
(USC Thesis Other)
Interoperability among complex defense computer -based systems: The Navy case
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
INTEROPERABILITY AMONG COMPLEX DEFENSE COMPUTER-BASED SYSTEMS: THE NAVY CASE VOLUME I by Cheryl A. Walton A Dissertation Presented to the FACULTY OF THE SCHOOL OF POLICY, PLANNING, AND DEVELOPMENT UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PUBLIC ADMINISTRATION May 2003 Copyright 2003 Cheryl A. Walton Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 3103976 Copyright 2003 by Walton, Cheryl A. All rights reserved. ® UMI UMI Microform 3103976 Copyright 2003 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UNIVERSITY OF SOUTHERN CALIFORNIA SCHOOL OF POLICY, PLANNING, AND DEVELOPMENT UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90089 under the direction o f her Dissertation Committee, and approved by all its members, has been presented to and accepted by the Faculty o f the School o f Policy, Planning, and Development, in partial fulfdlment o f requirements fo r the degree o f DOCTOR OF PUBLIC ADMINISTRA TION This dissertation, written by , V I , >• Dean d is s e r t a t io n c o : Chairperson Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DEDICATION I dedicate this dissertation to my deceased parents, Mr. and Mrs. Wendell R. and Rebecca E. M. Walton, who knew and promoted the value of education. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ACKNOWLEDGEMENTS Concern about the human being and his/her destiny must always be the main interest in every technical development effort... never forget that, amongst your diagrams and equations. —Albert Einstein A very special thank-you to Dr. Robert P. Biller, chairman of my committee, who relentlessly demonstrated concern about me and the development of my dissertation. I appreciate and admire him for our lengthy discussions, his thought-provoking comments, and the effort he dedicated towards helping me complete this venture. He challenged me to succeed and encouraged, supported, and progressively guided me through this very difficult social and technological subject matter—interoperability. Out of clutter, find simplicity. From discord, find harmony. In the middle of difficulty, lies opportunity. —Albert Einstein Many times I questioned whether the complexities of interoperability and its limited sources of empirical data would allow me to answer my dissertation questions. My sisters, who were not conversant in my topic, spent many hours reading, discussing with me, and understanding my drafts. They provided invaluable information that helped to establish important evidence supporting my hypotheses. I especially had enduring iii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. conversations with Margaret and enlightening information from Bill (Willa). A very special thank-you to Mrs. Margaret E. Williams and Dr. Willa Hemmons Taylor. Special thanks to Dr. Robert M. Carter and Dr. Marvin J. Langston, who used their valuable time and effort to read, critique, and provide “ value- added” comments to my work. Support and encouragement from both of them helped me attain my completion goal. Hats off to Mrs. Treva Langston, who was relentless in convincing me that I should participate in the doctoral program. She inspired and encouraged me to take this journey. Thank-you to Dr. John McGloughlin, who helped me focus on my research topic by pointing me in the direction of Everett Rogers— an author who captured some of my perspectives on the subject of Public Administration in his Diffusion-of-lnnovation Process Model. As a full-time Department of Navy employee with demanding responsibilities, finishing my dissertation was particularly challenging. Thank you to co-workers, seniors, or friends Dr. Frank Perry, Mr. Michael O’Driscoll, Mrs. Virginia (Ginger) Poole, Mr. Michael Rice, Ms. Christi Adams, Mr. David Ruf, Mrs. Delores Dupuy, and others who contributed gseful information and contacts that I used in developing my research. In performing my research, I found material that proved to strengthen and solidify my hypotheses. Thank-you to Amy Friedlander for iv Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. recognizing the potential value of identifying patterns in the development of successful infrastructures and using them to develop and establish future infrastructures. Her studies helped my research tremendously. And, last but not least, thank-you to Everett Rogers for understanding the complexity of technology and developing a model articulating that change and progress canriot be achieved until all aspects of the technology are addressed—technical, social, political, and economic. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. TABLE OF CONTENTS DEDICATION .......................................................................................... ii ACKNOWLEDGEMENTS........................................................................... iii LIST OF TABLES........................................................................................ xiv LIST OF FIG U RES.................................................... xv ABBREVIATIONS AND ACRONYMS ..................................................... xvi ABSTRACT .......................................................................................... xix Chapter VOLUME I I. INTRODUCTION........................................................................... 1 Background............................................................................. 2 Evolution of Computers and Computer Networks .... 2 DOD and Military Services Use of Computer-Based Systems .................................................................... 4 Everett Rogers’ Diffusion-of-lnnovation M o d el 5 Hypotheses................. 8 II. COMPLEX DOD AND NAVY COMPUTER-BASED SYSTEMS ................................................................................... 10 Introduction.......................... 10 System Technology Complexity ................................. 11 Organizational Complexity................... 14 Process Complexity.................................................. 20 The Complexity of Acronyms, Terms, and Definitions .... 22 Summary................................................................................. 24 vi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. III. ARE DOD AND NAVY COMPUTER-BASED SYSTEMS SUCCESSFUL? .................................................................... 26 Introduction— Hypothesis 1 ............................. 26 Computer-Based Systems ................. 26 Standalone Systems....................................................... 27 Stovepipe Systems......................................................... 29 Dependent Systems ................................. 33 Legacy System s.............................................................. 34 The Analysis— Hypothesis 1 ................................................. 36 Summary—Hypothesis 1 . ................................................... 40 IV. ARE NAVY COMPUTER-BASED SYSTEMS THAT USE DEPARTMENT OF DEFENSE (DOD) AND DEPARTMENT OF NAVY (DON) PROCESSES ACHIEVING ACCEPTABLE LEVELS OF INTEROPERABILITY? .......................................... 42 Introduction— Hypothesis 2 . ......................................... 42 Achieving Acceptable Levels of Interoperability 44 Interoperability and “Legacy” Systems ........................ 45 Wolfowitz’s Six Action Item s...................... 46 Actions Taken on Wolfowitz’s Six Action Items ......... 48 Interoperability and Non-Legacy Systems ......... 53 Legacy and Non-Legacy Systems Summary ............. 57 DOD and DON Processes Used To Achieve57 Interoperability ................................................. 57 The Analysis— Hypothesis 2 .......................................... 59 Requirements Generation System ............................... 64 Mission Needs Statement (MNS) . ...................... 67 Capstone Requirements Document (C R D ) 68 Operational Requirements Document (ORD) .... 77 Defense Acquisition System .......................................... 86 Planning, Programming, and Budgeting System (PPB S)....................................... ................. 97 Integrating Decision Support System Processes .... 98 Evidence of Interoperability ........................................ 103 Summary—Hypothesis 2 ..................................................... 104 vii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. V. ARE “ WORK-HARDER” STRATEGIES ACHIEVING IMPROVED LEVELS OF INTEROPERABILITY? ........... 108 Introduction— Hypothesis 3 .............................................. 108 Significant Resources Invested Towards Interoperability ....... .. .. ... .. .. .. ... .. .. 109 T echnoIogy-Based Solutions ................................... 110 Technology Advancements ................................... 111 Use of “Common Products” ................................... 112 Competition-in-Contracting A c t................... 112 The “Not-lnvented-Here” NIH Syndrome .......... 113 Standards and Commercial Products .. . .. ........ 114 Post-Cold-War Impacts on Interoperability 114 Incremental Marginal Solutions ........... 116 Policy, Policy Updates, and Updates to Updates .... 118 Requirements Generation System Policy 119 Defense Acquisition System ................................... 120 Interoperability ............. .. .. .. ... .. .. . 121 Certification: CJCSI 6212.01B ........................ 121 CINCLANTFLT/CINCPACFLT: Instruction 4720.3A .................................................... 122 Deployment Minus 30 Process (D -30 Process) . . . . .. . . .. .. ... .. .. ... . 122 Planning, Programming, and Budgeting System (PPB S)............................ 123 Experimentation and Testing ............. 125 Fleet Battle Experiments (FBEs) 125 Joint Warrior Interoperability Demonstrations (JW IDs). ................. 126 Unit and Integration Testing...................... 126 Development Testing . . . . .. . .. .. ... .. .. .. .. 127 Operational Test and Evaluation (OPEVAL). . . . . 127 Interoperability Certification Testing ........... 127 Infrastructure.................................................................... 128 Architectures and Their Obstacles........................ 129 Architectures ...................................... 129 Obstacles in Populating Architectures ............. 130 Analytical Rigor in Architectures........................ 134 Overarching Central Data Base ............................. 135 Institutionalizing an Architecture Infrastructure................. 135 Interoperability Aspects of a Central Data B a s e ................................................... 137 viii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Example of Architecture Assessment ........ 138 Engineering Analysis for Architecture Data Base Verification and Validity........................ 139 Developing a Central Data Base........................ 140 Assessments ........................................................... 141 Systems Engineering Analysis............................... 142 Infrastructure Summary .......................................... 144 Family of Interoperable Operational Pictures (F IO P )......................................................................... 145 Naval Capabilities Program (NCP) . . . . . . . . . . . . . . . 148 Integrated Product Teams and Virtual Organizations............................................................ 151 Transformation.............................................. 152 Network Centric Warfare ...................... 153 FORCEnet ........... 156 Transformation Roadmap........................................ 158 Congress........................................................................... 160 Congressional Mandates ........................................ 160 Appropriation and Authorization 161 Congressional P o w e r.............................................. 161 Power of the P urse.............................................. 161 Power of the Goldwater Nichols Act and Title 10 of the U.S.C.......................................... 162 The Analysis— Hypothesis 3 ............................ 163 Summary— Hypothesis 3 ....................................................... 166 VI. ARE DOD AND DON USING THE EVERETT ROGERS DIFFUSION-OF-INNOVATION PROCESS MODEL TO ACHIEVE IMPROVED INTEROPERABILITY?................... 168 Introduction— Hypothesis 4 ............................................ 168 The Model and its Elements 168 Innovations .............................................. 173 Information and Uncertainty ............................. 174 Diffusion of Undesirable Innovations................ 178 Technology Clusters ........... 178 Characteristics of Innovations 179 Reinvention ...................................... 180 The Innovation Development Process 180 The Innovation of this Research...................... 183 Identifying the Problem . . . . . . . . . . . . . . . 183 Identifying the Innovation ........... 186 Characterizing the Innovation .................... 187 ix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Communication and Communication Channels .. 189 Communication . , . ................................. 189 Communication Channels................................. 189 The Messengers................. 190 Time .............................................. 190 I nnovation-Decision Process............................ 191 Timeliness of Adoption ..................................... 192 Rate of Adoption................................................ 193 Social System ............................................ 195 Social Structure and System N orm s............... 195 Diffusion and Members of the Social System .................................................... 196 Opinion Leaders and Change Agents .... 196 Types of Innovation Decisions.................... 197 Consequences.............................................. 198 Impact of Use of Rogers’ M o d el............................ 198 The Analysis— Hypothesis 4 ..................... 200 Achieving Interoperability with Diffusion...................... 205 Applicability of Rogers’ Model to DOD and Navy Processes.................................................................. 207 Innovation Applicability................................. 208 Communication and Communication Channel Applicability......................................................... 212 Time Applicability ..................................................... 215 Social System Applicability........................ 219 Summary— Hypothesis 4 ............. 220 VII. EVERETT ROGERS’ DIFFUSION-OF-INNOVATION PROCESS MODEL: AN IMPROVED PATH TO ACHIEVING INTEROPERABILITY? ........................ 225 Introduction— Hypothesis 5 . .............................................. 225 Information Sources for Historical Infrastructures .... 226 Interoperability Successes ................................. 227 Telephones....................................... 229 Electricity ......................................................................... 229 Airlines ........................................................... 230 Railroads .......................................... 231 Banking ......................................................... 231 Internet ............. 232 x Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Analysis— Hypothesis 5 ................................................. 235 Use of the Rogers Diffusion-of Innovation Process Model in Infrastructure Successes 235 Historical Infrastructure Them es............................. 236 National Order ................................ 236 Standardizing Across the Infrastructure............... 239 Achieving Interoperability in Historical Infrastructures ........................ 240 Historical Infrastructures and the Rogers Diffusion-of- Innovation Process Model ...................................... 241 Rogers’ Diffusion-of-lnnovation Process Model and National Order .......................... 241 Rogers’ Diffusion-of-lnnovation Process Model and Standardization .......................................... 242 Relationships Between Rogers’ Diffusion-of- lnnovation Process Model and Historical Infrastructure Implementations . .................... 243 Implication of Infrastructure Successes for DOD and Navy Achievement of Acceptable Levels of Interoperability ......................................................... 248 Process Strategy ..................................................... 249 Internet Strategy .................... 250 New Infrastructure Strategy ................................... 251 Strategy Summary ................................................... 252 Summary—Hypothesis 5 ....................................................... 253 VIII. CONCLUSIONS AND FURTHER RESEARCH........................ 256 Summary of Findings ............................................ 256 Findings— Hypothesis 1 ................................................. 261 Findings— Hypothesis 2 ........................ 262 Findings— Hypothesis 3 ................................................. 265 Findings— Hypothesis 4 ................................................. 267 Findings— Hypothesis 5 ................................... 271 Importance and Relevance of Findings ...................... 273 Action Implications ......................................... 274 Further Research .................................................................. 276 Future Research Questions .......................................... 276 Importance to Public Administration ............. 277 xi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. GLOSSARY/DICTIONARY OF T E R M S .................................................. 281 Introduction ......................................................................... 281 Terminology and Definitions................................................ 281 SELECTED BIBLIOGRAPHY.................................................................... 299 VOLUME II APPENDICES A. Lessons-Learned—Afghanistan ........................................ 309 B. Lessons-Learned— Bosnia ................................................. 310 C. Lessons-Learned— Kosovo................................................. 313 D. Lessons-Learned— Desert Storm ...................................... 314 E. Lessons-Learned— Defense Leaders . . . . . . . . . . . . . . . . 316 F. Navy Organizational Structure............................................. 318 G. Memorandum on Legacy System and Interoperability . . . 329 H. DOb Interoperability Directive 4630.5, November 12, 1992 ....................................................... 332 I. DOD Interoperability Directive 4630.t, January 2002 .................................................................. 336 J. DEPSECDEF Acquisition Policy Document Cancellation Memorandum ........... 349 K. CJCS (Requirements Policy Documents Cancellation Memorandum .................................................................. 351 L. Population of Navy Mission Needs Statement (MNS) .... 354 M. Population of Unclassified Navy Mission Needs Statem ent......................................................................... 360 N. Population of Navy Acquisition Category (ACAt) Systems ......................................................................... 363 O. Population of Operational Requirement Documents (ORDs) .................................................... 391 P. Population of Unclassified Operational Requirement Documents (O RDs)......................................................... 405 Q. Table Relating MNS’s to O R D s........................................... 410 R. Table Relating Unclassified MNS’s to Unclassified ORDs ......................................................................... 433 S. Population of Navy Unclassified Time Critical Targeting Systems .................................................... 438 T. Direction Memorandum for the Family of Interoperable Pictures (F IO P ).......................................... 466 U. Telephone Infrastructure..................................................... \ 469 V. Electricity Infrastructure........................................................... 471 xii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. W. Railroad Infrastructure........................................................... 475 X. Banking Infrastructure................................ 477 Y. Internet Infrastructure ........................................................... 481 Z. Cooperating Through Memorandum of Agreement (MOA) ......................................................................... 496 xiii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. LIST OF TABLES 1. Lessons-Learned Excerpts .. .. ......................... 39 2. Senior Defense Official Comments/Direction on Interoperability ........... 55 3. Programs Presented to the Defense Acquisition Board (DAB) for Milestone Decisions between April 2001 and November 2002 62 4. Interoperability, KPPs, and lERs in the Population of Navy Unclassified Capstone Requirements Documents (CRDs) .. 76 5. Dates that the population of Navy Unclassified ORDs was Developed and the Quantities Developed ................... 81 6. CRD Relationships to O R D s ........................................................... 82 7. Navy Mission Capabilities for POM 04 ............... 100 8. “ Work-Harder” Strategy Scorecard ..................... 165 9. Relationship Between the Everett Rogers Diffusion-of- lnnovation Process Model and Historical Infrastructures with a Focus on the Innovations................................................. 244 10. Relationship Between the Rogers Diffusion-of-lnnovation Process Model Elements and Historical Infrastructure with a Focus on Change Agent Influence on the Social System ............................................................................. 246 xiv Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. LIST OF FIGURES 1. Risk Among Dependent Systems . . . . .. . . .. .. ... .. .. ... .. 13 2. Requirements Documentation Evolution....................................... 66 3. Requirements Document Evolution Implied by Requirements Generation System ........................ 71 4. Products Delivered and their Approval Authority for Implementing the Requirements Generation System ....... 85 5. Defense Acquisition System from 1996-1999 .............................. 88 6. Requirements Generation and Acquisition Systems Interfaces in 1999 .......... 90 7. Defense Acquisition System Interfaces in 2001 .......................... 93 8. Requirements Generation and Defense Acquisition System Interfaces in 2001 .......................... 95 9. Summary of Rogers’ Diffusion-of-lnnovation Process Model . . . 170 10. Aligning Rogers’ Innovation Development Process with DOD and Navy Requirements and Acquisition Systems.................. 182 11. Summary Relationship between Rogers’ Diffusion-of-lnnovation Process Model and DOD and DON Processes ...................... 203 xv Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ABBREVIATIONS AND ACRONYMS ACAT Acquisition Category ACW Advanced Color Workstation AEHF Advanced Extremely High Frequency ASD (C3I) Assistant Secretary of Defense for Command, Control, Communications, and Intelligence ASN (RDA) Assistant Secretary of Navy for Research Development and Acquisition ASN (RDA) Assistant Secretary of Navy for Research Development CHENG and Acquisition Chief Engineer ATW Advanced Tactical Workstation BCAPP Battleforce Capabilities Assessment Programming Process BRAC Base Realignment and Closure C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance CEB CNO Executive Board CFFC Combined Fleet Forces Command CIO Chief Information Officer CJCSI Commander, Joint Chiefs of Staff Instruction COA Course of Action CNO Chief of Naval Operations CRD Capstone Requirements Document CSCS/R Cost Schedule Control System CWS Color Work Station D-30 30 Month Deployment Process, also known as the Deployment Minus 30 or D Minus 30 Process DASN (C4I, Deputy Assistant Secretary of Navy for Command, EW, and Control and Communications, Computers, and Space) Intelligence, Electronic Warfare, and Space DASN (TSC) Deputy Assistant Secretary of Navy for Tactical Surface Combatants DAU Defense Acquisition University DOD Department of Defense DOD CIO Department of Defense Chief Information Officer DODD Department of Defense Directive xvi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DODI Department of Defense Instruction DON Department of Navy DON CIO Department of Navy Chief Information Officer DRPM Direct Reporting Program Manager FBE Fleet Battle Experiment FfOP Family of Interoperable Operational Pictures FoS/FOS Family of Systems FY Fiscal Year INTA Integrated Naval Targeting Architecture ITMIRA Information Technology Management Information Reform Act, also known as the Clinger-Cohen Act IWAR Integrated Warfare Architecture J2 Joint Staff Intelligence Office J6 Joint Staff Command, Control, and Communications Office J8 Joint Staff JBC Joint Battle Center (Lab) JCS Joint Chiefs of Staff JS Joint Staff JTIC Joint Test Interoperability Command JWID Joint Warfare Integration Demonstration MAIS Major Acquisition Information System MBC Maritime Battle Center (MBC) MCEB Military Communications and Electronics Board MCP Mission Capability Package MDA Milestone Decision Authority MDAP Milestone Decision Authority Program MNS Mission Needs Statement MOA Memorandum of Agreement N2 Operations Navy (OPNAV) Intelligence Resource Sponsor N61 Operations Navy (OPNAV) Command and Control N7 Operations Navy (OPNAV) Navy Architect N70 Operations Navy (OPNAV) Warfare Integration N74 Operations Navy (OPNAV) Anti-Submarine Warfare (ASW) N76 Operations Navy (OPNAV) Surface Warfare N77 Operations Navy (OPNAV) Under Sea Warfare (USW) N78 Operations Navy (OPNAV) Air Warfare N81 Operations Navy (OPNAV) Assessments N096 Operations Navy (OPNAV) Navigation NAT IPT Naval Afloat Targeting Integrated Product Team NAVAIR Naval Air Systems Command xvii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. NAVSEA Naval Sea Systems Command NCTSI Naval Command for Testing and Systems Integration Nil National Information Infrastructure NMCI Navy Marine-Core Internet NRAD Navy Research and Development Laboratory NRL Naval Research Lab NROC Naval Resources Oversight Committee NTOA Naval Targeting Operational Architecture NWDC Naval Warfare Development Center Command OASD (C3) Office of the Assistant Secretary of Defense for Command, Control, and Communications ONR Office of Naval Research OPNAV Operations Navy OPTEVFOR Operational Test and Evaluation Force ORD Operational Requirements Document OSD Office of the Secretary of Defense OUSD Office of the Under Secretary of Defense for Acquisition, (AT&L) Technology, and Logistics PEO Program Executive Office PEO (A) Program Executive Office for Aircraft PEO (T) Program Executive Office for Tactical Weapons PEO (TSC) Program Executive Office for Tactical Surface Combatants PEO(W) Program Executive Office for Weapon and Unmanned Air Systems PM Program Manager POA&M Plan of Actions and Milestones RDA Assistant Secretary of Navy for Research Development CHENG and Acquisition Chief Engineer SEA 53 Naval Sea System Command Code 53— Navy’s Battle Force Systems Engineer SME Subject Matter Expert SoS/SOS System of Systems SPAWAR Space and Naval Warfare Systems Command SYSCOM Systems Command TCS Time Critical Strike T C I Time Critical Targeting use University of Southern California u.s.c. United States Code xviii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ABSTRACT Interoperability among computer-based systems imposes serious and difficult problems in government. The Department of Defense (DOD) defines interoperability, relative to computer-based systems, as the ability of systems to exchange information and use the exchanged information to operate effectively together. This dissertation explores: • The success of DOD and Navy computer-based systems; • The achievement of acceptable levels of interoperability among Navy computer-based systems that use DOD and Department of Navy (DON) processes; • The success of “ work-harder” strategies in improving interoperability; • Whether there is evidence that DOD and DON processes employ the Everett Rogers Diffusion-of-lnnovation Process Model; and • Use of the Everett Rogers Diffusion-of-lnnovation Process Model to potentially improve the achievement of interoperability. This research uses complexity theory, lessons-learned reports and observations, diffusion theory, and historical infrastructure studies to xix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. explore interoperability among DOD and Navy computer-based systems. DOD and Navy computer-based systems not only embody system technology complexity but also impact complexity across organizations, processes, and acronyms, terminology, and definitions. The findings of this research are: • Lessons-learned reports and senior leaders disclose that interoperability problems degrade the success of DOD and Navy computer-based systems. Cancellation of policy documents to implement DOD and DON processes and inadequate documents resulting from these processes indicate that use of them is not achieving acceptable levels of interoperability. • “ Work-harder” strategies have thus far failed to make Navy computer-based systems interoperable at acceptable levels. Surprisingly, Congress has not weighed in from an overall interoperability resolution perspective. Everett Rogers uses diffusion theory research in a Diffusion-of- lnnovation Process Model. Diffusion theory and, particularly, the Rogers model are potentially useful in DOD and DON policy processes to achieve interoperability at acceptable levels. These processes inherently use the research and model but not deliberately or in any substantial way. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Historical infrastructures successfully achieved interoperability by establishing social technology infrastructures. The Everett Rogers Diffusion-of-lnnovation Process Model potentially offers a means of establishing a social technology infrastructure conducive to achieving acceptable levels of interoperability among DOD and Navy systems. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER I INTRODUCTION Interoperability among computer-based systems imposes serious and difficult problems in government. The Department of Defense (DOD) defines interoperability as the ability of systems, units, or forces to provide data, information, material, and services to and accept the same from other systems, units, or forces, and to use the data, information, material, and services so exchanged to enable them to operate effectively together (DOD Directive 5000.1, 2000; Joint Publication 1-02, 2002). Specific to computer- based systems, interoperability is the ability of these systems to exchange information and use the exchanged information to operate effectively together. This research explores: • The success of DOD and Navy computer-based systems; • The achievement of acceptable levels of interoperability among Navy computer-based systems that use DOD and Department of Navy (DON) processes; • The success of “ work-harder” strategies in improving interoperability; 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Potential evidence that DOD and DON processes employ the Everett Rogers Diffusion-of-lnnovation Process Model; and • Use of the Everett Rogers Diffusion-of-lnnovation Process Model to potentially improve the achievement of interoperability. DOD and the military Service Departments of Navy (DON), Air Force, and Army, as well as defense agencies use computer-based systems in military operations. DON includes Navy and Marine Corps forces. The analysis of this research focuses on interoperability among Navy computer- based systems used in military operations. Background Evolution of Computers and Computer Networks The evolution of the computer and the introduction of computer networks enabled computers to connect so they could exchange information. Adoption of these technology advancements was a double-edged sword that changed and enhanced the way of life, as well as introduced unintended consequences. Not since the invention of telegraphs and the post office has information been so easily accessible and exchangeable, and the speed of information access and quantity far surpasses that available using the older technologies. Nonetheless, incessant and persistent interoperability problems were almost an immediate consequence of computer and network technology advancements arising from connectivity and information 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. exchange issues. These problems appear to have grown larger as system complexity increased. Connectivity, information exchange, and the effective use of exchanged information among computer-based equipment have been technically feasible, but difficult to implement. Connectivity of computers, networks, and other devices requires compatibility and standardization among this equipment. Equipment vendors do not build electronic computer-based devices the same way or with the same standards. Unless they all agree to use the same or compatible equipment, standards, and/or methods, connectivity among them does not occur. If electronic devices are able to successfully connect with each other, their information-enabling tools, such as computer firmware, software, and data bases, enable the receipt, acceptance, and effective use of information. Information exchange occurs when one electronic device receives and accepts information as formatted from another electronic device. Interoperability occurs at different levels (DOD Framework document, 1999). The optimal level of achieving interoperability is when the receiving device effectively uses the exchanged information. The electronic devices and their information-enabling tools are subject to compatibility, standards, and methodology agreements among vendors/other developers before interoperability is possible. 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DOD and Military Services Use of Computer-Based Systems DOD and the military Services have been working for more than twenty years to resolve interoperability problems. Much progress has been made. During that period, offices have become increasingly dependent on desktop computers, email, and the Internet. Without them, offices will literally shut down. Today, military operations are becoming increasingly dependent on the use of computers and networks in combat, command and control, weapon, and other systems. With increasing quantities of systems and their complexities due to technology advancements, use of these systems is growing equally complex. Many of the systems are not integrated and do not exchange information. They require a greater number of resources to use and maintain than are available. Integration and interoperability are becoming necessities to alleviate complexities and ease of use. Many systems have achieved interoperability, but the increasing complexities associated with technology advancements are outpacing the ability to maintain, sustain, and even attain interoperability as new systems are added or older ones are upgraded. Achieving interoperability has not proven to be an easy problem to solve. Consistently, interoperability problems have been in the “lessons- learned” reports of American military operations, such as the Gulf War, Kosovo, Bosnia, and Afghanistan. Appendices A, B, C, D, and E include examples from news articles, quotations from senior leaders, and “lessons- 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. learned” reports that demonstrate some of the interoperability problems faced during the operations. Those examples make clear the persistence of DOD interoperability problems during the past 20 years. Everett Rogers’ Diffusion-of-Snnovation Model To solve interoperability problems, DOD and Navy began incorporating interoperability into policy processes. Decision-makers need policies that produce intended results. A way to assure that this occurs is to develop policy that uses process or methods that are established or have been proven. Determining whether proven methods are incorporated into policy is not always evident. Given an understanding of the intent of the policy, though, is a good starting point to search for process or methodology models that may be applicable. Aware that DOD and Navy were using requirements and acquisition policy to achieve interoperability at acceptable levels, the author searched for theories and models that were potentially applicable to the policy processes. Complexity theory and diffusion theories were the best fits for DOD and Navy processes. Interoperability is a complex issue that has many moving parts, all in need of order. Complexity provided an opportunity to discuss the many parts and explore whether a natural order would emerge. Chapter 2 addresses the many complex areas that interoperability impacts. 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Diffusion theory began in 1903 with the work of Frenchman Gabriel Tarde (Rogers, 1995, pp. 38-95). Multiple disciplinary theories are embedded in diffusion theory. Many appeared to be applicable to this research; but, alone, they were lacking. The theories that best fit include scientific management, organizational behavior, organizational culture, communications, and leadership. Scientific management theory addressed the technology aspects of computer-based systems and their use as tools to improve efficiency. Organizational behavior and culture addressed the social system problems that appeared to accompany interoperability problems. Communications theory was applicable to both the interoperability of computer-based systems, as well as information exchanges of the many people potentially impacted to achieve interoperability. Leadership theory applies to organizations that need to be adjusted to better achieve interoperability, senior advocates of interoperability to persuade organizations and other stakeholders of changes needed to achieve interoperability, and technology developers to adopt standards that lead to the achievement of interoperability. Everett Rogers developed a Diffusion-of-lnnovation Process Model based on diffusion theory. He used the four elements of diffusion theory to articulate their definitions, dependencies, and attributes, as used in his model. The model fit well in this research, because it addressed most of the 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. disciplines that were applicable. It also fit with DOD and Navy processes in that, as will be discussed in Chapter 6, these organizations inherently and probably unknowingly use parts of the Rogers’ diffusion model to diffuse computer-based systems. The problem is that, though the systems are diffused, they are not always interoperable. In addition to the Rogers process model, scientific and social science models were reviewed at a high level. DOD and Navy used systems engineering models based on scientific theory as the primary source of their processes. Scientific theory alone was insufficient to solve interoperability problems; because, while a solution may be technically feasible, it may be socially, economically, and politically infeasible. Social and organizational ergonomic models were equally insufficient, because DOD and Navy pursued social aspects at a micro level but were reluctant to address macro ergonomics. The Rogers process model includes a macro ergonomics perspective, as applicable to technology innovations. Micro ergonomics models incorporate users into the perspective of technology. Macro ergonomics embraces the external technical, economic, and political context of technologies that may lead to social and organizational change. Organizational restructure requires the changing of law that is potentially costly, and the outcome of the change is speculative. Social technology concepts offer potential, but they combine both social and scientific aspects in the design of social technologies. These are discussed 7 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in Chapter 7. Also in Chapter 7 are discussions of infrastructures that demonstrate interoperability success using macro ergonomics combined with technology innovations. Hypotheses This dissertation explores five hypotheses. 1. Department of Defense (DOD) computer-based systems are successful. 2. Navy computer-based systems that use Department of Defense (DOD) and Department of Navy (DON) processes are achieving acceptable levels of interoperability. 3. “ Work-harder” strategies are achieving improved levels of interoperability among Navy complex computer-based systems. 4. Department of Defense (DOD) and Department of Navy (DON) processes are using the Everett Rogers Diffusion-of-lnnovation Process Model to achieve interoperability. 5. The Everett Rogers Diffusion-of-lnnovations Process Model: an improved path to achieving interoperability among complex Department of Defense (DOD) and Navy computer-based systems. The analysis of this research provides evidence to reject hypotheses one through three. This research compares DOD and DON processes to the 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. analysis of this research suggests that hypothesis five appears to offer promise in achieving higher levels of interoperability among complex Departments of Defense and Navy computer-based systems. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER II COMPLEX DOD AND NAVY COMPUTER-BASED SYSTEMS Introduction What is the complexity of computer-based systems in Navy all about? What is the structure in DOD and Navy? M. Mitchell Waldrop (1993), author of Complexity: The Emerging Science at the Edge of Order and Chaos, defines complexity: “[A] system is complex in the sense that a great many independent agents are interacting with each other in a great many ways . . . the richness of the interactions allows the system as a whole to undergo spontaneous self-organization” (p. 11). Waldrop uses the term “ system” generically. He cites examples of biological, ecological, nuclear, human, as well as computer systems. His usage applies to interoperable DOD and Navy computer-based systems in that they are independent agents and require a great deal of interaction. The complexity of Navy computer-based systems is not limited to the independent physical technologies of these systems. Other independent agents include the organizations, processes, and activities involved in defining the need for Navy systems, acquiring, budgeting for, distributing, and using them. 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In past years, the need for computer-based systems was based on countering enemy threats and responding to emergent needs of individual and, often, isolated users. Little thought went into designing a system that would both satisfy the emergent need of a single or few users and at the same time fit within the complex context of flexible overarching designs of interoperable systems that would serve in accomplishing broad military missions or purposes. Even today, this concept is not widely practiced. The development of such an overarching mission design is complex, time- consuming, and expensive. Though an objective of both DOD and Navy, this use of an overarching design is still just a concept. Pilot projects to achieve interoperability have been created, but the other independent agents (organizations, processes, and budgets) and their interactions have major impacts on implementing overarching designs and development of interoperable computer-based systems within them. System Technology Complexity Interoperability adds complexity to computer-based systems. The complexity begins when the technology of one system needs to interact with the technology of another system. Technologies may or may not be compatible. The technologies need to have physical, remote, functional, and data compatibility to effectively interact. This interaction constitutes interoperability, because it includes the effective exchange of information. 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Interoperable computer-based systems depend on sharing information with another or other systems. If needed information is not provided, the dependent systems risk the vulnerability of malfunctioning. Dependent systems include systems that either directly or indirectly link with another system. A single system can destroy the order and interoperability among dependent systems if it Mils to provide information needed by the other systems. In Figure 1, the first View shows the dependency among systems A, B, C, D, and E. The systems are interoperable. The second View shows that, when system B fails or inadequately exchanges information, all of the systems directly or indirectly connected to system B are at the risk of failure or malfunction, because they may not receive needed information. The result of the non-occurrence of information exchange when needed is an interoperability problem among dependent systems. Complexity increases when multiple systems need to interact. The greater the quantity of systems that must exchange information, the greater the complexity and the error that can accompany it, i.e., the greater the number of interoperability problems. Large multi-purpose organizations that are supported by many computer-based systems experience the most complexity. Navy is one such organization. 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. SYSTEM SYSTEM SYSTEM\ ^ e m f e T O TSYSTEM\ d e Pendencj \ SYSTEM s y s te m \ d e Pe n d e n c e f sY S JB m d e Pe n d e n c ¥ 3 y s te m \ RISK RJSK SYSTEM SYSTEM View 2: Risk Introduced to All Dependent Systems When System B has Interoperability Problems View 1: Dependent Interoperable Systems Figure 1. Risk among dependent systems. A single system with interoperability problems can impact a network of systems that are using the shared information. w ........ .......... Organizational Complexity Who is in charge? Unlike other federal organizations, the military Services include both uniformed and civilian personnel. Both groups have their own structures that interact and routinely combine for purposes within the structure of the military Service. The Secretary of the Navy (SECNAV) is a civilian. He is in charge, but the Navy organizational structure, though hierarchical, is not that simple. It is complex. Appendix F provides a high- level organizational structure relative to Navy civilian and uniformed operations. Even within these high-level organization depictions, the complexity becomes evident. Computer-based systems are the norm in Navy organization working environments. Diagram 1 in Appendix F shows a relatively simple naval organizational structure with the Chief of Naval Operations (CNO) and the Commandant of the Marine Corps reporting to SECNAV. The Shore Establishment and Navy Operating Forces report to CNO, while Marine Corps Operating Forces report to the Commandant of the Marine Corps. What is not shown on Diagram 1 are the nested organizational structures within the boxes labeled SECNAV, CNO, Commandant of the Marine Corps, Shore Establishment, and Operating Forces. Diagrams 2 through 9 provide a sample of the vastness and diversity of those nested organizations. As an example of the complexity, Diagram 2 shows the three major Systems Commands (SPAWAR, NAVAIR, and 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. NAVSEA) reporting to the Assistant Secretary of Navy for Research Development and Acquisition. Diagram 8 shows the same three systems commands reporting to CNO. NAVSEA alone is comprised of almost 3,000 people (Young, 2002). If you were to walk through the office spaces of any Navy office, you would likely find a computer-based system on the desk of each person in the office. If you were to visit a Navy ship, submarine, or aircraft, you would find multiple computer-based systems in most of the offices and working spaces. When you hear of United States forces in action, Navy computer-based systems contribute to these actions. Computer-based systems are the norm in Navy organization working environments. The complexity of the Navy organizational structure is but one source of the complexity relative to its supporting computer-based systems. The thrust behind interoperability is the need to share information. Technology exists today to track aircraft and exchange information via local, regional, national, and global networks. Federal agencies shared a vision of a National Information Infrastructure (Nil) more than ten years ago. Nil is an Internet-like infrastructure predicated on sharing networks, common software, data bases, and information exchange. An objective of the Nil is to connect Federal agencies so they can be prepared and ward off potential threats, such as the one imposed on September 11, 2001. 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. If the National Information Infrastructure (Nil) had been in place on September 11, 2001, officials may have been able to evacuate the Pentagon, especially since the nation was already on alert. The news media reported that an aircraft slammed into the Pentagon one hour after two other aircraft slammed into the World Trade Center Twin Towers in New York City on September 11, 2001. The Federal Aviation Administration (FAA) was aware that two other aircraft were off-course, with one on a course towards the Pentagon. Information of impending danger did not reach Pentagon officials in time to evacuate employees. Lives were lost. Of all of the arguments for improving interoperability among computer-based systems, 9/11, as we have come to know that dreadful day, is a most poignant and compelling one; but interoperability among systems begins with interoperability among organizations. If government agencies had been able to share information via Nil, the potential may have existed for the evacuation. Interoperability among organizations is the sharing of information and effective use of shared information among the organizations. Computer- based systems provide organizations with more efficient means of information exchange. Large organizations, such as DOD and FAA that provide most employees with computers, present a challenge to achieving interoperability. Who and what people need to exchange information and why? What computer-based systems are needed to exchange information in 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. support of these people? The answers to these questions must address the complexity of the organizations, their computer-based systems, the interactions among them, and the processes and budgeting of the organizations. Many DOD and military Service organizations have interoperability responsibilities. Some of them are as follows: • Defense and military Service Program Managers in the acquisition community are responsible for including interoperability in computer-based systems that they acquire, develop, and produce for warfighters. • The Assistant Secretary of Navy for Research, Development, and Acquisition (ASN [RDA]) is responsible for the Navy acquisition community. In 1999 ASN (RDA) established a Chief Engineer Office (ASN [RDA] CHENG) as the senior technical authority in the acquisition community for overall integration, interoperability, and architectures of combat; command, control, communications, and computers (C4); and weapon systems (Buchanan, 1999). • The Chief of Naval Operations (CNO), responsible for the naval operational community, established the Naval Sea Systems Command (NAVSEA) as the Chief Engineer for the Battle Force. NAVSEA, in this role, is responsible for assuring, among other things, that systems are integrated and interoperable after the 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. acquisition community delivers them, but before they deployed for operational use (CNO, 1998). • Test organizations are responsible for certifying that systems acquired by Program Managers are interoperable (URL 1). • Senior Defense and military Service decision-makers are responsible for approving these systems for operational use by warfighters based on, among other things, interoperability criteria (DOD Instruction 5000.2, 2001). • Fleet users and their commanding officers (warfighters) are responsible for identifying their capability needs and requirements and reporting, among other things, interoperability problems. A single interoperability authority for these organizations and others within Navy, other military Services, and Defense agencies is lacking. These organizations are independently defining processes and methods to resolve interoperability problems. They exchange information but selectively accept or reject ideas, depending on how these ideas fit their own approaches. Unless the organizational structure accommodates the coordination, cooperation, and communication among organizations responsible for achieving interoperability, processes to solve interoperability problems will not work. They, too, will not be interoperable. A situation similar to the following hypothetical example actually happened: ASN (RDA) CHENG, as technical authority agent for ASN (RDA), makes a process recommendation. ASN 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. (RDA) CHENG requests that the Systems Commands, who report to ASN (RDA), implement the process. The CNO directs the Systems Commands, who rely on CNO for sponsorship and funding, to implement a process that conflicts with the ASN (RDA) process. The Systems Commands complain, but respond to both CNO and ASN (RDA) with different answers. The outcome is that senior decision-makers do not receive sufficient information to make sound investment decisions due to conflicting recommendations from CNO and ASN (RDA) reports. Dependency is the key factor in complexity, but it means giving up some degree of control. An organization can control its own population with rewards, punishment, or fulfilling individual and organizational needs. This control does not extend to other organizations. DOD and the military Services have strong bureaucratic organizational structures. Control is at the top of the hierarchy. Dependence on other organizations lessens the control and requires external intervention when conflict cannot be resolved between the two organizations. Because of the strength of hierarchies, organizational members clearly understand and adhere to reporting authorities in hierarchies. The clarity of authority blurs in network or disparate organizations. Members of these organizations need to proactively seek out horizontal interactions, both within the organization and external to it, to enable interoperability. Complex networks, dependencies, and cooperation needed in DOD and the military Services to achieve interoperability call for organizational change to accommodate the complexities. The strength of the hierarchies is 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. a potential obstacle, if these structures do not strongly advocate and support interoperability with its network, dependencies, and needed cooperation. Only when the organizations become interoperable will the systems follow that path. Process Complexity The analysis of this research focuses on interoperability among complex Department of Defense (DOD) and Navy computer-based systems and their directive, regulatory, and implementation processes. Due to the rigors of environments in which many computer-based systems must operate, technological aspects of computer-based systems used for military operations are subject to special rules. Process complexity is an outgrowth of organizational complexity. Each organization acts as an independent agent with its own rules, norms, charters, agendas, and processes. In addition to these, each organization must use the policies and processes of higher authority that cross multiple organizations. In the event of conflict and where it exists, higher authority prevails. Organizational independence, though, allows great leeway in interpreting policy and process to the extent that, at times, conflict remains unresolved or resolved only superficially. As an example, as part of the preparation for fixing potential Year 2000 problems, organizations were required by higher authority to identify 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. system interfaces and sign a Memorandum of Agreement (MOA) with other organizations for each system interface. The MOA was a guarantee that the two programs in the organizations would assure interoperability across the interface. One program identified an interface with a piece of communications equipment that had originally been procured and maintained by another program. They drew up a MOA and requested that the other program sign it. The other program had upgraded its equipment and no longer needed nor maintained the communications equipment. They refused to sign the MOA. The initiating organization had not budgeted for the procurement or maintenance of the communications equipment, but they needed the interface. Higher authority was also pressuring them for the MOA. Failing to get the other program to accept responsibility for the system, the initiating program drew up an MOA with itself. The initiating organization and its implementing contractor signed. The above experience represented a superficial resolution. On the surface, policy and process were followed. The MOA had requisite signatures. The details, though, disclosed flaws in the implementation of the process. Since both programs failed to take ownership of the communications equipment, no MOA was written for the other side of the interface— between the communications equipment and its interface with the radio that connected to other systems. The initiating program and its 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. organization expended much energy with this issue to the extent that the radio was an afterthought long after the Year 2000 crisis was over. The program with the radio was also remiss, because they did not identify the communications equipment as one of their interfaces. The three systems in these programs were a small representation of thousands that required MOAs among their organizations. A seemingly simple process on the surface can hide complexities that are only realized with investigation and validation of system and organizational populations that execute the process. Programs had great reluctance in signing the MOAs. The MOAs represented a commitment to depend on other programs for success with their technology. The realization that implementing a process involves organizations, technology, and ground truth understandings is a step in the right direction to find order in the complexities of these things. Process complexities are major contributors to making the achievement of interoperability among DOD and Navy systems a substantial challenge. The Complexity off Acronyms, Terms, and Definitions The natural language used in DOD and DON is robust with complex and unfamiliar acronyms, terminology, and definitions. Though an in-depth knowledge of the language is not needed, understanding the terms used in this analysis is important in order to increase its transparency. This 22 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. understanding helps to keep track of the information that explains the processes, their implementation, and the analysis. Two sections are provided in this document as reference guides to keep track of the analysis and support the understanding. The Abbreviations and Acronyms section provided before Chapter 1 is a quick reference to the many acronyms used. The Glossary that follows Chapter 8 provides a broader view of the terms used and their definitions. Definitions used to refer to terms in the Department of Defense (DOD) and Navy have proven to be particularly challenging. A term may be used for the first time to describe a concept, idea, or thing. It may be a spin-off of a word or words used in a dictionary, or the user may create the word to describe an innovation. The terms are a user’s attempt to express his or her, sometimes, complex visions in simple language. If others begin using these terms, they become norms, even though they do not have formal definitions. Some of them eventually get formal definitions. Before the formal definition occurs, though, use of the term may differ from person to person. Additionally, recognizing the need, multiple people develop definitions for the terms. DOD developed a Dictionary of Military Terms (Joint Publication 1-02, 2002) to provide a reference source for the many often- used military terms. Even within this document, multiple definitions exist. The definitions already occurred in other military documents. The Dictionary 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of Military Terms consolidated the definitions in a single source. Though this document helps, it has not captured all of the military terms that are often used. Multiple definitions of single terms cause confusion and misunderstanding. Definitions may vary slightly, but this variation could have a domino effect on accomplishing missions, tasks, and developing products. It is further exacerbated when users add their own interpretations to the definitions. The confusion over the definition of terms is reflected in the development of systems. Developers either formulate their own definitions or reach for and use the closest document that defines a term. If the definition of a term in one system differs from the definition of the same term in another system, the two systems cannot share that information, because it is not acknowledged as being the same term. So, the complexity of acronyms, terminology, and lexicons also contributes to the difficulty of achieving interoperability. Summary DOD and Navy computer-based systems are complex. The organizations that use them are complex. Technology, organizations, organizational processes, budgeting, today’s environment, and the systems are all agents contributing to the complexity. The objective of dealing with complexity is to find and adapt to a natural organized order. Interoperability 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. is the catalyst that should connect the agents, thereby enabling them to interact and adapt. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER ill ARE DOD AND NAVY COMPUTER-BASED SYSTEMS SUCCESSFUL? Introduction—Hypothesis 1 Hypothesis: DOD and Navy computer-based systems are successful. Department of Defense (DOD) and the military Services continually procure computer-based systems to equip the men and women of the armed forces (Navy, Marine Corps, Army, and Air Force) with tools to perform missions in defense of the nation. Thousands of these systems are used for the missions within military operations today. The majority of them are “standalone,” “stovepipe,” and “legacy” systems. The others are dependent systems. Are these computer-based systems successful? This chapter examines this question. Computer-Based Systems Who knew in the late 1940s and early 1950s, when a few commercial corporations began using the UNIVAC computer, that computer technology would revolutionize the world? Who knew that the DOD network efforts 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. would initiate a chain reaction that forever changed society by making information technology available and accessible as a household commodity—the information revolution? With every step, DOD and the military Services have been in lock step with technology and information revolutions. They have used technology advancements to provide the military Service men and women with the finest affordable equipment to defend and protect the nation. Use of computers to create weapon, combat, communication, command and control, surveillance, reconnaissance, and intelligence systems has evolved as computer technologies evolved. Interoperability is part of the evolution. Standalone Systems Development of standalone systems was the norm in DOD and Navy until 1997, when policy processes mandated an interoperability certification as decision criteria for procuring computer-based systems (DOD Regulation 5000.2R, 1997). In August 1999, policy processes added the mandate for measurable interoperability performance parameters and interoperability requirements as part of the procurement of computer-based systems (CJCSI 3170.01A, 1999. Unfortunately, the mandates were not applicable to computer-based systems that were procured and approved for use in military operations prior to 1997 and 1999. Thousands of standalone systems were approved for operational use prior to these dates. Because of this, most of 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the systems that are in operational use today were developed as standalone systems. A system is standalone if it is not connected to or dependent on a host system or network (URL 2: See Glossary for definition of “ standalone system.” This definition is found from the Web site with the following URL: http://nscp.upenn.edu/aix4.3html/aixuser/aixqbeg/sys_setup.htm). The standalone system generally performs one or a few functions specific to a single purpose or audience. It does not depend on other systems to perform the function(s) it was designed to perform, nor does it depend on the automated exchange of information with other systems. It is self-sufficient. Self-sufficiency in systems, though, could mean inefficiency if needed information exchange does not occur or occurs manually in the absence of automated information exchange. A large number of standalone systems are needed to perform the collective functions necessary to complete military operations. Through the years, the quantity and complexity of electronic computer-based systems increased as the need for and uses of systems increased. The nature of threats to the nation changed from “ strategic” to “ dynamic.” The Cold War was strategic and based more on “ what if scenarios—e.g., what if the enemy launched a nuclear attack? Defensive responses to this question included strategies to counter the attacks as well 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. as producing greater quantities of nuclear weapons than the enemy in order to deter such an attack. Today’s threats require more dynamic and quick responses to regional conflicts and terrorist attacks as they emerge. The “ tempo of war” increased dramatically with dynamic threats. The “ tempo of war” is the speed at which warfighters act and react during military operations. As the tempo of war has increased, so has the demand for rapid responses from systems supporting the war. For a standalone system to be successful, its functions must produce desired effects in response to the needs of the warfighters who are setting and keeping pace with the existing tempo of war. The challenge to standalone systems is to succeed in more rapid tempos of war. The threat changed; technology changed; but DOD and Navy systems have been slow to follow. Standalone systems prevail, but do they successfully respond to the needs of the warfighter? Stovepipe Systems Stovepipe systems consist of both standalone and dependent systems. They are called stovepipe systems because of the autonomy in their development/production. DOD policy grants much autonomy to Program Managers (PMs). They have decision-making authority to procure, develop, and produce computer-based systems. This autonomy potentially results in standalone systems or dependent systems with standalone 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. characteristics, i.e., no or inadequate interaction with other systems; inadequate information exchange with other systems; and inability to efficiently change to accommodate interactions and information exchange. Looking at the definitions of standalone and stovepipe systems in the Glossary, it is difficult to distinguish between them. Information-sharing and the ability to evolve with technology are lacking in both and evolving. The primary difference is in the intent. The intent of standalone systems is that they stand on their own, able to perform functions independent of other systems. A personal home computer is an example of a standalone system—though, today, their owners also want to share information with other systems. During the era in which DOD and military Services standalone systems were developed, interoperability was a concern but not an objective. Interaction with other systems meant delays and technical difficulties for the PM. He/she was usually a military officer on a three-year tour. “Success” for the PM was defined as meeting cost, schedule, and performance objectives of the program within the three-year period. These were significant criteria for upward movement in his/her career. Less interaction with other systems meant fewer obstacles. Standalone systems fit neatly into the plans of “successful” PMs, because the systems are not required to be interoperable. A system may have a requirement to be interoperable, but the PM may elect to minimize interactions with other systems in order to maintain 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. his/her own schedule, cost, and technical goals. On the surface, the PM appears to have a successful acquisition program that will produce a successful dependent system. The PM who initiates the program and gets it through the initial years in the life of the program walks away after three years with accolades, but an acquisition program generally has a five- to twenty-year life span and sometimes substantially more. On the other hand, PMs who manage phases of the program that demonstrate system dependencies are faced with challenges, such as interoperability problems that underlie the initial surface success. This is a result of minimized interactions. Even if the PM does interact with other programs and systems, his/her system has the potential of being a stovepipe. What would make it a stovepipe are autonomous decisions made by the PM that lead to development/production of a system with standalone characteristics, despite the interactions with other programs. The PM has decision-making authority for the degree of interaction, cooperation among programs, and mutual understanding and agreement of the technical interactions with other systems. He/she has the option of producing a standalone system by developing self-sufficient data and functions in their systems rather than depending on other systems. Oversight groups provide some checks and balances. They, however, only see the surface of the interactions as presented by the PM. They do not see the detailed design, programming 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. code, and data bases in the system that could raise questions of self- sufficiency and potentially result in a standalone system. Nor does there exist an overarching framework that establishes controls, boundaries, and a reliable consistent set of standards for the PM to follow.1 When many systems depend on another system, interactions, understandings, and agreements are complex. Working cooperatively with many programs to establish and implement dependencies is difficult. This, however, is the crux of achieving interoperability. The dependent systems must work together. The programs must work together. Each of the complexities that present barriers to achieving interoperability must be addressed and resolved as simply as possible. Aside from the complexities addressed in Chapter 2, integration of systems is another important barrier to achieving interoperability. System integration implements the ability to “ effectively use” information exchanged among systems in the achievement of interoperability. To achieve interoperability, systems connect externally and internally. External connectivity can be accomplished by using wire, connectors, and protocols, either directly or indirectly, between the systems that need to connect. Connectivity alone, though, does not assure interoperability among systems. The Department of Defense Joint Technical Architecture (JTA) establishes standards and protocols, but they are inconsistent both within and external to Navy. A team is working to solve this problem, but solutions will have impacts across the military Services and may not be cost effective to implement. 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The systems need to be able to effectively use the information exchanged. Integration, or synchronization of the functions, data, and processes within the systems, enables the effective use of information. Stovepipe systems inhibit the integration of systems, where interoperability creates dependency among systems by the sharing of information. Integration creates dependency among systems through the sharing of functionality, information, and processes among these systems. A system relies on another system to perform a function or process rather than performing the function or process itself. It uses the information exchanged by another system. Standalone systems are and were designed to be stovepipe systems. In recognizing the need for interoperability, DOD and the military Services are moving away from stovepipe and standalone systems. They are moving towards interoperable integrated dependent systems. Dependent Systems Dependent systems rely on other systems to perform functions or provide data. The two types of dependent systems are those that are stovepipes and those that are not. Since a standalone system is a stovepipe system, it is not a dependent system. Dependent systems represent a movement in the right direction to achieve interoperability. A major issue with which dependent systems are contending is their dependence on 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. functionality and data that is available in stovepipe systems. Because the functionality already exists, programs are not authorized to include the functionality or produce the data in the newer dependent systems. Legacy Systems A legacy system has been defined as a system that"... significantly resists modification and evolution to meet new and constantly changing business requirements" (Brodie & Stonebraker, 1995). The multiple definitions of a legacy system, as defined in the Glossary, amplify that legacy systems are mostly aging systems. DOD and Navy refer to systems as legacy systems when their full operational capability is officially in use by warfighters. Senior DOD and Navy decision-makers approve systems for operational use. Once approved, they are ready for warfighters to use in military operations. Many standalone systems are legacy systems comprised of old or obsolete equipment, software, and data. Modification of these systems is difficult, because equipment may no longer be available, or the legacy equipment and software may be incompatible with that of the newer systems. If these issues are insurmountable, the modification cannot take place. Legacy systems can be standalone, stovepipe, or even dependent systems. Their inflexibility or inability to change in light of emergent needs or 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technologies makes them legacy systems. In today’s environment, no plan exists to effectively prevent the stagnation of legacy systems. Organizations are just beginning to systematically and deliberately reassess the functionality of collective systems needed to perform military operations. Retention of systems is currently based on the functionality they perform independently as opposed to their cost-effective ability to integrate and interoperate with collective systems in performance of military operations. Plans do not now exist for deletion or replacement of legacy systems, if they are unable to fit within collective integrated interoperable systems. Non-legacy standalone systems may be easier to upgrade. A drawback with them, though, is that their design may not lend itself to changes that accommodate effective interoperability. Standalone systems have a risk of being unsuccessful, if they are unable to connect to or exchange functions or data with dependent systems, whether they are legacy or non-legacy. Dependent systems also risk being unsuccessful, if they do not get needed functionality and data. Investing in the upgrade of standalone systems may be to no avail. One solution, as indicated in the previous paragraph, is to migrate functionality and data from legacy systems to newer dependent systems. Or, perhaps the status quo success of the systems warrants that no action be taken? Or, possibly, a new approach to accomplishing the mission renders the functionality unnecessary? This 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. hypothesis in this chapter explores the success of these DOD and Navy computer-based systems. The Analysis—Hypothesis 1 Are Department of Defense (DOD) and Navy computer-based systems successful? The short answer is “no, they are not”; but this is not necessarily a fair answer. In the brief period of time since the 1980s, technology skyrocketed. American military Services remain the best in the world with the use of computer-based technologies. Advancements in technologies, though, have been rapidly accelerating with new ideas and concepts at such a pace that keeping up with them has been challenging. Military Services have made phenomenal progressions— moving from a handful of military ships and other platforms using automated systems in the mid 1980s to fully automated platforms today. One reason that systems are not successful is because the majority of them are standalone and stovepipe systems that are unable to keep pace with the growing demand for interoperability. Standalone and stovepipe systems provided a technology leap in the past twenty years, but technology advancements have rapidly diminished their novelty. Today, standalone, stovepipe, and legacy systems are not sufficiently responding to the interoperability needs of the warfighters in performance of 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. their missions. Warfighters experienced the support provided by technology to perform their missions and wanted more. DOD and Navy responded by moving away from military-specified systems towards the use of military systems that included commercial computer equipment. This act shortened the time of getting systems to warfighters and increased the technology available to warfighters. They wanted even more. In 2002, the United States went to war against terrorism with the primary battlefield in Afghanistan. Early action reports from the war identified that interoperability was a problem (Bender, Burger, & Koch, 2001). Consistently, “lessons- learned” reports have documented continuing interoperability problems. This meant the computer-based systems used by warfighters did not exchange information and effectively use the information so exchanged to operate effectively together. Most of the systems were standalone stovepipe systems and were not designed to be interoperable. Warfighters now want interoperability among the technologies. Standalone, stovepipe, and legacy systems, by design, are not interoperable. Table 1 includes brief examples of interoperability problems among these systems from lessons-learned reports. Appendix B provides additional and expanded examples. Both the table and appendix include direct quotes from the reports showing that interoperability problems among systems were reported in all regional conflicts or wars since 1991. Many interoperability 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. problems reported were resolved; but, with new technologies being continually introduced, new interoperability problems were reported. By means of lessons-learned reports, warfighters express the need for computer-based systems to achieve more effective interoperability. Standalone systems are inadequate, because they cannot be used to efficiently exchange information. They are not interoperable and need to be upgraded or replaced. Lessons-leamed reports suggest overall success for many military operation missions, but interoperability problems during the missions indicate the need for improving interoperability among complex DOD and Navy computer-based systems. Mission successes were degraded, because these systems fell short in responding to interoperability needs of the warfighter. The criticality of the need is in the details of the activities that occur during the mission. 38 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 1 Lessons-Leamed Excerpts Quotes from M ilitary Operations Lessons-Learned Reports Event Date Military Operation Interoperability Problem Excerpt 2001 Afghanistan Some of those early problems were said to be due to interoperability issues and other technical difficulties (Bender, Burger, & Koch, 2001). 1999 Kosovo The Joint Requirements Oversight Council (JROC) validated the need to use Kosovo Emergency Supplemental funds for upgrades to improve joint interoperability for the EP-3E [aircraft],. .. (Lautenbacher, 1999). 1999 Kosovo The lack of interoperable secure communications forced reliance on non-secure methods that compromised operational security. These problems persisted throughout the campaign (OASD, 1999). 1995 Bosnia [D]espite “standard NATO interfaces,” interoperability trials still have to take place to reduce interface problems (Wentz, 1995). 1991 Desert Storm Some problems were noted—primarily in the areas of communications interoperability—but. .. overall success. . . . (NHC, 1991). 1991 Desert Storm There were some problems with production of the [Air Tasking Order] ATO and its delivery to naval forces (NHC, 1991). 1991 Desert Storm The volume of communications traffic, the scope of the USN/joint/combined connectivity requirements, and the high precedence of a large percentage of the message traffic, presented a communication challenge of previously unimagined proportions (NHC, 1991). Interoperability problems were reported for all Regional Conflicts or Wars involving the United States since 1991. J 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Many activities are performed during the execution of a mission. An example includes the actions taken to respond to an enemy attack on U.S. forces. These forces need authorization from higher authority to respond to the attack. If this authorization is not received, a counter attack cannot occur. Computer-based communication systems provide a means of receiving the authorization. If the systems are used in this capacity, interoperability problems among them could prevent receipt of the authorization. As worst cases, loss-of-life, capture, or loss-of-battles for those risking their lives for our nation are potential costs of these interoperability problems. Summary—Hypothesis 1 DOD and Navy systems have made tremendous progress and advances over the past twenty-plus years, despite their interoperability problems; but because most of them are legacy stovepipe systems that are not interoperable, their success is diminished. Interoperability problems among these systems have been reported in every regional conflict or war since 1991. Warfighters told DOD and the military Services eleven years ago that, to be useful in the new warfighting environment, systems must be interoperable. They are still saying this, yet standalone legacy systems prevail. DOD and the military Services, though listening, may not have the resources or do not yet have the answers to solve interoperability problems 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. for standalone and stovepipe systems. Without solutions to interoperability problems, systems will remain standalone, and stovepipes and their success will continue to be less than desired or needed. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER IV ARE NAVY COMPUTER-BASED SYSTEMS THAT USE DEPARTMENT OF DEFENSE (DOD) AND DEPARTMENT OF NAVY (DON) PROCESSES ACHIEVING ACCEPTABLE LEVELS OF INTEROPERABILITY? Introduction—Hypothesis 2 Hypothesis: Navy computer-based systems that use DOD and DON processes are achieving acceptable levels of interoperability. “ Actions speak louder than words” is an often-used saying. DOD senior officials state words of commitment and acknowledgement of the need to resolve interoperability problems. Despite earnest intentions and despite many successful strides taken, their responses and actions have yet to result in overall problem resolution. This raises questions. What is an acceptable level of interoperability? Is the achievement of acceptable levels of interoperability too difficult and complex to attain? Or, perhaps, current levels of interoperability among computer-based systems are acceptable to DOD and the military Services even though problems exist? 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Evidence in Chapter 3 showed that standalone and legacy systems are major roadblocks to the success of DOD and Navy systems, because they are not interoperable or have difficulty in achieving interoperability. In today's environment the demand for interoperability is getting stronger. Strategy documents cite the goal of enabling the warfighter to respond in the face of adversaries—1 "any time and anywhere” (Johnson, 2001, preface, p. I). The ability to respond any time and anywhere becomes more possible, when the means to respond is available. Computer-based systems that exchange information provide this means, because they make the exchange to other systems feasible regardless of where they are. Evidence in Chapter 3 also showed that standalone systems are incapable of exchanging information. Since the majority of DOD and Navy systems are standalone, they are unable to exchange information and cannot achieve interoperability at acceptable levels. Newer systems have been developed to be interoperable; but can interoperability at acceptable levels be achieved without dependence on information from standalone systems? The answer lies in understanding how an acceptable level of interoperability is measured. The hypothesis of this chapter explores whether DOD systems are achieving interoperability at acceptable levels. 4 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Achieving Acceptable Levels of Interoperability Alexander Graham Bell achieved an acceptable level of interoperability between the first two telephones. His measures of interoperability success evolved as telephone quantities and technologies advanced. This is a good analogy to use to identify the metrics of achieving acceptable levels of interoperability among computer-based systems. Though DOD and Navy worked on interoperability problems for greater than twenty years, the problems have been evolving with the quantity and complexity of technology advancements. Programs have worked through connectivity, interface, and data base issues related to interoperability with many systems; but the new technologies introduce new interoperability problems that are incompatible with the older technologies; and these are coming faster than the older interoperability problems can be solved. The Navy invested in an Information Technology for the Twenty-First Century (IT-21) program to keep pace with advancing technologies. The objective of the IT-21 program was to procure affordable commercial information technology (IT) products that were disposable after a two-year period. Disposing IT was viewed as more cost effective than years of maintaining them. The products had to use DOD-approved standards. These were usually commercial standards. Though achieving many interoperability successes with the program, the 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. weapons and combat community was hesitant to use the products due to insufficient engineering rigor and control of systems. “Lessons-learned” reports, senior leader comments and actions, and continuous new strategies about interoperability problems indicate that, though strides have been made, achieving acceptable levels of interoperability remain elusive. Thus, an acceptable level of interoperability is an evolving metric defined by the level of attention it receives from military operations, senior leaders, and attempts to solve its problems. Interoperability and Legacy Systems On October 12, 2001, Deputy Secretary of Defense (DEPSECDEF) Wolfowitz, in a memorandum, endorsed his commitment to resolving the interoperability problems of “legacy systems” that require Command and Control (C2) functions. C2 functions include information exchange enabling processes and products. S am committed to resolving the problems of legacy C2 interoperability in an expeditious and cost effective manner. Therefore, I am establishing a goal for the Department to have legacy systems interoperable, with respect to critical command and control functions by the end of Fiscal Year (FY) 2008. (Wolfowitz, 2002) The enormity and difficulty of the Wolfowitz commitment are underscored by the elevation of interoperability problems to such a senior level as the Deputy Secretary of Defense (DEPSECDEF). This is compounded by twenty-plus years of searching for solutions to 45 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interoperability problems plus the fact that DOD and Navy legacy systems that require C2 functions encompass the majority of DOD and Navy legacy systems. The analysis in Chapter 3 found that standalone systems are not successful, because they are unable to interoperate. These systems are primarily legacy systems. Since the majority of Navy systems are standalone and they are legacy, they are not achieving interoperability at acceptable levels. The processes for attaining approval to use legacy systems in military operations were documented in versions of DOD and Navy policy that pre date the direction to make systems interoperable. Though current policy requires interoperability in new and upgraded systems, it does not require it for legacy systems. In his memo, DEPSECDEF Wolfowitz directs a policy update to include the achievement of interoperability in legacy systems. The question remains as to whether non-legacy systems provide interoperability to the degree that they do not need legacy systems to interoperate. Wolfowitz’s Six Action Items Along with his commitment to interoperability among legacy systems in his October 2001 memorandum, Paul Wolfowitz, in his providence, recognizes that resolving interoperability problems is non-trivial. He provided guidance to senior staff members in several organizations to initiate and 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. implement change that could result in interoperability achievement. A copy of his memorandum with complete text of his action items is in Appendix G. The following summarizes this guidance: 1. Define additional provisions necessary to support the achievement of interoperability among systems as a life cycle responsibility. Implement required changes by March 29, 2002. 2. Ensure that the Planning, Programming, Budgeting System (PPBS) considers C2 legacy interoperability funding requirements. Specifically, ensure appropriate funding for a prioritized set of overarching program initiatives beginning in FY ‘03. Initiatives should focus on mission critical C2 interoperability for the Joint Task Force (JTF) and below, the Joint Integration and Interoperability organization, and the Joint Distributed Engineering Plant. Also, identify funding for the Family of Interoperable Pictures (FIOP) as directed by the JROC. Candidate initiatives will be considered for acceleration and FY ‘03 funding based on JROC recommendations and clear benefits to JTF operations. Effective immediately. 3. Address issues and develop material and non-material options to resolve JTF C2 legacy interoperability shortfalls. Forward recommendations to the JROC for prioritization and referral to OSD by March 29, 2002. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4. Identify the key DOD component organizations addressing legacy interoperability, areas of duplication, and opportunities for consolidation or elimination. Provide recommendations to the JROC by March 29, 2002. 5. Develop initial metrics for operationally determining success in overcoming legacy C2 interoperability shortfalls. Modify CJCS Instructions, as appropriate, by March 29, 2002. 6. Identify opportunities for strengthening the implementation of DOD Directive 4630.5 and DOD Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems. Forward recommendations to the CIO by March 29, 2002. Actions Taken on Wolfowitz’s Six Action items The following were in response to the Wolfowitz action items or closely adjacent in time: 1. In response to the action to define additional provisions necessary to support the achievement of interoperability among systems as a life cycle responsibility, USD (AT&L) issued new interoperability policy January 11, 2002 (DOD Directive 4630.5, 2002). The additional provisions were as follows: Appendix H provides a copy of the old policy; Appendix I provides a copy of the new policy. 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Additionally, on August 30, 2002, Naval organizations received an E-mail notifying them of the intent of Secretary of Defense, Mr. Donald Rumsfield, to cancel the Defense Acquisition System policy on September 30, 2002. A draft interim replacement policy was distributed to these Naval organizations on September 5, 2002. The SECDEF cancellation policy memo was signed by DEPSECDEF Wolfowitz on October 30, 2002. The memo is provided in Appendix J. The interim policy was enclosed with the memo. 2. In response to the action to ensure appropriate funding for a prioritized set of overarching program initiatives beginning in FY ‘03, OSD (AT&L) responded with the following overarching initiatives, a concept for institutionalizing interoperability, and Joint Requirements Oversight Committee (JROC) approval of FY ‘03 funding for tasks targeted to implement the initiatives: • Overarching Initiatives • Family of Interoperable Operational Pictures (FIOP) • Single Integrated Air Picture (SIAP) • Single Integrated Ground Picture (SIGP) • Shared Tactical Ground Picture (STGP) • Precision Engagement/Time Sensitive Targeting (PE/TST) • Combat Identification 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • institutionalizing interoperability • System-of-Systems (SOS) Mission Areas and Capabilities • Developing System Architectures with Emphasis on “Open” Systems • Laying the Systems Engineering Foundation FIOP, also discussed in Chapter 5, encompasses SIAP, SIGP, STGP, and maritime pictures. PE/TST is a pilot designed to institutionalize interoperability. Precision engagement is one of the mission areas. Time-Sensitive Targeting is a capability within the mission area. Additionally, USD (AT&L) was responsible for the PE/TST pilot using Defense Science Board (DSB) Precision Engagement program recommendations (not necessarily C2). Funding for eight of these was initiated for FY ‘03. 3. In response to the action to address issues and develop material and non-material options to resolve Joint Task Force Command and Control (JTF C2) legacy interoperability shortfalls and forward recommendations about resolutions to JROC for prioritization, JFCOM identified a list of ten top interoperability problems. The USD (AT&L) staff incorporated these into their FIOP initiative for presentation to the JROC. 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4. The response to the action to identify key DOD component organizations addressing legacy interoperability, areas of duplication, and opportunities for consolidation or elimination was unanswered. 5. CJCS has partially completed the action to develop initial metrics for operationally determining success in overcoming legacy C2 interoperability shortfalls and modify CJCS instructions. In response to the second part of the action item to modify CJCS instructions, CJCS instructions were partially cancelled with a plan to reissue them within 120 days. Appendix K provides a copy of the cancellation policy memo. It is not yet clear, though, that the metrics from the first part of this action item will be available in time to be addressed in the new policy issuance or whether the memo will resolve the action. 6. In response to the action to identify opportunities for strengthening policy implementation (DOD Directives 4630.5 and 4630.8), OSD (AT&L) is developing an overarching concept of operations, an integrated joint architecture, and a new process that will be integrated into the new policies. In addition to the events occurring in response to the DEPSECDEF Paul Wolfowitz’s legacy systems memo, DEPSECDEF Wolfowitz and Vice Director of the Joint Staff, James A. Hawkins, Major General, United States 51 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Air Force, respectively, canceled requirements and acquisition system policy documents. These policy documents are key in directing the development and acquisition of computer-based systems. They also mandate interoperability as a measurable requirement. Occurring eleven months after the issuance of the Wolfowitz legacy system memorandum, cancellation of requirements and acquisition policy documents further demonstrate the seriousness of DOD and military Service leaders to solve computer-based system problems. DEPSECDEF Wolfowitz implied that the current acquisition policy is too prescriptive (2002). Appendix J provides a copy of the memo canceling the policy. On October 30, 2002, at the same time DEPSECDEF cancelled the acquisition policy, he issued an interim acquisition policy with the mandate for a new policy within 120 days. CJCS, as mentioned in the Wolfowitz response number 5, canceled the Mission Needs Statement and Capstone Requirements Document processes from the requirements policy on October 7, 2002 (CJCS, 2002). Appendix K provides a copy of his memorandum. The current plan is to replace these documents with an integrated architecture that describes the more holistic needs of the warfighter. The actions taken by the three very senior leaders are clear indications of the seriousness of the interoperability problems and the difficulty in solving them. 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Interoperability and Non-Legacy Systems Non-legacy systems are in the early stages of operational use, approved but not yet in operational use, or not yet approved. Legacy systems were developed and produced as standalone systems by design. Policy processes did not include interoperability as a requirement until 1997. Eleven years of lessons-learned reports imply the non-interoperable status of legacy systems, but interoperability for legacy systems is lagging behind. Operational and interoperability testing are criteria that must be completed before a system is approved for use in military operations. An issue that non-legacy systems run into is that they fail to pass interoperability testing, because they are unable to interoperate with the legacy systems. The problem arises, because the newer non-legacy systems do not perform many of the functions provided by the legacy systems. Both legacy and non legacy systems are needed to provide the warfighters with the capabilities to perform military operations. They do not, however, interoperate. Acquisition of the Cooperative Engagement Capability (CEC) is a good example of the interoperability problems between new and legacy systems. CEC was a new program specifically designed to improve interoperability among systems. Its technological components were so advanced that it was unable to pass its interoperability testing due to incompatibility with legacy systems. CEC had a requirement to be interoperable with three other systems. They were legacy systems that did 53 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. not have the technology needed to achieve interoperability. The issue became a contest among four Program Managers—one for each system involved—that eventually received Congressional attention. When the Program Managers were required, many of the problems were resolved. Program Managers achieved success and resolved many of the interoperability problems with CEC, when they were required to show progress towards achieving interoperability to Congress. Barriers to cooperation among the programs were dropped because of the greater fear that Congress could potentially eliminate funding for programs. Cooperation among the programs resulted in interoperability success. CEC, though, made capability concessions in order to become interoperable with legacy systems. The legacy systems also conceded to upgrade technologies to improve achieving interoperability. As evidenced in Appendices A through E, DOD systems experienced interoperability problems during military conflicts between 1991 and 2002. Interoperability problems are haunting DOD and Navy systems, but the United States (U.S.) is successful in military operations despite the problems. Table 2 provides additional evidence that senior officials are not happy with the present level of interoperability. The excerpts in the table demonstrate that these officials are aware of and searching for answers to interoperability problems. 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 2 Senior Official Comments/Direction on interoperability Date Position interoperability Problem Excerpt 2002 LTGEN AIR FORCE The interoperability problem is getting worse (Woodward, 2002). 1999 ASN (RDA) Established a Chief Engineer to . .. create a process that does not yet exist... to address interoperability (Buchanan, 1999). 1999 Congress Directed Secretary of Navy to report to Congressional Defense Committees at least quarterly on CEC/combat direction system interoperability problems and planned solutions (105-736). 1998 NAVSEA CNO NAVSEA created the Warfare System’s Directorate to address the Fleet’s concerns. .. CNO message May 1998 to address interoperability (021648Z, May 1998). 1985 VCNO [The Navy has] a fragmented approach to BFC2 resulting from a lack of understanding of interoperability issues and programmatic actions being taken without full understanding of the impact on other interrelated programs.. .. (VCNO, 1985). 1982 DASN (C31) What information exchange and functional agreements exist between ACDS, TFCC, ACS, and C2P [Navy systems] Programs (Kitson, 1982)? ^Senior officials have been commenting and giving direction on interoperability for the past 20 years. Yet, the problem of DOD and Navy systems achieving interoperability at acceptable levels appears to be g e ttin g worse (Woodward, 2002). J 55 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Since the U.S. has successful military operations, does this mean that the achievement of interoperability at its current levels is acceptable? How is an acceptable level of interoperability measured for Navy systems? If interoperability success has no measure, does this mean it cannot be accomplished? Are senior officials willing and able to commit the attention and resources needed to achieve interoperability at more acceptable levels? These questions will be revisited in Chapters 7 and 8. As evidenced in Table 1 in Chapter 3 and Appendices A through E, warfighter responses state that interoperability levels are not acceptable. Congressional responses go both ways, implying that they are and they are not acceptable. Nevertheless, Congress has not committed sufficient financial, personnel, and materiel resources to attain interoperability. The latter may be due to ill- or undefined approaches and justifications for achieving interoperability. Sufficient resources may include replacement of many of the thousands of legacy systems. Navy may be remiss in providing the bill. An acceptable level may mean that interoperability would not be a major issue in lessons-learned reports, and the processes would produce interoperable systems. The Wolfowitz memo, though, provides unequivocal evidence that DOD systems are not achieving interoperability at acceptable levels. 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Legacy and Non-Legacy Systems Summary The achievement of acceptable levels of interoperability is non-trivial and an extremely difficult problem to solve. Lessons-learned reports make clear that DOD and DON systems are not achieving interoperability at acceptable levels. These systems consist of both legacy and non-legacy systems. The lessons-learned reports do not distinguish between them, because the systems need to work together. They do not. The reports continue to cite that interoperability is problematic. Senior officials have dedicated much attention to establishing new organizations, new policy processes, and new systems to achieve interoperability at acceptable levels. The interoperability problem persists, and interoperability is not being achieved at acceptable levels. DOD and DON Processes Used To Achieve interoperability Today, three primary policy systems, known as "decision support systems,” provide the processes for developing, producing, and delivering computer-based electronic systems. Interoperability is embedded as a requirement in one of these policy systems and as implementation policy and guidance in another one. One of the policy systems does not specifically address interoperability but is essential to fund interoperable systems. The following are the policy systems that comprise the decision support systems: 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Requirements Generation System (CJCSi 3170.01 B, 2001) • Interoperability is embedded as a measurable key performance parameter (KPP). • Information exchange is embedded as a requirement (IER). • Defense Acquisition System (DOD Directive 5000.1, 2000; DOD Instruction 5000.2, 2001; (DOD Regulation 5000.2-R, 2001). • Interoperability is a key goal. • Systems developed must implement the interoperability KPP and IER. • Planning, Programming, and Budgeting System (DOD Directive 7045.14, 1990). • Interoperability is not addressed. Policy letters from organizations within Navy provide additional policy, when senior authorities deem it necessary to supplement general policy. Two such supplements provide support for achieving interoperability. They are as follows: • Interoperability and supportability of Information Technology (IT) and National Security Systems (NSS) (DOD Directive 4630.5, 2002); and • Implementation of Interoperability and supportability of Information Technology (IT) and National Security Systems (NSS) (DOD Directive 4630.8, 2002). 58 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Three major communities are involved in implementing the above decision support systems. The requirements community represents the warfighter. This community develops capability requirements that computer- based systems must satisfy. Acquisition, development, and production of these computer-based systems are implemented by programs in the acquisition community. The operational community plans and budgets for the acquisition of systems. They evaluate requirements and acquisitions to satisfy those requirements. Alignment of the processes, cultures, and products of these three communities is essential to deliver even a standalone system that benefits warfighters. Achieving interoperability among computer-based systems involves greater complexity in aligning the processes, cultures, and their products. The Analysis— Hypothesis 2 Do Navy computer-based systems achieve interoperability at acceptable levels using DOD processes? Interoperability problems between and among electronic computer- based systems surfaced more than twenty years ago. DOD did not include the term “interoperability” in its policy processes until 1996 (DOD Regulation 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5000.2R, 1996; CJCSI 3170.01, 1997)2 and did not publish a definition for it until 2000 (Joint Publication 1-02, 2002; DOD Directive 5000.1, 2000; DOD Directive 5000.2, 2001; CJCSI 3170.01B, 2001). Even with the addition of the term in policies, interoperability problems continue to persist. Further, policy processes target principally new or planned electronic systems but not those that already exist— legacy systems. Legacy systems have been almost exclusively developed and designed as standalone systems. Interfaces existed but were treated as simulations (artificially manipulated inputs to the standalone system). Today, programs implement upgrades to these systems for the purpose of exchanging information with other systems. When Program Managers upgrade the systems, they are not required to subject it to the policy processes or interoperability review again. Policy processes have little impact on enabling the interoperability of these systems at any level. Recognizing this, Deputy Secretary of Defense Paul Wolfowitz sent a memorandum directing that a team address interoperability of legacy systems in decision support systems processes (Wolfowitz, 2001). A copy of this memo is in Appendix G. One of the policies referred to in the Wolfowitz memo is in Appendix H. 2 The term “interoperability” was weakly used in the Department of Defense (DOD) Regulation Number 5000.2R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs, March 15,1996. Interoperability key performance parameters and information exchange requirements were identified as requirements in the Commander, Joint Chiefs of Staff Instruction (CJCSI) Number 3170.01, The Requirements Generation System, June 13, 1997. Both of these documents have since been updated with stronger discussions of interoperability. 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 3 depicts the eleven acquisition programs that were ready for Defense Acquisition System milestone decisions from the Defense Acquisition Board (DAB) during the period February 2001 through March 2002. Ten of these systems were approved for operational use by Navy warfighters. They make little impact on the interoperability of the thousands of legacy systems already fielded and operational. The new systems have an interoperability requirement, but legacy systems do not. Until the processes address a reasonable plan for the interoperability of these legacy systems, DOD and DON systems will not be interoperable. 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 3 Programs Presented in the Defense Acquisition Board (DAB) for Milestone Decisions between April 2001 and November 2002 ASN (RD&A) PDM/DAB Production Decisions (April 2001-November 2002 Status Approve Date Program DASN CA 6-ApriI-01 ESSM SHIPS A 12-April-01 MTVR SHIPS A 7-Sept.-01 E2-C MCU AIR A 29-Sept. 01 T-AKE SHIPS A 1-Nov.-01 AIM-9X SHIPS CA 1-June-02 F/A-18 ATFLIR AIR A 15-Aug.-02 MH-60S AIR CA 14-Sept.-02 TACT TOMAHAWK AIR CA 28-Sept.-02 AMC&D AIR A 18-Nov.-02 LW-155 AIR N N/A SSGN SHIPS A-Approved CA-Contingent Approval N-Not Approved /E v e n if all 11 of the programs reviewed for m ilestone^ decisions from February 2001 to March 2002 were approved and fielded immediately, they would barely make a dent in solving the interoperability problem due to the thousands of previously approved and fielded V^systems that are potentially not interoperable. 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology insertion decisions to acquire and field new electronic systems often circumvent policy processes. Awareness of technology solutions does not always occur within the framework of policy processes. Implementation of policy processes occurs over a period of time— usually five to twenty years. Users are not always willing to wart five years for a technology they believe is available today. The technology insertion challenge is to fit the technology within policy processes while shortening the processes in order to field the technology as quickly as possible. Lack of interoperability may be an unintended consequence of the insertion. The insertion of new technology requires sufficient forethought or analysis to determine impacts on other electronic systems. Decision-makers can determine whether sufficient time is provided for the analyses. If not, the technology insertion can also lead to the insertion of new interoperability problems. Examples of technology insertion that circumvented policy processes include the Joint Operational Tactical System (JOTS) and Tactical Exploitation System-Navy (TES-N) that were fielded in 1986 and 2001, respectively. These systems were fielded as research and development prototypes before they began to implement the decision support system processes. The system prototypes were and, in the case of TES-N, are used in real-life operational settings. Both systems created much controversy and are experiencing interoperability problems. Other systems, 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. such as the Cooperative Engagement Capability (CEC), did use the policy processes but also experienced interoperability problems. The implication is that there are problems in the policy processes. Policy systems require that new systems identify all systems (legacy, planned, technology insertion, and other new systems) with which they will interoperate. This requirement enables decision-makers’ interoperability visibility into some of the legacy and technology insertion systems. From this perspective, will the hypothesis question be answered? Requirements Generation System The purpose of the Requirements Generation System process is to produce information for decision-makers about the mission needs and requirements of warfighters to operate in performance of their mission (CJCSI 3170.01 B, 2001, p. 4). Definitions for terms used for this purpose are located in the Joint Dictionary of Military Terms (Joint Publication 1-02). A mission is a task, together with the purpose, that clearly indicates the action to be taken and the reason therefore. Mission needs are deficiencies in capabilities to perform a military objective. Capabilities are tasks and activities necessary to achieve a course of action. Objectives are metrics that measure the achievement of the course of action. Requirements identify the role(s) of computer-based systems to respond to the needs. Implementing the Requirements Generation System yields three types of 64 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. products— Mission Needs Statements (MNS), Capstone Requirements Documents (CRDs), and Operational Requirements Documents (ORDs). The four-phased process used to evolve from a MNS to CRD to ORD or MNS to ORD involves the translation of the needs of the warfighter to operational requirements that can be satisfied by a materiel solution. An example of a materiel solution is a computer-based system as opposed to a non-materiel solution, such as a change of procedures. Phase one of the four evolutionary phases defines, analyzes, evaluates and justifies the development. The second phase is the formal document preparation and review. Phase three validates requirements documents by means of reviews. Approval of documents by decision makers is the fourth phase and is performed by designated approval authorities, depending on the category assigned to the requirements. Interoperability and Information Exchange Requirements are mandated in developing the CRD and ORD. Figure 2 captures the Requirements Generation System depiction of the evolution. The language in the figure— “non-system specific needs” — means that the needs are identified independent of whether they can be satisfied by a materiel or non-materiel solution. System-specific performance-based operational requirements are requirements that need a materiel system response. The system response is measured according to specified performance parameters. 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Established ORDs that fa ll under CRD New ORD development that falls under CRD Very Broad Non-System Specific Needs (MNS) FoS/SoS Capabilities Based Requirements (CRD) System Specific Performance Based Operational Requirements (ORD) Figure 2. Requirements documentation evolution. Source: CJCSI 3170.01B (2001, April 15). The Requirements Generation System, Enclosure D, p. 7. MNS evolve to an ORD or to a CRD. CRDs evolve to multiple ORDs. CRDs are optional. At best, the starting point for achieving interoperable systems is a usually narrowly-focused MNS. Missing is the “big picture” —an overarching context from which it can be determined that a need exists and that provides guidance for the collective MNS, CRDs, and ORDs. V ______________ / Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Mission Needs Statement (MNS) A MNS is a formatted statement describing operational capability needs written in broad operational terms. Without referring to a system, the MNS identifies and describes the projected needs of the user in the context of the threat to be countered or business need to be met (DOD Instruction 5000.2, 2001, p. 10; CJCSI 3170.01B, 2001, p. 16). Though the MNS does not specifically state that a system (which is a materiel solution) should be the solution to satisfy user needs, MNS are usually developed when it is believed that non-materiel solutions, e.g., procedural changes, do not work. Missing from the Requirements Generation System is an overarching “big picture” that describes the context—the threat to be countered or business need to be met. References in the policy are made to identifying existing capabilities and current national and defense strategy documents and projected threats in order to derive MNS, but the information about the context is attained by means of analyses. This information is individualized and may not reflect the same “big picture” from one MNS to another. The MNS format and development guidance do not identify interoperability as a requirement, but interoperability is described as a key boundary condition constraint related to infrastructure support that may impact on satisfying the need. DOD automated the list of all MNS’ and put them on classified and unclassified (but password protected) Web sites. Navy has a population of 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 123 classified and unclassified MNS, as listed in Appendix L. The population (70) of Navy unclassified MNS is in Appendix M. An immediate question these numbers raise is whether the automated documents represent the “big picture” and the Navy’s role in it. How does a Program Manager of a Navy system know how or whether his/her system(s) fits within this “big picture"? Though policy processes require the assessment of current and projected capability to accomplish assigned missions, they do not address the consolidation of these capabilities derived from strategy documents and threats. As a result, MNS documents tend to focus on stovepipe needs that may not easily fit into clearly-defined mission areas. Additionally, in the year 2000, Navy had a population of 517 ACAT programs, each of which was acquiring or developing one or more systems. Appendix N provides the list containing the population of Navy Acquisition programs. When comparing the minimum population (517) of Navy acquisition systems in Appendix N to the population (123) of Navy MNS in Appendix L, at feast 394 systems do not have a MNS. This means policy was absent on the subject at the time, not followed, or Navy was unable to consolidate and automate the population of a MNS. Capstone Requirements Document (CRD) The CRD is a document that contains overarching requirements to facilitate development of multiple computer-based systems. It provides a 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. common framework and operational concept to guide their development (CJCSI Numbers 3170.01, 1997; 3170.01A, 1999; 3170.01B, 2001, p. 54; DOD Instruction 5000.2, 2001, p. 10). The requirement to develop CRDs is fairly new, with the first unclassified Navy document appearing in 1996. (URL 3: MNS, ORD, CRD data base, URL: http://ncw.navair.navy.mil. This URL enables one to apply for login access to the Interoperability Data Resource (IDR) Web site data base that houses MNS, ORDs, and CRDs. The multiple systems in a CRD are related and identified as belonging to a Family-of-Systems (FOS) or System-of-systems (SOS) that will satisfy the requirements in the CRD (CJCSI 3170.01B, 2001, p. 24). As shown in Figure 2, CRDs evolve from MNS. A MNS identifies a user shortfall or need. The CRD frames a response to the shortfall or need in the form of overarching requirements for multiple systems that must work together. These frames are intended to establish guidelines for future or legacy joint systems and are initiated at the option of the Joint Requirements Oversight Committee’s (JROC) senior decision-making body. The Requirements Generation System policy attempted to be flexible, because emergent requirements often resulted from the emergence of technologies that disclosed improved efficiencies in military operations. These technologies and their potential uses occurred prior to development of supporting requirement documentation. Because of this, the Requirements Generation System states both that MNS are developed using CRD 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. guidelines (CJCSI 3170.01 B, 2001, p. 24) as well as that CRDs are derived from MNS (CJCSI 3170.01 B, 2001, pp. 4, 6-7). The policy supports both situations. This appears to be a contradiction. It is likely that there are situations where CRDs will appropriately lead to MNS instead of vice versa. Figure 3 depicts this dichotomy. The issue is critical because of the influence of the documents on interoperability. Identifying all MNS, ORDs, and systems with overarching requirements of the CRD begins to set boundary conditions for the systems in the FOS or SOS that need to be interoperable. Another issue associated with developing CRDs for mission areas is the lack of a common understanding in DOD of what constitutes mission areas. The Requirements Generation System does not provide a definition for the term. Lacking this understanding, inconsistency within and among CRDs will result. This, too, influences interoperability because of the difficulty in determining the interactions needed among systems in the mission areas. 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Legacy ORDs FoS/SoS Capabilities Based Requirements (CRD) / System Specific Very Broad Performance Non-System Based Specific Needs Operational (MNS) Requirements \ (ORD) V Key: New ORD development Planned Systems (In a POM Cycle) Future and Legacy Systems Figure 3. Requirements document evolution implied by Requirements Generation System. Source. CJCSI 3170.01B (2001, April 15). The Requirements Generation System, Enclosure D, p. 24. As stated in the Requirements Generation System, capabilities-based “big picture” CRDs drive MNS, which drive ORDs. This is a departure from another statement in the policy that MNS drive CRDs. (See Figure 2.) The intent of the CRD is to address mission area requirements for multiple systems—such as in FOS or SOS. As developed CRDs have failed to define, standardize, and address mission areas. J Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DON automated the population of DON-related CRDs in classified and unclassified data bases. These are available from data bases on appropriately protected Web sites. The following six documents constitute the population of Navy unclassified CRDs: e Global Air Traffic Control (GATM) Phase II; • Global Combat Support System GCSS), • Global Information Grid (GIG); • Information Dissemination Management (IDM); Defense Information Systems Network (DISN); and • Submarine Exterior Communication System. Though the Requirements Generation System requires a MNS to identify the need for multiple systems (see Figure 2) and, subsequently, a CRD to describe capabilities-based requirements for these systems, developers do not necessarily derive CRDs from MNS. Some CRDs represent Program Manager solutions that fill a FOS or SOS acquisition milestone. Other CRDs have been the result of attempts to establish an infrastructure. Still, other CRDs represent an organizational solution in response to a senior authority or political action item, e.g., a Congressional mandate for development of a system. Mission areas are discussed but not defined in the Requirements Generation System. Further, each military Service creates its own mission areas. Standard, defined mission areas are missing from existing policies 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and CRDs. The overarching requirements for target FOS or SOS in CRDs cannot, therefore, represent a complete mission area. Review of the 70 unclassified MNS, shown in Appendix M, and the population of six CRDs, shown above, proved to be difficult, when attempting to align mission areas to needs. The mission area of the CRD was difficult to discern. Interoperability requirements of new systems and/or shortcomings of fielded or planned systems are defined in the CRD. Interoperability, as defined in the Requirements Generation System, includes both the definition found in the Defense Acquisition System as well as the following definition: “ The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users” (CJCSI 3170.01B, 2001, p. 38; Joint Publication 1-02, 2002). All systems associated with a CRD are required to be interoperable. As a means of including interoperability as a requirement for systems, the format used to develop a CRD requires the following information: • Interoperability concept (for internal and external to the FOS and SOS); Interoperability shortcomings of existing systems and architectures; • Information Exchange Requirements (lERs); and • Interoperability Key Performance Parameters (KPPs). 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Interoperability concept is a general description of an operational capability in sufficient detail for program, logistics, and support planning. It also addresses the mission area and the types of system proposed to provide the capability. Interoperability shortcomings describe why existing systems cannot meet current or projected requirements within the capability. An example of a family-of-systems is the set of missile systems used for land-based targets. An example of a system-of-systems is the set of systems needed to perform a specified mission, such as a search and rescue mission. In the SOS, surveillance, command and control, communications, and combat identification systems may be needed. If a surveillance vehicle, a ship, and a handheld computer are needed for the search and rescue mission, but they do not have ability to exchange information, this interoperability shortfall could result in mission failure. CRD lERs are defined as follows: The requirement for information to be passed between and among forces, organizations, or administrative structures concerning ongoing activities. Information exchange requirements identify who exchanges what information with whom, as well as why the information is necessary and how that information will be used. For CRDs, top-level lERs are defined as those information exchanges that are between systems that make up the FOS or SOS, as well as those that are external to the FOS or SOS (i.e., with other CINC/Service/Agency [C/S/A], allied, and coalition systems). For ORDs, top- level lERs are defined as those information exchanges that are external to the system (i.e., with other C/S/A, allied, and coalition systems). The quality (i.e., frequency, timeliness, and security) and quantity (i.e., volume, speed, and type of information, such as data, 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. voice, and video) are attributes of the information exchange included in the information exchange requirement. (CJCSI 3170.01B, 2001, pp. 54-55) CRD KPPs are defined as follows: “ Those capabilities or characteristics considered essential for successful mission accomplishment. Failure to meet a CRD KPP threshold can be cause for the FOS or SOS concept to be reassessed or the contributions of the individual systems to be reassessed” (CJCSI 3170.01B, 2001, p. 56; DOD Instruction 5000.2, 2001, p. 38). lERs and KPPs are used as the primary basis to measure interoperability requirements in CRDs and ORDs. Table 4 indicates that four of the six CRDs included lERs, and four of six included KPPs. lERs and KPPs were not required until August 1999 (CJCSI 3170.01A, 1999). In systems dated before 1999, CRDs have not been updated to address interoperability. The table demonstrates that interoperability is not being back-fitted to processes that are already approved. Based on the date and the policy at the time, lERs and KPPs should also be in the 1998 CRD. Additionally, since each CRD represents multiple ORDs and systems, the 1996 CRD, its associated ORDs, and associated systems should be updated to include lERs and KPPs. Statistical inferences on the table are not achievable until the quantities of systems associated with each CRD are known. 75 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 4 Interoperability, KPPs, and lERs in the Population of Navy Unclassified Capstone Requirements Documents (CRDs) Title Date Interoperability Addressed Interoperability KPPs Included Interoperability lERs Included Global Information Grid (GIG) 4-Oct.-01 MED YES YES Information Dissemination Management (I DM) 8-May-01 HIGH YES YES Global Combat Support System (GCSS) 27-June-00 HIGH YES YES Global Air Traffic Control (GATM) Phase II 7-June-00 MED YES YES Submarine Exterior Communications System 12-May-98 LOW NO NO Defense Information Systems Network (DISN) 15-April-96 HIGH NO NO /A s recently as May 1996 systems did not address KPPs and lERs; but today, CRDs and ORDs must endeavor to address Interoperability better by including it in Concepts, KPPs, and lERs. This practice began in st of 2000. \Augus KPPs should be in the 1998 CRD. To address interoperability, the DISN system should be updated along with the CRD to include the interoperability KPP. Since each CRD represents multiple systems, statistical inferences on the table are not achievable, until the quantities of 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. systems associated with each CRD are known. They are currently undetermined or unknown. Operational Requirements Document (ORD) An ORD is a product of the Requirements Generation System. It is a formatted statement containing performance and related operational parameters for a proposed concept or system (CJCSi 3170.01 B, 2001, p. 57; DOD Instruction 5000.2, 2001). Objective and threshold values for the parameters are stated. These values are the means of measuring the operational utility of requirements. Threshold values are the minimal acceptable parameter values (CJCSI 3170.01B, 2001, p. 35). Objective values are operationally significant increments above threshold values (CJCSI 3170.01B, 2001, p. 35). ORDs evolve from either MNS or CRDs. ORDs translate MNS/CRDs into operational goals. These goals are further detailed into specific operational capability requirements (DOD Instruction 5000.2, 2001). The ORD is the primary bridge between the needs and requirements developed under the Requirements Generation System and computer-based systems developed using the Defense Acquisition System (CJCSI 3170.01B, 2001, p. 35). It includes links that enable contractual specifications for establishing and implementing the programs that develop and deploy computer-based systems. 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ORDs, like CRDs, should include interoperability shortcomings of existing systems and architectures, information exchange concept, Information Exchange Requirements (lERs), and Key Performance Parameters (KPPs) for interoperability. ORD lERs and KPPs should be system-oriented and more detailed than CRD lERs and KPPs. Interoperability, as defined in the ORD format section of the Requirements Generation System, is as follows: “ The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users” (CJCSI 3170.01B, 2001, p. 38). The above definition differs from that found in the Defense Acquisition System. Differences in lexicon definitions for the same term often cause confusion in gaining common and reliable understandings among systems. This contributes to the difficulty in achieving interoperability. Interoperability shortcomings of existing systems explains why those systems do not meet the requirements prescribed in the CRD or ORD. lERs are defined as follows: The requirement for information to be passed between and among forces, organizations, or administrative structures concerning ongoing activities. Information exchange requirements identify who exchanges what information with whom, as well as why the information is necessary and how that information will be used. (CJCSI 3170.018,2001) 78 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. For CRDs, top-leve! lERs are those information exchanges that are between systems that make up the FOS or SOS, as well as those that are external to the FOS or SOS (i.e., with other CINC/Service/Agency (C/S/A), allied, and coalition systems). For ORDs, top-level lERs are defined as those information exchanges that are external to the system (i.e., with other C/S/A, allied and coalition systems). The quality (i.e., frequency, timeliness, and security) and quantity (i.e., volume, speed, and type of information, such as data, voice, and video) are attributes of the information exchange included in the information exchange requirement (CJCSI 3170.01B, 2001). KPPs are those system capabilities or characteristics considered essential for successful mission accomplishment. Failure to meet an ORD KPP threshold can be cause for the concept or system selection to be reevaluated or the program to be reassessed or terminated (DOD Instruction 3170.01B, 2001, p. 38). Interaction among sponsors and leads for CRD and ORD products are clearly stated. An ORD is required for each computer-based system. It includes the requirements that a single system must satisfy to provide a capability to users of the system. The population of Navy ORDs, classified and unclassified, is 317 and listed in Appendix O. At the option of a decision making body, a CRD may be developed for multiple systems that are part of a Family-of-Systems (FOS) or System-of-Systems (SOS). An ORD is required for each system in the CRD. Development of the ORD is a 79 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. response to a system needed to satisfy the needs identified in a MNS or a system needed to satisfy requirements of one of the systems in a CRD. If a CRD does not exist, it is not likely part of a FOS or SOS and represents a potentially a standalone stovepipe system. The earliest unclassified Navy CRD for Navy systems was developed in April 1996 (see Table 4). As shown in Table 5, 57 unclassified Navy ORDs were developed prior to 1996. Neither these ORDs nor the systems developed from them were derived from a CRD. They also did not belong to the FOS or SOS derived from the CRD. According to the Requirements Generation System, an ORD should be developed for each system needed for a CRD. A system that does not require a CRD is an indicator of a potential stovepipe or standalone system, unless significant effort is put forth to make the system interoperable. The population of Navy unclassified ORDs includes 158 ORDs and is listed in Appendix P. Since these ORDs represent systems, the expectation is that those that are interoperable will map back to the six CRDs discussed above. Table 6 demonstrates that it is difficult to map ORDs to CRDs, because most of the ORDs were developed prior to the CRD. They do not all specify a relationship, but the newer ORDs are required to state the relationship. The implication is that, even with CRDs and ORDs, it is difficult to identify systems that, as a minimum, should connect or be interoperable. 80 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 5 Dates that the Population of Navy Unclassified ORDs Was Developed and the Quantities Developed Total Date Developed ORD Quantity Cumulative Quantity 2001 7 158 61 2000 16 151 1999 25 135 1998 13 110 1997 17 97 80 1996 23 80 1995 29 57 1994 11 28 1993 7 17 16 1992 8 10 1991 1 2 1990 0 1 1 1989 1 1 /Though thousands of Navy systems exist and ORDs \ are required for each system, Navy can only account for a population of 317 ORDs, 158 of which are unclassified. Interestingly, the rate of ORD development falls off, when policy changes are introduced, e.g., 1996, 2000, and 2001. 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 6 CRD Relationships to ORDs Title Date Quantity Related ORDs Global Information Grid (GIG) 4-Oct.-01 5 Information Dissemination Management (IDM) 8-May-01 Unknown Global Combat Support System (GCSS) 27-June-00 Unknown Global Air Traffic Control (GATM) Phase II 7-June-00 Unknown Submarine Exterior Communications System 12-May~98 1 Defense Information Systems Network (DISN) 15-April-96 2 ORDs or their Program Managers do not indicateX a relationship with CRDs. A quantity of unknown is shown where the relationship could not be established. Most CRDs were developed after the ORDs. Only new are required to identify a relationship with CRDs. J Review of the ORDs discloses that 94 ORDs relate to the 123 MNS. This is corroborated in the MNS to ORD relationship table in Appendix Q. Since the population of Navy ORDs is 317 and an ORD is required for each system, the implication is that the MNS for at least 223 systems do not exist in the official Navy data base. Additionally, as shown in Appendix R, 30 unclassified ORDs relate to the 70 unclassified MNS, implying that 40 of the 223 MNS are unclassified and easier to access. 82 ORDs Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Further, the systems without MNS have no visible means of demonstrating that processes to invoke interoperability were used. Also, relationships cannot be established between CRDs and ORDs. This is counter to the processes stated in the Requirements Generation System. Again, established processes are not implemented. If these processes are the means of defining, implementing, and assuring interoperability, it is not surprising that the systems developed using these processes are not interoperable. Most of the ORDs were developed prior to 1996 and 1997 and refer to deployed (legacy) systems. Legacy systems were developed using decision support systems or the processes in effect at the time of their development. When systems are approved for operational use, they do not need to repeat the process. This makes it difficult if the newer systems need to be interoperable with systems that are already approved for operational use. The approved systems have already completed previous processes that did not address interoperability. Upgrades to the systems do not need to repeat the processes. New systems that are subject to the requirement are finding it difficult to establish their exchange concepts, lERs, and interoperability KPPs with the legacy systems. As discussed in Chapter 5, Dr. Paul Wolfowitz (2001) recognized the problem of legacy systems. His memorandum (see Appendix G) directed that a team address the interoperability of legacy systems in decision support systems. 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Requirements Generation System paves the way for the Defense Acquisition System. Figure 4 depicts the products delivered when the Requirements Generation System is implemented. The DOD agencies and military Services responsible for acquiring systems must understand and are often participants in the preparation of needs and requirements. This enables them to better understand the functions needed in computer-based systems to achieve the capabilities defined in the needs and requirements documents. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. M M MNS MNA CRD (If Required) AOA ORD AOA Update ORD (If Required) — c^-» o ---■ — o ORD o Products ■or Analysis JROC JROC JROC JROC JROC Approval ■ -Authority Figure 4. Products delivered and their approval authority for implementing the Requirements Generation System. Source: This depiction was drawn from the original depiction in the Requirements Generation System, 15 April, 2001. r ------------------------------------------------------------------------------------------------------------------ \ Products include Mission Needs Statement (MNS), Capstone Requirements Document (CRD), and Operational Requirements Document (ORD) and its Updates. The JROC approves the products. The analyses needed to develop CRDs and ORDs include Mission Area Analysis (MAA), Mission Needs Analysis (MNA), and Analysis of the ^ Alternatives (AOA). j Defense Acquisition System The Requirements Generation System produces MNS, CRD, and ORD products that document user needs. The Defense Acquisition System translates the requirements products to produce and distribute computer- based systems. “ The Defense Acquisition System establishes a management process to translate user needs into reliable and sustainable systems that provide capability to the user” (DOD Instruction 5000.2, 2001, p. 4). Users are the men and women in the military who use computer- based systems to perform their missions. User needs are responses to adversarial threats; responses to new ways of doing business; and opportunities that arise from technology. Policy processes of the Defense Acquisition System involve development of concepts, technologies, and computer-based systems and the demonstration, production, and deployment of these systems. Achieving interoperability leads the list of policies in the Defense Acquisition System. As defined in these processes, interoperability is as follows: The ability of systems, units, or forces to provide data, information, material, and services to and accept the same from other systems, units, or forces, and to use the data, information, material, and services so exchanged to enable them to operate effectively together. (DOD Directives 5000.1, 2000, p. 3; 5000.2, 2001, p. 6) 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Defense Acquisition System today identifies interoperability as a key goal and associates it with standardized data and architectures as a means of assessing and characterizing its success. Additionally, the policy mandates that the acquisition communities adopt a family-of-systems (FOS) management approach targeted towards individual system reviews to ensure the following: . . mutual understanding of key systems in a given mission area; shared decision-making and close cooperation between the requirements, test and evaluation, and acquisition communities; and disciplined control over development and introduction of acceptable interoperable systems” (DOD Directive 5000.1, 2000, p. 3). An Evolving Defense Acquisition System. This policy process system has been continually evolving. Though DOD produced a major update of the acquisition process in 1996, it did not significantly focus on interoperability. Many systems are still using this version of the process. Figure 5 depicts this version. 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Determination of Mission i Need ! Concept Exploration / / MSO t DAB or Acq Exec Program Definition & Engineering & Risk Reduction ■ Manufacturing ,W \ Development i & Operational Support i MSI Production, , Fielding/Deployment A . ♦ DAB or Acq Exec MS II JL ♦ DAB or Acq Exec MS III JL DAB or Acq Exec 4 “Approvals Figure 5. Defense Acquisition System from 1996-1999. Source: This depiction of the Defense Acquisition System was drawn from the original depiction in DODI 5000.2, Change 4, Operation of the Defense Acquisition System, 1996. DAB or Acquisition Executive decision-makers conducted reviews to approve up to four formal Milestones (MS 0, I, II, and III) required for each program. Criteria and approvals were required before programs implemented the Milestone. o o 00 Greater visibility for interoperability was gained in the policy process, when interoperability certification became a mandate in 1997. Even with the mandate, computer-based systems that were procured through the acquisition system still lacked a means of getting certified, because interoperability was not yet a requirement in the Requirements Generation System. Aside from the certification, though, only minor updates to the acquisition system were made yearly through 1999. Figure 6 is a graphic depiction of the milestone phases and their interfacing relationship with Requirements Generation System products and decision authorities using the 1996 version of the acquisition process. Mission Needs Analysis (MNA), Mission Area Analysis (MAA), and Mission Needs Statement (MNS) were the criteria needed to enter Milestone 0. The MNS is the result of the analyses performed in the MNA and MAA. The Joint Requirements Oversight Committee (JROC) approves the MNS. The Defense Acquisition Board (DAB) or Acquisition Executive (Acq. Exec) approves entry into Milestone 0 based on approval of the products. Milestone 0 explores potential concepts that could solve the mission need. 89 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Determination Concept Exploration Program Definition & Engineering & of Mission i Need [ Risk Reduction M M MNA Manufacturing Development Production, Fielding/Deployment & Operational Support AOA Update i,,, "T .. AOA i(lf Required) (If Required) I ORD —Products i } * JROC DAB/ JROC Acq Exec DAB/ JROC Acq Exec DAB or JROC DAB or JROC -4"Approvals Acq Exec Acq Exec Figure 6. Requirements Generation and Acquisition Systems interfaces in 1999. Source: This depiction of the combined Requirements Generation System and Defense Acquisition System was drawn from the original depiction in CJCSI 3170.01A, The Requirements Generation System, 1999. The Requirements Generation System and the Defense Acquisition System depend on each other. This depicts their merger; refer to Figures 4 and 5. Products of one are approval criteria for the other. Approvals are sequentially combined and implemented. (D O Capstone Requirements Document (CRD), Analysis of Alternatives (AOA), and Operational Requirements Document (ORD) are the products needed for JROC product approval and DAB/Acq. Exec Milestone I entry approval. Milestone 1 defines a program to develop a computer-based system solution and identifies risks and means of reducing the risks. The CRD is viewed primarily as a joint document and is required only if the JROC deems it necessary. JROC approval of updated AOA (if needed) and ORD and DAB/Acq. Exec approval will gain a program entry into milestones II and III. During Milestone II, the computer-based system is developed and establishes manufacturing blueprints to be used in production of the system. The system goes into production and is fielded during Milestone III. The Current Defense Acquisition System. Interoperability became more prominent in the acquisition policy process, when information exchange requirements (lERs) and interoperability key performance parameters (KPPs) were mandated in the Requirements Generation System. This instigated a major update of the Defense Acquisition System. The 2001 version is the result of the update. This version defines three milestone phases that lead to the completion of translating user needs to deployed computer-based electronic systems that meet those needs. Figure 7 depicts the 2001 version of the Defense Acquisition System. A summary of the Milestone phases for the 2001 acquisition policy process is as follows: 91 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Milestone A: This is the Concept and Technology Development phase. During this milestone phase, Program Managers (PMs) conduct concept analysis to determine whether concepts/strategies already exist to satisfy mission needs and operational requirements. • Milestone B: This is the System Development and Demonstration phase. During this milestone phase, PMs develop computer- based electronic systems to satisfy mission needs and operational requirements. • Milestone C: This milestone includes the Production and Deployment and Operations and Support phases. PMs go into production mode to produce the quantities of and support for systems needed to satisfy mission needs and operational requirements. 92 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology Opportunities & User Needs* A A A • Process entry at Milestones A, B, or C.** • Program outyear funding when it makes sense, but no later than Milestone B.*** "angle Step o r Evolution to Full vCapability***> IOC FOC Concept & Technology Development System Development & Demonstration Production and Deployment Production and Operations & Deployment Support O Pre-Systems Acquisition Systems Acquisition (Engineering and Manufacturing Development, Demonstration, LRIP & Production) snsainmenr Figure 7. Defense Acquisition System interfaces in 2001. ‘ Technical opportunities and user needs are considered at each Milestone. "Programs may start the acquisition process at any milestone or within any phase within the milestones. "•Programs may delay identifying funding for the program in the outyears until Milestone B. If the program enters the process at Milestone C, funding for the outyears must be identified at that time. ""Programs may opt to complete the acquisition of the system in one step or complete it in increments as partial capabilities evolve. Fielding of the increments begin with the Initial Operational Capability (IOC) and continue periodically until Full Operational Capability (FOC) can be achieved. The four Milestones from the 1996 Defense Acquisition System policy were compressed to three Milestones in the 2001 policy. Programs assert interoperability to decision-makers during reviews, but problems found after these reviews indicate flaws in this assertion. This policy was cancelled 30 October 2002! Interim guidance continued to support the three Milestones of the 2001 policy. Source: This depiction of the combined Requirements Generation System and Defense Acquisition System was drawn from the original depiction in DOD 5000.2, Operation of the Defense Acquisition System, 2001. A V Milestone A: Concept and Technology Development Milestone B: System Development and Demonstration Milestone C: Production and Deployment/Operations Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 8 depicts the current relationship between the Requirements Generation System and the Defense Acquisition System. Program Managers (PMs) are assigned the responsibility of translating user needs to computer-based systems. The ORD represents the requirements for the system. Each ORD represents a single computer- based system. The majority of the systems have a PM per system. This is a key point that promotes the decision-support-system norm that perpetuates standalone stovepipe systems. The PM manages his/her system. The system is subject to the understanding and interpretations of the PM and his/her staff and contractors who are performing the user need translations to the system. Integration and interoperability testing with other systems occurs at the end of the acquisition process but must be completed prior to approval. Systems that cannot pass integration and interoperability testing often receive approval for low-rate-productions (small quantities of systems) pending re-testing after problems are fixed. 94 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology Opportunities and User Needs * ' .. Concept & Technology Development System Development and Demonstration Production and Deployment O Operations and Support Pre-Systems .Systems Acquisition Sustainment .Acquisition (Engineering and Manufacturing Development, Demonstration, LRJP & Production) MNS REQUIREMENTS GENERATION SYSTEM* ORD Relationship to Requirements Process Figure 8. Requirements Generation and Defense Acquisition System interfaces iri 2001. Source: This depiction of the combined Requirements Generation System and Defense Acquisition System was drawn and modified from the original depiction in DOD 5000.2, Operation of the Defense Acquisition System, 2001. *MNS and ORDs are Validated by Requirements Authority or Principal Staff Assistant. They are used as Milestone entrance criteria in the acquisition system. f This graphic combines the Requirements Generation System with the 2001 version of the Defense Acquisition System. Also, refer to Figure 7 on second preceding page. The graphic depicts the three Milestone decision points (A, B, and C) and their alignment with MNS and ORDs. Interoperability was more pronounced in the 2001 acquisition policy but the complexity and prescriptive nature of the policy made it difficult, if not impossible, to use. SECDEF cancelled the policy. CJCS also cancelled the requirements policy on 7 October 2002! J 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Cooperative Engagement Capability (CEC) is a major Navy program that began its system operational test and evaluation (OPEVAL) in 1999. CEC used the 1996 version of the Defense Acquisition System and its updates. The system did not pass its OPEVAL or interoperability certification testing. The problems CEC encountered were with legacy systems. In 2001, the system conditionally passed its testing. Many interoperability problems still existed, but the benefit of capability that it offered was determined greater than the problems it caused. The program received Congressional visibility requiring it to report at least quarterly on the interoperability problems. The major problem was that CEC needed to exchange information with several legacy systems. The systems could not receive, accept, or use information from CEC. The legacy systems were not designed to be interoperable. They are mostly stovepipe systems, but factors such as affordability and value-added inhibit their replacement. As demonstrated by the quantity of Defense Acquisition Board (DAB) reviews and approvals of new programs per year, legacy systems make up the bulk of Navy fielded systems. Normally, the PM has not been responsible for developing/procuring a Family-of-Systems (FOS) or System-of-Systems (SOS). The PM focuses on his/her system, but not much on other systems. When the PM knows that the system must interoperate with another system, the two PMs may establish agreements for information exchange, but the exchange is likely to 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. be reduced to an interface document handed to the engineer developing the system and the testing agent that is likely to simulate data from the other system. The true determination of interoperability generally occurs during the operational testing at the end of development or after the system is fielded. Discussions of changing this norm are just beginning. The Requirements Generation System now has a brief paragraph that states that combined reviews for FOS and SOS may be conducted at the discretion of decision making officials. In the meantime, a PM continues to develop a standalone system based on an individual ORD with high expectations of passing interoperability testing, when the systems that need to interoperate are integrated at the end of their development and undergo integration and interoperability testing. Planning, Programming, and Budgeting System (PPBS) The Programming, Planning, and Budgeting System is a resources management process that enables decision-makers to determine what systems to develop and buy within a five-year period in the future. It does not directly address interoperability in the policy. It does provide procedures for developing a plan, program, and budget. The purpose of the PPBS is to produce a plan, a program, and, finally, a budget for the Department of Defense. The budget is forwarded in summary to the President for his approval. The President’s budget then 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. is submitted to Congress for authorization and appropriation. (DOD Directive 7045.14, 1990, p. 2) The current policy delves into defining programs and systems from the Defense Planning Guidance developed from strategic documents and unspecified decision options and an analysis of missions and objectives as derived from MNS, CRDs, and ORDs. Interoperability aspects are indirectly addressed based on the analysis. The vagueness of the analysis, though, has not helped the interoperability cause. The importance of the PPBS process is that it produces a five-year budget for the planned procurement of DOD and military Services computer- based systems and other products and services. This budget goes forward to become part of the Presidential budget presented to Congress each year. Congress approves the defense part of the Presidential budget, or a modified version, by means of passing the Defense Appropriation and Authorization Bills each year. When Congress authorizes the budget, funding is made available to Program Managers to implement the acquisition system. Program Managers acquire computer-based systems as appropriated and authorized in the bill. Integrating Decision Support System Processes Navy has been proactive in changing from a standalone stovepipe paradigm to an interoperable integrated package of FOS and SOS paradigm. The change that is being explored is based on an early definition 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of the FOS and SOS needed to execute military missions or operations. A mission is a military objective accomplished by means of implementing tasks and activities and optimizing the use of resources. Mission capability is a new term unique to Navy. The mission capability consists of performance characteristics that enable measurement of the degree of success of achieving specific tasks and activities of the mission. Each mission capability consists of its own population of systems that participate in executing the mission capability during military operations. In 2001, Navy named the seven mission capabilities listed in Table 7. The objective was to identify a population of systems for each mission capability and propose the most viable of those for execution as part of the PPBS planning guidance, program proposal, and budget submission for the year 2004. As part of the program proposal, analysis would be performed to determine the systems that needed to be interoperable. To identify an FOS or SOS early in the process, integration of the decision support systems is required. The CRD would have a greater role, and an understanding of overarching needs, as opposed to individual single system-oriented needs, will be a part of the process. The focus would be on FOS and SOS, as constrained by the mission capability. In 2001, Navy used one of the mission capabilities—Time Critical Targeting (TCT)—as a pilot to test the concept. 99 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 7 Navy Mission Capabilities for POM 04 Mission Capability Acronym Time-Sensitive Targeting TST Theater Air Missile Defense TAMD Under Sea Warfare USW Battle Force Command and Control BFC2 Intelligence, surveillance, and Reconnaissance ISR Precision Navigation and Time PNT Homeland Security HLS Selection of mission capabilities occurs yearly. Analysis of them will lead to investment decision recommendations. These recommendations include the systems needed to perform the capabilities. Seven MCPs were identified in FY \^01 for POM 04. Ten were identified in FY ‘02 for PR 05. J For TCT, the ideal implementation of decision support system processes began with a clean slate, because it was an unexplored mission capability. Lacking an overarching document that described military operation that needed the capability, a draft Concept of Operations (CONOPS) document was developed. The CONOPS described how Navy forces wanted to operate to implement the mission capability. The implementation evolved to systems with creation of overarching operational 100 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. architecture that organized the TCT CONOPS and made it easier for engineers to understand and develop systems from it. The architecture described the overall concept, operational nodes, operational information exchange requirements, organizational structures, tasks and activities, and event-driven scenarios. As opposed to the development of a MNS, an interim capstone requirements document (CRD) was developed. The interim CRD prescribed performance parameters and their values for TCT. Existing ORDs were decomposed to determine how they fit within the Architecture and interim CRD. Performance data validating how well legacy and planned systems would satisfy performance parameters was significantly missing. Only with this information could an analysis show whether the systems satisfied TCT performance parameters. Examination of potential systems that potentially fit within the Architecture and interim CRD enabled the determination of the population of potential systems for TCT. Experimentation, surveys, and interviews with PMs or their representatives enabled the refining of the list. Cost, history, and other analyses resulted in the current population. Navy is in the process of validating the list. This is done via analysis. The list includes existing, planned, and future systems. The next step is to initiate new programs; merge, eliminate, or modify existing systems; and determine the programs to eliminate, if they did not make the 101 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. list. The systems also need to be viewed from the perspective of other Mission Capability Packages. They may not be needed to perform the TCT capability but may be essential to another capability. The integration of decision support systems enables a more integrated and interoperable view of systems. Still, the Requirements Generation System reduces the CRD to ORDs, and PMs develop and acquire systems based on the individual ORD, but they are able to better envision other systems with which their system will need to interoperate. The population of 517 Navy computer-based systems that comprised the TCT mission capability package is in Appendix S. Though systems may perform in multiple missions and be included as part of multiple mission capability packages, the 517 TCT capability package appears to equal the number of systems on the ACAT list in Appendix N. Investigation into this similarity is showing that there is not a clear picture of the population of all Navy systems. Nonetheless, there were six MCPs, each with their own population of systems in 2001. In 2002, the TCT MCP was expanded to include all types of targets as opposed to just those that were time-sensitive or time-critical. The name was changed to the Strike MCP. Additionally, there are nine other MCPs. The population of Navy acquisition programs, each of which develops at least one computer-based system, is at least 517. 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Evidence o f interoperability A Population of Computer-Based System Documents. DOD collected, automated, and put the population of all MINS, CRDs, and ORDs for each Defense Agency and military Service on a Web site called Doorsnet. The Web sites are password protected on both classified and unclassified Web sites and are releasable to the general public on a need-to-know basis with appropriate permissions and/or security clearances. Each document is available for review and capture once access is attained. Appendix L provides the lists of all Navy MINS. Appendix O includes the population of Navy ORDs. Appendix P provides the population of Navy unclassified ORDs. Most of the 158 systems represented by ORDs are legacy systems. The CEC system mentioned above was a new system that needed to interoperate with three legacy systems. These four systems represent only 2.53% of the 158 systems represented by the ORDs. Other new systems face the same challenges, with similar impacts on interoperability. Two key points are made here. First is that the solving interoperability with select systems may represent only a small portion of achieving interoperability at acceptable levels. The solution that generates a tremendous impact needs to be systemic. Second is that interoperability with legacy systems is an example of the challenge new systems face. Even if the legacy ORDs included interoperability requirements, the interoperability was applicable to 103 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the systems during their acquisition period. They have not been funded or required to interoperate with new systems. The interoperability onus is on the new system. The ORD list of 317 MNS represents 63% of the 517 Time Critical Targeting Systems. The ORDs on the list are also representative of other mission areas and domains that are not included in the Time Critical Targeting list. This potentially further reduces the percentage representation of ORDs on the list to total ORDs required. According to the decision support systems processes, there is a one-to-one relationship between the development of an ORD and a program responsible for development or acquisition of a computer-based system. In addition to the need for an ORD per program/ system, the processes require that each ORD include an information exchange concept, lERs, and interoperability KPPs. The ORDs on the list do not include these items. Summary—Hypothesis 2 Navy programs that use DOD and Navy processes are not achieving acceptable levels of interoperability. The processes have constantly changed through the years in reaction to lessons-learned reports, new visionary documents, and organization, economic, technology, and political/environmental changes. In a visual demonstration of the frustrations related to existing processes, both the Secretary of Defense and 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Commander of the Joint Chiefs of Staff canceled the processes. Complexity and being overly prescriptive were cited as reasons for the cancellations. Though designated personnel are rapidly working to replace the broken Requirements Generation and Defense Acquisition Systems, it remains to be seen whether the replacement policy will be adequate. As discussed in Chapter 3, legacy stovepipe and standalone computer-based systems are major culprits in preventing the success of interoperability. These systems are not subject to Requirements Generation and Defense Acquisition Systems processes. Yet, due to their numbers alone, they significantly impact the interoperability of computer-based systems that are subjected to the processes. At one point in time, legacy, standalone, and stovepipe systems implemented predecessor processes, but most of the processes did not or scantily addressed interoperability. The analysis in this chapter examined the processes, their products, and systems that used the canceled processes or their predecessors. The processes in this newer policy included interoperability as key performance parameter and information-exchange requirements. The policy also required certifications. Risk, nevertheless, remained in achieving interoperability at acceptable levels, because the guidance in the processes was speculative. What made the authors believe that the systems developed would be interoperable, if the processes were implemented? Did the policy include 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. concepts that were based on demonstrated research? None that were specified and none that worked. MNS, CRDs, and ORDs were products of the Requirements Generation System process. Computer-based systems developed using the MNS, CRDs, and ORDs were products of the Defense Acquisition System process. Plans and funding for programs to develop computer-based systems were products of the Planning, Programming, and Budgeting System. The finding here was that documentation was either missing or disjoint from computer-based systems and, more often than not, treated as merely paper drills to attain milestone approvals. Once approved, documents were not maintained and sustained with the systems. They also lacked coordination with other documents for the same system and even less with documents for systems with which interoperability was required. Interfaces were documented at an individual program level but were not sustained and visible beyond the stovepipe program. The final products from DOD and Navy processes have been stovepipe systems, developed by stovepipe programs and historically have had interoperability problems. Despite changes to the processes over the past twenty years, interoperability has not yet been achieved at acceptable levels. Lastly, the processes have become extremely complex, which makes training, implementing, or even observing them difficult and fraught with 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. opportunities for error. Achieving interoperability is not possible under the current processes. Nor is it yet obvious that new processes being developed will offer solutions to achieve interoperability at acceptable levels. Much research has been performed demonstrating the achievement of interoperability. Whether the new policy incorporates techniques and methods from this research remains to be seen. 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER V ARE “WORK-HARDER” STRATEGIES ACHIEVING IMPROVED LEVELS OF INTEROPERABILITY? Introduction—Hypothesis 3 Hypothesis 3: “ Work-harder” strategies are achieving improved levels of interoperability. DOD and Navy tried many “ work-harder” strategies to achieve improvements in interoperability among computer-based systems. This chapter looks at a few of the strategies and assesses whether they worked, are working, or have the potential of working in the future. The following are the “ work-harder” strategies that are addressed in this chapter: • Significant Resource Invested Towards Interoperability; • Technology-Based Solutions; Use of Common Products; • Standards and Commercial Products; • Incremental Marginal Solutions; • Policy, Policy Updates, and Updates to Policy Updates; • Experimentation and Testing; Infrastructure (Architectures); 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Family of Interoperable Pictures (FlOP); Naval Capability Program (NCP); • Integrated Product Teams and Virtual Organizations; • Transformation; and • Congress. Significant Resources Invested Towards Interoperability DOD and military Services, during the past twenty years, invested significant resources in the form of competent, professional people, funding, and materials to resolve interoperability problems. They addressed the problems through the establishment of organizations, working groups, and processes to investigate and resolve the problems (see Appendix A). These forums responded to interoperability problems by establishing and implementing DOD, Joint (Joint Chiefs of Staff—JCS), and military Service specific policy,3 and instituting greater engineering rigor in development, testing, and oversight of military systems. The efforts resulted in technical, funding, policy, and resource reallocation solutions that have thus far proven to require constant revision, because the problems persist. 3 The following policies specifically address interoperability: Department of Defense (DOD) Directive 5000.1, The Defense Acquisition System, October 23, 2000; DOD Instruction 5000.2, Operation of the Defense Acquisition System, January 4, 2001; DOD Regulation 5000.2-R (Interim), Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs, January 4, 2001; and CJCS Instruction 3170.1A, The Requirement Generation System, 1999. 109 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The significant effort applied to interoperability has not been able to keep pace with the increases in system complexity and system dependency. As system complexity increases additively, system dependency and, along with it, interoperability problems, increase at an even faster rate. Technology-Based Solutions Finding a solution to the interoperability problem has primarily been presented to technical engineers to solve. The implication was that the solution is a technical one, because it involves technologies. Increased awareness and engineering rigor have been applied to military systems and their intrinsic interactions. Engineers, recognizing the magnitude of the problem, opt for single-system solutions of high-visibility computer-based systems. Engineers understand that the difficulty in achieving a technology- based solution to interoperability problems increases quickly with increases in quantities of systems, the complexity involved with the need for those systems to exchange and effectively use exchanged information, and the uncertainties (unintended consequences) of the solutions. While taking bows to small, high-visibility, technical solution victories, many bright engineers found that the nature of the problems remained (some old, some new). Technology alone will not enable the solving of interoperability problems. 110 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology Advancements At the same time Congress was responding to new threats, they were also responding to technology advancements, such as the Internet and the potential of programs to share information and resources. The implication of these leaps in technology was a reduction in cost for the new systems. Congress took money away from programs in order to get programs to share systems information and functions. Even with this reduced funding, programs did not demonstrate sufficient interaction to develop interoperable systems. Though programs had reduced budgets, they continued to maintain their independence rather than collaborating with other programs to take advantage of potential opportunities to share system capabilities. Congress reduced budgets at the three Navy Systems Commands, yet each was able to continue development of mission planning systems. Advancements in technology introduced rapid availability and accessibility of technology products, such as the Internet and other information exchange and information-sharing enabling technologies. The products became readily available via the commercial marketplace. They enabled programs to share information and resources. An implication of these leaps in technology was that new systems using them would cost less and be available for use (diffuse) sooner. Acquiring military systems comprised of these products reduced their life span from what, in the past, has been a 5-20-year cycle to a 2-5 year cycle. Congress, accordingly, 111 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. reduced budgets. Instead of getting better, though, interoperability problems persisted. As an example, the Navy DD-21 program provided the latest technology for destroyer ships. New commercial technologies, though, need to be interoperable with legacy systems. In addition to having interoperability problems with these legacy systems, new commercial technologies were changing too rapidly to be interoperable with each other. Use of “Common Products” Use of “ common products” among the systems is a technology solution that DOD and military Services have to resolve interoperability problems. This is an old theme that dates back to Henry Ford’s assembly line. It worked for him. Ford produced common parts and was able to stamp out automobiles quickly, inexpensively, and successfully. In theory, twin or common computer-based products should be compatible among each other and capable of easily exchanging and using exchanged information. Competition-in-Contracting Act At least two factors, though, inhibited the effective use or reuse of common products. First, the Competition In Contracting Act of 1984 was a primary deterrent. It required that Federal Agencies compete product and service acquisition contracts. Since programs procure systems independently, different vendors are likely to win the contracts to produce 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. systems that must share information. The products they use or develop may not be compatible with those of other vendors. The “Not-lnvented-Here8 3 — N1H Syndrome The “Not-lnvented-Here” — NIH Syndrome is the second factor that inhibited successful use of common products. Managers of programs that develop computer-based systems want the flexibility to change their systems as necessary to attain their individual success-oriented, time-based goals. Common products do not always include all of the functions a program may need in the system. The program does not have the control to change common products to suit their needs. To get control, they invent duplicate functions of their own. Ironically, many of these same programs are using commercial products, such as Microsoft Windows, Microsoft Word, Microsoft Power Point, Microsoft Office, all of which are common commercial products. Nonetheless, use of common products has been forced but is not becoming a prevalent norm. As an example, DON, the Department of Army, and the Department of Air Force received direction to use a common system—the Global Command and Control System (GCCS)—as a means of promoting interoperability among the military Services. Initially, the three military Services gathered to collaboratively resolve differences in the product. Subsequently, each Service decided to adapt them to what worked best for 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the Service rather than the collective military. At the risk of interoperability, they created their own variants of the system (GCCS-Maritime for DON, GCCS-Army, and GCCS-Air Force). Today, the three variants of GCCS are not common and not interoperable. Standards and Commercial Products Another solution focuses on using commercial industry standards and products4 (Osbourne & Gaebler, 1992). The hope here was that, in catering to a general public, the commercial world would produce common affordable interoperable products that are suitable for DOD and the military Services use. If industry standardized technologies costs, all could use without having to create their own. This works for some products, but others contain errors that are acceptable to the general public but not for DOD or military use. Post-Cold-War Impacts on Interoperability When the Cold War ended in 1989, new or modified systems were needed to respond to new or different threats. This increased interoperability problems, because the new systems could not interoperate with many of the older systems that were designed to operate independently and respond to Cold-War threats, even with their modifications. The modified and new systems needed to use advancements in technology and 4 The Competition in Contracting Act requires that Federal Agencies compete Product and Service Acquisition Contracts. 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. do so with fewer resources and dollars—do more with less (Gore, 1993). Congress reduced or eliminated the budgets (reduced funding) of Defense and military programs requiring them to modify or acquire new systems needed to respond to post-Cold-War threats. Resource reallocation was imminent in light of the changes occurring since the Cold War. The DOD Base Realignment and Closure (BRAC) policy resulted in closure of many bases, relocation of organizations, and loss or reallocation of personnel resources, e.g., SPAWAR lost 90% of its personnel when the BRAC mandated that the organization move to San Diego. The realities of doing more with less from the personnel perspective meant the need to rebuild organizations with newly-hired people who came from many other organizations. One would think that, with this new start, it would be easier to move into more interactive relationships with other organizations. Surprisingly, this did not happen. Organizational structure and policies did not change. They continued to promote the independence of systems and programs that developed them. Title 10 of the United States Code mandates organizational structure. Program Managers operating in accordance with this law continued to operate in the manner in which they were trained. This was to develop or acquire computer-based systems autonomously. Although some organizations began participating more in cross-organizational groups, their cultures and structures remained intact. Their systems continued to have interoperability problems. One comment 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. from a senior executive at SPAWAR was as follows: “It’s surprising that, even though we lost 90% of the people during BRAC, the culture remained” (Arkin, 1999). Incremental Marginal Solutions Recognizing the need for authoritative direction to support interoperability by means of technology and funding changes, senior leaders initiated and signed policy to provide that direction. A major acquisition system is valued at greater than $355 or $30 million. The dollar amount depends on who is the decision-making authority. The full extent of interoperability in the Defense Acquisition System Regulation read as follows between the years 1996 and 1999. (The policy was updated four times during this period.) Compatibility, interoperability and integration are key goals that must be satisfactorily addressed for all acquisition programs. These goals shall be specified and validated during the requirements generation process. Satisfaction of these requirements shall be addressed throughout the acquisition life cycle for all acquisition programs. The DOD JTA is mandatory for all emerging systems and system upgrades. The JTA applies to all Command, Control, Communications, and Intelligence (C4I) and automated information systems, and the interfaces of other key assets (e.g., weapons systems, sensors) with C4I systems. The Component Acquisition Executive may grant waivers to the standards in the JTA with the concurrence of the USD (A&T) and the ASD (C3I). Interoperability of C4l Systems shall be in compliance with DODD 4630.5, DODI 4630.8, and CJCSI 6212.01A. (Clinger Cohen Act and Paperwork Reduction Act). (DOD Regulation 5000.2R, Sec. 4.3.9, 1999) 116 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Note that interoperability is a goal but not a requirement. It is a goal of each and every Program Manager who is responsible for developing each system in accordance with the regulation. Yet, the regulation did not include a definition for interoperability. It also left the specification of the goal to another policy—the Requirement Generation System. Fulfillment of the goal was also left to Program Managers. The JTA referenced in the quote is the Joint Technical Architecture. System standards and protocols for the military Services are specified in the JTA. The thought is that, if all systems adhere to the same standards and protocols, they will be compatible and decrease the risk of interoperability problems. Systems do not use the same standards. At the risk of oversimplification, the JTA accommodates multiple standards, multiple protocols, and multiple systems used by multiple programs in multiple military Services, many of which, at some point, try to interact and result in continued interoperability problems. The Under Secretary of Defense for Acquisition and Technology (USD [A&T]) and the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD [C3I]) are decision-making authorities for designating, approving, and delegating approval authority for major programs. The Component Acquisition Executive is a decision-making authority who, when delegated with that responsibility, approves milestone 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. decisions (permits programs to start working in certain areas, e.g., system development, of the program). Policy, Policy Updates, and Updates to Updates DOD and the military Services began establishing policy to address interoperability in the mid 1980s. Since that time, a steady stream of updates has been forthcoming as a reaction to continuing interoperability problems. Policies changed each year until 1996, when the Commander of the Joint Chiefs of Staff (JCS) canceled policy, and the Secretary of Defense threatened to cancel policy. Updates and updates to updates were not solving the problems. Complexity had taken over policies making them impossible to implement. Additionally, due to the period of time needed to acquire and test systems, the results of implementing some policies may not be known for another five to ten years. A few reasons that policy became so complex was that it incorporated lessons leaned from previous policy, corrected known deficiencies, and incorporated visionary goals and objectives. Policy also establishes processes and templates for acquisition, budgeting, and generation of requirements that are based on the experiences of the authors rather than on documented research. The authors may use fragments of process models (such as systems engineering, systems analysis, training, et al.) that may have documented research supporting it, but a model that specifically 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. addresses interoperability does not exist, and each author interpreted models differently. Chapter 7 examines DOD and DON policy in the context of a diffusion model. This diffusion model is backed by documented research and may offer a means of addressing interoperability. Research shows that innovations diffuse more successfully with appropriate interaction of elements in the model. The Diffusion of Innovation, by Everett Rogers (1995), provides several examples demonstrating the interactions of the elements. Requirements Generation System Policy The Commander JCS has responsibility for Requirements Generation System policy. Processes in this policy focus on identifying the needs and requirements of the warfighter. As discussed in Chapter 4, this policy, though updated frequently, operates on identification of single purpose solutions. Though needs are identified, they address only a small part of an overall mission. This makes it difficult to determine whether or how the computer-based response to the need will impact the overall mission. The Requirements Generation System process names the fleet or their representatives as responsible for identifying their needs and requirements. These are documented in Mission Needs Statements (MNS), Capstone Requirements (CRDs), and/or Operational Requirements 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Documents (ORDs). Interoperability is one of the requirements specified in the CRD and ORD. Interoperability has remained an issue, even with this process in place. Defense Acquisition System The Defense Acquisition System requires that Program Managers acquire computer-based systems that meet the needs and requirements stated in documents developed under the Requirements Generation System. This system has evolved since the 1980s. Beginning in 1996, policy for the system changed yearly until 2002, when it was canceled. Interim guidance has been issued until new policy can be developed. Recognizing shortfalls in the Defense Acquisition System, DOD initiated augmenting interoperability policy. DODD 4630.5 (1992), DODI 4630.8 (1992), CJCSI 6212.01A (1992), Clinger-Cohen Act (1996), and Paperwork Reduction Act (1995) are all policies that address interoperability. Yet, the problem persists. Policy makers used a “ satisficing” approach to include lessons-leamed and experience, as opposed to models that were supported by research data to establish interoperability related policies (Simon, 1997). The result has been continual policy rewrites and modifications. As interoperability problems grew, the more recent policy rewrites and revisions have more aggressively coordinated and addressed 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. these problems. Still, policy makers failed to use proven documented research to support policy-making. Interoperability DOD developed Interoperability policy in 1985 and required that requirements documents include a section on supportability and interoperability. Few requirements documents actually discussed interoperability in that section, focusing more on supportability. The policy was updated in 1992, with little impact on discussion on interoperability in requirements documents. In January of 2002, another update of the policy was issued. Requirements documents began including interoperability as a requirement in 2000 (CJCSI 3170.01B, 2001). Appendix G provides a copy of the 1992 policy directive for interoperability of C4I systems (DOD Directive 4630.5, 1992). Appendix H provides a copy of the updated policy (DOD Directive 4630.5, 2002). Appendix I provides a summary of the 1999 policy directive that includes procedures for implementing the interoperability policy (DOD Directive 4630.8, 1999). Certification: CJCSI 6212.01B The Joint Chiefs of Staff Compatibility, Interoperability, and Integration Instruction requires interoperability certification for each computer-based system (CJCSI 6212.01B, 2000). The Defense Acquisition System requires this certification as one of the criteria for approving the acquisition of a 121 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. computer-based system. Program Managers use this certification as proof that their systems are ready and eligible for installation and integration in the D -30 Process. CINCLANTFLT/CINCPACFLT Instruction 4720.3A The CINCLANTFLT/CINCPACFLT instruction 4720.3A is intended to provide a process to ensure the highest degree of warfighting capability and interoperability that is adequately supported. The Fleet CINCs, CINCLANTFLT or CINCPACFLT, wanted improvement and certification of the technology products and support they were getting from the acquisition community. The process addresses the initiating, approving and scheduling of computer-based system installations and upgrades. Certifications are implemented via the Deployment Minus 30 Process described below. Deployment Minus 30 Process (D -30 Process) The D -30 Process is the process for initiating, approving and scheduling Battle Force combat systems and C4I installations and upgrades. It outlines a thirty-month schedule prior to deployment of a battlegroup to install or upgrade computer-based systems for ships or other platforms (aircraft, submarines, et al.) that are part of the battlegroup. One significance of the D -30 process is that it is the first time that all of the systems available to fleet users are integrated and tested together to determine their synergy and interoperability. D -30 occurs towards the end 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of the acquisition process. This means that the systems involved in the testing have already been developed in a stovepipe environment. A pre requisite for inclusion of a system in the process is the requirement for test certifications. This helps, but interoperability problems are still found during D -30 Process testing. Interoperability testing during the D -30 process begins 13 days before deployment of the battlegroup. If interoperability problems are found, they are logged as limitations. Finding a serious interoperability problem 13 days or less before a system deploys with the battlegroup does not contribute to the achievement of acceptable levels of interoperability. The log of limitations, though, provides warfighters with information that alternative means of exchanging information are needed. The resolution of interoperability problems needs to occur before the D -30 process begins. D -30 should be the final check of already-proven interoperability. Planning, Programming, and Budgeting System (PPBS) Policy for the PPBS system has not changed since 1992 (DOD Directive 7045.7, 1992). Implementation policy has not changed since 1992 (DOD Directive 7045.14, 1992). The objective of this policy was to provide guidance for funding programs and their systems over a five-year period. This involved products for each of the three PPBS phases— planning, programming, and budgeting. 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The PPBS is directly related to the Requirements Generation System and Defense Acquisition System. Under the planning phase, vision documents are developed and assessed to determine if deficiencies exist in the ability of the nation’s forces to execute military operations. The Requirements Generation System generates documents that identify the deficiencies and determines whether computer-based systems are needed to eliminate them. When the planning phase identifies that a new system or an upgrade to an existing system is needed, a program is identified to acquire the system or upgrade. The identification of these programs is part of the programming phase. The determination that a program is needed to satisfy a need links the PPBS to the Acquisition System, where computer- based systems are procured and fielded. Budgeting is the final phase and occurs when assessments are performed to determine the affordable mix of computer-based systems (or other acquisition deliverables) that are needed to perform military operations. Today’s national defense economic, technology, social, and political needs have caused senior leaders to re-think the methods used to equip warfighters with tools needed to win. These leaders are calling for a transformation. Vice Admiral Cebrowski (1998) referred to this as a “Revolution in Military Affairs” (RMA). A discussion on transformation as a “strategy” is addressed later in this chapter. The Chief of Naval Operations’ response to the old methods implemented via the “ decision support systems” 124 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. has been to move towards a new process—the Battieforce Capabilities Assessment Programming Process (BCAPP). This process is also addressed as one of the “ strategies” in this chapter. CNO also established a policy to begin to address the BCAPP process. The BCAPP is still being established. An initial policy developed to jumpstart the process is the Alignment and Responsibility of Navy Requirements Generation and Resource Planning Policy (OPNAV Instruction 3050.23, 2001). The purpose of this policy is as follows: “. . . to modify the Department of the Navy’s Planning, Programming, and Budgeting System (PPBS) to focus on capability-driven warfighting requirements.” The BCAPP is an end-to-end process that brings together the key “ decision support systems” within an integrated architecture framework. Experimentation and Testing Fleet Battle Experiments (FBEs) Fleet Battle Experiments (FBEs) are conducted to test new concepts and Future Naval Capabilities (FNCs). Currently, the experimenters select a theme, and volunteers come forth with potential products that will validate the concepts in concert with the theme. There is a disconnect, though, between many of the products participating in the experiment and their ability to be fielded, if the experiment is successful. This is due largely because the experiments are not part of the requirements and acquisition processes that 125 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. determine the products that should be fielded. FBEs are primarily Naval experiments. Joint Warrior Interoperability Demonstrations (JWIDs) Joint Warrior Interoperability Demonstrations (JWIDs) are similar to experiments. Participants, who are usually from research and development organizations or programs, demonstrate their concepts for improved interoperability capability. JWID, though, offers the promise of “ gold nugget” status, if the products are part of the acquisition process and have reached a level of maturity to add value. “Gold nugget” status means they receive funds and support in moving their programs forward. All of the military Services participate in these demonstrations. Unit and Integration Testing Unit and integration testing occurs as the system is being developed—usually at the development contractor facility. Government acceptance testing is performed also at the contractor facility to demonstrate readiness of the system for delivery to government. Testing is performed in accordance with a test specification that demonstrates that the system satisfies requirements specified from the ORD. Interoperability requirements are either simulated or left to development testing. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Development Testing After delivery from the contractor, the Program Manager generally delivers the system to a Government laboratory to perform development testing. The laboratory uses a test specification to demonstrate that the system satisfies requirements. Interoperability testing is generally simulated due to unavailability or non-access to the other systems. Operational Test and Evaluation (OPEVAL) OPEVAL is performed by the Operational Test and Evaluation Force (OPTEVFOR), a special test organization that reports directly to the Secretary of Navy (SECNAV). OPTEVFOR acts independently, but with the cooperation of Program Managers, to test all computer-based systems that are planned for use by Naval warfighters. The intent of the testing is to assure that the systems will perform as specified during military operations. OPTEVOR provides an independent report on the operational readiness of computer-based systems to support warfighters in their missions. Interoperability Certification Testing The Joint Chiefs of Staff instruction, Defense Acquisition System, CINCLANTFLT/CINCPACFLT process, and D -30 Process require interoperability certification testing. The Joint Test and Interoperability Command conduct this test. All new acquisition systems are subject to the 127 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. test as one of the criteria for the approval of systems acquisition and development. This is a new mandate, 2000, for programs. Infrastructure Michael Dertouzos (1997) expressed the need for an infrastructure as the key to effective information exchange and use (pp. 15-21). He discusses this infrastructure as follows: . . . a shared infrastructure made up of all the information tools and services that enable its many activities to function smoothly and productively. This infrastructure will be distributed and owned by all of us, not a single organization. It will move the data, voice, text, and X-Ray images . . . by negotiating with phone, cable, satellite, and wireless carriers and with the kiosk and computers.. . . (pp. 15-16) This infrastructure would include computers, networks, and other information tools and services. These are basic tools and services needed to access, use, and exchange information. DOD and the military Services are acting in concurrence with Dertouzos in their implementation of the Information Technology Management Information Reform Act (ITMIRA—also referred to as the Clinger-Cohen Act). ITMIRA mandates development of an Information Technology (IT) architecture to provide such an infrastructure. Additionally, the Assistant Secretary of Navy for Research, Development, and Acquisition established an organization (Program Executive Office for Navy and Marine Core Interoperability (PEO [NMCI]) to develop such an infrastructure for Naval United States land-based interchanges. An 128 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. infrastructure for afloat, air-based, and foreign soil land-based information exchange still awaits a potential solution. Architectures and Their Obstacles Architectures Architectures provide the means of visualizing and documenting how computer-based systems share information. They are graphic, alphanumeric, and physical templates that provide a means of organizing information, data, and systems. DOD and Navy through the years produced large amounts of data about computer-based systems used by warfighters. This information is scattered among the programs responsible, past or present, for acquiring computer-based systems. No central repository exists from which to extract this information. As proven during the Year 2000 (Y2K), effort to fix date-related computer problems— collecting information from individual programs— is massively difficult and expensive. Because of this, organizing this information is difficult. Organizing information and data about systems provides a means of accessing, displaying, and assessing the information to determine the benefits, problems, and potential grouping options of the systems. In what military operation(s) is a system needed? How does the system contribute to capability objectives or requirements within missions in these operations? How does the system interact with other systems to achieve capability 129 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. objectives and requirements? If data about computer-based systems were organized into an architecture in the form of a centralized data base, these questions could be more easily answered. This data base also supports rapid and common generation of graphic depictions of systems participating in potential missions, including the depiction of connectivity feasibility among the systems. A central data base of system information is the architecture vision. Implementation of the vision, though, has its obstacles. The Defense Acquisition System mandates the development of architectures for new computer-based systems. DOD produced a framework document to provide format templates in the form of architecture views and examples to populate the templates. This DOD C4ISR Architecture Framework document defines an architecture as: “ The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time” (IEEE and DOD Framework document, 1997). Obstacles in Populating Architectures Articulating measurable objectives and what needs to be done is the first obstacle. This is achieved by understanding military operations and what the warfighters need to do. Identifying viable missions and the systems that need to participate in the mission is one of the easily stated, but difficult to accomplish, steps to this understanding. Without an articulation of objectives, the Cheshire cat’s response in the following discourse will apply: 130 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “Cheshire Puss,” she began, . . . “ Would you tell me, please, which way I ought to go from here?” “ That depends a good deal on where you want to get to,” said the cat. “I don't much care where,” said Alice. “ Then it doesn't matter which way you go,” said the cat. (Carroll, n.d., Chapter 6) Only when the mission is clear and well-articulated can an architecture form a foundation for how systems perform the mission. Since Navy already has systems available, a logical decision is to identify systems that potentially perform the mission. This can prove to be an immense undertaking, depending on the size and understanding of the mission. Few people or organizations have achieved common understandings of missions. If architectures do not have this a part of as set of unified ground rules, they will be just as “ stovepiped” as the systems that are not interoperable. Populating architecture templates is strengthened through analysis. The difference between a sound architecture and a weak one is the degree of engineering, quantifiable analysis, and validation used to collect data to populate the architectures. Navy typically uses subject matter experts (SMEs) to collect and verify this information. SME data is couched as “best available judgment.” Validation of SME data is at times challenging, because different SMEs may provide different data, depending on their personal experiences. Quantitative analysis provides documented, 131 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. repeatable conditions and data. Populating architectures result in visual and descriptive data. Architectures, like computer-based systems, have the potential of being “stovepipe” depictions of information. This has been demonstrated by Program Managers who are populating architecture templates with data about their computer-based systems. These Program Managers interpret the templates from their own perspectives. In many cases, the resulting stovepipe architectures fail to or inadequately address the missions in which the systems will be used. This is another obstacle. Populating architectures for legacy systems is a third obstacle. Mandates for publishing architectures have only been required for acquisition systems since 2000. This excludes legacy systems. Without legacy system architectures, descriptions and functions of legacy systems are difficult to assess, verify, and/or validate. This aggravates a fourth obstacle—only a limited number of systems have context or guidelines, and those guidelines are not standard across missions in which they operate. Context and guidelines are in the form of operational concepts that establish boundaries for the missions in which systems will be used. The operational concept describes how military forces operate in the mission. Without operating boundaries, decision-makers cannot determine the metrics against which the effectiveness of systems that participate in the mission are measured. Since legacy systems were developed before boundaries were established, 132 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. measuring their fit and effectiveness in missions is challenging. This information, though, is needed to populate the architectures. Descriptions of interactions between systems used in missions or operational settings are also obstacles. Who needs the data? What systems need to exchange data with other systems? The Joint Command and Control Ship program identified greater than 10,000 information exchange requirements during the architecture development phase of the program. Is this accurate? How does an architecture assessment certify and validate the need for this many interactions? Identification of hardware and service tools that force adherence to the rigidity of consistency and standards is an obstacle. In 1987, Navy followed the Air Force lead in adopting the Raytheon Corporation’s Advanced Color Workstation (ACW) as their standard desktop computer. Since it did not quite meet their needs, a Navy organization modified and renamed the ACW the Color Work Station (CWS). Two years later, the same Navy organization decided that the CWS did not fit their needs and acquired a different commercial desktop computer, the Tactical Advanced Computer (TAC) Workstation, as their standard. Another organization determined that this desktop did not meet their needs and acquired yet another desktop, the Q-71, as their standard. Navy is proliferated with “standard” hardware and service tools that are incompatible and inhibit 133 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interoperability. Architectures have not yet established a set of standard tools that accommodate the interaction between its incompatible “ standards.” The final obstacle discussed here is the time and money it takes to perform the engineering analysis to get verified or valid information. Lacking this information, architects are using isolated, unverified, non-validated SME data to populate architectures. If this information is used to create the architecture infrastructure, trust in the validity of the central data base will always be suspect; but to wait for the completion of analyses means more delay in establishing a much-needed architecture infrastructure. This is a serious investment decision for senior authorities. What degree of analytical rigor do they want in their decision-making and at what cost? Analytical Rigor in Architectures In summary, architectures provide a means of documenting information about systems, but institutionalizing and certifying validity of the architecture is necessary to assure the rigidity of accuracy, consistency, and standardization. Architecture descriptions, networks of system interactions, and standardizing tools form the basis of institutionalizing an architecture infrastructure. This can only be achieved through the rigor and cost of analysis based on formal authoritative data. Attaining this infrastructure is costly, both in terms of time and money. Once established, though, the front-end costs may prove worth the investment in later years. 134 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Overarching Central Data Base Institutionalizing an Architecture Infrastructure An architecture infrastructure preserves the integrity of an architecture by documenting it in the form of an overarching central data base. This data base is user-friendly, accessible, yet certified and controlled, and is based on inputs from verified and validated authoritative sources. Data is only meaningful, if it can be used, stored, accessed, updated, and reused. Historically in Navy, data has been gathered, studied, used, and even stored. The storage, though, has been arbitrary and retained only in the files of individual programs. It has not been available in a massive central repository for Defense- or Navy-wide decision-making. DOD and Navy do not have a single controlled central data base in which information about any of its systems can be described. Disjoint data bases with systems information are scattered among multiple organizations, contain limited and selective information, and are relatively invisible to broad DOD and Navy communities. The Navy’s financial data base is an example of a disjoint data base. It contains financial as well as descriptive information about programs for many systems but is specific to the financial community. Considerable effort must be made to link information from this data base to information about the performance of the systems or to missions in which the systems operate. The data base is not unified or connected with information about systems relative to the missions in which they operate. 135 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Another huge Navy data base is the Automated Mission Planning System (AMPS) data base. It is a controlled accessible data base but contains only pieces of information about systems and is not linked to other data bases that contain information about these same systems. Nor is all of the data in this data base certified or validated. A certified, controlled, user-friendly central data base that provides access to a wide range of authoritative source information is needed. A data base is only as good as the data that goes into it. Certification of the data base assures the quality, verification, and/or validity of its information. Control maintains and sustains the certification. User-friendliness facilitates continued use of the data base. Decision-makers could quickly and easily establish or identify families- and systems-of-systems that have the ability to perform or support military operations, if this data base existed. Lacking such a data base, organizations that need information about systems continually recollect the same information, introducing errors as they do so. If this information is used to make investment decisions about systems, the answer changes relative to the errors introduced by data collectors. Data collected in a central data base must reflect whether each Navy computer-based system contributes to the capability objectives and requirements of a mission. Capability objectives are desired and measurable effects within a military mission that are accomplished through 136 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the execution of specified actions, as identified in a warfighting plan. Requirements specify the metrics of capability objectives. Interoperability Aspects of a Central Data Base Graphic architecture depictions can provide visualization about the way in which systems need to connect. A central data base can provide greater fidelity about connectivity among systems. Connectivity, though, is but a single aspect of interoperability. It gives systems a means of potentially exchanging information. In addition to assuring that systems can connect, systems that need to exchange information must also be able to understand each other. Understanding among computer-based systems comes from information-sharing or accurate interpretation of information. Architecture graphics fall short in depicting these aspects of interoperability. Information-sharing among systems is difficult to accomplish. Programs have autonomy in their means of developing, acquiring, and/or processing information. They prefer to retain control of any processing and data associated with their system(s). This results in overlaps of information among systems, because Program Managers do not interpret requirements or data in the same way. Nor do they get the same answers from their interpretations. Interoperability suffers. Exchanged information may not have the same meaning from one system to the next. A central data base does not necessarily prevent this from happening. It does make the 137 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. information available and accessible so that assessments and analysis can disclose potential problems and deficiencies. Example of Architecture Assessment An example of an architecture assessment is the determination of whether new systems are needed or old systems should be deleted. This is accomplished by a comparison between the mission tasks or actions and the systems needed to accomplish a mission. If systems are not achieving capability objectives within a mission, new or upgraded systems may be needed. If multiple systems are performing the same actions, some of those systems may not be needed. Theoretically, warfighting operators who document what they do in a standard format create mission tasks and actions. DOD standard formats are in the form of Universal Joint Task List (UJTL). Navy-unique tasks and actions are in the form of Universal Navy Task List (UNTL) and Navy Mission Essential Task List (NMETL). Though created by the warfighter, these task lists are not used in doctrine or operational concepts. This creates disconnects between the warfighter’s description of what they do and the doctrine and operational concepts that describe what they are supposed to do for specified missions. These descriptions must be inextricably linked. Otherwise, verifying or validating the architecture description of these tasks is difficult or impossible. 138 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. System architects and engineers often translate mission actions into functions to capture greater levels of detail about the systems. This translation is a process of decomposing the mission actions to specific actions or functions that systems can achieve. For new systems, architectures can arbitrarily create new names for decomposed mission actions, if they are not already used by other systems. The architecture assessment identifies whether functions of systems are already used. Engineering Analysis for Architecture Data Base Verification and Validity Engineering analysis of computer-based systems is needed to determine if, how, and how well system(s) contribute to capability objectives and their requirements in a mission. Engineers use authoritative engineering knowledge and processes to examine in detail systems and how they interact to accomplish missions. They verify and validate their findings through authoritative sources of information, SME experience, testing, and experimentation. Testing is an essential part of engineering analysis. Only through testing or use of systems in operational settings can data be validated. SMEs who either witness testing or have experience with a system’s operational use can verify data. SME verification, though, is still based on knowledge of the testing or operational use of systems. Some testing is accomplished through use of systems in experiments. Testing and 139 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. experimentation are also documented as part of studies about systems. When this information is formally approved and published, it may be deemed as an authoritative source. Most programs learn that, to avoid re-introducing problems or errors in systems and data that have been fixed, they must adhere to configuration controls. Configuration control is the establishment of a baseline product that does not change, unless formally approved by a configuration manager. Today’s problem is that each program has its own configuration manager and controls. Much is known about their own program and systems, but very little is known about the systems of other programs. Configuration control is important to the validation process. Analysis uses specifications of operational systems. The degree of accuracy of the analysis depends on the accuracy of the system and performance specifications used in the analysis. Configuration controls allow for repeatable testing, if errors are made. Developing a Central Data Base Architectures, architecture assessments, and engineering analyses are needed to develop a central data base. Architecture assessments capture the engineering analysis in specified architecture formats. Architectures design and provide formats and guidance for capturing information. Engineering analysis examines problems with existing information and can provide information leading to the population or update 140 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of architecture formats with verified or validated information. The verified or validated information is captured in a certifiable, controlled data base. Architecture assessments use this information to determine its significance or importance to the context in which it is used. Assessments Assessments and analysis of information in a central data base potentially provides decision-makers with sufficient understanding and analytical rigor to make better decisions about families- and systems-of- systems operating within mission areas. These assessments can potentially identify requirement, processing, and information gaps and overlaps among systems. They can identify potential locations of systems (ships, aircraft, or land sites), system interfaces, and, after additional engineering analysis, effectiveness of systems. If the data base is extended to include operational, logistics, training, and financial data about the systems, a broader set of assessments can be accomplished. The assessments primarily consist of spreadsheet comparisons of information about the systems in the data base. Further engineering analysis may be needed to supplement these comparisons. The data base does, however, allow the comparisons to be performed quickly and uniformly. 141 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A variety of assessment and analysis methods may be used to collect the data for the comparison. Architects build architecture models to describe generic system functions. They use spreadsheets to compare specified actions to the system functions identified in the model. System engineers decompose systems into functions and may use sophisticated engineering models for the comparison. Others use the knowledge and experience of Subject Matter Experts (SMEs). Regardless of the methods used to assess data, all are in search of the same information—do the systems contribute to capability objectives? Systems Engineering Analysis Systems engineering analysis quantitatively answers the question: Do, how, and how well do systems contribute to capability objectives in missions? Since, by definition, capability objectives can be measured, the obvious analysis to be performed is to test, simulate, or operate the systems that contribute to the capability objective. Performance data can be collected during the test, simulation, or operation to measure the collective contribution of the systems. Comparing the results to the capability objective measurement provides the performance quantity achieved relative to the quantity needed. This is easily stated but not easily accomplished. The Defense Acquisition System mandates that all systems undergo development, interoperability, and operational acceptance testing. These 142 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. tests identify the degree to which an individual system satisfies interoperability and performance, as stated in test specifications. Though the tests include operational evaluations, currently, neither they nor the test specifications are linked to a clearly defined military operation, missions, or capability objectives. The interoperability link is based on simulated data, unless the system is physically available during the test. The D Minus 30 Process mandates additional interoperability testing. This, also, is not linked to missions or capability objectives. The precept for deploying systems appears to be: Give them whatever you’ve got regardless of mission and capability objectives—quantity has gotten us through in the past. Results of tests, as they are currently designed, provide some performance information about individual systems. The applicability of this data to answer how well systems contribute to capability objectives raises questions as to its viability. Experiments and demonstrations potentially offer another means of gathering performance data. The intent of experiments and demonstrations is to show how advanced technology concepts may benefit warfighters. Organizations responsible for experiments or demonstrations may use these concepts in systems, but the systems do not necessarily correspond to planned or specified military operations, missions, and capability objectives. The systems used in experiments and demonstrations that incorporate technology concepts are usually disjoint and unstructured from “ decision 143 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. support systems” processes. As such, measuring performance data of these systems does not have analytical value, unless the systems contribute to specified military operations, missions, and capability objectives. Models and simulations purport to provide another way of performing analysis to show how well systems contribute to capability objectives. Models and simulations are very like data bases in terms of needing valid performance data about individual systems before they can show whether and which systems collectively contribute to capability objectives. This is probably the more costly means of determining the contributions. Also, erroneous information in the model results in faulty modeling results. Infrastructure Summary DOD and Navy have many organizations working in the right areas to achieve interoperability with a sound infrastructure. They are currently disjoint and unstructured. The laboratories working on experiments want to select their own experiments. Only a few are working with other organizations to synchronize efforts. Experimentation offers a great opportunity to extract much-needed performance data about families- and systems-of-systems that contribute to capabilities and capability objectives. The Fleet claims responsibility for operational requirements but does not dedicate resources to develop overarching concepts that encompass their military operations, missions, and capability objectives. The Systems 144 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Commands work diligently to protect legacy, upgrade, and new systems whether or not they contribute to capability objectives. And many others are producing products that may be needed, if combined with the other organizations, but that are merely additional stovepipe attempts to solve the interoperability problem until the organizations and their products become interoperable. DOD and the military Services are currently undergoing massive restructuring and work realignments to overcome many of the obstacles that are inhibiting an integration and interoperability infrastructure. Organizations are now avowing to cooperate with each other. Cooperation among organizations is a key factor to gaining the understanding needed to build architectures with sound engineering and analysis data in them. Such promises have been made in the past. The time is right. Momentum for cohesion among organizations is building. This may be the answer. Or it may not. Family of Interoperable Operational Pictures (FIOP) The Family of Interoperable Operational Pictures (FIOP) is an initiative to solve the interoperability problem. The Joint Requirements Oversight Council (JROC) directed that the overarching goal of FIOP was to provide an all-source picture of the battlespace (Joint Requirements Oversight Committee memo, 2000). The quote from this memo is often used in briefings presented by Under Secretary of Defense for Acquisition, 145 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technology, and Logistics (USD [AT&L]), Director of Interoperability, Dr. V. Garber and is provided in Appendix T. Dr. Garber has overall lead for the FIOP initiative. He acknowledged that inadequate interoperability is today’s problem and responded with FIOP as its conceptual solution (Garber, 2000). FIOP encompasses a highly flexible, interoperable, integrated approach to sharing information for creation of maritime, ground, air, and space pictures to achieve battle management. Though Air Force has the systems engineering lead for FIOP, all services have lead representation on the FIOP team. Additionally, these military services or a military command leads one or more of the maritime, ground, air, and space picture initiatives. Navy leads the Single Integrated Air Picture (SIAP) and FORCEnet initiatives parts of FIOP. Implementation of all the parts is based on spiral development and is intended to solve known prioritized interoperability problems over time with the fix for each part centripetalty spiraling around interoperability. Dr. Garber’s FIOP priorities are scheduled through the year 2009 with most of them planned for completion by 2008. The JROC approved funding for the ones scheduled in 2002 and 2003. Coincidentally, or probably not, the year 2008 is the time frame given to USD (AT&L) by Deputy SECDEF Paul Wolfowitz to solve the interoperability problem of legacy systems. If successful, FIOP could be Dr. Garber’s response to the honorable Mr. Wolfowitz. 146 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The thrust behind the FIOP initiative is a set of the most pressing known interoperability problems. Though proactive and results-oriented, a question of context underlies the FIOP initiative. What is the basis for determining that fixing these problems will provide adequate interoperability? The context rests with a question of whether the FIOP initiative suffers from Lieutenant Colonel Anthony Faughn’s discussion of band-aid fixes (Faughn, 2002). Faughn draws attention to continued interoperability problems after 20 years of solutions to interoperability problems. He suggests that, historically, solutions treat symptomatic problems but fail to solve the overall problem. The difference between the FIOP interoperability problems and historical interoperability problems is that the breadth of the scope for FIOP problems and solutions are much larger. Problems in the past were isolated to interoperability between individual system and another or other systems. FIOP focuses on the most pressing known interoperability problems identified in families-of-systems across joint and military service organizations, their systems, their data bases, and missions in which systems and data bases serve. The expansion in scope may solve a greater number of interoperability problems, but a strategy for institutionalizing, preserving, and repeating a process to eliminate or diminish the problems is not yet evident. Nor is it clear that the planned solutions will actually solve the problems. 147 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Among all the “ work-harder” strategies, though, FIOP has a major focus on legacy systems. One of their objectives is to force their modification or eliminate legacy systems that will not or cannot be modified. Other interoperability strategies view legacy systems outside of their jurisdiction or too hard to resolve. Legacy systems are the primary culprits, though, of the most pressing known interoperability problems. Will solving the most pressing known problems enable Dr. Garber to say that DOD no longer has inadequate interoperability? Is the approach to solving these problems sound enough to be considered an overall interoperability solution? Or are DOD and the military Services in for another 20 years of interoperability problems even after solving the top ten problems? The FIOP initiative is being implemented. Today, though, the FIOP strategy for providing long-term solutions to achieve adequate interoperability problems focuses only on the JFCOM known top ten problems. The effectiveness will be demonstrated in 2008 and beyond. Naval Capabilities Program (NCP) The Naval Capabilities Program had its origins in the Navy as the Battle Force Capabilities Programming Process (BCAPP) and the Mission Capability Package (MCP) process. The names change when it is determined that the scope may be inadequately defined or when a new authority deems it necessary. Nevertheless, the intent is to field capabilities- 148 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. based systems that result from investment decisions based on analytical rigor. Vice Admiral Arthur K. Cebrowski introduced the term “Mission Capability Package” in a magazine article in 1998 (Cebrowski & Garstka, 1998). A year later, a Navy Captain, John Yurchak, defined the term MCP. Captain Yurchak was involved in the Navy’s Integrated Warfare Architecture (IWAR) process that performed studies on focus areas that were considered trouble spots within specified high-level mission architectures. He began developing a process to better address the use of architectures to provide a foundation for investment decisions. Simultaneously, the Chief Engineer (CHENG) designated by the Assistant Secretary of Navy for Research Development and Acquisition (ASN [RDA]) was developing a process to improve integration and interoperability during the acquisition phases. ASN (RDA) CHENG had four primary directorates—architectures, engineering, collaborative engineering, and standards, policy, and guidance. Their objectives were to establish an overarching technical foundation and guidance for the acquisition community to achieve integration and interoperability among its systems. Captain Yurchak and ASN (RDA) CHENG teamed in the development of the process. Subsequently, the Chief of Naval Operations (CNO) established an Operations Navy (OPNAV) Warfare Integration Organization (N7) with responsibility to embrace, continue development of, and implement 149 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the process. ASN (RDA) CHENG teamed with OPNAV to provide architecture assessments and engineering analysis for use in making investment decisions. OPNAV developed an instruction to describe the process (PNAV Instruction 3050.23, 2001). The instruction, though, only covered products that OPNAV developed. The process overall, though, touched on products from every “ decision support system” process. The process is still evolving and is the first that required mobilization of many organizations, their products, their processes, but most importantly, their cooperation. Much potential exists in the successful implementation of this process. This year, Navy is taking heed from visionary documents such as Sea Power 21, Naval Power 21, and the Navy’s Transformation Roadmap (DON, 2002). Instead of discussing MCPs, four new concepts were introduced— Sea Shield, Sea Strike, Sea Basing, and FORCEnet. Sea Shield addresses defensive power and joint access; Sea Strike addresses offensive power; and Sea Basing addresses power projection from the sea. FORCEnet is the infrastructure enabler for the other three concepts. OPNAV is viewing each concept as a Naval Capability Program (NCP) and aligning the existing MCPs to these NCPs. The plan is still to coordinate and cooperate among organizations to establish context for investment decisions. Though in its infancy, the processes that are being explored today are moving away from “stovepipe” solutions. What would 150 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. help in the implementation of the concepts is proven research that demonstrates and validates many of the ideas that are being put forth in the concepts. Integrated Product Teams And Virtual Organizations Acknowledging the need for cooperation among immovable organizational structures, many Navy organization leaders promoted Integrated Product/Program Teams (IPTs) and virtual organizations. These teams were informal organization structures, usually formed to implement specific projects or products. Often, Memoranda of Agreement were signed to show good intention of honoring the informal relationships. Paul Schneider, former Principal Deputy Assistant Secretary of Navy, established a Virtual Program Office, when the three Navy Systems Commands were in non-productive competition for development of a Naval Fires Network (NFN). Essentially, a senior representative from each SYSCOM was assigned, and their assignment was to produce an integrated architecture, engineering design, and system for NFN. Though well-intended, organizational representatives either carry agendas of their home organizations with them to the VPO or they are viewed as “ going native” or being traitors to their home organizations. Additionally, if the representative is not continually working with the home organization, they are sometimes overlooked when it comes to participating in home organization activities, events, and/or rewards. Organizations are 151 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. still learning how to participate in teams and virtual organizations that are not part of their own organizations and cultures. Strides have been made in achieving interoperability by teams that focused specifically on solving an interoperability problem. The teams were established to solve the problem and dissolved after the problem was solved. These teams achieved cooperation among members of the team. They established and implemented standards, guidelines, and commitment to “ get the job done.” Though successful in achieving interoperability for the particular problem, they did not put into place a long-term strategy to institutionalize interoperability solutions for DOD and Navy systems, nor was this their objective. Transformation James Burke and Robert Ornstein, in The Axemakefs Gift, corroborate the profound impact that technology has on society (Burke & Ornstein, 1997). They relate how technology captured, shaped, and controlled the minds and culture of humanity. This was transformation. It has occurred throughout the history of society. Transformation is the co evolution of technology, organization, and doctrine (England, Clark, & Jones, 2002). Navy organizations and doctrine have been exposed to technology advancements and their impacts but have not evolved with them. Unintended consequences of technology evolutions are now mandating 152 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. evolutionary responses that cannot go unanswered by organizations and doctrine. Vice Admiral Cebrowski, former Chief of Naval Operations, and John J. Gartska discuss the need for transformation in a visionary military magazine article (Cebrowski & Garstka, 1998). They acknowledge the potential of technology evolutions and its inevitable transformational impact on American society. The Navy-Marine Corps responded by describing critical operational goals of transformation in the 2001 Quadrennial Defense Review Report (DOD Quadrennial Defense Review Report, 2001) and developed a transformational roadmap in 2002 (England, Clark, & Jones, 2002). The DON Transformational Roadmap is specific about the transformation and its major supporting programs. It anticipates an open architecture and the maritime components of FIOP as the bases for interoperability relying on strengths from the evolution of strategies that preceded it. Still, though, the success of interoperability in the transformation remains to be seen. Network Centric Warfare Vice Admiral Cebrowski, former Chief of Naval Operations, and John J. Gartska introduced Network Centric Warfare (NCW) to DOD and the military services in 1998 (Cebrowski & Garstka, 1998). Dave Alberts, 153 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. another NCW advocate, defines Network Centric Warfare (NCW) as “ a set of warfighting concepts designed to create and leverage information” (Alberts, 2002). The bases driving the need for NCW are changes in American society that are linked by three themes: • The shift in focus from the platform to the network ; • The shift from viewing actors as independent to viewing them as part of a continuously adapting ecosystem; and • The importance of making strategic choices to adapt or even survive in such changing ecosystems. (Moore, 1996) A platform is an electronic device used to process/compute data (Oracle 8, 1997). Since the mid 1980s, desktop computers proliferated American Society. Network technology paved the way to proliferate massive amounts of information throughout society. If platforms were not connected to the network, they did not have access to the information. The Internet demonstrated the power of being connected. In the platform-centric environment computing power is centered on the platform. Individuals independently rely on the processing power of their platforms and whatever information it can create or store. In a network-centric environment, computing power expands to the accessibility of processing power from those connected to the network. Individuals become partners with others who are connected to the network and potentially have access to information available from sources connected to the network. This significantly increases their potential knowledge base. 154 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Vice Admiral Cebrowski views the shift from ptatform-centricity to network-centricity as a viable solution to interoperability. He cites another former CNO, Admiral Jay Johnson, who views the fundamental shift from platform-centric warfare to network-centric warfare as the most important Revolution in Military Affairs in the past 200 years (Cebrowski & Garstka, 1998). From a technical perspective, the shift from platform-centricity to network-centricity is feasible and achievable. From the perspective of the ecosystem, the shift from independence to sharing and adapting in the changing ecosystem is transformational. NCW introduces the concept of transformation—transforming from a culture that autonomously uses technology to solve complex problems to a culture that collaboratively solves these problems. Dave Alberts connects NCW to the translation of broad vision statements espoused in Joint Visions 2010 and 2020 to a way ahead. The translation is accomplished through the adoption of and adaptation to information technologies to effectively facilitate information-sharing. In this way, he also relates interoperability to NCW. From his perspective, NCW facilitates a culture change from information- hoarding and self-sufficiency to information-sharing and cross-organization dependency. This change is a transformation that attains synergy among organizations. NCW is a concept that appears to lead DOD and the military Services in the direction towards achieving interoperability. With the concept defined, 155 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. what is the next step? How is the concept proven; and, if proven, what is the implementation strategy? DOD and military Services began the technical shift but continually ran into organizational issues of the ecosystem. As an example, the Naval Fires Network concept attempted to connect, in a network, those systems contributing to Naval Fires. Organizational disputes reaching very senior levels caused the establishment of a virtual program office consisting of representatives from each of the disputing organizations. This solution, though, was an isolated incident. What about other disputes that do not reach the visibility of senior authorities, because resourceful independent organizations or Program Managers devise ingenious work arounds? To demonstrate the commitment to move forward with NCW, senior authorities created a new concept that deals with ecosystem issues— FORCEnet. FORCEnet FORCEnet is the Navy’s plan to make NCW an operational reality (Clark, 2002). The plan is to integrate warriors, sensors, networks, command and control, platforms, and weapons into a combat force that is fully robust and networked. Implementation of the plan is based on establishment of an overarching architecture for the integration within the boundaries of a Global Operational Concept. The definition for FORCEnet is: 156 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. . . . a robust, adaptive ecosystem comprising human, technology, structural and other “organisms” providing an environment supporting interaction, information exchange, presentation and a dynamic flow of knowledge that enables unique individual, aggregated sub-organizational and spectrum of military Interagency operations. (FORCEnet Operational Definition, 2002) The power of networking technologies underlies the strength in implementing the synergies of a force responding to contingencies and conflict throughout the world. FORCEnet is the enabler. FORCEnet mobilizes the concepts of NCW. It is the Navy response to the implementation plan for NCW. Is it? During a conference in April 2002, senior leaders of participating Navy organizations presented their understandings of FORCEnet and held panel discussions. One area of the discussion addressed barriers and assumptions to overcome barriers. One of the acquisition barriers was that interoperability is an unfunded requirement. The assumption to overcome the barrier was to offer incentives for optimizing interoperability. This is a weak response. Interoperability comes with a bill that has to be paid or, despite organizational transformations, it will not be achieved. Despite being named as a plan to operationalize NCW, FORCEnet still appears to be yet another concept. A plan identifies what needs to be done to achieve a clearly defined set of objectives. Thus far, only high-level concepts, such as being an enabler for military operations such as defensive, offensive, and projecting forces from the sea, have been 157 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. identified; but no objectives exist for achieving them. Additionally, while the churn is on and organizational change is occurring in all organizations, it is only moderately addressed in FORCEnet discussions. Emphasis is more on the physical technologies than on the overall human aspect. The areas of human resources addressed include the human as network or technology users and decision-maker leaders. Human resources and their roles as designers, managers, or developers of the ecosystem, the networks, and technologies are not addressed. FORCEnet has potential, but its success remains a future vision. Transformation Roadmap Out with the Old, in with the Needed! Discussion: What it is. How it contributes to interoperability. Value it added or did not add. Each of the military Services developed a transformation roadmap in response to guidance in the DOD Defense Planning Guidance (DPG) for 2003-2007. The DPG summarizes the findings from PPBS policy implementation—discussed in Chapter 4. The Naval Transformation Roadmap does the following: “... describes the key naval concepts, capabilities, initiatives, processes and programs that will guide the transformation efforts of the Navy-Marine Corps Team in support of the 158 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. critical operational goats of transformation described in the 2001 Quadrennial Defense Review Report” (England, Clark, & Jones, 2002). FORCEnet is the concept in the roadmap that addresses interoperability. It is identified as an enabler for the other concepts. The concept and plan appear to be reasonable and holistic in perspective, but it is treading new ground with no demonstrated or proven models to support its success. This will impact its implementation, and implementation is subject to the culture and understanding of the organizations executing it. Where are the models for success? Sea Warrior is the name of the Naval process in the Naval Transformation Roadmap to develop a culture of innovation that implements transformation. This process addresses a plan for establishing the culture to use products and services of transformation. It neglects the culture needed to plan, program, budget for, acquire, experiment, test, and field these products and services. Also, the co-evolution of the organizational culture for these communities did not occur. The single system Program Manager is still autonomously developing systems. This increases the risk of developing a “ stovepipe” system. Navy is reorganizing this culture to accommodate transformation, but the roadmap to do so is missing. Also missing is the interoperability of this culture with the “ sailor” and human resources identified in Sea Warrior. 159 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Congress Congressional Mandates Congress has and exercises the ability to circumvent decision support system processes. This potentially occurs when Congress deems that an issue of significant importance is not being addressed or if sufficient progress is not being made on programs by existing or planned programs. Congressional intervention can also occur when lobbyists convince Congressional men or women of the need to fund programs outside of the normal requirements generation or acquisition processes. Lobbyists include industry giants or other constituents who potentially influence Congressional votes. In these situations, Congress takes action to mandate the acquisition of systems. Based on the power of Congressional intervention, Congress is demonstrating weak interest in a universal solution to interoperability problems. Congressional mandates have the potential of introducing new interoperability problems by protecting systems from many of the rigors of DOD and Navy processes that are applicable to other systems. This occurs when Congress focuses only on one or two systems to appease their constituents. More importantly, though, Congress has the power of the purse and the power to change the Goldwater Nichols act as delineated in Title 10 of the United States Code. This is significant because, potentially, it directly impacts the ability to achieve interoperability. 160 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Appropriation and Authorization A more traditional role of Congress in DOD and Navy processes is the appropriation and authorization of funding based on approval of the President’s budget. The House and Senate Armed Services Committees approve appropriations in the President’s budget. The House and Senate Authorization Committees authorize the spending of the appropriations. Appropriations identify funding for programs that will acquire and or develop systems. This ability to mandate, appropriate, and authorize spending of tax dollars on behalf of “ the people” gives Congress a tremendous amount of power. Congressional Power Congress has the power to initiate, continue, or end a program at any time through the course of its acquisition. Congress also has the power to prioritize and control the spending of funds on programs. With this degree of power, even if DOD and Navy were not interested in solving interoperability problems, Congress could make it happen. Power of the Purse Congress has an obligation to tax payers. This obligation is to maximize the benefit to “ the people” for expenditure of their tax dollars. The cost/benefit assessment of interoperability has yet to be accomplished. Congress may be waiting for interoperability problems to become national 161 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. crises before taking serious steps to resolve them. Neither Congress nor DOD and Navy appear to be serious about interoperability. Their commitment to interoperability is not yet evident. Until this happens, interoperability problems will persist. In the meantime, Congress funds individual programs that continue to experience interoperability problems. This causes one to wonder whether it is in the best interest of taxpayers to do this or to mandate the redefinition of Program Manager responsibilities to be more expansive. An expanded role potentially gives the Program Manager responsibility with appropriate funding for acquiring a collection of interoperable systems. Currently, DOD and Navy are referring to such a set of systems as families-of-systems (FOS) or systems-of-systems. Power of the Goldwater Nichols Act and Title 10 of the U.S.C. The Goldwater Nichols Act (1987) and Title 10 of the U.S.C.5 give Program Managers autonomy in the acquisition of systems. The Goldwater Nichols Act authorizes organizational restructure. Title 10 authorizes the reporting structure and charter of the Program Manager in the Defense Acquisition System. The charter gives autonomy to Program Managers in the acquisition of computer-based systems. It also allows for the designation 5 The United States Code codifies the laws of the federal government. Title 10 is designated for armed forces laws. Available: http://www4.law.cornell.edu/uscode/10/. 162 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of a single Program Manager for each system— resulting in hundreds to thousands of Program Managers. Congress passed these laws. The autonomy of the Program Manager potentially gives him or her a means of bypassing informal guidance or direction with which he or she may disagree. To achieve interoperability at acceptable levels, cooperation among many cultures in many organizations is imperative. If Program Managers autonomously reject methods with which they disagree, achieving interoperability at acceptable levels may continue to be problematic. Congress has the power to pass the laws. Congress has the power to change them. Their exercise of this power has the potential of seriously addressing interoperability among complex DOD and Navy systems. The Analysis—Hypothesis 3 Are “ work-harder” strategies working? Translation: Are Navy computer-based systems achieving acceptable levels of interoperability? Not yet. Navy spends lots of money on the problem. Isolated cases of success contributed little to the overall achievement of interoperability. An overall collaborative approach to solving interoperability was missing. For IT-21, Navy bought the latest technology off the shelf from commercial vendors. Commercial vendors could not solve the Navy interoperability problem, because they, too, were not interoperable. They had standards for some of the products, but even these quickly became 163 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. legacy systems. As industry competitors introduced new technology yearly, by the time Navy procured all the systems needed, commercial vendors had moved on to newer technologies that were not necessarily compatible with previous versions before Navy systems were fielded. Table 8 provides the scorecard for the work-harder strategies. Interoperability success ratings denoted on the table are based on the author’s observations. The full sense of whether they work has not yet been proven. The potential rankings are low, moderate, high, and unknown and based on the observed judgment and experience of the author. A ranking of “unknown” means that the results are still out. The strategy may be new or its results not yet demonstrated. A “low” ranking means the strategy is not working or has been stopped. The “moderate” ranking means that some successes have been demonstrated but not enough to institutionalize the strategy. No strategy ranked “high” or the achievement of interoperability at acceptable levels at a critical mass. 164 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 8 Work-Harder Strategy Scorecard “Work-Harder” Strategy Interoperability Success Significant Resources Investment Low Technology-Based Solutions (Technology Advancements) Low Use of Common Products Low Standards and Commercial Products Low Incremental Marginal Solutions Low Policy, Policy Updates, and Updates to Policy Updates Low Infrastructure Unknown Architectures Unknown Family of Interoperable Pictures Unknown Deployment Minus 30 Months (D -30) Process Moderate Battleforce Capabilities Assessment Programming Planning (BCAPP) Process Unknown Integrated Product Teams and Virtual Organizations Moderate Network Centric Warfare Unknown FORCEnet Unknown Transformation Roadmap Unknown Congress Low Thus far, “ work-harder” strategies have not been very successful. New strategies are underway, but they are' breaking new ground. One fact is certain—the systems that are not interoperable are legacy, stovepipe, and standalone systems. If the strategies do not address these systems and the complexities identified in Chapter 2 \ s they may not be successful either.____________ 165 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Summary—Hypothesis 3 The earlier strategies have not worked. The newer strategies are more complex and begin to address some of the shortfalls that were identified in the processes. Will the newer strategies work? Not until they adopt a model of success. Not until they address the interoperability of the standalone, stovepipe, and legacy systems. Not until they address a means to prevent the stagnation of future legacy systems. Arthur R. Jensen (1969) wrote: [W]hen bridges do not stand, when aircraft do not fly, when machines do not work, when treatments do not cure, despite all conscientious efforts on the part of many persons to make them do so, one begins to question the basic assumptions, principles, and hypotheses that guide one’s efforts. Significant observations are clear about the “ work-harder” strategies. Many organizations were responsible for these strategies. Each used different approaches to solve or address interoperability problems. The strategies were the result of planning and effort that senior leaders approved and made decisions to fund and implement over a twenty-year period. Yet, the interoperability problem persists, and uncertainty remains about whether the strategies that are still ongoing will result in achieving interoperability at acceptable levels. Strategies to solve interoperability problems are resulting in expenditure of tax dollars on products and methodologies that are disjoint 166 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and potentially conflicting or irrelevant. Yet, Congress, which has the power over the spending of tax dollars, has not weighed in. DOD and Congress continue to spend dollars for the many disjoint strategies but have not seriously mandated that the problem be solved. No single authority is responsible for orchestrating whether and how organizations synergize their efforts and eliminate those that are duplicative or add no value. FORCEnet has the potential of bringing together many interoperability strategies, but it is limited to Naval efforts. But even the implementation of FORCEnet is focused only on Command, Control, Communications, Computers, and related Intelligence systems. Organizationally, policy may be needed that formally designates a senior authority with approval and veto power over all interoperability efforts. Since each of the military Services has unique requirements, the senior authority could organize with delegation authority to the Services; but, as soon as that happens, delegated Services are subject to working their own agendas. The responsibility of a single authority would be to orchestrate the efforts of organizations with interoperability requirements to develop organizational, technical, and doctrine interoperability for the transformation ecosystem. In conclusion, a model of success and a coordinating senior authority for ail strategies is needed. Are the “ work-harder” strategies working? Not yet! 167 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER VI ARE DOD AND DON USING THE EVERETT ROGERS DIFFUSION-OF-INNOVATION PROCESS MODEL TO ACHIEVE IMPROVED INTEROPERABILITY? Introduction— Hypothesis 4 The Model and its Elements Hypothesis: DOD and DON processes are using the Everett Rogers Diffusion-of-innovation Process Model to achieve improved interoperability. This chapter analyzes whether DOD and DON processes use Everett Rogers’ Diffusion-of-lnnovation Process Model to achieve interoperability among DOD and Navy systems. The premise is that use of Rogers’ Diffusion-of-lnnovation Process Model potentially serves to achieve acceptable levels of interoperability. The diffusion of innovation is “ the process by which an innovation is communicated through certain channels over time among the members of a social system” (Rogers, 1995, p. 5). Under certain conditions, attributes of the four elements in Rogers’ Diffusion Model interact to promote diffusion of an innovation. The following diffusion elements from Rogers’ Model, their attributes, and interactions are 168 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. addressed to assess their current usage in DOD and Navy processes to achieve acceptable levels of interoperability: Innovation; Communication through certain channels; • Time; and • Social system. The innovation must be communicated to a social system that must be convinced over time that the innovation is one they want/need to adopt. A summary of the Rogers’ Diffusion-of-lnnovation Process Model, its diffusion elements, and attributes that describe his Model is shown in Figure 9 in three parts. Figure 9 summarizes Everett Rogers’ Diffusion-of- lnnovation Process Model by providing definitions for the diffusion elements and describing how Rogers uses them and their attributes in the Model. This section discusses the diffusion elements, supporting concepts, and attributes. 169 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Diffusion Elements Definition of Elements Rogers' Traits and Attributes of Elements INNOVATION Idea, practice, or object that is perceived as new by an individual or other unit of adoption. Technological Innovation Hardware Software Technology Clusters innovation Attributes: relative advantage compatibility complexity trialibility observability Reinvention COMMUNICATION (of innovation) over Process of convergence (or divergence) as two or more individuals exchange information in order to move toward each other (or apart) in the meanings that they give to certain events. Change agents to transfer innovation info to social system Heterophilious Homophilious COMMUNICATION (CHANNELS) The means by which messages get from one individual to another. interpersonal mass media local cosmopolite critical mass Figure 9. Summary of Everett Rogers’ diffusion model. -a o Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Figure 9 (continued) Diffusion Elements Definition of Elements Rogers' Traits and Attributes of Elements 1 nnoyatipn Decisjon Process.......... First Knowledge Persuasion Adoption Decision Implementation Confirmation Innovativeness of Adopter Innovators TIME Passage of individual from first knowledge through adoption or Early Adopters Early Majority rejection of innovation ................................... Late Majority ....................................... Laggards Rate of Adoption Innovation Attributes relative advantage compatibility complexity trialibility observability Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Figure 9 (continued) Diffusion Elements Definition of Elements Rogers' Traits and Attributes of Elements SOCIAL SYSTEM Interrelated units (members - individuals, groups, organizations, or subsystems) engaged in joint problem-solving to accomplish a common gtoal. Boundary of social system within Social Structure Norms Opinion Leaders Change Agents Types of Innovation Decisions Optional innovation-decisions Collective innovation-decisions Authority innovation-decisions Consequences of Innovation Functional/Dysfunctional Immediate/Second Order response Recognized and intended ------------------------------------------------------------------------------------------------------------------ Everett Rogers uses elements of diffusion theory in the definition and design of concepts and attributes for his Diffusion-of- Innovations Process Model. ^ These elements are depicted on this and the previous two pages, j ■ " •j K3 Innovations “An innovation is an idea, practice, or object that is perceived as new by an individual or other unit of adoption” (Rogers, 1995, p. 11). Rogers leans towards innovations as objects and refers to them as technologies that have both physical and information component— usually with one or the other dominating. He views physical components as hardware or equipment tools that can perform useful purposes and information components as software or information tools that describe the technology or how it is used. Rogers points out that individuals who do not understand technologies have uncertainty about whether to adopt or use them. Information about the technologies and how to use them reduces the uncertainty. Citing J. D. Thompson and J. D. Eveland, Rogers (1995, p. 12) concurs that information components reduce uncertainty in the technology. Information about the technology reveals expected consequences or what the user can expect of the technology. When users understand what they can expect, their uncertainty about the technology is reduced. Rogers also finds the concepts of information and uncertainty important to explaining the interaction between the innovation and the other elements. The creation of the innovation alone does not guarantee that it will successfully diffuse. Information about the innovation must be communicated to a social system that must be convinced over time that the innovation is one they want/need to adopt. 173 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Navy computer-based systems are technologies with hardware and software components. Though these systems are not new, the technologies that comprise them today and their intended usage are new, and as such are innovations. In particular, achieving acceptable levels of interoperability among the systems is a new concept and represents a challenge for providing the guidance to do so in DOD and DON processes and policy. Information and Uncertainty Information and uncertainty are concepts of the innovation element. Uncertainty is the perception that there are a varying number of alternatives (choices) associated with an event and the likelihood of these alternatives (Rogers, 1995, p. 6). Information describes and explains how to use the innovation. Rogers makes use of information and uncertainty concepts to link the four elements of his model and propose that innovations generate uncertainty because of their newness to potential adopters/users. When individuals are presented with a new innovation, they face the choice of remaining with the status quo or adopting the innovation. Rogers finds the uncertainty and information concepts important to explaining the interaction among the elements. Development and existence of an innovation does not guarantee that it will successfully diffuse. Interactions among the elements are needed such that the innovation is communicated to potential adopters who need to be convinced over a period 174 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of time to adopt it. These potential adopters are uncertain that they need to adopt an innovation until they have enough information to know whether and how it will benefit them. Communicating information about the innovation over communication channels provides the means of making adopters smart about the innovation. Gaining an understanding about the information communicated takes time. Adopters receive, understand, and accept information at different rates of time. If they believe the innovation adds value to their lives, they may adopt it. They may not. An innovation gives an individual or organization alternatives to the status quo. Uncertainty arises when individuals/organizations do not know whether these alternatives will be better than the status quo. This motivates them to seek further information about the innovation to cope with the uncertainty that it creates. Two types of uncertainty exist—unexpected and expected consequences. An unexpected consequence is not knowing what to expect from using an innovation or whether the innovation will live up to expectations. An expected consequence is knowing what to expect from using an innovation, because information is available that explains the innovation. Even expected consequences, though, have an unexpected side. This is not knowing whether the expectations are wanted or needed. Potential adopters want to reduce uncertainty before they adopt an innovation. The more information they receive and understand, the more 175 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. willing they will be to make the decision to adopt the innovation. They want answers to questions about both expected and unexpected consequences. These answers may put them in a comfort zone that will reduce uncertainty and move potential adopters closer to making adoption decisions. Technological innovations provide many of the answers, because they are based on cause-effect relationships that enable development of the innovation. This provides for uncertainty reduction in these types of innovations. Arthur L. Chait (1994) discusses how rapid technology diffusion contributes to uncertainty. New technology products are becoming available to potential adopters faster than they understand how to use them. An example is the Video Camera Recorder (VCR). The main purpose of the VCR is to record and replay television programs or movies on and from a tape cartridge. Many VCRs have additional technology features that amplify its primary purpose. These features raise the cost of the VCR. Potential buyers (adopters) may not buy a VCR because of the uncertainty associated with the features. Even Informed potential buyers may become uncertain when they discover that, for a few dollars more, they can get the latest features, but they do not yet have information about the new features. Clayton M. Christensen (1997) discusses how uncertainty contributed to the downfall of industry giants, when upstart companies created disruptive innovations that rapidly achieved critical mass. Disruptive innovations are 176 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. radical changes from status quo technologies. Normally, disruptive technologies are unable to compete with the status quo and have a different market. In recent years, though, these changes caused economic, social, and technical impacts on the status quo. Industry giants were caught between investing in the status quo or new innovations. They needed information about how their customers would respond to both the status quo as well as the new technology. Market research provided information on the old but not on the new. As such, the new technology brought uncertainty to both the industry and its customers. The industry giants made investment choices based on minimizing the uncertainty. They went with market research indicators for more of the status quo. They were wrong. Unable to compete with markets of industry giants, upstart companies invested in new innovations and targeted untapped markets, e.g., the average home consumer. In the case of personal computers and networks, adoption was rapid not only for home consumers but also for the markets of industry giants. These giants lost their markets to the upstart companies. Uncertainty exists in Navy systems that are not interoperable. Information is needed about whether the systems will successfully connect, exchange information, or effectively use exchanged information. If the systems do not effectively do these things they will not be interoperable. Uncertainty that arises from interoperability is due to the many potential 177 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. paths and methods available to exchange and use information among systems. Each system that touches exchanged information potentially changes it in ways that may make it foreign to the next system that receives it. The risk of error increases with each path. When more information is known and available about the paths and use of exchange information, less uncertainty about interoperability exists. Diffusion Of Undesirable Innovations Another aspect of innovations, particularly important to this research, is Rogers’ discussion about diffusing innovations that are not necessarily good or desirable. The innovation may not be good for an individual or a social system. Or, one individual or group may want the innovation, while others may not. Conflict arises between the innovations as well as the individuals or groups. This leads to the need to understand the interaction of the innovation(s) and the total members of the social system that need to adopt the innovation. Otherwise, the diffusion may create more problems than it solves. Technology Clusters Defining the boundaries of the innovation is likely the most important concept and methodology aspect that Rogers presents relative to this research. Should the boundary include the diffusion of a single innovation or a group of innovations in the form of a technology cluster? “ A technology 178 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. cluster consists of one or more distinguishable elements of technology that are perceived as being closely interrelated” (Rogers, 1995, pp. 14-15). This research proposes that, to be interoperable, innovations must diffuse in technology clusters. According to Rogers’, this is a reality, because innovations are interdependent. Investigation, though, of independent technologies is easier. Everett Rogers would identify systems with dependencies as part of a technology cluster. The systems within the technology cluster are dependent on each other, because they need to share information. Rogers affirms the need for technology clusters to diffuse together. Diffusion of systems with their dependencies becomes a critical factor to its success. Characteristics of Innovations Innovations have five characteristics that, according to past research, explain their different rates of adoption— relative advantage, compatibility, complexity, trialability, and observability (Rogers, 1995, pp. 15-16). Relative advantage is the perceived benefit an innovation has over its predecessor. Compatibility is the perception that the innovation fits the needs of the social system for who it is intended. Complexity is the perceived difficulty of the use and understanding of the innovation. Trialability is the ability to experiment with the innovation on a trial basis. Observability is the demonstration of the innovation to potential adopters to show its results. “Innovations that are perceived by individuals as having greater relative 179 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. advantage, compatibility, trialability, observability, and less complexity will be adopted more rapidly than other innovations” (p. 16). Reinvention Another important concept of the innovations element that is relevant to this research is reinvention—the modification of an innovation by a potential adopter during the adoption process and implementation (Rogers, 1995, p. 17). A potential adopter may find other uses for or changes to innovations so that they better suit needs of the adopter. The original innovation adapts to their needs. The innovation Development Process Rogers identifies six stages in the innovation development process. These stages are as follows: Identifying the Problem; • Basic and Applied Research; • Development; • Commercialization; • Diffusion; and Consequences. DOD and Navy requirements and acquisition systems begin with identification of problems or needs—the “Recognizing Needs/Problems” phase in the Rogers Model and the Mission Needs Statement (MNS) in the 180 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Requirements Generation System. Basic and applied research are involved in the Rogers Model and in the Requirements Generation System. In the latter, analyses are performed to validate the need (Mission Needs Analysis [MNA]) and determine research options that support problem resolution (Analysis of Alternatives [AOA]). An Operational Requirements Document (ORD) is generated from the analyses. Development of the innovation is the next phase of the Rogers Model and aligns with Milestone B of the Defense Acquisition System. Development of a system, in accordance with requirements identified in the ORD, occurs during Milestone B. Commercialization is the manufacturing, packaging, marketing, and distribution of innovations. Production and fielding of systems occurs during Milestone C of the acquisition system and aligns with commercialization in the Rogers Model. And, finally, consequences in the Rogers Model align with user feedback from the use of systems in the form of “lessons-learned reports,” messages and “ trouble reports." Figure 10 depicts the alignment of the processes. 181 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Rogers Innovation Development Process Recognizing Basic or Development: Diffusion Needs or Applied Potential Commercialization and Consequences Problems Research Problem Solutions Adoption Requirements Generation System Mission Needs Statement Analysis MNA/AOA Operational Requirements Document (ORD) r \ r Defense Milestone A: Milestone B : System Milestone C: IOC Trouble Reports Acquisition Pre-Acquisition Development and Production and System Approval Decision Demonstration Approval Decision FOC Figure 10. Aligning Rogers’ innovation development process with DOD and Navy Requirements and Acquisition Systems . Combined, the Requirements Generation and Defense Acquisition Systems Include Both Pre-diffusion, Diffusion, and Post-diffusion aspects of innovations. The Innovation of this Research Identifying the Problem As discussed in the preceding section, innovations are responses to problems. If the innovations are effective, they solve the problems, and their diffusion is more likely to be successful. Navy successfully diffuses computer-based systems to the extent that warfighters adopt or use the systems and have successful military operations with these systems. Historically, though, military operations that use the systems report that the systems are not interoperable. Warfighters cannot share needed information, because the systems deny continual and consistent access to accurate and sufficient information due to interoperability problems. Navy has an interoperability problem. Interoperability problems are complex, take on many forms, and appear to multiply faster than they can be solved. An innovation that solves interoperability problems for one or a few systems may not be applicable to other systems. An interoperability problem may be due to the lack of adequate connectivity, incompatibility between systems, or many other causes. Each instance of a problem may require different or unique solutions. Success in solving isolated cases is applauded but appears to have minimal impact on overall interoperability problems. Navy has attempted many strategies to solve interoperability problems. Most of the strategies focused on finding technical solutions— 183 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. fixing the problem by fixing the physical and information technology interfaces. Some case solutions have been successful. Thus far, the strategies have not overall yet worked. A particularly troubling aspect of strategies to achieve interoperability has been that visibility of their success is always promised as a future event. The events have yet to manifest. New strategies come with new promises of future results. The question that needs to be answered is whether DOD and Navy can continue to wait. Personal computers and the Internet are examples that diffusion of good ideas or objects can occur rapidly. They give hope for interoperability problems. DOD developed policy for all military Services mandating interoperability for all computer-based systems that needed to exchange information. Navy followed suit and mandated interoperability. The policies, though, did not account for the majority of the systems that were already in use—legacy, standalone, and stovepipe systems. New systems could not be interoperable, unless they limited their capacities and abilities to be compatible with the older systems that were not equipped to achieve interoperability. Though policies became increasingly detailed about the technical details of computer-based systems, the organizational structure for their acquisition and development remained unchanged. A single Program Manager autonomously manages the technical details of architecting, 184 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. engineering, developing, testing, and delivering computer-based systems. This autonomy is augmented by senior-decision maker authority and approval, but charismatic politically savvy Program Managers have succeeded in getting systems approved that have interoperability problems. Only recently are discussions being conducted to frame the problem in terms of economic and social perspectives in addition to physical technologies. The concept is uncomfortable, so social and economic views still center around the use of physical technologies rather than social environments needed to create, develop, or use these physical technologies. Since most Navy systems that need to be interoperable already exist, the solution is not one of developing new systems. It is primarily one of defining a means of bringing together existing technologies, integrating new technologies, and networking them to be interoperable. The solution will require an interaction and exchange of technologies, funding, and information. This only happens if social communities that own physical technologies come together and, either through authoritarian or cooperative agreements, decide on and fund a common interoperability infrastructure. The interoperability problem, then, is greater than a physical problem. It involves the physical and information technologies, as they impact and interact with social, economic, and political elements. Multiple DOD, Navy, and other military Service organizations have taken on the challenge of finding solutions to interoperability problems. 185 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Interactions among these organizations are courteous politeness and acknowledgment of their existence, but no real dependencies or alliances. The organizations have different ideas on what to do to achieve acceptable levels of interoperability and how to do it. Competition among government organizations is as fierce as with industry, even though profit is not a factor. They want credit and recognition for solving a difficult problem. No single organization has the authority to orchestrate integration and interoperability among the organizations and establish a unified plausible approach based on documented national successes in achieving interoperability. Because organizational structures and interactions are critical to unifying the people, technologies, and funding, the interoperability problem is first and foremost a social problem. Identifying the Innovation So, what is the innovation of this research? The innovation is the technology that achieves acceptable levels of interoperability. It embodies the strategies of nationally-known, large-scale interoperability ventures that have been successfully implemented. It adheres to a model used in these ventures that has substantial research to support its soundness. The innovation is primarily a social technology that promotes, develops, and relies on interoperability as a normal pattern of life. 186 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Social technologies are organizations that contain social systems that produce technologies (Taylor & Felten, 1993). This describes most organizations. The key to success in diffusing a social technology is defining and implementing an organizational design such that achieving interoperability at acceptable levels is the technology focus of all members. But, what about the physical technologies—the system, family-of- systems, or system-of-systems that need to be interoperable? Why are they not the innovations? Identifying them as the innovations that were required to be interoperable was too hard. It did not work. The search to achieve interoperability at acceptable levels in DOD and Navy has resulted in many strategies. Some of these strategies have already proven to be unsuccessful. It is not clear whether the others will succeed or if they are competing with each other, conflicting, or irrelevant. Chapter 7 includes a summary and judgment view of how well these strategies are working. For certain, no structure exists to unify the strategies or determine how they should create synergistic results to achieve acceptable levels of interoperability. DOD and the military services are ripe for a social technology that can facilitate the synergy. Characterizing the Innovation Adoption of a new social technology will be painful because of the freedom of judgment and action environment taught to American citizens 187 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. from birth. But free will dictates choice, and choice renders differences, unless an authoritative social technology dictates otherwise. Karl Marx, from 1843 until his death in 1883, advocated socialism (Ruis, 1976). His issue was who should profit from the use of technology—the private owner or working class citizen? His answer was the working class citizen. American society frowns upon socialism and promotes competition and free will in the private sector. In government, though, society promotes equity, the tenet of socialism. Taxes are collected to fund government programs that will benefit the collective society. The profit of publicly-owned products and services resulting from these programs is shared by society. Surfacing in the quest for acceptable levels of interoperability is this paradox of equity and free will. Free will is expressed by the many strategies attempting to solve the problem. Interoperability represents the equity of shared information. The synergy of pulling the wills together towards the solution is not occurring. Some of the strategies have already proven to be unsuccessful. It is not clear whether the others will succeed or if they are competing, conflicting, or irrelevant. Now that it is clear that a social technology in a routine operation is needed, how is it attained? The elements, concepts, and attributes in Everett Rogers’ Diffusion-of-lnnovation Process Model provides a means of making a social technology to achieve interoperability among Navy computer-based systems work. Following are discussions of Rogers’ 188 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. elements and how they support the implementation of such a social technology. Communication and Communication Channels Communication Rogers’ Diffusion Model differs from previous models in that he uses a convergence approach to communication. He defines communication as “. .. a process in which participants create and share information with one another in order to reach a mutual understanding” (Rogers, 1995, pp. 5-6). Individuals converge on (or diverge from) mutual understanding of meanings of information they exchange. Using a linear approach to communication (sending information from one source to a receiver) has been the basis for past but is not adequate for all diffusion research. The diffusion of innovation is a type of communication process in that it communicates an innovation through certain channels. In this role, diffusion focuses on information exchange as the means of converging on an understanding of the innovation that convinces a social system (potential adopters) to use it, i.e., successful diffusion. Communication Channels Communication channels communicate information about an innovation. They are the means by which messages get from one individual to another (Rogers, 1995, p. 18). The two types of communication channels 189 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. are mass media (e.g., radio, television, newspapers, et al.) that enable information from limited sources to reach the many and interpersonal channels (face-to-face) that occur between a limited number of people. Rogers asserts that interpersonal communication channels are more effective and that adopters of new innovations rely more on interpersonal information exchanges about an innovation to decide on its adoption than on the results of scientific research. The Messengers Homophily refers to the similarities in characteristics of people who interact. They may have similar beliefs, education, social status, or other characteristics. These similarities create a familiarity among people that makes it easier for them to effectively communicate the message than people who are heterophilous. People who are heterophilous (having different characteristics) experience problems in becoming messengers in the exchange of information. Without the familiarity of shared experiences, the sharing of information becomes difficult and communications, ineffective. Time Decision-making, timeliness, and rate of adoption are characteristics of the time element. 190 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Innovation-Decision Process People/Organizations make decisions about whether to adopt at different times after they become aware of an innovation. Some adopt when they first hear about the innovation and understand what it can potentially do—first knowledge. Others need to be persuaded that the innovation will be of value to them or their organization. Engaging in activities that will show the options of adopting or not adopting the innovation is the criteria for some to make the adoption decision, while others need to actually use the innovation on a trial basis. Though many make the decision to adopt, they may change that decision at a later time, if they determine that their initial decision was in error or confirm that the decision was a good one. These decision points are steps in an innovation-decision process that lead to the adoption of an innovation. The innovation-decision process involves information-gathering, processing, and exchange to reduce the uncertainty of the innovation and enable potential adopters to make and keep the adoption decision. The five steps of the process usually occur sequentially (though there are exceptions) over a period of time. Summarizing, they are as follows: ® First knowledge of the existence of the innovation and how it works (mass media channels work well here); • Persuasion that the innovation has or does not have benefit to the potential adopter (interpersonal communication work here); 191 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Decision about whether to adopt or reject the innovation; • Implementation (use) of the innovation; and • Confirmation that the decision to adopt the innovation was the right decision. Timeliness of Adoption Rogers (1995, pp. 22, 263-266) puts adopters into categories based on the timeliness at which they adopt innovations. These innovativeness and adopter categories have to do with when (early or late) potential adopters adopt an innovation. The timeliness and description of the categories are sequentially in the order of adoption as follows: • Innovators are few in number, considered deviants in the social system, but are the first to adopt. They seek information about new ideas and are risk takers willing to adopt with little information and much uncertainty. • Early adopters are the second to adopt. They operate more within the norms of a social system than innovators. Usually leaders/role models in the social system, they deliberately adopt innovations with little information in order to explore their usefulness to themselves and the social system. • Early Majority Deliberate is the third category and third adopters to adopt. This category ties with the Late Majority category in having the largest number of people that will adopt. Though not role 192 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. models in their social systems, they are the first to accept change and follow the opinions of early adopters. • Late Majority adopters are the next to adopt. These skeptics reluctantly adopt the innovation after removal of most of the uncertainty, their financial resources mandate it, or when pressured to do so. They do not like change. • Laggards are the last to adopt. Virtually all uncertainty must be removed for them to adopt. They cling to old traditions, do not like change, and are unwilling to do so. Rate of Adoption The speed that innovations are adopted as measured by the time it takes for percentages of people in the social system to adopt innovations is the rate of adoption. When measured, the rate of adoption takes the form of an S-shaped distribution curve that varies in slope for each innovation or for each social system adopting the same innovation. The faster an innovation is adopted, the steeper the slope of the S-curve. The slopes are different from innovation to innovation. Imagine what happens when computer-based systems diffuse at different rates but have dependencies on each other. The potential for several interoperability problems arise: (1) A computer-based system cannot exchange information with another system, if the other system is not available (see Figure 1 in Chapter 2); and (2) Both systems may eventually 193 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. be available; but, because they diffused independently, the information exchanged could not be validated. This is a problem if their connecting equipment, software, or both are not compatible. These problems lead to the following: • A computer-based system must include dependent systems (systems with which it shares information or functionality— technology clusters) in its diffusion. • A computer-based system that is dependent on a system that has not yet diffused must include non-diffused systems upon which it depends in its diffusion. • A system that is dependent on an already diffused system must include the already diffused system as part of its diffusion. • A system that exists, is operationally in use, and is dependent on other systems must be evaluated for diffusion. • If the diffusion of a system that exists, is in operational use, and depends on other systems has not been adequately diffused, it must be diffused. A system that diffuses independently but is dependent on a system that already diffused must include the already diffused system as part of its diffusion, i.e., all systems that are dependent should diffuse together. The definition and development of the innovations include its dependencies. 194 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Social System Determining the full membership of a social system is critical to understanding whether an innovation successfully diffuses. Individuals, groups, organizations, and subsystems are members or units of a social system. Rogers (1995) defines a social system as a set of interrelated units that are engaged in joint problem-solving to accomplish a common goal” (p. 23). A social system can be small or large, segregated to a certain group of people, such as golfers only, integrated to include a nation, or populated however one chooses to do so. Certain characteristics, as established in a social structure, help to determine how it is populated. Only with the knowledge of the total population in the social system can one know the extent to which the innovation diffuses. Rogers captures the essence of a social system as follows: Diffusion occurs within a social system. The social structure of the system affects the innovation’s diffusion in several ways. The social system constitutes a boundary within which an innovation diffuses. Here we deal with how the system’s social structure affects diffusion, the effect of norms on diffusion, the roles of opinion leaders and change agents, types of innovation- decisions, and the consequences of innovation. These issues involve relationships between the social system and the diffusion process that occurs within it. (p. 24) Social Structure and System Norms Structure brings order and stability to a social system. It enables patterns (such as rules and norms—established behaviors) and establishes 195 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. relationships and networks in the social system to maintain order and stability among the members or units. As such, structure affects the diffusion of innovations in the system. Rules, norms, relationships, and networks govern and control the actions, including adoption of new ideas, of the members or units within the social system. Diffusion and Members of the Social System The members or units of a social system are viewed as potential adopters of innovations. Relative to diffusing innovations, these members may consist of opinion leaders, change agents, potential adopters who span the range of the innovation-decision categories, and those who will not adopt. Opinion Leaders and Change Agents Opinion leaders belong to the social system and advise and influence members of it. These leaders gain their ability to influence based on competence, acceptability in the social system, and respect of the rules of the social system. Whether opinion leaders support or reject the adoption of an innovation, members of a social system generally follow the advice. Change agents come in the form of opinion leaders or agents, external to the social system, seeking the adoption or non-adoption of an innovation within the system. If they themselves are not opinion leaders, they use them to influence social systems. Change agents often face 196 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. heterophilous issues with members of social systems, especially if they are external to the system. Types of Innovation Decisions Who makes the innovation decision within a social system has an impact on whether and how fast an innovation is diffused. Individuals are each free to make optional innovation decisions, but these individuals are usually influenced by norms of the system. Nevertheless, the individual has complete control over adoption of the innovation. Consensus of members or units of the social system are needed to make collective-innovation decisions. The individual has some say over the adoption. Authority Innovation-Decisions, which result in the fastest rate of adoption, are adoption decisions made by a few in the social system who have been granted the authority to make these decisions. Technical expertise, power, and status form the basis for granting the few the authority. The individual has no say in the innovation that is adopted. The last type of innovation decision is the Contingent Innovation-Decision. This type of decision is made by individuals, consensus, or authority only after and contingent on an initial decision (of any of the other three types). 197 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Consequences Changes that occur to members or units of the social system after adopting an innovation are known as consequences. The three types of consequences are as follows: • Desirable Versus Undesirable Consequences— Results of the adoption are favorable or unfavorable. • Direct Versus Indirect Consequences— Immediate or secondary reactions to the innovation are experienced. • Anticipated Versus Unanticipated Consequences—Whether the changes are recognized and intended by the adoption or not. Desirable, direct, and anticipated consequences are those expected by change agents. Use of the innovation by the social system, though, determines its actual consequences. Impact and Use of Rogers’ Model Rogers’ Diffusion-of-lnnovation Process Model is based on diffusion research that began in 1903 with Frenchman Gabriel Tarde (Rogers, 1995, pp. 38-95). Rogers is a diffusion researcher who performs research, builds on the research of others, identifies contributions to the field, and also critiques his own and their research (pp. 96-130). He cites research supporting his model throughout his book. Diffusion plays a prominent role 198 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in society today. Rogers discusses its roles and research in the following excerpt: [Rjesults of diffusion research are commonly taught to students] in social psychology, communication, public relations, advertising, marketing, consumer behavior, rural sociology, and others.. . . United States government agencies are devoted to diffusing technological innovations to the public or to local governments, [e.g.,] National Institutes of Health, U.S. Department of Agriculture, and the U.S. Department of Education. These federal agencies also sponsor research on diffusion, as does the National Science Foundation and a number of private foundations. Federal research and development laboratories in the United States are required by law to transfer their technologies to private companies, who commercialize the technologies into new products that are then sold in the marketplace. . .. [Applications of diffusion theory [are] in development programs in Latin America, Africa and Asia.... [M]ost commercial companies have a marketing department that is responsible for diffusing new products and a market research activity that conducts diffusion investigations in order to aid . . . marketing efforts. This dissertation proposes to add to the knowledge base of Rogers and others as well as demonstrate use of diffusion concepts in the world of the practitioner—identifying the need, planning and budgeting for, developing, acquiring, and fielding computer-based systems. Diffusion research provides a common ground that offers a bridge to many divergent disciplines. One more is introduced in this paper. 199 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Analysis—Hypothesis 4 Do DOD and Navy processes use Everett Rogers’ Diffusion-of- Innovation Process Model to achieve interoperability? DOD and Navy processes inherently use Everett Rogers’ Diffusion-of- Innovation Process Model to diffuse systems, but the diffused systems are not achieving interoperability at acceptable levels. In 2000, the Joint Forces Command (JFCOM) identified a list of top ten interoperability issues (Janeczek & Borey, 2001). The Joint Requirements Oversight Council (JROC) senior decision-making body approved these issues and assigned them to the Office of the Secretary of Defense for Acquisition, Technology, and Logistics (OSD [AT&L]). The OSD (AT&L) Director of Interoperability initiated actions to resolve the issues. Visionary documents in the past have alluded to the definition of acceptable levels of interoperability as being the ability of the warfighter to exchange information anywhere, anytime. Analysis documents measure interoperability in terms of fratricide and leakers. Fractricide may occur, if information exchanges do not provide needed information to prevent it. Leakers are enemy ships or other platforms that get through U.S. defenses because of failure of systems to detect, send, or receive information about them. Though a quantifiable measure of an acceptable level of interoperability has not been defined, a growing body is beginning to use 200 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. lethality and survivability metrics associated with fratricide and leakers as criteria for measuring interoperability performance. Though DOD and Navy processes inherently use the Everett Rogers Diffusion-of-lnnovation Process Model to diffuse computer-based systems, they do not use it to achieve interoperability. The processes mandate an interoperability requirement, but neither the requirement nor diffusion of the system assures the achievement of acceptable levels of interoperability. An innovation that assures achieving overall interoperability has not yet been defined, developed, or diffused. The DOD and Navy processes provide direction to programs and their sponsors to develop individual computer-based systems and deliver them to warfighters to use in military operations. Computer-based systems are communicated through certain channels over time to members of a social system. This constitutes Rogers’ definition of diffusion. Computer-based systems are the innovations being diffused. Program Managers use interpersonal channels to communicate information about their systems. The time element is represented by milestone reviews that are scheduled to give decision-makers an opportunity to approve stages in the development of the system. The social system for the system includes the program developing the system, senior decision-makers who will eventually approve the system for use by warfighters, and the warfighter who 201 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. will adopt or use the system. Figure 11, in two parts, summarizes the relationship between Rogers’ Diffusion-of-lnnovation Process Model and DOD and DON processes. When Sessons-learned reports from military operations disclosed interoperability as a problem, it was added as a requirement to DOD and DON requirement and acquisition processes. The focus of the processes was still on the development of an individual system. Programs were now required to develop a system that was interoperable. New systems were designed to be interoperable, but did not replace or interoperate with legacy systems that were not designed for interoperability. Interoperability was still a problem. 2 0 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Rogers Elements, Concepts, and Attributes DOD and DON Processes Rogers Diffusion : . ,, . . „ , . • Diffusion Model Process Model : .. . . . .. p .. . i Attributes/Characteristics Elements : Requirements Generation System Defense Acquisition System I Idea, practice, or object that is •perceived as new by an INNOVATION jindividual or other unit of -adoption. Process identifies that new concept /computer-based system should be considered to resolve problems. Computer-Based System is the Innovation. •Innovation Development ■Process Problem identified in MNS/ORDs Solve Problem with System COMMUNICATION jConvergence of Information jExchange MNS/ORDs Approval Process System Approval Process Heterophiliousi Advocates different from Change Agents! adopters Delegated MNS/ORDs Developers Civilian Program Managers Homopliilious Change! A . . . .. . . . r A T . : Advocates similar to adopters Agents: Fleet Representatives Military Program Managers COMMUNICATION !,. .. . . CHANNELS ;^ edia used to communicate Interpersonal Interpersonal Mass Media: Widely available broadcasts N/A N/A Interpersonal! Word of mouth info delivery Meetings, Memos, VTC, Phones Reviews, Meetings, VTCs, Phone Figure 11. Summary relationship between Rogers’ Diffusion-of-lnnovation Process Model and DOD and DON processes. KJ s Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Figure 11 (continued) Rogers' Elements, Concepts, and Attributes DOD and DON Processes Roger's Diffusion Process Model Elements Diffusion Model Attributes/Characteristics Requirements Generation System Defense Acquisition System TIME Innovation Decision Process Senior Decision Approvals Senior Decision Approvals (Social System Identified) Innovativeness and Adopter Categories Senior Authority Designated i Senior Authority Designated Rate of Adoption Senior Authority Decision Program Manager Scheduled : : Opinion Leaders/Change Agents t Fleet Representatives Program Managers Most innovative Leader Senior Decision-Makers: Senior Decision Maker SOCIAL SYSTEM Opinion Leaders Combat Commandsj Resource Sponsors Change Agents_, Fleet Representatives] Program Managers Types of Innovation Decisions Disjoint Authorities ; Disjoint Authorities Consequence of the Innovation Warfighter Response ■ Trouble Reports Problem Addressed? : Problem Addressed? / ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------V In the two parts of this figure, DOD and Navy processes inherently use the Everett Rogers Diffusion-of-lnnovation Process Model. i -__________/ Over a twenty-plus-year time period, many strategies were attempted to achieve acceptable levels of interoperability. Some did not work and were abandoned. Some are still ongoing. Most of the strategies were technical solutions. The newer strategies are including doctrine, organizations, training, logistics, personnel, and facilities as part of the solution. Success of solutions to these newer strategies remains to be seen. But, thus far, neither they nor their predecessors have changed the innovation or process of diffusion. Nor has interoperability at acceptable levels been achieved. The newer systems are still autonomously developed by Program Managers and diffused by means of approvals from senior decision-makers. The older systems are being modified, if possible, but do require senior decision-maker authority to remain operational. Instead of diffusing systems, interoperable systems, families-of- systems, or systems-of-systems, DOD and Navy need to consider diffusing a social technology conducive to achieving interoperability. This epitomizes a “new way of doing business” —a phrase that is often quoted but never explained. Used here, it means developing and implementing DOD and DON processes to diffuse a social technology that achieves desired results, such as interoperability at acceptable levels or mission capabilities. Achieving interoperability with Diffusion Establishing effective and mutual information exchange among computer-based systems determines the technology of whether 205 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interoperability can be achieved. It is not difficult to diffuse a single system. This single system, though, may not be useful, if it is not interoperable with other systems. DON is adept at “diffusing” individual computer-based systems to DON fleet users (adopters). In a military operational environment, a system becomes one of many systems that perform functions contributing to a mission within a military operation. Without automated information exchange, fleet users manually perform the information exchange. This becomes difficult, if one system is on the water and the other is in the air. Computer-based systems must be interoperable to be useful and effective. The implication is that diffusion of an individual system is incomplete if, it does not include or account for the dependence on systems with which it must be interoperable. Rogers (1995) refers to the diffusion of like technologies together as technology clustering. “ A technology cluster consists of one or more distinguishable elements of technology that are perceived as being closely interrelated” (pp. 14-15). When a system depends on another/other system(s) to exchange information, diffusion of that system must encompass diffusion of the dependent system(s) as well. Systems within the technology cluster are dependent on each other, because they need to share information. If a dependent system does not diffuse with its interacting system(s), it may not be available to exchange information when called on to do so. 206 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Other systems are also at risk, if they need the information of an inadequately diffused system. The result of the non-occurrence of information exchanges when needed is an interoperability problem among dependent systems (see Figure 1 in Chapter 2). Diffusion of systems with their dependencies is a critical factor to its success. Diffusing military computer-based systems involves several DOD and military Service processes. Experience demonstrates that implementing one of the processes—the Defense Acquisition System—for a single system has taken a period of 5 to 20 years from start to completion. To be useful, effective, and minimize problems, a system must be interoperable with other systems, i.e., have dependencies. Each system goes through the process. Dependent systems need mutual alignment among their processes for each so that they diffuse together. Applicability of Rogers’ Model to DOD and Navy Processes DOD processes inherently use the Rogers Diffusion-of-lnnovation Process Model. This chapter discusses and summarizes the relationships between elements of the Rogers Diffusion-of-lnnovation Process Model and DOD and Navy processes. Discussion and analysis of this summary are in the remaining paragraphs of this chapter. To set the stage, Navy Program Managers are change agents to communicate knowledge of the systems and influence their adoption. The 207 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Defense Acquisition System includes the decision-making process that sets time boundaries for diffusing systems and their availability to stakeholders (users and others), and the social system for diffusing Naval systems today includes resource/functional sponsors and fleet users of the systems. Diffusion elements are identifiable in every diffusion study (Rogers, 1995, p. 10). The innovation element involves defining, developing, and making the innovation available for adoption. DON uses the Requirement Generation and Defense Acquisition Systems to define and develop Naval systems. These systems include processes that give autonomy, with senior authority oversight, to Program Managers for the systems from birth through the diffusion process. Each Program Manager is individually responsible for defining, developing, as well as all other aspects of the diffusion process for his/her systems. The Program Manager, though, does not have diffusion autonomy or responsibility for systems that belong to other Program Managers, and only joint Program Managers have joint responsibility for getting joint systems to work extending dependencies. Innovation Applicability The first question that needs to be answered is: What is the innovation that needs to be diffused? DOD and Navy processes provide direction and policy for determining the need, acquiring, and budgeting for computer-based systems. These systems are technology-based innovations 208 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. that are developed and produced to provide warfighters with information and tools to perform missions in military operations. From this perspective, computer-based systems are the innovations that are being diffused to warfighters. Warfighters have more difficulty in performing their missions, when the computer-based systems they are using are not interoperable. They need interoperable computer-based systems. In recognition of this need, DOD and Navy processes were modified to include interoperability as a technical requirement that was measurable. The intended result of the modifications was to enable the diffusion of interoperable computer-based systems to warfighters. Uncertainty, an attribute of the innovation element, arises when Program Managers do not have diffusion authority for all systems that need to interact. Innovation literature on uncertainty discusses its affect on changing technologies. Arthur L. Chait (1994) discusses how rapid technology diffusion contributes to uncertainty. Clayton M. Christensen (2000) discusses how “ disruptive” innovations, due to uncertainty, felled industry giants and boosted upstart companies. Christensen also discusses, by means of the resource dependence theory (Pfeffer & Salancik, 1978), the need to align “ disruptive” innovations with those who provide resources (Christensen, 2000). 209 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “Disruptive” technologies are those that cause a radical departure from the use of existing technologies. They rapidly achieve critical mass and force social system, economic, and political change. Interoperability causes systems to become “ disruptive.” Programs with systems exchanging information are important members of the social system of a diffusing system (Christensen, 2000). This will introduce inter-organizational issues that require understanding the alignment of culture, interactions, structure, product, and schedule among organizations with dependent systems. Navy systems that do not collectively diffuse with others become disruptive and are more likely to cause interoperability problems. Computer-based systems that were developed using modified policies that mandated interoperability continue to have interoperability problems. Modified policies have been modified yearly since 1996 with minimal impact on the overall interoperability problem. On October 30, 2002, Deputy Secretary of Defense (DEPSECDEF) Paul Woifowitz canceled policy documents for the Defense Acquisition System. He simultaneously issued an interim policy statement and required revised policy documents. On October 7, 2002, the Commander JCS cancelled the Requirements Generation System policy. These policies were not effective. The DEPSECDEF policy memo is provided in Appendix K. The Joint Staff policy memo is provided in Appendix L. 210 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DOD and Navy processes used elements of the Everett Rogers Diffusion-of-lnnovation Process Model for acquisition and distribution of computer-based systems. The diffusion model was only used by chance; and, even then, the processes incompletely address the Rogers diffusion model elements. Nevertheless, in use of the diffusion model, computer- based systems were technology products—the innovations. Uncertainty existed, and systems were not diffused as technology clusters. Each system diffused as a standalone product independent of other systems. Interoperability with other systems was managed via documents that provided interface specifications. Testing of interfaces was often accomplished using simulations, and Program Managers were rewarded for achieving success for the system and its attributes that were in his or her span of control. Focus was on the technology. Social, economic, and political aspects of the technology were addressed by each Program Manager but not in a cooperative, collaborative manner. Further uncertainty was introduced when DOD and Navy processes failed to provide a context that identified the boundaries within which the systems were required to be interoperable. When tested or provided to the warfighters, a system had interoperability problems with other systems and did not always suit the needs of the warfighters. An innovation will successfully diffuse only to the extent that its uncertainties are resolved. The uncertainties associated with not knowing 211 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the boundaries within which a collection of systems should interoperate to perform a mission potentially inhibit interoperability. Without this context, Program Managers do not know the systems that need to be interoperable. Reduction of these uncertainties must be addressed in DOD and Navy processes to achieve interoperability at acceptable levels. It is not clear whether the new policy documents will take the elements of the Rogers Diffusion-of-lnnovation Process Model into account, but the first step of acknowledging that current deficiencies in processes has been taken. Communication and Communication Channel Applicability Title 10 of the United States Code gives the authority for managing defense programs to Program Managers. This authority was autonomous to the extent that criteria for milestone decisions were satisfied. Essentially, Program Managers developed acquisition strategies that established the cost, milestones, developer selection plan, and fleet users of a computer- based system. This acquisition strategy identified the elements of diffusion of innovation. The milestones represented an aspect of the time element. Fleet users are potential adopters representing the social system. The computer-based system was the innovation. The Defense Acquisition System policy stated that Program Managers had to work closely with fleet users of the system and present criteria for approval to milestone decision authorities or their designees. To do this, Program Managers needed to 212 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. communicate with them. Most, if not all, of this communication used interpersonal channels to perform the communication. Little guidance was provided with regard to communicating with programs that developed systems that needed to be interoperable. This interaction was left to the discretion of the Program Manager. Program Managers are change agents who deliver the message about development and availability of their systems to potential adopters. Their delivery is interpersonal and uses formal and informal milestones and reviews identified in the Requirement Generation, PPBS, and Acquisition Systems. Program Managers deliver decision-making presentations to senior authorities for approval to explore the need for, develop, and diffuse systems. They also personally interact within their narrowly defined internal social system. Only recently are they being asked to address critical mass (sufficiency to sustain continued adoption by all who will be affected by the system) in their environments. This would include Program Managers of interacting systems and their internal environments. Alwin Mahler (1999) discusses how diffusion will not be complete until the critical mass accepts interacting technologies (pp. 719-740). Rogers (1995) also addresses critical mass and its origins (pp. 313-334). Several authors discuss the means and media of communicating technologies. Arun Rai, T. Ravichandran, and Subhashish Samaddar (1998) express concern about the adequacy of diffusion of the Internet based on internal influence 213 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. models (pp. 97-107). Eric Abrahamson and Lori Rosenkopf (1997) study the structure of social networks through which potential adopters of innovations find information about these innovations (pp. 289-300). These are but a few examples of diffusion literature on communications that address the importance of message delivery. The Program Manager for the Area Air Defense Capability had the requirement to be interoperable with the Global Command and Control System. In trying to meet his schedule, he could not wait for delivery of the GCCS-M system he needed from the GCCS-M Program Manager. His risk reduction course of action was to simulate an interface with GCCS-M and gain milestone approval based on the simulation. This is a common practice substitution. More often than not, the systems fail when actual systems are used in place of the simulations. Communications between the two Program Managers was insufficient to provide the information needed to either provide an adequate simulation or a real system. Another Program Manager of the Navy Fires Network needed to build a prototype system. He, too, was up against a schedule and could not negotiate a Portable Targeting Workstation (PTW) from its Program Manager. His solution was also to use a simulation—a PTW-like system. The success of Program Managers, as autonomous authorities, depends on their ability to acquire computer-based systems within budget, on time, and performing as required. They are unwilling to fail due to an 214 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. inability to get the cooperation of other Program Managers or gain access to other systems to use for their own testing purposes. Their interpersonal communication is narrowly focused on those who are in their chain-of- command, grant approvals, and those who will specifically use their system. Communicating with those responsible for or using other systems is not deemed essential nor in the span of control of a Program Manager. Time Applicability By the time a program becomes a program, the decision to adopt has already been made. Early adopters are usually senior decision-makers who concur with the need for a computer-based system to satisfy military operation missions. Under the current Requirements Generation System, decision-makers approve these needs. Under the Defense Acquisition System, decision-makers approve both the initiation of a system solution and, subsequently, the program that will acquire the system. These approvals constitute early adoption of the system. Decision, speed, and rate of adoption are attributes of the time element. Senior DOD and Navy authorities make the “ decision-to-adopf Navy systems by means of the Requirement Generation, PPBS, and Acquisition Systems. These time-related processes include decision points for establishing and continuing programs that will develop, produce, and diffuse systems. The decision points are the times or milestones at which 215 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. these authorities adopt (approve) the systems in their available states of development or production. The social system for Navy computer-based systems is vast and much broader than Program Managers typically consider as users. Their users are viewed to be the warfighters who will ultimately operate the system. Missing are the programs responsible for systems interacting with the diffusing system. In reality, the social system includes the decision makers who approve the systems, contractor and government developers of the systems, laboratories and test facilities, warfighters who operate the systems, other DOD and each of the military Services who have potential interoperating systems, and potentially many others. These stakeholders must all be included as potential adopters in the social system. Program engineers, as developers, take ownership of the systems they are developing and hence adopt these systems immediately. Labs and test facilities are the next adopters as they begin to understand the value added of the system. Fleet users, as recipients of systems, progressively make the decision-to-adopt after authority approval and delivery of systems to test, training, demonstration, exercise, and operating (based on availability) shore-based and afloat sites. Their decision-to-adopt is generally conditional based on resolution of problems with the systems. The decision to adopt computer-based systems is primarily authoritarian. Program Managers implement the Defense Acquisition 216 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. System and request permission throughout the process to proceed to the next milestone. A small body of senior defense authorities reviews decision criteria and decides whether the program should continue. Congress also can make this decision. Program Managers, though, autonomously present their systems to decision-makers. Interoperability with other systems is only provided from the perspective of the autonomous Program Manager. Policy documents are beginning to address this shortfall DOD Directive 5000.2R, 2001). Until the social system for diffusing systems includes this group and they are given a decision-to-adopt authority in the diffusion of all systems with which their systems interact, diffusion of the interacting systems will not be adequate. The risk of interoperability problems will exist. Including other systems as part of the decision process introduces greater complexity and slows the diffusion process. Namwoon Kim and Rajendra K. Srivastava (1998) address methods for speeding up adoption. All too often, and in response to emergent urgent needs, programs do not begin with the processes and products prescribed by policy. Their beginnings are triggered through many sources, such as a prototype system, that respond to an unmet need that a decision-maker had when serving as a fleet user. The source may also be a prototype system that resulted from an outgrowth of a science and technology, research and development, or proof of concept project. Whatever the source, decisions to adopt prototype systems are also made by early adopters. 217 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Whether initiated within or outside of DOD and DON processes, decision-makers require that programs follow guidelines prescribed by the processes. Milestones are combined and the time line shortened, if necessary, but the same documentation is needed for approval of the system for subsequent adopters. The interoperability challenge for these systems, whether of prototype origin or not, is as addressed previously—one of context. What are the overarching missions in which the system will need to perform? What are the other systems that need to be interoperable within each of the missions? And, will all of the systems that need to be interoperable be available when needed— are their time lines synchronized? Ground rules to address these questions in DOD and DON processes have not been established, nor do the processes address the issues presented by these questions. Individual systems with individual time lines with no “big picture” context are in the processes. The time element shortfall is failure to address a synchronized time line to diffuse a technology cluster of interoperable computer-based systems in DOD and DON processes. The Defense Acquisition System was based on a time line that began with identification of the need for a computer-based system and ended with the fielding or diffusion of that system to end-users. Milestones were established along the time line to review the progress of the system and confirm the need for its continuance. The actual individuals who received 218 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the end product had but representative voice in the requirements generation process and little, if any, voice in the acquisition process. Their voice, though, has been strong in stating that the systems are not interoperable. Social System Applicability Identifying the applicable social system is probably the most significant of Rogers’ elements to support the achievement of interoperability among Navy systems. The social system that needs to adopt interoperability includes the entire Navy. This population becomes smaller when interoperability is segmented to families- or systems-of-systems developed for some specific purpose. Even this segmentation requires a significant social system. It includes the warfighting end-users, programs for all of the systems that need to be interoperable among the family- or system-of- systems, as well as other stakeholders and decision-makers for all of these systems. The difficult part is being able to identify the appropriate social system for the systems. Current social systems consist of the program for an individual computer-based system, its decision-makers, and the end-user warfighters for that computer-based system. Casual attention is paid to the social systems of other interoperating computer-based systems. Systems that are not interoperable have resulted from this casual attention. 219 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Edgar Schein (1985), in the area of culture, points out that, even within a group, non-comparable technologies could result from different observers and that the difficulty comes in determining how the members relate (pp. 1-22). Malcolm Smith (1998), in a London, England-based study, investigates how the diffusion of accounting innovations impacts organizational change (pp. 60-63). He delves into how new accounting systems require the matching of managerial practices with cultural settings to attain success. Bart Nooteboom (2000) notes that interrelationships between firms can enhance diffusion and innovations (pp. 915-940). Chait (1994) says that technology is shaping organizational structures. The emergent literature indicates the need to pay close attention to organizational structure in the diffusion of innovations. Summary—Hypothesis 4 Everett Rogers’ Diffusion-of-lnnovation Process Model is an inherent part of DOD and DON requirement and acquisition processes. These processes primarily focus on developing individual computer-based systems, as opposed to diffusing them, but diffusion is part of the processes. Diffusion of a system occurs in milestone reviews that result in approvals from senior decision-makers to develop or deliver the system. The systems were successfully diffused—adopted and used. Systems are communicated to senior decision-makers who are convinced, over time, that the system is 220 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. one that warfighters need to adopt. Warfighters, who become users of the system, have little or no voice in the adoption of the system. Senior decision-maker approvals are analogous to what Rogers describes as authority decisions that, nonetheless, result in valid diffusions. Rogers’ elements of diffusion (innovation, communication channels, time, and social systems) and their interactions are the heart of diffusing innovations. These elements, in some form, were used to successfully diffuse systems, but the systems did not achieve interoperability at acceptable levels. The implication is that the system is not the innovation to be diffused to achieve interoperability at acceptable levels. What, then, is the innovation— a technology that assures the achievement of interoperability at acceptable levels? Technical solutions have not yet worked. Economic solutions are potentially unaffordable. A social solution may have potential—a social technology that focuses on achieving acceptable levels of interoperability. Just as a system required diffusion, a social technology that is conducive to achieving acceptable levels of interoperability must be diffused. This means the social technology must be communicated to those with a stake in it who must be convinced over time that the social technology is one they want/need to adopt. The social technology, communication channels, schedule, and social system all need to be defined, developed, and implemented for successful diffusion. Diffusing a social technology is 221 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. difficult, but, as demonstrated in national infrastructure-related innovations discussed in Chapter 7, achievable. The scope of DOD and DON processes should no longer be the development of individual systems and their inherent diffusion. This scope should encompass overarching objectives that lead to the accomplishment of DOD and military strategy. It should be the means to implement these objectives. Physical technologies do not accomplish objectives. The people, as orchestrated through a social technology, accomplish these objectives through use of physical technologies. Computer-based systems, as examples of physical technologies, become natural by-products of the diffusion of the social technology. A social technology is the innovation. It must be defined, developed, and subsequently diffused. The results that are desired from the social technology must be included as part of its definition and development. As an example, some of the factors that contribute to interoperability problems include legacy systems, “stovepipe” development of systems, battle management, lack of funding, connectivity issues, integration issues, duplicative systems, unavailable systems, et al. These factors need to be addressed in the definition, design, and development of a social technology conducive to achieving acceptable levels of interoperability. Rogers’ elements of diffusion and their interactions are the heart of diffusing innovations. Just as a system required diffusion, a social 222 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technology that is conducive to achieving acceptable levels of interoperability must be diffused. This means the social technology must be communicated to those who use it. They must be convinced over time that the social technology is one they want/need to adopt. Diffusing a social technology is difficult, but, as demonstrated in previous national infrastructure-related innovations, achievable. Significant is the fact that, as discussed above and in Chapter 4, SECDEF and CJCS canceled the Defense Acquisition System and Requirements Generation System policy documents. These documents set forth directives, instructions, and guidelines to implement the major policies that mandate the requirement for interoperability in computer-based systems. The memo canceling acquisition policy documents stated: “I am issuing interim guidance .. . to rapidly deliver affordable, sustainable capability to the wafighter that meets the warfighter’s needs” (SECDEF, 2002). Interoperability, as discussed in Chapter 3, is a warfighter need. Current policy is not working. The needs of the warfighter are not always being met. The strategies scorecard (Table 8, Chapter 5) corroborates interoperability deficiencies in warfighter needs. Diffusing a social technology should be a top priority incorporated into solutions to address warfighter needs. High among those needs is achieving interoperability at acceptable levels. The overarching interoperability problem has not been solved. 223 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Many fields of study, as well as practitioners, used diffusion research to successfully demonstrate advances in the fields, market products, or even open and expand a new study area, such as communications. These successes achieved critical mass and demonstrated that diffusion research is a viable approach to gaining the acceptance and adoption of innovations. Interoperability among computer-based systems had all of the markings of an innovation that needed help to successfully diffuse. Rogers’ Diffusion-of- lnnovation Process Model appears to offer a means to successfully diffuse interoperability so that it is achievable. More about these successes are in Chapter 7. 224 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER VII EVERETT ROGERS’ DIFFUSION-OF-INNOVATION PROCESS MODEL: AN IMPROVED PATH TO ACHIEVING INTEROPERABILITY? Introduction—Hypothesis 5 Hypothesis: Everett Rogers Diffusion-of-lnnovation Process Model potentially offers an improved path to achieve interoperability. Our nation has experienced many interoperability successes. Use of the telephone is an integral part of everyday life. Individuals are able to exchange information and use this exchanged information as an effective part of their normal lives. These same individuals are free to get on an airplane to go all over the world and feel relatively safe that they will arrive at their intended destination under normal operations of the airlines. Travel via the airlines has another underlying interoperability infrastructure that exchanges information and uses this exchanged information to assure that airplanes effectively get to their designated destinations. The railroad, post office, and Internet infrastructures demonstrate additional interoperability successes that people take for granted as a normal way of life. 225 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. More basic than the ability of individuals to use technology innovations that allowed them to exchange information was the establishment of the infrastructure to make a diffusion of the technology occur. An infrastructure represents the networking of technology innovations. Successful diffusion occurs with critical mass use of the infrastructure. This chapter explores how historical infrastructures achieved interoperability successes and the potential implication of these successes on DOD and Navy towards their achieving interoperability at acceptable levels. Additionally, the chapter provides an assessment of using the Rogers Diffusion-of-lnnovation Process Model in the infrastructure interoperability successes. Moreover, however, as part of the hypothesis of this chapter, the basic themes and strategies for achieving interoperability are applicable to infrastructures and are subsumed in the Everett Rogers Diffusion-of- lnnovation Process Model. Information Sources for Historical Infrastructures Dr. Amy Friedlander was sponsored by the Corporation for National Research Initiatives (CNRI) to conduct a series of historical large-scale infrastructure studies. From a CNRI perspective, historical precedents may shed light on new technical, social, and economic challenges introduced by an evolving information infrastructure. The intent of the studies is to potentially reveal insights into information and knowledge. Four CNRI studies conducted by Dr. Friedlander and discussed below depict examples 226 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of interoperability successes. Abstracts for the telephone, electricity, railroads, and banking studies are in Appendices U, V, W, and X, respectively. Questions that these studies answered were: • How did the infrastructure begin to develop? • When did it achieve critical mass? • What were the driving technologies? • What were the public and private sector roles? » How did an integrated infrastructure evolve? In addition to these infrastructure studies, Dr. Robert Kahn, President of CNRI and also distinguished as being one of the founders of the Internet, and Dr. Vinton Cerf provide a source of information for the Internet infrastructure. Drs. Kahn and Cerf, at the request of the Internet Policy Institute, prepared a condensation of a longer paper on the Internet and its infrastructure. Most of this condensation is in Appendix Y. Dr. Kahn also provided a preface for each abstract prepared by Dr. Friedlander. The airlines industry is the final infrastructure discussed in this chapter. Source material describing the airline history and how it became an infrastructure was available on the Internet (URL 4). Interoperability Successes Interoperability successes discussed in this section consist of infrastructures that were created in response to evolving technologies, economies, social systems, and policies. The importance of this is that it 227 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. shows how technology drives societal and economic change and drives the progress of mankind. Infrastructures are created when social systems acknowledge and react to the needs of the many who vie for the same resources. Individually, scarce resources increase technology costs, making them available only to those who can afford them. Resource sharing, through infrastructures, reduces costs by distributing the burden to the many. The following definition of infrastructure is the one used in this research: An infrastructure is a large-scale technological system, consisting of immovable physical facilities and delivering [an] essential public or private service(s) through the storage, conversion and/or transportation of certain commodities. The infrastructure includes those parts and subsystems necessary for fulfilling the primary storage, transportation and/or conversion function(s) as well as those supporting a proper execution of the primary function(s). (Verhoef, 1999) To achieve interoperability in an infrastructure, information is one of the commodities stored, converted, and/or transported. Infrastructures demonstrate interoperability success, because they provide and were created using effective sharing and use of information, material, and services. They unify technologies by providing common commodities or services to large societal groups. The exploration of successful interoperability achievements in this chapter includes the following historical infrastructures: • Telephones, • Electricity, 228 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Airlines, • Railroads, • Banking, and Internet. Telephones The telephone was invented in the 1870s to solve problems introduced by the telegraph infrastructure. Dr. Amy Friedlander addresses both infrastructures in her abstract provided in Appendix U. Diffusion of the telephone was initially targeted to local services because of technology limitations. Though independent companies went after markets that the Advanced Telephone and Telegraph (AT&T) company had ignored, eventually AT&T gained technology and organizational control of both local and long-distance telephone and telegraph services. AT&T gained control over independent industries by establishing technology policy, acquiring or merging with competing companies, and accepting and adhering to government intervention. This control gave them cooperative conditions, though monopolistic, and enabled them to set standards needed to sustain the infrastructure. Electricity Origins of the electrical energy infrastructure began in the late 1870s, when Thomas Edison and his team were searching for a solution to interior 229 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. lighting. Edison used the gas infrastructure model to establish technology, organization, and policy structures to create the electrical lamp. The organizational structures were conducive to forming companies that focused on specific electrical products, services, and financiers. These became holding companies that stabilized smaller companies and introduced standards. Cooperation among private companies, including holding companies, held the electrical energy infrastructure together for the most part, but government intervention was needed to quell price controlling. Appendix V provides the abstract developed by Dr. Amy Friedlander for her electricity infrastructure study. Airlines The airline infrastructure was born as part of another national infrastructure—the Postal Service. The Postal Service, in 1917, contracted for development of aircraft for an experimental mail service. As an interim measure, until the contract was awarded, the Post Office used Army aircraft to deliver mail. By 1921, they established their own fleet of aircraft. With the successful delivery of mail more than three times faster than train service, the government subsidized the venture. Finally, in 1925, law was passed to establish a permanent, non-experimental airline industry. Standard routes were established and used as the basis for contract airline bids for delivery of mail. The quality of aircraft improved; and, in 1926, 230 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the airlines began to take on passengers. Government intervention provided controls and standards that caused industry mergers and buyouts resulting in larger and more stable airlines for mail delivery. These mergers and buyouts caused the standardization and stabilization of aircraft also. As with other national infrastructures, the airlines required cooperation and standardization. Private companies and government interventions helped shape the infrastructure. Competition among private companies helped sustain the airline industry and support the economies of its users. Railroads Railroads and their infrastructure spanned a 70-year period beginning in the late 1820s. Local lines dominated until the 1850s, when they were linked together to provide long-distance travel. Organizationally, major companies informally merged via cooperative agreements to standardize gauge and administrative practices. Appendix W provides the abstract developed by Dr. Amy Friedlander for her railroads infrastructure study. As with the previous infrastructures, cooperation and standards emerged as themes in development of the railroad infrastructure. Banking Banking constitutes an information rather than physical technology. Initially, banks provided credit and invested funds using money obtained for safekeeping from the public. Banks were privately owned and federally 231 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. chartered, but Alexander Hamilton further imposed government intervention with his proposal to use privately-owned banks to serve public missions. This commitment was retained through President Franklin Delano Roosevelt’s New Deal equity reforms. Cooperation, collaboration, and standards had a heavy hand in development of the banking infrastructure. Despite government intervention, private banks cooperated to establish monetary standards that stabilized paper money. The collaboration between government and financial institutions was essential to the infrastructure. Appendix X provides the abstract developed by Dr. Amy Friedlander for her banking infrastructure study. Internet Prior to the advent of network technology, interoperability was viewed as interfaces between two computer-based systems. Success in data sharing consisted of physical connection between two computers; transmission, receipt, and acceptance of data from the sending computer; and processing and use of the data sent. Network technology caused a capability leap that allowed computers to share data and systems functions. This new technology allowed multiple computers connected to the network to receive data from any other computer-based device that was connected to the network. Again, data 232 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. sharing depended not only on the connection but also on the ability of computers on the network to effectively exchange and use the data sent. In the early 1970s, the Defense Advanced Research Programs Agency (DARPA) initiated the first wide area network technology. Dr. Robert Kahn and Dr. Vinton Cerf later used this and other technologies to link networks. Appendix Y provides a condensation of the Internet infrastructure developed by Drs. Kahn and Vinton. The networking of networks increased data sharing to include computer-based devices on the network of networks. More about the history of the Internet can be found on the Internet (URL 5). The network of networks created by DARPA was initially called the ARPANET. This linking of networks was the beginning of the Internet. Dr. Robert Kahn has the following view of the Internet: “ The Internet, as an integrating force, has melded the technology of communications and computing to provide instant connectivity and global information services to all its users at very low cost” (Kahn & Cerf, 1999). The Internet is an architecture infrastructure that combines communications and information infrastructures. It consists of connections among hundreds of thousands of independent computers, communication systems, and other information systems. Common communication standards, procedures and formats make the connection possible. Key to the connectivity is the linking of independent networks. These networks include groupings of computer-based communication and information 233 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. systems that are combined by the Internet architecture infrastructure. Connectivity is available via the communications infrastructure. Creation, storage and access of information resources are available from the information infrastructure. Prior to the advent of networks, one interoperability problem was the retransmission of information by computer-based systems that received, processed, and used data from another system. Each system processed and stored data differently. When this data was retransmitted to another or other computers, it was not always in the same form as sent by the data originator. Users of computer-based systems were not getting consistent, reliable data. This was a standards problem as well as a connectivity problem. Based on interoperability successes among historical infrastructures, the resolution requires cooperation among the thousands of owners of transmitting systems, government and industry entities, and other stakeholders. Cooperatively, they must adopt common standards, data bases, and processes and operate within an Internet infrastructure. Standards and cooperation were two key factors in establishing the Internet infrastructure and attaining interoperability. Many organizations, including government, industry, and academia, formed cooperative alliances. Independent network owners adopted guidelines and rules that provided integration tools and commonality for all networks. 234 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The Analysis—Hypothesis 5 Does the Everett Rogers Diffusion-of-lnnovation Process Model potentially offer an improved path to achieving interoperability? The answer is “ yes.” But this answer depends on a clear understanding and use of the Rogers Diffusion-of-lnnovation Process Model and its applicability to physical or information technologies that need to be diffused. To make this assessment, this section examines the use of the Rogers model in historical infrastructure successes and the implication of these infrastructure successes on the DOD and Navy achievement of interoperability. Use of the Rogers Diffusion-of-lnnovation Process Model in Infrastructure Successes Historical infrastructures followed two themes to successfully integrate and interoperate technologies. The themes were the attainment of national order and critical mass adoption of standards. Within these themes, interoperability was achieved. Basic were interactions with physical or information technologies and social, economic, and political elements. These elements are embodied in the Rogers Diffusion-of-lnnovation Process Model elements. They were needed to implement the strategies. Hence, the historical infrastructures inherently used the Rogers Diffusion-of- lnnovation Process Model. This section examines the themes, achieving interoperability within them, and the relationship between historical 235 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. infrastructures and the Rogers Diffusion-of-lnnovation Process Model, and implications of potential strategies derived from historical infrastructures on DOD and Navy. Historical Infrastructure Themes National Order Finding national order was a key factor to achieving interoperability success for historical infrastructures. To attain this order, a monopoly, cooperative body, or government intervention was necessary. This caused a monopolistic-like condition that served to reduce conflicts and establish common integrated rules and standards imposed on users or potential users of the infrastructure to achieve resource sharing. In most of the infrastructures the federal government intervened to gain cooperation or set standards. After order was established and critical mass attained, users of the infrastructure pushed for anti-monopoly behavior. To assure that monopolistic behavior did not drive prices up, they wanted competition and an end to the monopolistic conditions. DOD and the Navy have a bureaucratic organizational structure— based on hierarchy and order. Ironically, order is disjoint among DOD and Navy organizations seeking to achieve interoperability among their computer-based systems. Order is not conducive to interactions across hierarchies. Title 10 of the United States Code, establishes DOD and Navy 236 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. organizational structures for acquiring computer-based systems. Title 10 identifies the roles of Program Managers who are designated to acquire systems using the Defense Acquisition System. They focus on the technical development of an individual system rather than on its social dynamics across hierarchical organizations. Program Managers are accountable to multiple people and organizations, but accountability and order among themselves are lacking. Additionally, accountability and order among the organizations in which Program Managers physically reside are lacking. Changing the social structure of organizations is a monumental effort. The Naval Transformation Roadmap acknowledges the need for organizational change in order to evolve with advancing technologies. Unwilling, thus far, to take on a major overhaul of Title 10 and Defense-wide organizational structures, DOD and Navy are initiating cooperative restructuring across organizations at senior-most levels. This moves them closer to the social-technical construct used to develop infrastructures that achieved successful interoperability. In cooperative restructuring, a single organization may be responsible for acquisition of certain types of systems. They must also include other organizations in the process. As an example, the Space and Naval Warfare Systems Command (SPAWAR) has the responsibility for the FORCEnet pillar. FORCEnet is a concept that establishes an infrastructure capability to enable combat, weapon, and other systems to interact via networks, 237 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. communications, and information exchange. Though SPAWAR is the acquisition lead, the Naval Sea (NAVSEA) and Naval Air (NAVAIR) systems commands and other organizations are part of the FORCEnet team. Many organizations have lead roles with team participation from other organizations. The team establishes and enforces standards, guidelines, and approvals to orchestrate and guide development, testing, and interoperability of a system by a Program Manager. Using teaming, DOD and Navy are moving in the direction of the type of ordering instituted in infrastructure successes. Caution is needed, though, because cooperative agreements have been established in the past, but their implementations were only partially successful. Appendix Z provides a Memorandum of Agreement (MOA) with SPAWAR, NAVSEA, and NAVAIR. Earnest efforts were made to honor the MOA; but, though the effort resulted in improvements in some interoperability problems, it did not reach far enough across organizations or prevent programs from becoming sources of interoperability problems. Teaming to establish order is only effective, if the standards and guidelines are institutionalized by policy and used by the critical mass. Reaching critical mass includes the programs as part of the teams, but they are so numerous that the team may become unmanageable, unless programs agree to limited representation on a team .. 238 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Standardizing Across the Infrastructure Establishing standards was the second key factor in historical infrastructure interoperability success. Historical infrastructures were developed using existing standards or newly-created standards, depending on which worked best. Internet infrastructure developers built a common interface around existing standards. Banking infrastructure developers needed a new and common monetary standard. Standards introduced stability and reliability for users of the infrastructure. DOD has produced standards for twenty-plus years. Technology outpaces the standards, making it difficult to use newer technologies while conforming to the standards. Additionally, in acquiring computer-based systems, organizations adopted the standards of the time and of their choice. Though the Joint Technical Architecture (JTA) documents standards for computer-based systems across DOD and the military Services, legacy systems that use standards of the past are getting waivers to JTA. Also, the JTA currently caters to military Service differences, causing differences in standards between the Services. Given the current state of standards, a strategy is needed to assess and make decisions on attaining standards that work. 2 3 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Achieving interoperability in Historical Infrastructures National order and standards as imposed by controls mandated under monopolistic or cooperative conditions forced organizations to effectively exchange information. This cooperation among organizations was reflected in the cooperative and effective information or material exchange of technologies. When cooperative conditions gave way to competition, standards and controls were already in place with continued adherence. With forced competition, new companies, such as those affiliated with the telephone industry, began moving away from standards or failing to support the infrastructure. Lacking standards and maintenance, the infrastructure began to falter. The great divestiture of monopolistic power of the telephone industry caused by the Telecommunications Act of 1996 (1997) caused diversification that led to many upstart companies entering the industry. Many standards and the maintenance of the infrastructure were diminished or lost. The industry suffered. Today’s trends are mergers that reunite companies. They appear to be seeking interoperability to repair a degraded industry. 240 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Historical Infrastructures and the Rogers Diffusion-of-lnnovation Process Model Rogers’ Diffusion-of-lnnovation Process Model and National Order National order means that a collective group of stakeholders with common goals join together to achieve those goals. Individual goals are modified or aligned with common goals of the collective group. Because of the increased number of stakeholders, the complexity of agreeing on and achieving common goals increases. From the perspective of the Rogers Diffusion Model, each diffusion element expands when monopolistic or cooperative conditions are created due to the need for national order. Rather than diffusing a single system, the network, family-, or system-of- systems is the technology innovation that gets diffused. This constitutes diffusion of multiple related systems, or a technology cluster. The time schedule expands to assure that all systems that are part of the network, family, or system are ready to diffuse together. Communication and communication channels are much more complex, because they involve a greater number of people and systems. Achieving critical mass will require more mass media interactions rather than interpersonal communications due to the increase in the social system. Stakeholders for all of the systems are part of the social system. 241 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Rogers’ Diffusion-of-lnnovation Process Model and Standardization From the perspective of the Rogers Diffusion Model, a common standard reference infrastructure is the technology innovation that gets diffused. Existing program schedules will be perturbed by the additional development of interfaces and functions to access the infrastructure. Also, development and diffusion of the infrastructure that supplements the Internet standard and guidance and policy to be imposed on systems will impact program schedules. Communication and communication channels reach for critical mass using mass media communications across all programs to disseminate the standards and guidelines. The social system includes stakeholders for all programs. The Rogers Diffusion Model diffuses standards as the technology innovation of this third strategy. The time required to diffuse standards changes as standards change. With current usage of commercial products and the rapidity at which they evolve, it is difficult to maintain consistent standards. Communication and communication channels require critical mass and mass media means, due to the complexity and quantity of potential adopters in the social system. The social system includes stakeholders associated with acquisition of computer-based systems in DOD and Navy. 242 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Relationships Between Rogers’ Diffusion-of-lnnovation Process Model and Historical Infrastructure Implementations Tables 9 and 10 provide summaries of the relationships between the infrastructures and elements of the Rogers Diffusion-of-lnnovation Process Model. The tables address each of the elements with their initial development and public intent and how they were sustained over decades. Table 9 focuses on diffusion of the technology innovation. The innovation developed was either a physical or information technology that evolved over decades to become part of the infrastructure. Adoption of the technology achieved critical mass that mandated infrastructure development to accommodate public demand. Each of the Rogers Diffusion-of-lnnovation Process Model elements is addressed from this perspective. The infrastructure was sustained through the decades. Most of the technology diffusions started locally, expanded nationally, then internationally. Table 10 focuses on change agents. These change agents influenced the social system to adopt and use standards and technologies. They formed monopolies or banded together companies with vested interest in the proliferation of the technologies to create cooperative conditions with common goals. Cooperative conditions took the form of monopolies, because control was needed for change agents to assure that order and standards were adhered to among themselves and other stakeholders. Federal intervention supported cooperative conditions until the infrastructure stabilized or economies demanded competition. 243 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table 9 Relationship between the Everett Rogers Diffusion-of-lnnovation Process Model and Historical Infrastructures with a Focus on the Innovations Diffusion Elements Infrastructure Duration Telephones Electricity Airlines Railroads Internet Banking Innovation Developed Physical Physical Physical Physical Information Information Sustained Long distance telephone service Lamps/ electrical energy Long-distance air transportation Long-distance rail transportation Information sharing Information sharing Com m unication Developed Monopoly Authority Cooperation Authority Cooperation Authority Cooperation Authority Cooperation Authority Cooperation Sustained Federal Intervention Federal Intervention Federal Intervention Federal Intervention Federal Intervention Sustained Competition Competition Competition Competition Competition Competition Communication Channels Developed Local Interpersonal Local Interpersonal Local Interpersonal Local Interpersonal Local Interpersonal Local Interpersonal Sustained Mass Media Mass Media Mass Media Mass Media Mass Media Mass Media Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table 9 (continued) Diffusion Elements Infrastructure Duration Telephones Electricity Airlines Railroads Internet Banking Time Developed 1837-1940 1870-1940 1917-1926 1820s-1890 1985-2003 1790s-1930s Sustained 2003 2003 2003 2003 2003 2003 Social System Developed Local Local Local Local Local Local Sustained National/ International National/ International National/ International National/ International National/ International National/ International , ' v Diffusion of the innovation element, though physical or information-focused, also included other diffuse elements— communication and communication channels, time, and social system. Through these elements, social, economic, and political impacts .were essential to the innovation diffusion and infrastructure development. K3 ■ f c s . cn Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table 10 Relationship between the Rogers Diffusion-of-lnnovation Process Model Elements and Historical Infrastructure with a Focus on Change Agent Influence on the Social System Diffusion Elements Infrastructure Duration Telephones Electricity Airlines Railroads Internet Banking Innovation Developed Long distance telephone service Lamps/ electrical energy Long-distance transportation Long-distance transportation Information sharing Stabilize national debt/ money management Sustained Upgraded Upgraded Upgraded Upgraded Upgraded Public Use— Private Banks Communication Developed Monopoly Authority Cooperation Authority Cooperation Authority Cooperation Authority Cooperation Authority Cooperation Sustained Federal Intervention Federal Intervention Federal Intervention Federal Intervention Federal Intervention Sustained Competition Competition Competition Competition Competition Competition Communication Channels Developed Critical mass attained Critical mass attained Critical mass attained Critical mass attained Critical mass attained Critical mass attained Sustained Critical mass expanded Critical mass expanded Critical mass expanded Critical mass expanded Critical mass expanded Critical mass expanded K 5 O ) Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table 10 (continued) Diffusion Elements Infrastructure Duration Telephones Electricity Airlines Railroads Internet Banking Time Developed 1837-1940 1870-1940 1917-1926 1820S-1890 1985-2003 1790s-1930s Sustained 2003 2003 2003 2003 2003 2003 Social System Developed Nation-wide Nation-wide Nation-wide Nation-wide Nation-wide Nation-wide Sustained World-wide World-wide World-wide World-wide World-wide World-wide Interoperability occurs with the successful diffusion of an infrastructure. This involves interaction among all diffusion elements, particularly the change agents that influence social system decisions. V J ro a -4 As shown in Table 10, historical infrastructures successfully diffused physical and information technologies by incorporating monopolistic or cooperative conditions as a social system element of the diffusion. Politically, communication change agents evolved from monopolistic, to federally-imposed, to competitively-driven entities. Communication channels expanded from interpersonal local exchanges to mass media nation-wide and international channels. Technologies and infrastructures reached critical mass adoption locally, nationally, and internationally. Implication of Interoperability Successes for DOD and Navy Achievement of Acceptable Levels of Interoperability Historical interoperability successes are important in that experiences and methods to achieve these successes may be applicable to DOD and Navy achievement of interoperability at acceptable levels. All of the historical infrastructure successes were initiated by the introduction of a new physical or information technology followed by a recognition or need to share resources to more effectively use the technology— in other words, recognition of the need to be interoperable. Though the banking infrastructure does not claim to be based on a technology, Everett Rogers defines information as a technology. The banking infrastructure identifies information as the basis for the infrastructure. Also, the banking industry used existing technologies innovatively and followed a construct similar to the others to develop an infrastructure that promoted interoperability. 248 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Review of historical infrastructures revealed two common themes. The themes resulted from geographic, demographic, social, and economic growth impacts on the adoption of new technologies/innovations. Not all of the technologies were physical. Banking, for one, was based on information innovations. The common themes of the infrastructures centered on the need for national order and standardization. Three potential strategies emerged from assessing the historical infrastructures. The strategies are as follows: • Process Strategy. Expand the Scale of Program Manager. • Internet Strategy. Use the Internet as a common bus with its existing standards. • New Infrastructure Strategy. Create a new infrastructure with new universal and national standards. Process Strategy The process solution of expanding the Program Manager scale is a potential strategy associated with creating a monopolistic or cooperative condition to achieve interoperability at acceptable levels. DOD and Navy Program Managers have been working on the interoperability problem for many years for individual systems. As discussed throughout this research, interoperability is greater than a single computer-based system. It includes a network, Family-, or System-of-Systems (FOS/SOS) that must share 249 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. information, functions, and data bases. Responsibilities of the Program Manager must expand to a greater scale so that he, she, or they are responsible for multiple systems that need to be interoperable. Each of these systems is affected by social, economic, and political elements. Viewed collectively, the social, economic, and political elements expand to consider all of the systems. Uncertainty about systems that are not in the span of control of the Program Manager is reduced using this strategy. The process solution of expanding the Program Manager scale has its problems. As an example, some systems may belong to several networks or families-of-systems, or two Program Managers may use differing standards that cause incompatibility with other networks or systems-of-systems. Another potential problem is that management of multiple systems may require that the Program Manager delegate management of one or more systems to others. If not closely monitored, this situation may create a similar single system, single manager approach as exists today. Internet Strategy Using a common bus that is available to and accessible by an infinite number of systems to interact is the strategy behind the Internet solution. The Internet established a common bus for access by computers, peripherals and other equipment, and other networks, regardless of standards or non-standards these devices used as independent entities. 250 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Many DOD and Navy legacy and standalone systems need to be replaced, unless they have a viable means of exchanging information and achieving acceptable levels of interoperability without disrupting the capabilities of new systems. The Internet offers this buffer. The telephone, electricity, airline, and Internet infrastructures used existing standards, as depicted in Table 9. Applying the use of existing standards is to identify, select, and adopt existing common standard references that all systems use. Using these common references, systems are treated as “black boxes” that adhere to input/output standards of the common reference. The processing within the black box is invisible to other systems. The only change for Program Managers is the adherence to protocol and standards associated with accessing and using the common reference. Essentially, this is an infrastructure wrapper that allows availability of information from other systems to those who access it. This was the technique used to develop the Internet, which may be a viable standard to use as part of this infrastructure. New infrastructure Strategy Strategy three is to develop a new infrastructure by adopting new national standards applicable to all systems, DOD, and military Services. The banking infrastructure resolved problems created, when each state issued their own currency by adopting a gold standard and producing a 251 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. standard currency. Today, the Federal Reserve prints standard currency for all states. Adoption of new standards requires modification of legacy systems, if possible, and replacement of them, if not possible. Also, a schema for managing the standards is required. This will prove challenging for the many complex organizations in DOD and the military Services. A likely scenario is for DOD to assert the rules with military Services having veto rights. The Defense Advanced Research and Development Agency (DARPA) already accomplished the establishment of a new infrastructure, when they created the Internet. The issue is that commercial industries now own the Internet, the common bus, and all of the Internet addresses that are needed to access the Internet. DOD could negotiate attaining blocks of addresses, but they still need to be managed and maintained to keep up to date with changes. Another concern in establishing a new infrastructure is the cost. This challenge points back to adoption of the Internet strategy. S trate gy Summary The Internet solution is a good start for connecting the complex computer-based systems. Connectivity, though, is but one aspect of interoperability. The effective use of information occurs when functions and data bases have been synchronized. This requires immense cooperation among developers and Program Managers of the systems. A social 252 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technology is needed to assess and adapt and adopt the best strategy, or parts of the three strategies. Perhaps the answer is a combination of the strategies. Summary—Hypothesis 5 The Everett Rogers Diffusion-of-lnnovation Process Model potentially offers an improved path to achieving interoperability. This is based on a clear understanding of the Rogers Diffusion-of-lnnovation Process Model and its applicability to physical or information technologies that need to be diffused. This chapter reviewed successful physical or information technologies that were diffused as part of national infrastructures. The diffusion clearly articulated the involvement of social, economic, and political elements that impact or are impacted by the physical or information technologies. This is the essence of the Rogers Diffusion-of-lnnovation Process Model. As shown in the analysis above, technology, social, economic, and political elements are embodied in innovation, communications and communication channels, time, and sociai system elements of the Rogers Diffusion-of-lnnovation Process Model. Though an infrastructure is defined as a large-scale technological system, the Everett Rogers Diffusion-of-lnnovation Process Model causes one to expand the perspective of a technological system. It is not merely a physical and information tool that performs work, when manipulated by 253 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. humans. This infrastructure technological system embodies technology, social, economic, and political elements, such that only when all of the elements work together is technology diffused, progress made, and interoperability achieved. Interoperability was a by-product of establishing infrastructures. National order and standardization had to be attained. This required a social system structure conducive to controlling the many companies and organizations involved. It also called for the use of commonality across the companies to bring stability and reliability to the infrastructure. Effective information exchange to make this happen was an imperative. DOD and Navy are well-versed in developing and diffusing innovations in the form of computer-based systems. Policy documents, though, focus on the engineering needed to define, develop, and distribute individual systems. Technology is evolving and mandating use of Internet like infrastructures for these systems, and policies are realigning to do this. Immature in the policies are the social, economic, and political elements for diffusing interoperable computer-based systems and their infrastructure. The Rogers Diffusion-of-lnnovation Process Model offers a means of incorporating these elements by addressing his diffusion elements in the policies. Additionally, while using the Rogers model, DOD and Navy appear to have three strategies. They may find it wise to step back and reflect on 254 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. these strategies as means of achieving interoperability at more acceptable levels. The other choice is to continue to adopt the blizzard of “ work-harder” strategies that have not yet proven to be systemic and institutional in solving interoperability problems. 255 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER Vllf CONCLUSIONS AND FURTHER RESEARCH Summary of Findings The analysis of this research found that DOD and Navy computer- based systems made tremendous progress in the twenty-year period, since they were introduced as part of military systems. Though plagued with interoperability problems throughout those years, Program Managers, engineers, and many others demonstrated laudable skills in resolving these problems. The technical skills in DOD and Navy are phenomenal such that America leads other nations in innovative ideas and implementations that the U.S. maintains worldwide military superiority. Technology, though, took off at such a rate that replacing old technology with new was physically, socially, economically, and politically impossible. Interoperability problems mounted faster than solutions for them could be implemented. The result is that many computer-based systems are not successful as standalone systems. Interoperability among these systems is not at acceptable levels. “ Work-harder” strategies have failed to make them interoperable at acceptable levels, or results from them have not 256 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. been realized, DOD and DON processes are not making them interoperable at acceptable levels. The time was ripe to search out of the box for alternative means of finding solutions for the ever-expanding interoperability problems. Everett Rogers developed a Diffusion-of-lnnovation Process Model based on diffusion theory. His model explained and prescribed certain elements and their attributes that were needed to diffuse innovations. The initial thought of the author was that the model might have potential to successfully diffuse interoperability as an innovation. As it turns out, DOD and DON processes inherently use the Everett Rogers diffusion-based process model to acquire and distribute computer-based systems. The processes do not use the Rogers Diffusion-of-lnnovation Process Model to diffuse interoperability for the systems interoperable. A review of interoperability successes in developing national infrastructures had indications that the Rogers Diffusion-of-lnnovation Process Model was inherently used in the development. This encouraging information led to the belief that the Rogers model was viable and should be considered for use in the development and upgrade of policies that advocate interoperability. As the number one military power in the world, the United States owes much of its success to complex DOD computer-based systems. DOD spends billions of dollars per year procuring, distributing, and maintaining 257 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. these systems. Though these systems contribute to successful military operations in defense of the nation, many are becoming unaffordable, under- responsive to the Tempo of war," and are not interoperable. Standalone and “legacy” systems in particular have the most difficulty with measuring up to this affordability and responsiveness description of success. Maintaining standalone and legacy systems grows increasingly expensive. Their lack of interoperability causes them to be unable to keep pace with the “ tempo of war.” They were developed prior to technology advancements and recognition of the need for and capability of interoperability among electronic computer-based systems. Additionally, newer systems have difficulty with being interoperable with these legacy standalone systems as a cause for these newer systems to also be incapable of achieving interoperability at acceptable levels. The most recent and telling evidence of the magnitude of interoperability problems in DOD is a memorandum from the Deputy Secretary of Defense in which he stated the following: I am committed to resolving the problems of legacy C2 interoperability in an expeditious and cost effective manner. Therefore, I am establishing a goal for the Department to have legacy systems interoperable, with respect to critical command and control functions by the end of Fiscal Year (FY) 2008. (Wolfowitz, 2001) DOD “ work-harder” strategies to resolve interoperability problems included establishment of virtual organization structures comprised of working groups, Integrated Product Teams, or new organizations. Some of 258 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. these strategies have proven useful in improving interoperability. The virtual organizations were dedicated to fixing interoperability. These organizations blurred cultural, organizational, and competitive differences and focused on making a few specified systems interoperable. Cooperation among members of the virtual organization was a key factor to success. Usually, establishment of the virtual organization resulted from senior authority direction to fix high visibility programs that had interoperability problems. Members of the virtual organizations returned to their normal organizations after successful interoperability was achieved. Unfortunately, successful implementations of interoperability improvements have addressed only a few systems. “ Work-harder” strategies for achieving interoperability among the other computer-based systems are still ongoing, some with virtual organizations that are still searching for solutions. The hope is that these strategies will be successful, but the results of these strategies may not be known for years and may or may not be successful. The virtual organizations implementing the strategies may exist for years. Even if the strategies are successful, their implementations are occurring outside of the normal organizational structure. The implication of interoperability implementation is that organizational change is needed to achieve acceptable levels of interoperability. Despite the successes and the hopes for success, over a twenty-year period, most of the “ work-harder” strategies failed to demonstrate 259 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. improvements to interoperability problems among the larger community of Navy electronic computer-based systems. The problems have gotten worse. Processes are evolving in the attempt to better address interoperability among computer-based systems. Their content is based on untested theories about methods needed to achieve acceptable levels of interoperability. The processes focus on technical and engineering solutions for solving interoperability problems. During the past twenty-years, the processes have been slow to offer and include methods to improve interoperability. Implementation of the methods that were offered has not resulted in improvements. Results from the newer methods will not be apparent for six to ten years. The processes do not yet account for legacy systems that make up the majority of Navy electronic computer-based systems. Unless these legacy systems are part of the interoperability solution, the new methods will still be ineffective, and the processes are untested and not based on proven theory. A diffusion theory-based process model offers a potential method of enabling improvement in achieving interoperability at acceptable levels. Some of the tenets of the model are used in DOD and DON processes, but many are not. Incorporation of the model in these processes is worth exploring, as it is based on proven theory. 260 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. This research examined five hypotheses that corroborate the above statements. Below, the summary of findings for each hypothesis is reviewed. As a recap, the five hypotheses are: 1. Department of Defense (DOD) computer-based systems are successful. 2. Navy computer-based systems that use Department of Defense (DOD) and Department of Navy (DON) processes are achieving acceptable levels of interoperability. 3. “ Work-harder” strategies are achieving improved levels of interoperability among Navy complex computer-based systems. 4. Department of Defense (DOD) and Department of Navy (DON) processes are using Everett Rogers’ Diffusion-of-lnnovation Process Model to achieve interoperability. 5. Everett Rogers’ Diffusion-of-lnnovation Process Model: an improved path to achieving interoperability among complex Department of Defense (DOD) and Navy computer-based systems. Findings—Hypothesis 1 Hypothesis: Department of Defense (DOD) computer-based systems are successful. 261 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Finding: DOD and Navy systems have made tremendous progress and advances over the past twenty-plus years, despite their interoperability problems. But, because most of them are legacy, stovepipe systems that are not interoperable, their success is diminished. Interoperability problems among these systems have been reported in every regional conflict or war since 1991. Warfighters told DOD and the military Services eleven years ago that, to be useful in the new warfighting environment, systems must be interoperable. They are still saying this, yet standalone, legacy systems prevail. DOD and the military Services, though listening, may not have the resources or do not yet have the answers to solve interoperability problems for standalone and stovepipe systems. Without solutions to interoperability problems, systems will remain standalone and stovepipes, and their success will continue to be less than desired or needed. Findings—Hypothesis 2 Hypothesis: Navy computer-based systems that use Department of Defense (DOD) and Department of Navy (DON) processes are achieving acceptable levels of interoperability. Finding: Navy programs that use DOD and Navy processes are not achieving acceptable levels of interoperability. The processes have constantly changed through the years in reaction to lessons-learned reports, new visionary documents, and organization, economic, technology, and 262 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. political/environmental changes. In a visual demonstration of the frustrations related to existing processes, both the Secretary of Defense and Commander of the Joint Chiefs of Staff cancelled the processes. Complexity and being overly prescriptive were cited as reasons for the cancellations. Though designated personnel are rapidly working to replace the broken Requirements Generation and Defense Acquisition Systems, it remains to be seen whether the replacement policy will be adequate. As discussed in Chapter 3, legacy stovepipe and standalone computer-based systems are major culprits in preventing the success of interoperability. These systems are not subject to Requirements Generation and Defense Acquisition Systems processes. Yet, due to their numbers alone, they significantly impact the interoperability of computer-based systems that are subjected to the processes. At one point in time, legacy standalone and stovepipe systems implemented predecessor processes, but most of the processes did not or scantily addressed interoperability. The analysis in this chapter examined the processes, their products, and systems that used the cancelled processes or their predecessors. The processes in this newer policy included interoperability as key performance parameter and information exchange requirements. The policy also required certifications. Risk, nevertheless, remained in achieving interoperability at acceptable levels, because the guidance in the processes was speculative. What made the authors believe that the systems developed would be 263 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interoperable, if the processes were implemented? Did the policy include concepts that were based on demonstrated research? None that were specified and none that worked. MNS, CRDs, and ORDs were products of the Requirements Generation System process. Computer-based systems developed using the MNS, CRDs, and ORDs were products of the Defense Acquisition System process. Plans and funding for programs to develop computer-based systems were products of the Planning, Programming, and Budgeting System. The finding here was that documentation was either missing or disjoint from computer-based systems and, more often than not, treated as merely paper drills to attain milestone approvals. Once approved, documents were not maintained and sustained with the systems. They also lacked coordination with other documents for the same system and even less with documents for systems with which interoperability was required. Interfaces were documented at an individual program level but were not sustained and visible beyond the stovepipe program. The final products from DOD and Navy processes have been stovepipe systems, developed by stovepipe programs and historically have had interoperability problems. Despite changes to the processes over the past twenty years, interoperability has not yet been achieved at acceptable levels. 264 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. And lastly, the processes have become extremely complex, which makes training, implementing, or even observing them difficult and fraught with opportunities for error. Achieving interoperability is not possible under the current processes. Nor is it yet obvious that new processes being developed will offer solutions to achieve interoperability at acceptable levels. Much research has been performed, demonstrating the achievement of interoperability. Whether the new policy incorporates techniques and methods from this research remains to be seen. Findings—Hypothesis 3 Hypothesis: “ Work-harder” strategies are achieving improved levels of interoperability among Navy complex computer-based systems. Findings: The earlier strategies have not worked. The newer strategies are more complex and begin to address some of the shortfalls that were identified in the processes. Will the newer strategies work? Not until they adopt a model of success. Not until they address the interoperability of the standalone, stovepipe, and legacy systems. Not until they address a means to prevent the stagnation of future legacy systems. Arthur R. Jensen (1960) wrote: [W]hen bridges do not stand, when aircraft do not fly, when machines do not work, when treatments do not cure, despite all conscientious efforts on the part of many persons to make them do so, one begins to question the basic assumptions, principles, and hypotheses that guide one’s efforts. 265 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Significant observations are clear about the “ work-harder” strategies. Many organizations were responsible for these strategies. Each used different approaches to solve or address interoperability problems. The strategies were the result of planning and effort that senior leaders approved and made decisions to fund and implement over a twenty-year period. Yet, the interoperability problem persists, and uncertainty remains about whether the strategies that are still ongoing will result in achieving interoperability at acceptable levels. Strategies to solve interoperability problems are resulting in expenditure of tax dollars on products and methodologies that are disjoint and potentially conflicting or irrelevant. Yet, Congress, who has the power over the spending of tax dollars, has not weighed in. DOD and Congress continue to spend dollars for the many disjoint strategies but have not seriously mandated that the problem be solved. No single authority is responsible for orchestrating whether and how organizations synergize their efforts and eliminate those that are duplicative or add no value. FORCEnet has the potential of bringing together many interoperability strategies, but it is limited to Naval efforts. But even the implementation of FORCEnet is focused only on Command, Control, Communications, Computers, and related Intelligence systems. Organizationally, policy may be needed that formally designates a senior authority with approval and veto power over all interoperability efforts. Since 266 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. each of the military Services have unique requirements, the senior authority could organize with delegation authority to the Services; but, as soon as that happens, delegated Services are subject to working their own agendas. The responsibility of a single authority would be to orchestrate the efforts of organizations with interoperability requirements to develop organizational, technical, and doctrine interoperability for the transformation ecosystem. In conclusion, a model of success and a coordinating senior authority for all strategies is needed. Are the “ work-harder” strategies working? Not yet! Findings—Hypothesis 4 Hypothesis: Department of Defense (DOD) and Department of Navy (DON) processes are using Everett Rogers’ Diffusion-of-lnnovation Process Model to achieve interoperability. Findings: Everett Rogers’ Diffusion-of-lnnovation Process Model is an inherent part of DOD and DON requirement and acquisition processes. These processes primarily focus on developing individual computer-based systems as opposed to diffusing them, but diffusion is part of the processes. Diffusion of a system occurs in milestone reviews that result in approvals from senior decision-makers to develop or deliver the system. The systems were successfully diffused—adopted and used. Systems are communicated to senior decision-makers who are convinced over time that the system is 267 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. one that warfighters need to adopt. Warfighters who become users of the system have little or no voice in the adoption the system. Senior decision maker approvals are analogous to what Rogers describes as authority decisions that, nonetheless, result in valid diffusions. Rogers’ elements of diffusion (innovation, communication channels, time, and social systems) and their interactions are the heart of diffusing innovations. These elements, in some form, were used to successfully diffuse systems, but the systems did not achieve interoperability at acceptable levels. The implication is that the system is not the innovation to be diffused to achieve interoperability at acceptable levels. What, then, is the innovation—a technology that assures the achievement of interoperability at acceptable levels? Technical solutions have not yet worked. Economic solutions are potentially unaffordable. A social solution may have potential— a social technology that focuses on achieving acceptable levels of interoperability. Just as a system required diffusion, a social technology that is conducive to achieving acceptable levels of interoperability must be diffused. This means the social technology must be communicated to those with a stake in it who must be convinced over time that the social technology is one they want/need to adopt. The social technology, communication channels, schedule, and social system all need to be defined, developed, and implemented for successful diffusion. Diffusing a social technology is 268 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. difficult, but, as demonstrated in national infrastructure related innovations discussed in Chapter 7, achievable. The scope of DOD and DON processes should no longer be the development of individual systems and their inherent diffusion. This scope should encompass overarching objectives that lead to the accomplishment of DOD and military strategy. It should be the means to implement these objectives. Physical technologies do not accomplish objectives. The people, as orchestrated through a social technology, accomplish these objectives through use of physical technologies. Computer-based systems, as examples of physical technologies, become natural by-products of the diffusion of the social technology. A social technology is the innovation. It must be defined, developed, and subsequently diffused. The desired results that are desired from the social technology must be included as part of its definition and development. As an example, some of the factors that contribute to interoperability problems include legacy systems, “stovepipe” development of systems, battle management, lack of funding, connectivity issues, integration issues, duplicative systems, unavailable systems, et ai. These factors need to be addressed in the definition, design, and development of a social technology conducive to achieving acceptable levels of interoperability. Rogers’ elements of diffusion and their interactions are the heart of diffusing innovations. Just as a system required diffusion, a social 269 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technology that is conducive to achieving acceptable levels of interoperability must be diffused. This means the social technology must be communicated to those who use it. They must be convinced over time that the social technology is one they want/need to adopt. Diffusing a social technology is difficult but as demonstrated in previous national infrastructure related innovations, achievable. Significant is the fact that, as discussed above and in Chapter 4, SECDEF and CJCS cancelled the Defense Acquisition System and Requirements Generation System policy documents. These documents set forth directives, instructions, and guidelines to implement the major policies that mandate the requirement for interoperability in computer-based systems. The memo canceling acquisition policy documents stated: “I am issuing interim guidance . .. to rapidly deliver affordable, sustainable capability to the wafighter that meets the warfighter’s needs” (SECDEF, 2002). Interoperability, as discussed in Chapter 3, is a warfighter need. Current policy is not working. The needs of the warfighter are not always being met. The strategies scorecard, Chapter 5, Table 8, corroborates interoperability deficiencies in warfighter needs. To adequately address warfighting needs, diffusing a social technology should be a top priority. High among those needs is achieving interoperability at acceptable levels. The overarching interoperability problem has not been solved. 270 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Many fields of study, as well as practitioners, used diffusion research to successfully demonstrate advances in the fields, market products, or even open and expand a new study area, such as communications. These successes achieved critical mass and demonstrated that diffusion research is a viable approach to gaining the acceptance and adoption of innovations. Interoperability among computer-based systems had all of the markings of an innovation that needed help to successfully diffuse. Rogers’ Diffusion-of- lnnovation Process Model appears to offer a means to successfully diffuse interoperability so that it is achievable. More about these successes are in Chapter 7. Findings—Hypothesis 5 Hypothesis: Everett Rogers’ Diffusion-of-lnnovation Process Model: an improved path to achieving interoperability among complex Department of Defense (DOD) and Navy computer-based systems. Findings: Everett Rogers’ Diffusion-of-lnnovation Process Model potentially offers an improved path to achieving interoperability. This is based on a clear understanding of the Rogers Diffusion-of-lnnovation Process Model and its applicability to physical or information technologies that need to be diffused. This chapter reviewed successful physical or information technologies that were diffused as part of national infrastructures. The diffusion clearly articulated the involvement of social, 271 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. economic, and political elements that impact or are impacted by the physical or information technologies. This is the essence of the Rogers Diffusion-of- lnnovation Process Model. As shown in the analysis above, technologies, social, economic, and political elements are embodied in the innovation, communications and communication channels, time, and social system elements of the Rogers Diffusion-of-lnnovation Process Model. Though an infrastructure is defined as a large-scale technological system, the Everett Rogers Diffusion-of-lnnovation Process Model causes one to expand the perspective of a technological system. It is not merely a physical and information tool that performs work, when manipulated by humans. This infrastructure technological system embodies technology, social, economic, and political elements, such that only when all of the elements work together is technology diffused, progress made, and interoperability achieved. Interoperability was a by-product of establishing infrastructures. National order and standardization had to be attained. This required a social system structure conducive to controlling the many companies and organizations involved. It also called for the use of commonality across the companies to bring stability and reliability to the infrastructure. Effective information exchange to make this happen was an imperative. DOD and Navy are well-versed in developing and diffusing innovations in the form of computer-based systems. Policy documents, 272 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. though, focus on the engineering needed to define, develop, and distribute individual systems. Technology is evolving and mandating use of Internet- like infrastructures for these systems, and policies are realigning to do this. Immature in the policies are the social, economic, and political elements for diffusing interoperable computer-based systems and their infrastructure. The Rogers Diffusion-of-lnnovation Process Model offers a means of incorporating these elements by addressing his diffusion elements in the policies. Importance and Relevance of Findings Interoperability is not a new issue. Interoperability problems were occurring even before the advent of computer-based systems. Historically, mankind has found the need to exchange information, materials, and services to improve the quality of life and working conditions. Interoperability touches everyone. “No man is an island. No man stands alone.” As the development of national infrastructures demonstrated, interoperability is key to successful implementation of these foundations. More importantly, the progress of mankind pivots on successful interoperability. Institutionalizing a process to achieve success in interoperability efforts, then, has potential impact on all government organizations. 273 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Action implications Throughout history, America has experienced interoperability successes. These successes have monopolistic infrastructures in common. If DOD and Navy were to take this seriously, development of social technology strategies and the adoption and use of these strategies to develop policy and solve problems are imminent. As a matter of course, the strategies and policies must be based on proven research. Otherwise, “ the world is flat,” and all of the strategies developed to improve the quality of life will be based on a flat world. The Everett Rogers Diffusion-of-lnnovation Process Model is a social technology model that is based on diffusion theory research. It addresses the complexity of technology, social, economic, and political elements that must interact to reduce the uncertainty of adopting new ideas and technologies. Interoperability is a new idea that touches each of the elements and that is driving change among them. DOD and Navy must apply the Rogers Diffusion-of-lnnovation Process Model to defense and DON processes. For example, the social aspects must include both micro- and macro-ergonomics of a social technology. This means that not only will human factors be incorporated into technologies to address warfighter use of the technology, but also organizational change must accompany new technologies to address 274 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. management and development of the technology. Economic and political factors must also be incorporated into the social technology. DOD and Navy already have a sense of this, as massive re- organizational changes have been occurring since 1995.6 Organization location changes ranged from 10 to 3,000 miles. In at least one case, an organization lost 90% of its people in the move. People were replaced, but the original organizational structure and culture remained. DOD and Navy are already taking action to change organizations and system acquisition implementations. Transformational roadmaps, policy document cancellations, major organizational changes, and other movements are underway. At issue is the success model that demonstrates less guesswork and uncertainty and more change based on proven research or studies. Social change cannot be implemented based on a requirement to reduce the number of civilians and military Service members. It should reflect a holistic and analytical perspective of what it will take to achieve interoperability or other defense and military Service goals. Design of the social technology to achieve this should be based on a success model, such as the Everett Rogers Diffusion-of-lnnovation Process Model. A small group 6 Gongress passed the 1996 Defense Appropriation and Authorization Bill that included a mandate for Base Realignment and Closure (BRAC). The objective of BRAC was to move military Service members and civilians out of commercial buildings and into buildings owned by defense and military Service organizations. Additionally, those bases that did not serve useful purposes were to be closed. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. should come together to develop a proposal to use the Everett Rogers Diffusion-of-lnnovation Process Model to design such a social technology for DOD and the military Services to address interoperability. Further Research Future Research Questions • What is the Congressional, DOD, and military Service commitment to achieving interoperability? Is the Rogers Diffusion-of-lnnovation Process Model applicable to solving interoperability problems of other organizations—Army, Air Force, non-military? • How should DOD and DON proceed technically, organizationally, economically, and politically with the Rogers Diffusion-of- lnnovation Process Model? • How do DOD and DON impose the type of government interventions used to control Private companies on military organizations, as developers of an interoperable infrastructure? • What are the social technology and its design that need to be developed to achieve interoperability at acceptable levels? • Will DON’s interoperability problems support further research in technology clustering within diffusion research? 276 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. How does a commitment to interoperability impact commercial companies? • Does the Everett Rogers Diffusion-of-lnnovation Process Model open another door for exploring organizational behavior to include the behavior across organizations? Importance to Public Administration Public Administration is a multi-disciplined field. This research offers a multi-disciplined approach to explore this field. It addresses the technology, social, economic, and political elements that cause creative tension within Public Administration; because, though considered as a separate field of study, Public Administration involves multiple fields of study. Creative tension is caused when each of the multiple fields competes for dominance. Usually, Public Administration looks within the social element to focus on micro-ergonomics. Micro-ergonomics is concerned with the direct benefit of a technology by public members, whereas macro-ergonomics looks at the environment in which the technology is used. Micro-ergonomics often focuses on immediate feedback and quality-of-life improvements for users of technologies. In the case of Public Administration, the public refers to “ the people” or the taxpayer. The interoperability of military systems provides an indirect benefit to the public. National defense protects the people;, but, as 277 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. with any profession, adequate tools are needed to do so. When ships are destroyed, as in Pearl Harbor, because information of incoming aircraft is not received in time to take countermeasures, the disastrous results affect the people in the nation. Acceptable levels of interoperability provide the means of getting information to those who need it to defend the public. Just as Public Administration is multi-disciplined, the Rogers Diffusion-of-lnnovation Process Model also touches multiple disciplines. It makes clear that a balance among the disciplines must support their interactions to be useful and effective. Information exchange, as in interoperability, helps to achieve the balance. Attaining efficiency is also a basic foundation of the field of Public Administration. A finding is this research was that policies are developed with little efficiency. They appear to be response actions to problems, but they rely primarily on work experiences and hypothetical ideas as the basis for solving the problems. The use of proven research appears to be lost as policies are developed. The Rogers Diffusion-of-lnnovation Process Model potentially adds a research base to policies for diffusing technologies that include the appropriate elements. This potentially applies to government-wide applications. It also supports efficiency. Woodrow Wilson (1887) saw Public Administration in terms of executing government efforts with the “utmost 278 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. possible efficiency.” 7 Towards the attainment of efficiency, Frederick W. Taylor (1912) proposed Scientific Management—'1 the management of ‘initiative and incentive’: if employers adequately incentivized employees, these workers would respond by working to the best of their ability.” Herbert Simon (1976) proposed that decision-makers needed to understand the difference between fact (an efficiency constant) and value (an efficiency variable) and make informed choices on which gives greater benefit. Decision-makers need sufficient knowledge about available research to enable them to use it when necessary to quickly make choices in problem solving. Interoperability problems are not unique to DOD or the military Services. Information exchange by means of automation enables efficiency and is vastly changing the way we do business, not only within the confines of DOD and military organizations but locally, nationally, and internationally as well.8 Ensuring the effectiveness of this exchange by eliminating interoperability problems has the potential to increase efficiency and improve 7 ln this document, Wilson stated: “It is the object of administrative study to discover, first, what government can properly and successfully do, and secondly, how it can do these proper things with the utmost possible efficiency and at the least possible cost either of money or of energy.” ®While in London in 1994,1 was able to withdraw funds from my bank account in Washington, D.C. by inserting my banking card into an Automated Transaction Machine (ATM). The information exchanges among the systems in the participating banks made this possible. 279 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. quality of life in a way that Wilson and the drafters of the Constitution never dreamed. Organizational Behavior is another area in Public Administration that stands to benefit from this exploration into the impacts of interoperability. Most of the studies focus on interactions of people within a single organization. Discussion of groups or teams begins to look beyond the internal culture and structure of an organization, but interoperability requires large-scale interactions between organizations that are beyond short-term teams. Public Administration, the Rogers Diffusion-of-lnnovation Process Model, and complexity theory were adequately applicable to explore and understand impacts of interoperability. 280 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. GLOSSARY/DICTIONARY OF TERMS Introduction The terms below are from a variety of sources. The DOD Dictionary of Military Terms was the governing document but other sources, including military and non-military documents or Web sites, were used in the absence of a definition from the DOD dictionary. Sources are referenced for the terms. /^Understanding the terminology used is essential to achieving interoperability whether between systems, people, or complexities. A failure to communicate is a failure to interoperate is a V^Jfailure to diffuse. 1 Terms and Definitions acquisition executive The individual within the Department and Components charged with overall acquisition management responsibilities within his or her respective organization. The Under Secretary of Defense for Acquisition, Technology, and Logistics is the Defense Acquisition Executive responsible for ail acquisition matters within the Department of Defense. The Component Acquisition Executives (CAE) for each of the Components are the Secretary of the Military or Heads of Agencies with power of re-delegation. The CAEs are responsible for all acquisition matters within their respective Component. (DOD Directive #5000.1, 2000) 281 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. acquisition program baseline Development of objectives and thresholds for cost, schedule and performance for Milestone Decision Authority (MDA) approval. The objectives and thresholds will result in systems that are affordable, timely, operationally effective, operationally suitable, and survivable. The IPT shall refine these objectives and thresholds, consistent with the operational requirements, as the program matures and progresses through the acquisition process (ARMY, available: http://www.stricom.army.mil/STRIAM/ACQUISIT/ROADMAP/acquij3rogr amjbaseline.jsp). architecture “ The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time” (IEEE STD 610.12 as adapted by the U.S. DOD C4ISR Architecture Framework, Version 2.0, December 18, 1997). battle force (DOD) A standing operational naval task force organization of carriers, surface combatants, and submarines assigned to numbered fleets. A battle force is subdivided into battle groups (Joint Publication 1-02, 2002). battlegroup The platforms, including ships, aircraft, submarines, and other afloat units and related equipment, that comprise the mobile units deployed to participate in military operations abroad. Battle groups are referred to as Battle Force or Battle Forces (DOD Directive #4720.3A, 2000). battlespace The environment, factors, and conditions that must be understood to successfully apply combat power, protect the force, or complete the mission. This includes the air, land, sea, space, and the included enemy and friendly forces; facilities; weather; terrain; the electromagnetic spectrum; and the information environment within the operational areas and areas of interest (Joint Publication #1-02, 2002). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. capability The ability to execute a specified course of action (COA) (Joint Publication #1-02, 2002). capability component DOD does not have a formal definition for capability component. The following definition was derived from the combined definitions of capability (Joint Publication #1-02, 2002) and component (Webster, 1963): A key subdivision of the mission to be accomplished through the execution of a specified course of action. capability objective DOD does not have a formal definition for capability objective, but a derived definition from the combined definitions of capability, course of action, mission capability, objective (Joint Publication #1-02, 2002), and effect (Webster, 1963) is as follows: A desired and measurable effect within a military mission that is accomplished through the execution of specified actions, such as those actions identified in a military plan. capstone requirements document (CRD) A document that contains capabilities-based requirements that facilitate development of individual ORDs by providing a common framework and operational concept to guide their development. It is an oversight tool for overarching requirements for a system-of-systems or family-of-systems (DOD Directive #3170.01 B, 2001). communicate (DOD) To use any means or method to convey information of any kind from one person or place to another. 283 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. complexity A system is complex in the sense that a great many independent agents are interacting with each other in a great many ways. The richness of the interactions allows the system as a whole to undergo spontaneous self-organization. component 1. One of the main parts of the whole (Webster, 1963). 2. One of the subordinate organizations that constitutes a joint force. Normally a joint force is organized with a combination of Service and functional components (Joint Publication #1-02). 3. In logistics, a part or combination of parts having a specific function, which can be installed or replaced only as an entity. Also called COMP. See also functional component command; Service component command (Joint Publication #1-02). Component Acquisition Executive (CAE) The Secretary of the Military Departments (Navy, Marine Corps, Air Force, or Army) or Heads of Agencies with power of re-delegation. The CAEs are responsible for all acquisition matters within their respective Component (DOD Directive #5000.1, 2000). course of action (COA) A possible plan open to an individual or commander (warfighter) that would accomplish or is related to the accomplishment of a mission. critical mass The point at which enough individuals have adopted an innovation so that the innovation’s further rate of adoption becomes self-sustaining. Adoption decisions among members of a social system are interdependent when critical mass occurs (Rogers, 1995). data bases Information that is normally structured and indexed for user access and review. Data bases may exist in the form of physical files (folders, documents, etc.) or formatted automated data processing system data files. 284 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. dependent system A system that relies on data, information, functions, materials, or signals from another or other systems. differences in matter-energy Inked letters on paper, sound waves traveling through the air, or an electrical current in a copper wire (Rogers, 1995). effect Result (consequence of actions) (Webster, 1963). family-of-systems A set or arrangement of independent systems that can be arranged or interconnected in various ways to provide different capabilities. The mix of systems that can be tailored to provide desired capabilities dependent on the situation (DOD Directive #3170.016, 2001). fielded systems Systems that have been approved for production, certified for interoperability, and installed on deployed or deploying platforms. firmware Firmware is programming that is inserted into programmable read-only memory (programmable ROM), thus becoming a permanent part of a computing device. Firmware is created and tested like software (using microcode simulation). When ready, it can be distributed like other software and, using a special user interface, installed in the programmable read-only memory by the user. Firmware is sometimes distributed for printers, modems, and other computer devices (Internet, available: http://whatis.techtarget.eom/definition/0,,sid9_gci212127,00.html). fleet An organization of ships, aircraft, Marine forces, and shore-based fleet activities all under the command of a commander or commander-in-chief who may exercise operational as well as administrative control. See also major fleet and numbered fleet (Joint Publication #1-02, 2002). 285 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. host system System that provides data, information, functions, material, or signals to a dependent system. information A difference in matter-energy that affects uncertainty in a situation where a choice exists among a set of alternatives (Rogers, 1995). information exchange requirements The requirement for information to be based between and among forces, organizations, or administrative structure concerning ongoing activities. Information exchange requirements identify who exchanges what information with whom, as well as why the information is necessary and how that information will be used. For CRDs, top-level lERs are defined as those information exchanges that are between systems that make up the FoS or SoS, as well as those that are external to the FoS or SoS. For ORDs, top-level lERs are defined as those information exchanges that are external to the system. The quality and quantity are attributes of the information exchange included in the information exchange requirement (DOD Directive #3170.016, 2001). infrastructure 1. (DOD) All building and permanent installations necessary for the support, redeployment, and military forces operations (e.g., barracks, headquarters, airfields, communications, facilities, stores, port installations, and maintenance stations). See also bilateral infrastructure, common infrastructure, and national infrastructure. 2. The underlying basic buildings, institutions and facilities or other essential elements that are necessary to sustain and enable growth and development of a community. Larimer (1994) speaks of the underlying foundation or framework of basic services, facilities and institutions upon which the growth and development of an area, community or a system depend. Infrastructure, therefore, includes a broad spectrum of services, institutions and facilities that ranges from transportation systems and public utilities to finance systems, laws and law enforcement, and education and research. It is clear from the above definitions that infrastructures play key roles in our society (provided by Ewoud Verhoef, available: http://www.infrastructures.tudelft.nl/infradef.htm!). 2 8 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Internet The Federal Networking Council (FNC) agrees that the following language reflects a definition of the term "Internet." "Internet" refers to the global information system that: (I) is logically linked together by a globally unique address space based on the Internet Protocol (IP) or its subsequent extensions/follow-ons; (ii) is able to support communications using the Transmission Control Protocol/Internet Protocol (TCP/IP) suite or its subsequent extensions/follow- ons, and/or other IP-compatible protocols; and (iii) provides, uses or makes accessible, either publicly or privately, high-level services layered on the communications and related infrastructure described herein. interoperability 1. The ability of systems, units, or forces to provide data, information, material, and services to and accept the same from other systems, units, or forces, and to use the data, information, material, and services so exchanged to enable them to operate effectively together (DOD Directive Numbers 5000.1, 2000; 5000.2, 2001; Joint Publication #1-02, 2002). 2. The condition achieved among communications-electronics systems or items of communications-electronics equipment, when information or services can be exchanged directly and satisfactorily between them and/or their users (DOD Directive #3170.01B, 2001; Joint Publication #1-02, 2002). 287 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. key performance parameters (KPPs) Those capabilities or characteristics considered most essential for successful mission accomplishment. Failure to meet an ORD KPP threshold can be cause for the concept or system selection to be reevaluated or the program to be reassessed or terminated. Failure to meet a CRD KPP threshold can be cause for the family-of-systems or system-of-systems concept to be reassessed or the contributions of the individual systems to be reassessed. KPPs are validated by the JROC. ORD KPPs are included in the APB (DOD Directive #3170.01 B, 2001). legacy systems 1. A system that significantly resists modification and evolution to meet new and constantly changing business requirements (Brodie & Stonebraker, 1995). 2. A technically obsolescent component of the enterprise's infrastructure. Although the functionality that is delivered by a legacy system to enterprise business processes may be available from more modern technology, a migration to using newer systems may be deterred by the possibility of service disruption during system upgrading, or by the perceived difficulty in converting legacy content to conform to new content models and formats (Fourth Wave Group, 2002). 3. Definition 3: Software systems that exist now. We are creating tomorrow's legacy systems today. The key puzzle is: What strategy can an organization (e.g., the DoD or industry) use to maintain its software investment over time? This breaks down to problems of evolving and maintaining existing software systems, replacing old ones and adding new ones that can interoperate with old ones. Part of the trick to designing long-lasting legacy systems is understanding the requirements of the system as it is likely to evolve and scale up. . . . While it is likely DoD and industry will migrate some legacy systems like C4I systems toward new architectures, it is just as likely it will replace the existing with the new over a several-year period. military objectives A derived set of military actions to be taken to implement National Command Authorities guidance in support of national objectives. A military objective defines the results to be achieved by the military and assigns tasks to commanders (Joint Publication #1-02, 2002). 288 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. military operation 1. A military action or the carrying out of a strategic, operational, tactical, service, training, or administrative military mission. 2. The process of carrying on combat, including movement, supply, attack, defense, and maneuvers needed to gain the objectives of any battle or campaign (Joint Publication #1-02, 2002). mission 1. The task, together with the purpose, that clearly indicates the action to be taken and the reason therefore. 2. In common usage, especially when applied to lower military units, a duty assigned to an individual or unit; a task. 3. The dispatching of one or more aircraft to accomplish one particular task (Joint Publication #1-02, 2002). mission capability The possession of the means to use military force to achieve an intended effect within the battlespace that can be measured (Joint Publication #1-02, 2002). mission capability package (MCP) A task-organized bundle of operational concepts, processes, organizational structures, networks, sensors, systems, people, training, and the support services to sustain it (Yurchak, 2001). 289 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. national information infrastructure (Nil) (DOD) The nationwide interconnection of communications networks, computers, databases, and consumer electronics that make vast amounts of information available to users. The national information infrastructure encompasses a wide range of equipment, including cameras, scanners, keyboards, facsimile machines, computers, switches, compact disks, video and audio tape, cable, wire, satellites, fiber-optic transmission lines, networks of all types, televisions, monitors, printers, and much more. The friendly and adversary personnel who make decisions and handle the transmitted information constitute a critical component of the national information infrastructure. Also called Nil. See also defense information infrastructure, global information infrastructure, and information (Joint Publication #1-02, 2002). national infrastructure (DOD, NATO) Infrastructure provided and financed by a NATO member in its own territory solely for its own forces (including those forces assigned to or designated for NATO). See also infrastructure (Joint Publication #1-02, 2002). network ARPANET was the network that became the basis for the Internet. It was funded mainly by U.S. military sources and consisted of a number of individual computers connected by leased lines and using a packet- switching scheme. (Available: http://searchWebServices.techtarget.eom/sDefinition/0,,sid26_jgci213782 ,00.html). A network is a collection of terminals, computers, servers, and components which allows for the easy flow of data and use of resources between one another. (Definition provided by Jeremy Reis, available: http://www.learnthat.eom/define/n/network.shtml.) objective 1. The clearly-defined, decisive, and attainable goals towards which every military operation should be directed. 2. The specific target of the action taken (for example, a definite terrain feature, the seizure or holding of which is essential to the commander's plan, or, an enemy force or capability without regard to terrain features) (Joint Publication #1-02, 2002). 290 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Program Executive Officer (PEO) A military or civilian official who has primary responsibility for directing several major defense acquisition programs and for assigned major system and non-major system acquisition programs. A PEO has no other command or staff responsibilities within the Component and only reports to and receives guidance and direction from the DOD Component Acquisition Executive. Program Manager (PM) The individual designated in accordance with criteria established by the appropriate Component Acquisition Executive to manage an acquisition program and appropriately certified under the provisions of the Defense Acquisition Workforce Improvement Act (10 U.S.C. §1701 etseq.). A PM has no other command or staff responsibilities within the Component. protocols This definition was retrieved from searchNetworking.com (http://searchNetworking.techtarget.eom/sDefinition/O,,sid7_gci212839,0 O.html), a TechTarget site for Networking professionals. In information technology, a protocol (pronounced PROH-tuh- cahl, from the Greek protocollon, which was a leaf of paper glued to a manuscript volume, describing its contents) is the special set of rules that end points in a telecommunication connection use when they communicate. Protocols exist at several levels in a telecommunication connection. There are hardware telephone protocols. There are protocols between each of several functional layers and each corresponding layer at the other end of a communication. Both end points must recognize and observe a protocol. Protocols are often described in an industry or international standard. Protocol is the "language" of the network. A method by which two dissimilar systems can communicate. TCP is a protocol which runs over a network (Internet, available: http://www.learnthat.eom/define/p/protocol.shtml). prototype A model suitable for evaluation of design, performance, and production potential (Joint Publication #1-02, 2002). 291 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. requirement An established need justifying the timely allocation of resources to achieve a capability to accomplish approved military objectives, missions, or tasks. Also called operational requirement. See also objective force level (Joint Publication #1*02, 2002). social Of or having to do with human beings living together as a group in a situation in which their dealings with one another affect their common welfare (Webster, 1963). social structure The patterned arrangements of the units in a system. This structure gives regularity and stability to human behavior in a system (Rogers, 1995). social system A set of interrelated units that are engaged in joint problem-solving to accomplish a common goal. The members or units of a social system may be individuals, informal groups, organizations, and/or subsystems (Rogers, 1995). social technology Rogers nor Webster’s dictionary have a definition for the term “social technology.” As such, the following definition is derived from the definitions for social (Webster, 1963), social system (Rogers, 1995), and technology (Rogers, 1995): A social system and social structural design for instrumental action that reduces the uncertainty in the cause-effect relationships involved in achieving a desired outcome for the common benefit of the members of a social system. (As applicable to achieving interoperability as the desired outcome) a social system and design for bringing about actions that reduce the uncertainty in the cause-effect relationships involved in routinely achieving interoperability among computer-based systems. 2 9 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. software Software is a general term for the various kinds of programs used to operate computers and related devices. (The term “hardware” describes the physical aspects of computers and related devices.) (Available: http://whatis.techtarget.eom/wsearchResults/1,290214,sid9,00.html?quer y=software.) spiral development 1. Spiral development is often referred to as software engineering approaches or development strategies. Software engineering is performed in the context of systems engineering. Alternative strategies for software development include waterfall, incremental and spiral. In the waterfall approach, development activities are performed in order, with possible minor overlap, but with little or no iteration between activities. User needs are determined; requirements are defined; and the full system is designed, built, and tested for ultimate delivery at one point in time. The incremental approach determines user needs and defines the overall architecture but then incorporates a part of the total planned capabilities; the next build adds more capabilities, and so on, until the entire system is complete. The spiral approach also develops and delivers a system in builds, but differs from the incremental approach by acknowledging that the user need is not fully formed at the beginning of development, so that all requirements are not initially defined. The initial build delivers a system based on the requirements as they are known at the time development is initiated, and then succeeding builds are delivered that meet additional requirements as they become known. (Additional needs are usually identified dnd requirements defined as a result of user experience with the initial build.) (DSMC, available: http://www.miairforcemall.org/defs/Find Defs.asp?name=s.) 2. Employs evolutionary modular insertion techniques to ensure systems remain effective in the face of emergent threats. Under the spiral development philosophy, systems are designed to receive technological updates at regular intervals without disrupting production or performance. Spiral development controls costs while decreasing cycle times for technology insertion by using features such as open architecture, module interface standards, and commercial processors in conjunction with strict configuration control. Use of spiral development allows cutting-edge technologies to be 293 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. fielded more swiftly via a phased-flight approach to engineering and production. standalone systems system setup An important factor in your system setup is whether your system is a standalone system or a multi-user system that is connected to a host or to a network and is dependent on them. In a network with many users, one person is usually assigned the responsibility of managing the operation of the computers. This individual, called the system administrator, takes care of starting up and shutting down the computer; connecting terminals, printers, disks, tapes, and modems; backing up files; getting new users started; protecting the system from unauthorized entry; and so on. On a large system, this is often a full-time job in itself, requiring a qualified professional. In general, a UNIX system needs more system administration than a DOS system because of its complexity. You have a standalone system if it can perform tasks without being connected to a server or host system and if you do not share your system with other users. On a standalone system, you may have to become your own system administrator. If you do, then you must do more than log in and log off when you use your system. You have a dependent system if it must be connected to a host or a server to perform any tasks. This kind of system is typically found in a multi-user or network environment. In this environment, if the server or host stops functioning, your system also stops functioning. host connection In a multi-user system, there is one main computer, the host, which is shared by everyone. A host computer is the primary or controlling computer that serves the terminals that are connected to it. To use your system, you need to start a session on the host computer. To start a session, you log in. The main terminal connected to the host is known as the console. The system administrator uses the console to manage the system. The following illustration shows a host system. 294 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. network connection A network is a system with computers connected to other computers. Within a network, every computer is called a node. Every node in a system has its own address. In a network, computers play one of two roles: server or client. In some instances, a computer can act as a client to one computer and as a server to another. server A computer on a network that shares its resources or provides a service throughout the network is known as a server. The following are types of servers: file server: provides file storage to the other computers on the network. print server: provides printer facilities to the other computers on the network. communications server: provides access to and from computers outside the network. Client A computer that uses shared resources is known as a client. For example, you may have a UNIX system with its own disk storage where you save some of your files. You, the client, use the file server, which has greater storage capacity, to store other files. If someone on another computer needs to use the files on your computer, they are the client and your system is the server. This is a typical client/server relationship. The following illustration shows £ t typical client/server network: http://nscp.upenn.edu/aix4.3html/aixuser/aixqbeg/sys_setup.htm. 295 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. stovepipe DOD uses the term “stovepipe system” for closed systems that embody idiosyncratic compositions of thin and thick layers of various functions/ services and that are inflexible to evolve, expensive to maintain, and do not interoperate very well and make sharing data hard. There are many such systems, built for a specific C4I, intelligence analyst, or other need or at a time when the U.S. had one monolithic enemy (Russia), but now conditions have changed and these systems must interoperate in new ways under new conditions (regional conflicts, operations other than war (OOTW), depending on allies with heterogeneous computing environments), and there are architecture problems to solve (Object Services and Consulting, Inc., 1996). A closed legacy system containing special purpose variants of many functions that could individually be genericized and made into reusable patterns or components. A stovepipe system may have a minimal versioning capability, a custom query capability, a variant of a persistence capability, etc. The layers or functions may be thinner or thicker (have fewer or more) features than a standard layer, service, or function. The architectural glue that binds is special purpose code. Large stovepipe systems of systems replicate many functions in different layers in non-interoperable ways and are difficult to evolve. Functions available in one may not be available in others (Object Services and Consulting, Inc., 1996). target 1. An area, complex, installation, force, equipment, capability, function, or behavior identified for possible action to support the commander's objectives, guidance, and intent. Targets fall into two general categories: planned and immediate. 2. In intelligence usage, a country, area, installation, agency, or person against which intelligence operations are directed. 3. An area designated and numbered for future firing. 4. In gunfire support usage, an impact burst that hits the target. Also called TGT. See also objective area (DOD Dictionary; Joint Publication 1-02, 2002). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. targeting (DOD) The process of selecting and prioritizing targets and matching the appropriate response to them, taking account of operational requirements and capabilities. See also joint targeting coordination board, and target. technology A design for instrumental action that reduces the uncertainty in the cause-effect relationships involved in achieving a desired outcome. (Rogers, 1995). tempo of war The speed at which warfighters act and react during and in military operations. Time Critical Targeting Concept of Operations (TCT CONOPS) Document describing the concepts used in military operations to address time critical targets. Document can be found on the following classified Internet Web sites: h t t p ://C2FAFLOAT.SECONDFLT.NAVY.SMIL.MIL/ and http://c2fafloat.secondflt.navy.smil.mil/. Time Critical Targets (TCT) In general, time critical targets are a subset of time sensitive targets that are so critically important that resources to engage will be applied immediately. Defined by the TCT CONOPS: having immediate warfighting importance, compressed vulnerability windows and time-dependent values. They can be found throughout the battlespace and generally fall within three categories: 1. Those that present an immediate significant threat (implies a tremendous loss of life or loss of high-value assets) because of their capability, speed, location and/or range. Must be attacked when detected. 2. Those identified as priority targets that offer only a short window of vulnerability. Must be attacked, and data for targeting can change quickly. 297 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3. Those that become a priority due to their military significance during a particular phase of conflict or operation. High payoff, lucrative targets that, if struck immediately, could alter the course of conflict. time-sensitive targets (1ST) (DOD) Those targets requiring immediate response because they pose (or will soon pose) a dear and present danger to friendly forces or are highly lucrative, fleeting targets of opportunity (Joint Publication #1-02, 2002). uncertainty The degree to which a number of alternatives is perceived with respect to the occurrence of an event and the relative probability of these alternatives. Uncertainty implies a lack of predictability, of structure, or of information (Rogers, 1995). Effective use of exchanged information depends greatly on common understandings of this information between systems as well as people in the social systems that use these systems. The density and complexity of the information exchanged are exemplified in the terms used in this research. 2 9 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. SELECTED BIBLIOGRAPHY Abrahamson, Eric, & Rosenkopf, Lori (1997, May/June). Social network effects on the extent of innovation diffusion: A computer simulation. Organization Science, 8 (3), 289-300. Alberts, David S. (1996, April & October; 2002, June). Information age transformation: Getting to a 21s t century military. DOD Command and Control Research Program (CCRP). Armed Forced (n.d.). Title 10, United States Code. Office of the Law Revision Counsel, U.S. House of Representatives, Washington, DC. Bender, Bryan, Burger, Kim, & Koch, Andrew (2001, December 10). Afghanistan: First lessons. Jane’ s Defence Weekly. Brodie, Michael, & Stonebraker, Michael (1995). Migrating Legacy Systems. San Francisco: Morgan Kaufmann Publishers. Buchanan, Assistant Secretary of Navy for Research, Development and Acquisition (ASN [RDA]) (1999, April 13). Navy Chief Engineer Office memorandum. Burke, James, & Ornstein, Robert (1995, 1997). The axemakeTs gift. New York: Jeremy P. Tarcher/Putnam Books. Carroll, Lewis (n.d.). Pig and Pepper (Chapter 6). Alice in wonderland. Bridlington, USSR: Priory Books, A Peter Haddock Limited Imprint, B. W. (Leicester) Limited. Cebrowski, Arthur K., Vice Admiral, & Garstka, John J. (1998). Network- centric warfare: Its origin and future. Proceedings, U.S. Naval Institute. Available: http://www. usni ,org/Proceedings/Articles98/PROcebrowski. htm. Chait, Arthur L. (1994, January). Technology: The driving force. Across the Board. Available: il.proquest.com. 299 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Christensen, Clayton M. (1997, 2000). The innovator’s dilemma. Boston: The Harvard Business School Press. Clark, Vern, Admiral, United States Navy (2002, October). Sea power 21: Projecting decisive joint capabilities. U.S. Naval Institute Proceedings. Clinger-Cohen Act of 1996, Pub. L. No. 104-106 (1997). Incremental acquisition of Information Technology. Commander, Joint Chiefs of Staff (CJCS) Instructions: CJCS Instruction 6212.01A (1997, June 30). Compatibility, interoperability, and integration of command, control, communications, and intelligence (C31) systems. CJCS Instruction 3170.01 (1997, June 13). The requirements generation system. CJCS Instruction 3170.01A (1999, August 10). The requirements generation system. CJCS Instruction 3170.01B (2001, April 15). The requirements generation system. Joint Requirements Oversight Committee (JROC) memorandum (2000). Serial JROCM 203-00. Competition in Contracting Act of 1984 (1985). Title 41, United States Code, Section 253. Available: http://www.acq.osd.mit/installation/installation/utilities/uplinks/cica84. htm. ComponentWare Glossary. Available: http://www.objs.com/survey/ComponentwareGlossary.htm. Defense Appropriation and Authorization Bill (1996). Base realignment and closure (BRAC). Definition URLs: internet. Available: http://whatis.techtarget.eom/definition/0,,sid9_gci212127,00.htmi. 300 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Network. Available: http://searchWebServices.techtarget.eom/sDefinition/O,,sid26_gci213 782,00.html. Network. By Jeremy Reis. Available: http://www.learnthat.eom/define/n/network.shtml. Protocol. Available: http://searchNetworking.techtarget.eom/sDefinition/0,,sid7 gci212839, OO.html. Protocol. Available: http://www.leamthat.com/define/p/protocol.shtml. Software. Available: http://whatis.techtarget.eom/wsearchResults/1,290214,sid9,OO.html? query=software. Standalone Systems. Available: http://nscp.upenn.edu/aix4.3html/aixuser/aixqbeg/sys_setup.htm. Time-Critical Targeting Concept of Operations (TCT CONOPS). Available: h t t p ://C2FAFL0AT.SEC0NDFLT.NAVY.SMIL.MIL/ (Classified) and http://c2fafloat.secondflt.navy.smil.mil/ (Unclassified). Department of Defense (DOD) Policy Directives, Instructions, and Regulations: DOD Directive 4630.5 (1992, November 12). Compatibility, interoperability, and integration of command, control, communications, and intelligence (C3I) systems. DOD Directive 4630.5 (2002, January). Interoperability and supportability of Information Technology (IT) and National Security Systems (NSS). Department of Defense Instruction 4630.8 (1992, November 18). Procedures for compatibility, interoperability, and integration of command, control, communications, and intelligence (C3I) systems. DOD Directive 4630.8 (2000). Implementation of interoperability and supportability of Information Technology (IT) and National Security Systems (NSS). 301 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DOD Directive 5000.1 (2000, October 23). The Defense Acquisition System, 3. DOD Directive 7045.14 (DODD 7045.14) (1990, July 28). The Planning, Programming, and Budgeting System (PPBS). DOD Instruction 5000.2 (2001, January 4). Operation of the Defense Acquisition System. DOD Regulation 5000.2R (1996). Mandatory procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition programs, Change 1. DOD Regulation 5000.2-R (2001, June 15). Mandatory procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition programs. Standards and Guidance Documents: DOD C4ISR Architecture Framework Document (1999). DOD Command, Control, Communications, Computers, and Intelligence (C4I) (1997, December 18). Architecture Framework Document, Version 2.0, discusses the levels of interoperability. DOD Joint Technical Architecture (JTA), Version 4.0 (2002, July 17) establishes standards and protocols, but they are inconsistent both within and external to Navy. A team is working to solve this problem, but solutions will have impacts across the military Services and may not be cost effective to implement. IEEE STD 610.12, Version 2.0 (1997, December 17) as adapted by the U.S. Department of Defense (DOD) C4ISR Architecture Framework. DOD Quadrennial Defense Review Report (2001). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Department of Navy (DON) Policy Documents: CNO Message with a date time group of 021648Z MAY 98 to Navy organizations. Commander in Chief, United States Atlantic Fleet (CINCLANTFLT), Commander in Chief, United States Pacific Fleet (CINCPACFLT) Instruction 4720.3A, Code N66/N63 (2000, April 27). Operations Navy (OPNAV) Instruction 3050.23, Alignment and Responsibility of Navy Requirements Generation and Resource Planning (2001, November 5). Institute of Electrical and Electronic Engineers Standard (IEEE STD) 610.12, Version 2.0 (1997, December 18), as adapted by the U.S. DOD C4ISR Architecture Framework. ________ Standards and Guidance Documents: Chief of Naval Operations (CNO), Navy Strategic Planning Guidance (2000). Sea Power 21, Naval Power 21, and The Transformation Roadmap are visionary documents produced in 2002 to provide guidance to Navy and Marine Corps for their future direction. Operations Navy (OPNAV) Instruction 3050.23 (2001, November 5). Alignment and responsibility of Navy requirements generation and resource planning. ________ (1991). US Navy in Desert Shield/Desert Storm (Lessons learned and summary). Naval Historical Center, 805 Kidder Breese SE, Washington, DC 20374-5060, 7-8. Available: http://www.history.navy.mil/wars/dstorm/ds6.htm. Dertouzos, Michael (1997). What will be: How the new world of information will change our lives. San Francisco, CA: Harper Edge. England, Gordon, Secretary of Navy, Clark, Vern, Admiral, United States Navy, Chief of Naval Operations, & Jones, James L , General, United States Marine Corps, Commandant of the Marine Corps (2002). Naval transformation roadmap: Power and access... from the sea. Guidance document. 303 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Faughn, Anthony W., Lieutenant Colonel, United States Air Force (2002, October). Interoperability: Is it achievable? Program on Information Resources Policy, Center for Information Policy Research. Cambridge, MA: Harvard University Press. Federal Agency Responsibilities (Amended by Pub. L. Number 104-13, Paperwork Reduction Act [PRA]) (1995). Title 44, United States Code, 3506. Federal Networking Council (FNC). URL: http://www.itrd.gov. Fourth Wave Group (in the public domain). Available: http://www.fourthwavegroup.com/fwg/lexicon/1301w.htm Friedlander, Amy (1995). Natural Monopoly and Universal Service: Telephones and Telegraphs in the U.S. Communications Infrastructure, 1837-1940. Reston, VA: Corporation for National Research Initiatives (CNRI). _________ (1995). Emerging infrastructure: The growth of railroads. Reston, VA: Corporation for National Research Initiatives (CNRI). _ (1996). In God we trust: All others pay cash. Reston, VA: Corporation for National Research Initiatives (CNRI). _________ (1996). Power and light: Electricity in the U.S. energy infrastructure, 1870-1940. Reston, VA: Corporation for National Research Initiatives (CNRI). Garber, Dr. V. DOD interoperability/FlOP initiative. Briefing, Office of the Secretary of Defense, Pentagon. Delivered on several dates as early as June 2000. Goldwater Nichols Act of 1986 (1987). Department of Defense reorganization. United States Code (USC), Title 10, Subtitle A, Part I, Section 5. Gore, Al (1993). Re-inventing government. National Performance Review. Hawkins, James A., Major General (2002, October 30). Changes to the Requirements Generation System. Joint Staff policy memorandum, Serial DJSM-0921-02. 304 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Human Element and Culture Focus Team (2002). FORCEnet Operational Definition. Janeczek, Joseph J., & Borey, Bruce K. (2001, April). Root cause analysis for integration and interoperability for time critical strike: Survey of joint service concerns. Alexandria, VA: Center for Naval Analysis (CNA). Jensen, Arthur R. (1969, Winter). How much can we boost IQ and scholastic achievement? Harvard Educational Review, 39 (1). Johnson, Jay L, Admiral, U.S. Navy, Chief of Naval Operations (2001). Preface. Navy strategic planning guidance (NSPG). Guidance document, 1. Joint Publication 1-02 (JP 1-02) (2002). Dictionary of military terms. Available: http://www.dtic.mil/doctrine/jel/doddict/. Kahn, Robert E., & Cerf, Vinton G. (1988, December). What is the Internet (and what makes it work)? Abstract (see Appendix Y). Lautenbacher, Conrad C., Jr., Vice Admiral, Deputy Chief of Naval Operations (DCNO) for Resources (1999). Warfare requirements and assessments: Kosovo lessons learned. Available: http://www.fas.Org/man/congress/1999/99-10-19lautenbacher.htm. Mahler, Alwin (1999, November/December). The diffusion of interactive communication innovations and the critical mass: The adoption of telecommunication services by German banks. Telecommunications Policy, 23 (10/11), 719-740. Moore, James F. (1996). The death of competition: Leadership and strategy in the age of business ecosystems. Boston, MA: Harper Business. Namwoon, Kim, & Rajendra, K. (1998, May). Managing intraorganizational diffusion of technological innovations. New York: Industrial Marketing Management. Naval Historical Center (NHC) (1991). US Navy in Desert Shield/Desert Storm (Lessons learned and summary). Naval Historical Center, 805 Kidder Breese SE, Washington, DC 20374-5060, 7-8. Available: http://www. history, navy.mil/wars/dstorm/ds6.htm. 305 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Nooteboom, Bart (2000). Institutions and forms of co-ordination in innovation systems. Organization Studies, 21 (5), 915-940. Office of Assistant Secretary of Defense (OASD), Public Affairs (1999, October 14). Joint statement on the Kosovo after action review. News Release No. 478-99, 10-11. Available: http://www.defenselink.mil/news/Oct1999/bi 0141999_bt478-99. htm I. Oracle 8 (Business Corporation) (1997, June). Network computing and network centricity. An Oracle Business White Paper. Available: http://ntsolutions.oracle.com/solution/nca/htmi/nca_bwp2.htm. Osborne, David, & Gaebler, Ted (1992). Reinventing government. New York: Plume Penguin Publishing Group. Pfeffer, Jeffrey, & Salancik, Gerald R. (1978). The external control of organizations: A resource dependence perspective. New York: Harper & Row. Rai, Arun, Ravichandran, T., & Samaddar, Subhashish (1998, October). How to anticipate the Internet's global diffusion. Association for Computing Machinery: Communications of the ACM, 41 (10), 97-107. Rogers, Everett M. (1995). Diffusion of innovation (4t h ed.). New York: The Free Press. Ruis, Eduardo del Rio (1976). Marx for beginners. New York: Pantheon Books. Schein, Edgar H. (1996). Defining organizational culture. In Jay M. Shafritz & J. Steven Ott, Classics of organization theory (4t h ed., pp. 561-577). New York: Harcourt Brace College. Simon, Herbert A. (1997). Administrative behavior. New York: The Free Press. Smith, Malcolm (1998, July/August). Culture and organisational change. Management Accounting, 76 (7), 60-63. Taylor, Frederick W. (1912, January 25). Scientific management. Excerpt from Testimony before the U.S. House of Representatives. Reprinted in Jay M. Shafritz & Albert C. Hyde, Classics of public administration (4th ed.). Belmont, CA: Harcourt Bruce College Publishers. 306 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Taylor, James C., & Felten, David F. (1993). Performance by design: Sociotechnical systems in North America. Englewood Cliffs, NJ: Prentice Hall. Telecommunications Act of 1996 (1997). Pub. L. No. 104-104, 110 Stat. 56. URLs: URL 1: Joint Interoperability Test Command (JITC), http://jitc.fhu.disa.mil/index.htm. URL 2: See glossary for definition of “standalone system.” This definition is found at: http://nscp.upenn.edu/aix4.3html/aixuser/aixqbeg/sys_setup.htm. URL 3: MNS, ORD, CRD data base, http://ncw.navair.navy.mil. This URL enables one to apply for login access to the Interoperability Data Resource (IDR) Web site data base that houses MNS, ORDs, and CRDs. URL 4: http://airlines.afriqonline.com/features/usa.htm. URL 5: The history of the Internet can be found at: www.isoc.org/internet/history. URL 6, ARMY: http://www.stricom.army.mil/. URL 7: The ASN (RDA) ACAT list is published at: http://www.hq.navy.mil/RDA/programs.asp. URL 8: The source of the Navy organization charts is the Navy Web site at: http://www.chinfo.navy.mil/navpalib/organization/org-over.html. Verhoef, Ewoud (2002). Infrastructure definition: A short literature survey about infrastructure definitions. Available: http://www.infrastructures.tudelft.nl/infradef.html. Waldrop, M. Mitchell (1993). Complexity: The emerging science at the edge of order and chaos. New York: Touchstone. Webster’s Dictionary (1963). Cleveland, OH: World Publishing Co., Inc. 307 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Wentz, Larry (ed.) (1995). Lessons from Bosnia: The IFOR experience. Available: http://www.dodccrp.org/bostoc.htm. _________ (1995). C4ISR systems and services: Bosnia lessons learned. Available: http://www.dodccrp.org/bosch11 a.htm. Wilson, Woodrow (1887, June 2). The study of administration, essay. In Political Quarterly, reprinted in Jay M. Shafritz & Albert C. Hyde, Classics of public administration (3r d ed., p. 11). Belmont, CA: Wadsworth Publishing Company. In this document, Wilson stated: “It is the object of administrative study to discover, first, what government can properly and successfully do, and secondly, how it can do these proper things with the utmost possible efficiency and at the least possible cost either of money or of energy.” Wolfowitz, Paul, Deputy Secretary of Defense (2002, October 30). Defense Acquisition. Policy memorandum, Serial U16167-02. ________ (2001, October 12). Command and control (C2) legacy interoperability strategy and milestone action plan. SECDEF memorandum. Woodward, Jack, Lieutenant General, US Air Force (2002, March 27). Presentation at National Defense, Industrial Association (NDIA), Mesa, Arizona. Young, Vice Admiral, Commander of NAVSEA Systems Command (2002, August 9), in a message, discusses the need to reduce the number of people reporting to NAVSEA. 308 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. INTEROPERABILITY AMONG COMPLEX DEFENSE COMPUTER-BASED SYSTEMS: THE NAVY CASE VOLUME II APPENDICES by Cheryl A. Walton A Dissertation Presented to the FACULTY OF THE SCHOOL OF POLICY, PLANNING, AND DEVELOPMENT UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PUBLIC ADMINISTRATION May 2003 Copyright 2003 Cheryl A. Walton Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX A LESSONS LEARNED—AFGHANISTAN Bender, Bryan, Burger, Kim, & Koch, Andrew (2001, December 19). Afghanistan: First lessons. Jane’ s Defence Weekly. U.S. military sources say, for example, that as many as a dozen opportunities to strike high-value but time-critical targets, such as leaders of Al-Qaeda and the Taliban, were missed in the first few weeks of the war. This problem is attributed to the length of the decision loop—the time required from when a sensor detects a target to when it can be identified and approved by a human operator. Some of the those early problems were said to be due to interoperability issues and other technical difficulties, and others were questions of Rules of Engagement that could not be resolved quickly. Many U.S. tactical aircraft are still not equipped with digital satellite communications equipment—they are still reliant on aircraft such as the E-3 Airborne Warning and Control System to send messages to other aircraft and ground forces out of range. " " ........... N Interoperability problems have been a repeated theme in lessons-learned reports since the 1980s—Afghanistan, in the year 2001, was not an exception. N- - V 309 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX B LESSONS LEARNED—BOSNIA Wentz, Larry (1995). Lessons from Bosnia: The IFOR experience. Available: http://www.dodccrp.org/bostoc.htm. Wentz, Larry K. (1995). C4ISR systems and services, Chapter 11, 149, 150, 151. Wentz, Larry K. (1995). Bosnia lessons learned. Available: http://www.dodccrp.org/bosch11 a.htm. Although integrated C4ISR services are the desired objective, the realities tend to drive the solution to stove-piped implementations. In spite of technology advances, this will likely be the case for some time to come. There will continue to be uneven C4SSR capabilities among coalition members who will continue to rely on systems with which they are most comfortable-their own. For the IFOR operation, there were independent and separately managed NATO and national voice, message, data, and VTC networks; C4 systems and ISR systems; and so forth. This is simply the reality of coalition operations, with interoperability challenges and security disconnects that need to be dealt with. Agility and accommodation are truly keys to success in these types of operation. Early Interoperability Considerations Interoperability became a major concern when the total scope of the engineering effort for the IFOR network was realized. No one nation had committed to the integrated network engineering task that included terrestrial and satellite transmission systems; commercial PTT networks; and diverse systems of voice, video, and data of NATO and national strategic, theater, and tactical systems. It was decided to conduct a major interoperability exercise, called INTEROP 95, to get a better insight into the system integration and interface issues and solutions. INTEROP 95, held in April 1995, included more than 250 participants from 8 nations and tested all anticipated interfaces necessary to execute the AFSOUTH and ARRC OPLANs. System interfaces tested included the UN Ericsson commercial switch, the Olivetti 310 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. commercial switch, the Italian tactical system SOTRIN, the U.S. tactical systems TRI-TAC/MSE, the UK tactical system PTARMIGAN, the U.S. strategic system DSN, and the NATO voice network IVSN. The N.E.T. commercial IDNX, the SHAPE TSGT and deployable reach-back communications capability Replica, the USAF TSSR (TROPO/Satellite Support Radio) LOS radio, and NATO and national tactical satellite terminals (U.S. TSCs, UK VSC-501 and NATO Air Base SATCOM (NABS) (USAFE deployed)) were tested as well. The results of INTEROP 95 were so overwhelming that the U.S. Joint Interoperability Test Command (JITC) certified a number of the interfaces and published a NATO Interface Guide as a reference book. Lessons learned have shown that despite "standard NATO interfaces," interoperability trials still have to take place to reduce interface problems. Exercises such as INTEROP 95 and subsequently, Mountain Shield I and II, served to refine concepts of operation and work out many system integration and interoperability issues among various commercial and NATO strategic and national tactical switching and transmission systems. Among the 5th Signal Command learning experiences were difficulties in acquiring the NATO IVB satellite and poor-quality NATO satellite links (plagued with system hits). Subsequent U.S./NATO satellite testing revealed that BPSK rather than QPSK transmission needed to be used on the NATO IVB to achieve the desired link performance. Unfortunately, BPSK requires more bandwidth so the satellite planners had to reengineer the planned satellite network that was already bandwidth constrained. This problem may also have been a training-related issue as well, in that the U.S. personnel may not have been adequately prepared for accessing the NATO satellite system. Pre-deployment exercises serve to help resolve problems such as these. They also provide excellent training for the participating coalition organizations that end up supporting the actual operation. Based on field tests and exercises involving U.S., NATO, and allied communications systems, EUCOM J6 developed a EUCOM U.S./NATO/Allied Communications Systems Automated Interoperability Handbook. The handbook is on a laptop computer and is used to document known interoperable configurations that work. It provides a wiring diagram of the configuration, technical details, and other relevant information necessary to guide interface implementation in the field. An operator simply enters the configuration to be set up and if it has been accomplished before and documented, the computer provides the details necessary to implement, test, and operate the requested interface arrangement. 311 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Isolated exercises, such as INTEROP 95, were designed to add interoperability in Bosnia, but such a treatment is unique to the operational environment in Bosnia. The operational environment in Bosnia may not be the same in other military operations. Operational environments potentially influence the type and degree of interoperability problems. Dynamic operational environments make solving interoperability problems elusive .and difficult to solve. 312 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX C LESSONS LEARNED—KOSOVO Problems noted during the Kosovo conflict included interoperability with aircraft, U.S. allies, networks, and bandwidth as indicated in the excerpts below. Statement of Vice Admiral Conrad C. Lautenbacher, Jr, Deputy Chief of Naval Operations for Resources, Warfare Requirements and Assessments (1999). Kosovo lessons learned. Excerpt from Report, 2. Available: http://www.fas.Org/man/congress/1999/99-10- 19lautenbacher.htm. The Joint Requirements Oversight Council (JROC) validated the need to use Kosovo Emergency Supplemental funds for upgrades to improve joint interoperability for the EP-3E, for an additional EP-3E, and for conversion of an additional special mission P-3 aircraft. Office of Assistant Secretary of Defense, Public Affairs (1999, October 14). Joint statement on the Kosovo after action review. News Release, No. 478-99. Excerpt from Report, 10-11. Available: http://www.defenselink.mil/news/Oct1999/b10141999_bt478-99.html. . . . the operation highlighted a number of disparities between US capabilities and those of our allies, including precision strike, mobility, and command, control, and communications capabilities. The gaps in capability that we confronted were real, and they had the effect of impeding our ability to operate at optimal effectiveness with our NATO allies. For example, because few NATO allies could employ precision munitions in sufficient numbers (or at all), the United States conducted the preponderance of the strike sorties during the early stages of the conflict. The lack of interoperable secure communications forced reliance on non-secure methods that compromised operational security. These problems persisted throughout the campaign.. . . f ----- ---------------------------------------- Military forces must not only effectively exchange information among U.S. systems but also with allies. . . . . ^ 313 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX D LESSONS LEARNED—DESERT STORM During the Desert Shield/Desert Storm operation, interoperability problems were noted in warfighting areas (Anti-Air Warfare and Strike Warfare), communication with other military Services and nations, bandwidth capacity, and anti-jamming capabilities as indicated in the excerpts below. Department of Navy, Naval Historical Center (1991). U.S. Navy in Desert Shield/Desert Storm, lessons learned and summary. Excerpt from Report, 7-8. Naval Historical Center, 805 Kidder Breese SE, Washington, DC 20374-5060. Available: http://www.history.navy.mil/wars/dstorm/ds6.htm. ANTI-AIR WARFARE (AAW). Desert Shield/Storm presented an unprecedented AAW deconfliction challenge. All operations were conducted safely and successfully from pre-hostilities through re-deployment. There were no "blue-on-blue" air engagements. Restricted geography, unusual RF propagation conditions, proximity of the threat from Iraq and potential threat from Iran, the large number of commercial airfields and air routes in the vicinity, the joint/combined nature of the operation and the limited time available to establish positive identification of potential hostilities prior to entry into engagement envelopes combined to form a most complex, demanding AAW environment. Coalition air and surface units ere controlled through a complex sea-air land data link architecture. Some problems were noted—primarily in the areas of communications interoperability—but the overall success of joint/combined AAW during Desert Shield/Storm will provide a solid foundation for future operations. Department of Navy, Naval Historical Center (1991). U.S. Navy in Dbsert Shield/Desert Storm, lessons learned and summary. Excerpt from Report, 7-8. Naval Historical Center, 805 Kidder Breese SE, Washington, DC 20374-5060. Available: http://www. history, navy. mil/wars/dstorm/ds6. htm. STRIKE WARFARE. The Joint Force Air Component Commander (JFACC) used the air-tasking order (ATO) as a centralized 314 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. planning and execution tool. It was effective in managing the high volume of sorties generated to concentrate coalition air power against Iraq, especially during the preplanned, structured states of the campaign. There were some problems with production of the ATO and its delivery to naval forces. The flexibility of the ATO must be improved to account for changes, shifting priorities and real time target requirements as the campaign progresses. Department of Navy, Naval Historical Center (1991). U.S. Navy in Desert Shield/Desert Storm, lessons learned and summary. Excerpt from Report addressing Communication with other military Services and Nations, bandwidth capacity, anti-jamming capabilities, 7-8. Naval Historical Center, 805 Kidder Breese SE, Washington, DC 20374-5060. Available: http ://www. history, navy.mil/wars/dstorm/ds6. htm. COMMUNICATIONS. Almost every aspect of naval command and control communications capability was stressed to the limit during Desert/Shield/Desert Storm. Problems were solved through aggressive management, work-arounds, innovation, close cooperation and coordination, equipment upgrades and new installations. The volume of communications traffic, the scope of the USN/joint/combined connectivity requirements, and the high precedence of a large percentage of the message traffic, presented a communications challenge of previously unimagined proportions. The STU— III, INMARSAT, SHF installations, portable communications vans, and high speed modems stood out among many systems which contributed to success. We are focusing increased attention on improving our ability to communicate with other services and nations, strengthening jam-resistant communications, and using high speed computer networks to increase capacity. /^Lessons-learned from Kosovo crystallized the severity of Interoperability problems, as acknowledged by senior leaders. Almost ten years later, interoperability became a mandate in requirements and acquisition policy. , 315 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX E LESSONS LEARNED—DEFENSE LEADERS In 1982, Hal Kitson, Deputy Assistant Secretary of Navy for Command, Control, Communications, and Intelligence asked the question: “What inform ation exchange and functional agreements exist between ACDS, TFCC, ACS, and C2P [Navy systems] Programs?” The Vice Chief of Naval Operations wrote in a letter, 4 December 1985: .. [the Navy has] a fragmented approach to BFC2 resulting from a lack of understanding of interoperability issues and programmatic actions being taken without full understanding of the impact on other interrelated programs. Between 1980 and 1999, several Department of Navy organizations were established or committed to resolve system interoperability issues, including the following in chronological order: • Assistant Secretary of Navy for Research Development and Acquisition Office of the Chief Engineer; • Chief of Naval Operations—Operations Navy Integrated Warfare Architectures Process; • Program Executive Office for Theater Air Defense and NAVSEA 05 Systems Engineering; • NAVSEA and SPAWAR Combat System Functional Allocation Board; • Space and Naval Warfare Systems Command Code 30 (SPAWAR 30) Warfare System Architecture and Engineering; • Deputy Assistant Secretary of Navy Command, Control, Communications, Computers, and Intelligence (C4I) Force Warfare System Engineering Board; 316 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Naval Sea Systems Command Code 05 (NAVSEA 05) Chief Engineer; and • Navy Material Command. Through the years, defense leaders have spoken up about interoperability and the need to achieve it. They have been unable, thus far, to come together to make this happen. Organizations have been created to take on the task. They have not been given the authority, resources, and funding to implement. Or they have not successfully diffused a strategy to achieve interoperability that gained sufficient acceptance and adoption among the stakeholders charged with achieving interoperability. The strategies presented have primarily been focused on the physical technology—the system. Perhaps it is time to consider a strategy based on a social technology—a social system infrastructure with the authority needed to affect relationships involved in achieving interoperability for the common benefit of DOD and the military Services. “ A Senior leaders have acknowledged the interoperability problem but have not yet found the solution. J 317 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX F NAVY ORGANIZATIONAL STRUCTURE The Organizational Structure of the Department of Navy (DON) is vast and complex. It includes both Navy and Marine Corps. The structures in this appendix represent some, but not all, of the structures. Many of the boxes represent nested hierarchical structures. Though hierarchical, some of the boxes show up in multiple hierarchies, indicating that they are subordinate to multiple leaders. The Marine Corps boxes are shaded and are not expanded to the depth of Navy in the following structures that are in this appendix. Navy Organization; • The Secretary of the Navy; • Office of the Assistant Secretary of the Navy; • Program Executive Office (PEO) and Direct Reporting Program Manager (DRPM); Office of the Chief of Naval Operations; • The Type Commands; • Operating Forces; • The Shore Establishment; and • One of Three Major Navy Systems Commands. The source of the Navy organization charts is the Navy Web site at the following URL. http://www.chinfo.navy.mil/navpalib/organization/org- over.html. 318 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 1 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Chief of Legislative —AfejfS “ Chief of Legislative Affairs Chief of Legislative Affairs Chief of Legislative Affairs Assistant Secretary of the Navy (Research, Development, and Acquisition’) o The Secretary of the Navy The Secretary of the Navy T Unders of N he ecretary the avy Naval Inspector General Director of Program Appraisal Auditor General General Counsel Director, NCIS Assistant Secretary " “Assistant Secretary of the Navy of the Navy (Installation & (Financial Management ......Environment)... ...... & Comptroller!,,..... Chief 1 ComrrviUant of Naval of the ....... Operations Assistant Secretary of the Navy (Manpower & Reserve Affairs Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Office of the Assistant Secretary of the Navy (Research, Development, and Acquisition) Program Executive Offices (PEOs) Direct Reporting Program Managers (DRPMs) Acquisition Reform Executive Naval Supply Systems Command Deputy Acquisition & Business Management DASN International Programs Director Acquisition Career Management Marine Corps Systems Command Assistant General Counsel DASN Expeditionary Forces Programs Naval Facilities Engineering Command DASN Air Programs DASN Ship Programs Chief of Naval Research DASN C4/EW/Space Programs Naval Sea Systems Command DASN Planning Programming and Resources Space & Naval Warfare Systems Command Naval Air Systems Command DASN Mine/Undersea Programs DASN Theater Combat Systems Principal Deputy (PDASN) Assistant Secretary of the Navy (Research, Development, and Acquisition) w t*o Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Program Executive Office - PEO Direct Reporting Program Manager - DRPM NAVAIR A ir Force NAVAIR NAVAIR NAVSEA NAVSEA NAVSEA NAVSEA ALL SYSCOMS NAVSEA SPAWAR NAVSEA DRPM Advanced Amphibious Assault PEO Tactical Air Programs DRPM Strategic Systems Program — ------- PEO” — “ Air ASW, Assault and Special Missions Programs PEO Joint Strike Fighter PEO Submarines PEO Theater Surface Combatants PEO Strike Weapons and Unmanned Aviation PEO Aircraft Carriers PEO Information Technology PEO Mine and Undersea Warfare PEO Surface Strike Chief Engineer PEO Expeditionary Warfare Assisstant Secretary of the Navy (Research, Development, and Acquisition co h o h o Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Office of the Chief of Naval Operations Oceanographer of the Navy Chief of Chaplains of the Navy Director of Naval Reserves DCNO Plans Policy and Operations DCNO Manpower and Personnel Director of Naval Intelligence DCNO Fleet Readiness and Logistics Surgeon General of the Navy Director Navy Staff (DNS) Director of Space, Information Warfare, Command and Control DCNO Warfare Requirements and Programs Director of Naval Nuclear Propulsion Pgm. NOON Director of Test and Evaluation and Technology Requirements DCNO Resources, Requirements and Assessments Chief of Naval Operations Vice Chief of Naval Operations Special Assistants Public Affairs Safety Matters Inspections Legal Services Legislative Support Naval Investigative Matters and Security Material Inspections and Surveys 03 K 5 03 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. The Type Commands Commander Submarine Force US Atlantic Fleet Commander Submarine Force US Pacific Fleet Commander Naval Air Force US Atlantic Fleet Commander Naval Air Force US Pacific Fleet Commander US Atlantic Fleet Commander US Pacific Fleet Commander Naval Surface Force US Atlantic Fleet Commander Naval Surface Force US Pacific Fleet Naval Operations (CNO) Chief to Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. 6th Fleet US Naval Forces Europe Naval Reserve Forces C a3 N3 cn The Operating Forces 7th Fleet 3rd Fleet 5th Fleet 2nd Fleet Type Commands Type Commands US Naval Forces Central Command Atlantic Fleet Includes Fleet Marine Forces Pacific Fleet Includes Fleet Marine Forces Operational Test & Evaluation Forces Military Sealift Command Naval Special Warfare Command Naval Operations (CNO) Chief Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. The Shore Establishment Bureau Naval Personnel Naval Personnel Bureau Office of the CNO Naval Space Command Naval Sea Systems Command Naval Legal Service Command Navy Warfare Development Command Naval Air Systems Command Naval Supply Systems Command Space & Naval Warfare Systems Command Naval Facilities Engineering Command Naval Safety Center Chief of Naval Education & Training Naval War College Office of Naval Intelligence Naval Computer & T elecommunications Command Naval Meteorology & Oceanography Command Naval Operations (CNO) Chief 03 ro 03 Strategic Systems Programs Naval Security Group Command Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. One of Three Major Navy Systems Commands Space and Naval Warfare Systems Command - SPAWAR Echelon H - Headquarters SPAWAR Echelon III Organizations Headquarters Support Staff PEO IT CIO Washington Operations Office IT Center Space Field Activity Systems Center San Diego Installations/ Logistics Systems Center Norfolk Systems Center Charleston Contracts Corporate Planning & Operations Chief Engineer Comptroller Chief Technology Office Naval Networks & Information Assurance Intelligence, Surveillance, & Reconnaissance Space Technology Systems C2I & Combat Support Applications Communication Programs Space & Naval Warfare Systems Command w N3 --J The nine charts on the previous pages only begin to reveal the organizational complexity. There are many actors, orientations, opinions, preferences, and authorities relevant to achieving interoperability—none of which can be ignored. All must be taken seriously. The Navy, as an organization, is vast, complex, and bureaucratic. Does its hierarchical structure inhibit the achievement of interoperability that crosses this structure horizontally, vertically, and diagonally? How would the organizational infrastructure of a social technology, conducive to achieving interoperability, look? Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX G MEMORANDUM ON LEGACY SYSTEMS AND INTEROPERABILITY Introduction Interoperability is such a serious problem that it is at the highest levels of senior authority in the Department of Defense. Paul Wolfowitz, Deputy Secretary of Defense (DEPSECDEF), was compelled to demand that serious actions be taken to address the interoperability problem in legacy Command and Control (C2) systems. Wolfowitz astutely and accurately identified legacy systems as a major obstacle in achieving acceptable levels of interoperability. He recognized that the Defense Acquisition System does not address legacy systems, nor do other policy processes. The memorandum that starts on the following page includes the actions DEPSECDEF was compelled to take. Legacy systems are the crux of the interoperability problem— DEPSECDEF Wolfowitz understands this. Other interoperability strategies focus on new and future systems, but the legacy systems are not going away. Ways must be created to make them interoperable with other systems that are being introduced now and in the future. 329 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. THE DEPUTY SECRETARY OF DEFENSE W A S H IN G T O N , D .C . 2 0 3 0 ! n r 12 an MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTS CHAIRMAN OF THE JOINT CHIEFS OF STAFF UNDER SECRETARIES OF DEFENSE DIRECTOR, DEFENSE RESEARCH & ENGINEERING ASSISTANT SECRETARIES OF DEFENSE GENERAL COUNSEL, DEPARTMENT OF DEFENSE INSPECTOR GENERAL, DEPARTMENT OF DEFENSE DIRECTOR, OPERATIONAL TEST & EVALUATION ASSISTANTS TO THE SECRETARY OF DEFENSE DIRECTOR, ADMINISTRATION & MANAGEMENT DIRECTORS OF THE DEFENSE AGENCIES SUBJECT: Command and Control (C2) Legacy Interoperability Strategy and Milestone Action Plan I am committed to resolving the problems of legacy C2 interoperability in an expeditious and cost effective manner. Therefore, I am establishing a goal for the Department to have legacy systems interoperable, with respect to critical command and control functions by the end of Fiscal Year (FY) 2008. The Department has worked diligently to put appropriate policy and procedures in place to achieve the level of interoperability required to effectively conduct modernized military and business operations. A revision to Department of Defense (DOD) Directive 4630.5, Interoperability and Supportability of Information Technology (IT ) and National Security Systems (NSS), is necessary to clearly define the roles and responsibilities of all DOD components, to achieve the interoperability of information technology and national security systems throughout the Department. This must be coordinated and presented for my signature within 30 days from the date of this memorandum. Accordingly, I direct the following actions: a. Under Secretary of Defense (Acquisition Technology & Logistics) (USD (AT&L)): Review the current Defense Acquisition System and define, in coordination with the CIO and the Joint Staff, additional provisions necessary to support the achievement o f interoperability among systems a s a life cycle responsibility. Implement required changes by March 29, 2002. U15895 /01 330 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. b. Under Secretary of Defense (Comptroller): Effective immediately, ensure that the Planning, Programming, Budgeting System considers C2 legacy interoperability funding requirements. Specifically, the Comptroller in coordination with the USD(AT&L), Joint Requirements Oversight Council (JROC), and the DoD Chief Information Officer (CIO) will ensure appropriate funding for a prioritized set of overarching program initiatives beginning in FY03. Initiatives should focus on mission critical C2 interoperability for the Joint Task Force (JTF) and below; the Joint Integration and Interoperability organization; and the Joint Distributed Engineering Plant. Also, identify funding for the Family of Interoperable Operational Pictures (HOP) a s directed by the JROC. Candidate initiatives w ill be considered for acceleration and FY03 funding based on JROC recommendations and clear benefits to JTF operations. c. Joint Forces Command (JFCOM): Address issues and develop material and non-material options to resolve JTF C2 legacy interoperability shortfalls. Forward recommendations to the JROC for prioritization and referral to OSD by March 29,2002. d. Chief Information Officer, DOD: In coordination with the USD (AT&L), the Joint Staff, and JFCOM, identify the key DoD component organizations addressing legacy interoperability, areas of duplication, and opportunities for consolidation or elimination. Provide recommendations to the JROC by March 29, 2002. e. Chairman of the Joint Chiefs of Staff: In coordination with the USD (AT&L), CIO, DOT&E, JFCOM, and OSD(PA&E) develop initial metrics for operationally determining success in overcoming legacy C2 interoperability shortfalls. Modify CJCS Instructions, a s appropriate by March 29, 2002. f. Combatant Commands, Services and Defense Agencies: Identify opportunities for strengthening the implementation of DoD Directive 4630.5 and DoD Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT)and National Security Systems. Forward recommendations to the CIO by March 29,2002. Please direct questions or concerns you may have to Dr. V. Garber, Director, Interoperability, OUSD(AT&L) at (703) 695-9713. 331 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX H DOD INTEROPERABILITY DIRECTIVE 4630.5 NOVEMBER 12,1992 COMPATIBILITY, INTEROPERABILITY, AND INTEGRATION OF COMMAND, CONTROL, COMMUNICATIONS, AND INTELLIGENCE (C3I) SYSTEMS Introduction This policy mandated interoperability for new or upgraded systems developed under the Defense Acquisition System. It did not require special effort on the part of existing systems to be interoperable with new or upgraded systems. This is the reason the policy was a target identified in DEPSECDEF, Paul Wolfowitz’s, October 12, 2001, memorandum directing that action be taken to make legacy systems interoperable. The policy is on the following pages. DOD Directive 4630.5 of 1992 required C3I systems developed under the Defense Acquisition System to be compatible with existing (legacy) systems and interoperable with other systems, both U.S. and allied nations. The rhetorical objective of this policy is clear—assuring interoperability between new systems and existing systems. It is not clear that it will do so. Interoperability may be achieved but with diminished capability. 332 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1.1.1 DODD 4630.5,12 November 1992 Compatibility, Interoperability, and Integration of Command, Control, Communications, and Intelligence (C3I) Systems References: (a) DoD Directive 4630.5, "Compatibility and Interoperability of Tactical Command, Control, Communications, and Intelligence Systems," October 9, 1985 (hereby canceled). (b) DoD Directive 5000.1, "Defense Acquisition," February 23, 1991. (c) DoD Instruction 5000.2, "Defense Acquisition Management Policies and Procedures," February 23, 1991. (d) Section 2457 of title 10, United States Code. A. Reissuance and Purpose This Directive reissues reference (a) and promulgates policy for compatibility, interoperability, and integration of C3I systems used in the Department of Defense. B. Applicability and Scope This Directive applies to: 1. The Office of the Secretary of Defense (OSD), the Military Departments, the Chairman of the Joint Chiefs of Staff and the Joint Staff, the Unified and Specified Combatant Commands, the Inspector General of the Department of Defense, the Defense Agencies, and the DoD Field Activities (hereafter referred to collectively as "the DoD Components"). 2. All new C3I systems (including nondevelopmental systems) and major changes (e.g., release of a new software version) to existing systems that must interact with or be integrated into the C3I structures of the Department. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C. Definition Principal Staff Assistants. Undersecretaries of Defense, Assistant Secretaries of Defense, General Counsel of the Department of Defense, Inspector General of the Department of Defense, Comptroller of the Department of Defense, Assistants to the Secretary of Defense, and OSD Directors or equivalents who report directly to the Secretary or Deputy Secretary of Defense. D. Policy It is DoD Policy: 1. That forces for joint and combined operations must be, supported through compatible, interoperable, and integrated C3I systems that can support operations worldwide throughout the entire spectrum of conflict. 2. To establish as a long-term objective a DoD-wide, global C3I infrastructure that can accommodate the widest possible range of missions and operational scenarios by allowing users to enter the infrastructure at any time, any place, in the execution of any mission. 3. In accordance with DoD Directive 5000.1 and DOD Instruction 5000.2 (references [b] and [c]), to develop, acquire, and deploy C3I systems and equipment that meet essential operational needs of U.S. Forces, that are compatible with existing and planned C3I systems and other electronic equipment, and that are interoperable with other U.S. and allied nations, functionally related C3I information systems and equipment. See 10 U.S.C. 2457 (reference [d]), which establishes a policy of Standardization and interoperability within the North Atlantic Treaty Organization. 4. That, for purposes of compatibility, interoperability, and integration, dll C3I systems developed for use by U.S. forces are considered to be for joint use. 5. That interoperability and integration of C3I requirements shall be determined during the requirements validation process and shall be updated as necessary throughout the acquisition period, deployment, and operational life of a system. 334 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. E. Responsibilities 1. The Assistant Secretary of Defense for Command, Control, Communications, and Intelligence small assign responsibilities and prescribe procedures as necessary, to ensure the policies outlined in section D, above, are carried out. 2. The Principal Staff Assistants shall, during all technical, program, budget, funding, or other reviews of the Military Departments or the Defense Agencies affecting compatibility and interoperability requirements, make recommendations to the appropriate decision authority about the conformance to the policies outlined in section D, above. 3. The Chairman of the Joint Chiefs of Staff shall: In accordance with references (b) and (c), establish procedures for the development, coordination, review, and validation of compatibility, interoperability, and integration requirements for the C3I systems. Approve, document, and exercise doctrinal concepts and associated operational procedures to achieve compatibility, interoperability, and integration of C3I systems employed by U.S. military forces and, as appropriate, with coalition and allied forces. Establish procedures for and ensure compliance with certification of joint interoperability of C3I systems throughout those systems' life cycles. 4. The Heads of the DoD Components shall ensure that the provisions of section D, above, are followed during the requirements validation process, acquisition, deployment, and operation of systems and forces. F. Effective Date This Directive is effective immediately. Donald J. Atwood Deputy Secretary of Defense 335 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX I DOD INTEROPERABILITY DIRECTIVE 4630.5 JANUARY 2002 INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION (IT) AND NATIONAL SECURITY SYSTEMS (NSS) INTRODUCTION The Clinger-Cohen, Information Technology Management Reform Act (ITMRA) mandated better management of Information Technology (IT) and National Security systems (ITMRA, 1996). ITMRA called for IT and NSS architectures, standards, and policy. Implementers of ITMRA viewed all other policy that referred to the management of information via IT as part of their domain. DODD 4630.5 of 1992 was viewed as part of this domain. But, it did not address IT or NSS. DODD 4630.5 of 2002, included in this appendix, corrects this problem. The providence of this policy is not entirely clear. Though issued shortly following the Wolfowitz memo that mandated policy changes to address legacy system interoperability, it suggests but does not clearly address interoperability for legacy systems. There is no evidence that changes were made to specifically address the Wolfowitz memo mandate. DISCUSSION As did DODD 4630.5 of 1992, the 2002 policy also mandated interoperability for new or upgraded systems. It differs from the 1992 policy in that insfead of focusing the policy on C3I systems, it focused on IT systems, to include NSS. The distinction and scope of C3I, NSS, and IT systems has been an ongoing debate in DOD since issuance of ITMRA. IT proponents include NSS as part of IT. NSS advocates disagree. A solution to the debate is being attempted by incorporating it into policy. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The 4630.5, 2002 policy is more explicit than its C3I predecessor and had descriptions of roles for a greater number of organizations. As with the earlier policy, it mandates compatibility with existing systems, and it too does not require special effort on the part of existing systems to be interoperable with new or upgraded systems. This policy was issued after the DEPSECDEF Paul Wolfowitz’s, 12 October, 2001 memorandum. It does not, however, offer a means of solving the interoperability problems of Command and Control legacy systems. DEPSECDEF signed DOD Directive 4630.5 of 2002 policy issued after committing to resolving interoperability problems in Command and Control legacy systems. 4630.5 of 2002 replaces the earlier 4630.5 policy of 1992 of the same name. Neither directive offers solutions to legacy interoperability problems. Interoperability is achievable by requiring that new systems are compatible with the old, though this often limits capability of the new. DOD and Navy need to find a better way of dealing with interoperability to avoid sacrificing new capability. Willingness to accept limits on new capability slows progress. 337 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. SUBJECT: References: Department of Defense DIRECTIVE NUMBER 4630.5 January 11, 2002 ASD(C3I) Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS) (a) DoD Directive 4630.5, "Compatibility, Interoperability, and Integration of Command, Control, Communications, and Intelligence (C3I) Systems," November 12, 1992 (hereby canceled). (b) Division E of the Clinger-Cohen Act of 1996 (Chapter 25 of title 40, United States Code), as amended. (c) Sections 2223 and 2224 of title 10, United States Code, as amended. (d) Section 133 of title 10, United States Code. (e) DoD Directive 5000.1, "The Defense Acquisition System," October 23, 2000. (f) DoD Instruction 5000.2, "Operation of the Defense Acquisition System," October 23, 2000. (g) DoD 5000.2-R, "Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs," June 10, 2001. 338 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1. REISSUANCE AND PURPOSE This Directive: 1.1. Reissues reference (a) to update policy and responsibilities for interoperability and supportability of Information Technology (IT), including National Security Systems (NSS), to reflect DoD Chief Information Officer's (DoD CIO's) responsibilities contained in references (b) and (c). 1.2. Directs the use of a mission-related, outcome-based approach that considers both materiel (acquisition or procurement) and non-materiel (doctrine, organizational, training, leadership, personnel, or facilities) aspects to ensure interoperability and supportability of IT and NSS throughout the Department of Defense. This approach ensures that information is available to the Department of Defense in an assured, timely, useable, understandable, and cost-effective manner. 2. APPLICABILITY AND SCOPE This Directive applies to: 2.1. The Office of the Secretary of Defense, the Military Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, the Inspector General of the Department of Defense, the Defense Agencies (see paragraph E2.1.2., below) the DoD Field Activities, and all other organizational entities within the Department of Defense (referred to collectively as "the DoD Components"). 2.2. All IT, including NSS, acquired, procured (systems or services), or operated by any Component of the Department of Defense, to include: 2.2.1. All IT and NSS defense acquisition programs, defense technology IT and NSS projects, and IT and NSS pre-acquisition demonstrations (e.g., Advanced Concept Technology Demonstrations, Advanced Technology Demonstrations, and Joint Warrior Interoperability Demonstration Gold Nuggets when selected for acquisition or procurement), Joint Experimentation, and Joint Tests and Evaluations; non-5000 Series IT and NSS acquisitions or procurements (e.g., the Commander in Chief (CINC) Command and Control Initiative Program, CINC Initiatives Fund, CINC Field Assessments, Military Exploitation of Reconnaissance and Technology Programs, and Tactical Exploitation of National Capabilities Programs); and post acquisition (fielded) IT and NSS systems. 339 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.2.2. All inter- and intra-DoD Component IT and NSS that exchange and use information to enable units or forces to operate effectively in joint, combined, coalition, and interagency operations and simulations. 2.2.3. All IT and NSS acquired, procured, or operated by DoD intelligence agencies, DoD Component intelligence elements, and other DoD intelligence activities engaged in direct support of DoD missions. This Directive recognizes that special measures may be required for protection/handling of foreign intelligence or counterintelligence information, or other need to know information. Accordingly, implementation of this Directive must be tailored to comply with separate and coordinated Director of Central Intelligence (DCI) Directives and Intelligence Community policies. 2.2.4. All DoD IT and NSS external information exchange interfaces with other U.S. Government Departments and Agencies, combined and coalition partners, and multinational alliances (e.g., North Atlantic Treaty Organization). 3. DEFINITIONS Terms used in this Directive are defined in enclosure 2. 4. POLICY It is DoD policy that: 4.1. IT and NSS interoperability and supportability are essential to joint, combined and coalition forces working together seamlessly to enhance operational effectiveness. Attaining IT and NSS interoperability and supportability is a continuous process, addressed as a balance of materiel and non-materiel solutions that is achieved and sustained throughout a system's life. Achieving and sustaining interoperability and supportability is a DoD enterprise-wide responsibility that must be woven into the thread of organizational roles, responsibilities, processes, and resources. 4.2. The Department of Defense shall achieve and maintain information superiority for the warfighter and decision-maker by developing, acquiring, procuring, maintaining and leveraging interoperable and supportable IT and NSS. IT and NSS interoperability and supportability shall be attained through mission-related, outcome-based processes. Interoperability and supportability requirements shall be balanced with the need for Information Assurance. Joint, combined, coalition, and interagency missions must be supported through interoperable IT and NSS in global operations across the peace-conflict spectrum. 340 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.3. For the purposes of interoperability and supportability, IT and NSS used by U.S. Forces shall be developed with the capability to meet essential operational needs, and where required, shall interoperate with existing and planned, functionally related, systems and equipment of joint, combined and coalition forces; and with other U.S. Government Departments and Agencies, as appropriate. 4.4. IT and NSS interoperability and supportability requirements shall be characterized through operational mission area integrated architectures, operational concepts and Capstone Requirements Documents derived from Joint Mission Areas (JMAs) and business/administrative mission areas. The Joint Operational Architecture (JOA), the Joint Systems Architecture (JSA), and the Joint Technical Architecture (JTA) shall serve as the foundation for development of mission area integrated architectures. Mission area integrated architectures shall relate IT and NSS interoperability and supportability requirements in a Family-of-Systems/ System-of-Systems (FoS/SoS) context. IT and NSS FoS/SoS Information Exchange Requirements (lERs) and associated interoperability Key Performance Parameters (KPPs) shall be derived from the operational view of the mission area integrated architecture. 4.5. IT and NSS interoperability and supportability needs shall be identified through the requirements definition and validation process, in conjunction with the acquisition process, and shall be updated as necessary throughout the system's life. IT and NSS interoperability and supportability requirements shall be specified to a level of detail that allows verification of interoperability throughout a system's life. For IT and NSS defense acquisition and procurement programs, an interoperability KPP shall be defined during the requirements definition and validation process. The defined interoperability KPP shall be developed in such a way that it can be reliably measured tested and evaluated. If an evolutionary acquisition strategy is employed, IT and NSS interoperability and supportability requirements shall evolve consistent with the evolutionary acquisition approach. 4.6. IT and NSS interoperability and supportability shall be managed, evaluated, and reported over the life of the system using an existihg program support or management plan format. The support or management plan shall contain detailed and time-phased information for identifying dependencies and interface requirements, consistent with mission area integrated architectures, focusing attention on interoperability, supportability, and sufficiency concerns. For IT and NSS defense acquisition programs and procurements, system dependencies and interface requirements shall be described in sufficient detail to assist in acquisition and procurement decisions, and to provide test planners the information necessary to ensure that the system test program is sufficient to permit an accurate assessment of the systems' KPP capabilities and limitations. For non-acquisition 341 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. designated IT and NSS programs, the program support or management plan shall contain sufficient detail (commensurate with the size of the program/effort) to permit an evaluation of the associated interoperability and supportability requirements. 4.7. IT and NSS shall be tested early and with sufficient frequency throughout a system's life or upon changes affecting interoperability or supportability to assess, evaluate, and certify its overall level of interoperability and supportability. This certification will be cost effective and shall be successfully completed prior to fielding of new IT and NSS or prior to fielding a new capability or upgrade to existing IT and NSS. 4.8. The process for improving IT and NSS interoperability and supportability shall provide solution sets focused on mission-based outcomes that address both materiel and non-materiel aspects. Once IT and NSS interoperability solution sets are validated, appropriate resources shall be recommended to implement identified remedies. As part of this process, the operational community shall identify, prioritize, and synchronize non-materiel solutions with materiel solutions to resolve interoperability and supportability issues. 4.9. IT and NSS interoperability and supportability oversight and direction shall be jointly provided by the Under Secretary of Defense for Acquisition, Technology, and Logistics (USD [AT&L]); the Under Secretary of Defense (Comptroller) (USD [C])/DoD Chief Financial Officer (DoD CFO); the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD [C3I]), ASD(C3I) as the DoD CIO; the Director, Operational Test and Evaluation (DOT&E); the Chairman of the Joint Chiefs of Staff; and the Commander in Chief, U.S. Joint Forces Command (USCINCJFCOM), as appropriate. 5. RESPONSIBILITIES 5.1. The Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, shall: 5.1.1. Ensure, with the USD (AT&L), USD (C)/DoD CFO, the Chairman of the Joint Chiefs of Staff, DOT&E, and U.S. Joint Forces Command, that IT and NSS interoperability and supportability issues are addressed during the acquisition or procurement process. Ensure interoperability and supportability requirements, particularly cross system and cross-Service, are identified and recommended for programming and budgeting. 342 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.1.2. Advise the Deputy Secretary of Defense, in coordination with the affected DoD Components, regarding alternative solutions and funding needs to meet interoperability and supportability shortfalls. 5.1.3. Ensure that the Director, Defense Information Systems Agency (DISA), establishes and conducts an IT and NSS interoperability assessment, test, evaluation, and certification program in collaboration with the DoD Components. Results from DISA interoperability assessments, tests, evaluations, and certifications shall conform to applicable security classification guidance to avoid potential compromise of information that may reveal component and/or system susceptibilities and vulnerabilities. 5.1.4. As the Chairman of the National Security Telecommunications and Information Systems Security Committee (NSTISSC), consider requests for release of Information Security (INFOSEC) products or associated INFOSEC information to a foreign government or an international organization when required to achieve combined or coalition interoperability. 5.1.5. Ensure that the Director, National Security Agency, prescribes information assurance policy and procedures for safeguarding IT and NSS capabilities. 5.2. The Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, as the Department of Defense Chief Information Officer, shall: 5.2.1. Maintain this Directive, with the other DoD Components, to codify the policies and responsibilities necessary to ensure interoperability and supportability of IT and NSS throughout the Department of Defense. 5.2.2. Provide policy, guidance, and oversight, with the DoD Components, to ensure that IT and NSS are interoperable and supportable with other relevant IT and NSS internal and external to the Department of Defense. 5.2.3. Ensure the development, implementation, and maintenance of a sound and integrated Information Technology Architecture (ITA) for all DoD IT and NSS, as required by reference (b). Ensure, with the USD (AT&L), the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command that FoS/SoS IT and NSS mission area integrated architectures are defined, developed, integrated, coordinated, validated, synchronized, and implemented. 343 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.2.4. Establish responsibilities and procedures, with the USD(AT&L), DOT&E, the DoD Components, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command, to ensure early assessment, verification, evaluation and certification of IT and NSS interoperability and supportability throughout a system’s life. The DoD CIO, with the DoD Components, shall also ensure user-defined, mission-related, outcome-based performance measures are established for use in assessment and verification of IT and NSS interoperability and supportability. 5.2.5. Develop a process, with the DoD Components, to annually evaluate Department of Defense IT and NSS interoperability and supportability status. Findings will be reported to the Deputy Secretary of Defense in sufficient time to support the Department’s budgeting decisions. 5.2.6. Define, organize, and approve, with the USD (AT&L), the Chairman of the Joint Chiefs of Staff, and the DoD Components, Universal Reference Resources (URRs) for developing mission area integrated architectures throughout the Department of Defense. 5.2.7. Maintain a consolidated inventory, and identify associated interfaces, for DoD Mission Critical Information Systems (MCIS) and Mission Essential Information Systems (MEIS). 5.2.8. Prescribe, with the DoD Components, approved IT and NSS standards that apply throughout the Department of Defense. For non- Acquisition Category (ACAT) and procurement matters, the prescription of IT and NSS standards will consider tradeoffs among operational effectiveness, operational suitability, and IT and NSS interoperability and supportability. 5.2.9. Review, assess, and evaluate IT and NSS acquisitions and procurements, and, with the DoD Components, propose recommendations to the Secretary of Defense for the elimination of unnecessary duplication of IT and NSS within and among the DoD Components. 5.2.10. Provide the Deputy Secretary of Defense, with USD(AT&L), USD(C)/DoD CFO, the Chairman of the Joint Chiefs of Staff, the DoD Components, and U.S. Joint Forces Command, material and non material recommendations for resolving critical IT and NSS interoperability and supportability issues. These recommendations shall be prioritized and phased for acquisition (or procurement) and implementation. 344 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.3. The Under Secretary of Defense for Acquisition, Technology and Logistics shall: 5.3.1. As the Department of Defense Acquisition Executive (reference [dj), ensure the policies outlined in section 4., above, are incorporated into the 5000 series of DoD issuances (references [e], [f], and [g]) and addressed during systems acquisition, as appropriate. 5.3.2. For all acquisition matters, with the DoD CIO, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command, approve tradeoffs among operational effectiveness, operational suitability, and IT and NSS interoperability and supportability. 5.3.3. Define policy and procedures, with the DoD CIO and the DOT&E, for a management process, using a support or management plan for ensuring IT and NSS interoperability and supportability over a system's life. 5.3.4. Establish responsibilities and procedures, with the DoD CIO, the DOT&E, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command, for assessing and verifying interoperability KPPs throughout a system's life. Ensure mission-related, outcome-based performance measures are established for assessing and verifying IT and NSS interoperability and supportability. 5.3.5. Ensure, with DoD CIO and the Chairman of the Joint Chiefs of Staff, that approved architectural framework concepts and products are incorporated into acquisition guidance and policy. 5.3.6. Identify, coordinate, and integrate DoD system architecture views into an overall DoD-wide JSA. 5.4. The Under Secretary of Defense (Comptroller)/Chief Financial Officer shall: 5.4.1. Ensure, with affected DoD Components, IT and NSS interoperability and supportability funding issues resulting from the requirements of this Directive are addressed in the budgetary process. 5.4.2. Provide the Deputy Secretary of Defense, with USD(AT&L), DoD CIO, the Chairman of the Joint Chiefs of Staff, the other DoD Components, and U.S. Joint Forces Command, budget recommendations for addressing critical IT and NSS interoperability and supportability issues. 345 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.5. The Director of Operational Test and Evaluation shall: 5.5.1. Coordinate with the Chairman of the Joint Chiefs of Staff and U.S. Joint Forces Command, to ensure interoperability KPPs specified in requirements documents are measurable and contribute to the evaluation of a system's operational effectiveness and suitability. 5.5.2. Develop policy, processes, practices and test infrastructure, with USD(AT&L) and the DoD CIO, to ensure IT and NSS interoperability and supportability are evaluated as a measure of operational effectiveness throughout all test programs. Ensure interoperability test requirements are identified in test and evaluation master plans and operational test plans. Emphasize evaluation of IT and NSS interoperability and supportability, in a FoS/SoS environment, as early as possible during a system's development. 5.5.3. Provide an assessment of interoperability and related supportability at acquisition milestones. Report results of these interoperability and supportability assessments as part of the DOT&E Annual Report to Congress. 5.5.4. Assist the DoD Components with test planning and assessment of FoS/SoS IT and NSS interoperability and supportability. 5.6. The Heads of the DoD Components shall: 5.6.1. Ensure the requirements of this Directive are implemented, including the establishment of procedures for: the development, coordination, review, and verification of IT and NSS interoperability and supportability requirements; IT and NSS acquisition or procurement; and testing within respective functional areas. 5.6.2. Ensure interoperability and supportability capabilities are designed, developed, tested, evaluated, and incorporated into all DoD Component IT and NSS. When necessary, recommend tradeoffs among operational effectiveness, operational suitability, and IT and NSS interoperability and supportability to USD(AT&L), the DoD CIO, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command. 5.6.3. Ensure IT and NSS interoperability and supportability requirements are identified and accommodated in respective DoD Components' budgets. When necessary, propose alternative programmatic, technical and funding solutions to meet IT and NSS interoperability and supportability shortfalls to USD (AT&L), the DoD CIO, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command. 346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.6.4. Implement procedures to ensure the use of DoD JTA, Common Operating Environment (COE) technical guidance, and COE technology for programs under the DoD Components' cognizance. 5.6.5. Ensure test and evaluation plans are prepared for all IT and NSS acquisitions and procurements. 5.6.6. Develop procedures for all IT and NSS acquisitions and procurements to document, manage, evaluate, and report on IT and NSS interoperability throughout a system's life using a program support or management plan. 5.6.7. Provide results of all developmental and operational joint interoperability assessments, tests and evaluations to USD (AT&L), the DoD CIO, DOT&E, the Chairman of the Joint Chiefs of Staff, and U.S. Joint Forces Command. 5.7. The Chairman of the Joint Chiefs of Staff shall: 5.7.1. Establish policy and procedures, with U.S. Joint Forces Command and other DoD Components, for the development, coordination, review, and approval of IT and NSS interoperability and supportability requirements. 5.7.2. Develop, approve, and direct the use of the JMA-based JOA to facilitate the identification of IT and NSS interoperability and supportability requirements within a FoS/SoS context. 5.7.3. Develop, approve, and issue joint-doctrinal concepts and associated operational procedures to achieve interoperability and supportability of IT and NSS capabilities employed by U.S. Military Forces and, where required, with: joint, combined, and coalition forces; and with other U.S. Government Departments and Agencies. 5.7.4. Review and certify IT and NSS lERs, resultant interoperability KPP, and other requirements as derived from mission area integrated architectures. 5.7.5. Establish, with USD(AT&L), the DoD CIO, DOT&E, and U.S. Joint Forces Command, procedures for verification of interoperability for fielded IT and NSS throughout a system's life. 5.7.6. Establish a process to ensure insights are gained from Joint Exercises on IT and NSS interoperability and supportability and coordinated with the DoD CIO and USD (AT&L). 347 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.8. The Commander in Chief, U.S. Joint Forces Command shall: 5.8.1. Serve as the Chief Advocate for Interoperability by assessing IT and NSS interoperability requirements from the warfighter's perspective in accordance with Chairman of the Joint Chiefs of Staff responsibilities to review and confirm lERs and interoperability KPPs ensuring new systems and capabilities address interoperability and supportability from inception throughout a system's life. 5.8.2. Solicit from the CINCs joint, combined, and coalition IT and NSS interoperability and supportability issues. 5.8.3. Identify, consolidate, and prioritize IT and NSS interoperability and supportability issues affecting fielded systems in coordination with the CINCs. 5.8.4. Provide operationally prioritized and programmatically synchronized materiel and non-materiel recommendations for resolving IT and NSS interoperability issues to the Chairman of the Joint Chiefs of Staff. Coordinate recommendations with USD(AT&L), USD(C)/DoD CFO, the DoD CIO, and the Chairman of the Joint Chiefs of Staff. 6. EFFECTIVE DATE This Directive is effective immediately. Signed/ Paul Wolfowitz Deputy Secretary of Defense 348 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX J DEPSECDEF ACQUISITION POLICY DOCUMENT CANCELLATION MEMORANDUM Introduction Deputy Secretary of Defense, Paul Wolfowitz, signed a policy memo on October 30, 2002, canceling acquisition policy documents 5000.1, 5000.2, and 5000.2R. These policy documents direct and instruct the acquisition of computer-based systems. In his policy, provided on the following page, DEPSECDEF Wolfowitz stated the following: [The policy documents] require revision to create an acquisition policy environment that fosters efficiency, flexibility, creativity, and innovation. Therefore, ... I have canceled those documents effective immediately. DEPSECDEF Wolfowitz signed both this and the legacy m em o\ in Appendix G, but there is a gap in the logic of the memos. \ Both need a common framework so that interoperability can be achieved, but the memos appear to conflict. The memo in this appendix provides the Program Manager with a greater degree of autonomy by giving him or her more flexibility, creativity, and innovation. In the legacy memo, DEPSECDEF Wolfowitz makes a commitment to interoperability that requires control over the products developed or acquired by Program Managers. \ The conflict, or challenge, is in achieving interoperability in light \ o f increased autonomy. 349 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. T H E D E P U T Y S E C R E T A R Y O F D E F E N S E WASHINGTON, O.C. 20301-1000 O C T 30 2 0 0 2 MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTS SUBJECT: Defense Acquisition I have determined that the current DoD Directive 5000.1, “The Defense Acquisition System,” DoD Instruction 5000.2, “The Operation of the Defense Acquisition System,” and DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs,” require revision to create an acquisition policy environment that fosters efficiency, flexibility, creativity, and innovation. Therefore, by separate memorandum, I have cancelled those documents effective immediately. By this memorandum, I am issuing the attached interim guidance in place of the cancelled documents. The intent of the guidance is to rapidly deliver affordable, sustainable capability to the warfighter that meets the warflghter’s needs. Additional, supporting discretionary, best practices, lessons learned, and expectations have been posted to the DoD 5000 Resource Center at http://dod5000.dau.mil. I am directing the Under Secretary of Defense for Acquisition, Technology, and Logistics, with the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) and the Director, Operational Test and Evaluation, to jointly prepare revised documents within 120 days. CHAIRMAN OF THE JOINT CHIEFS OF STAFF UNDER SECRETARIES OF DEFENSE DIRECTOR DEFENSE RESEARCH AND ENGINEERING ASSISTANT SECRETARIES OF DEFENSE GENERAL COUNSEL, DEPARTMENT OF DEFENSE INSPECTOR GENERAL, DEPARTMENT OF DEFENSE DIRECTOR, OPERATIONAL TEST AND EVALUATION ASSISTANTS TO THE SECRETARY OF DEFENSE DIRECTOR, ADMINISTRATION AND MANAGEMENT DIRECTOR, NET ASSESSMENT DIRECTORS OF THE DEFENSE AGENCIES DIRECTORS OF DOD FIELD ACnVITIES Attachments: As stated U16167-02 350 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX K CJCS REQUIREMENTS POLICY DOCUMENTS CANCELLATION MEMORANDUM Introduction Vice Director, Joint Staff, General Hawkins, signed the policy memo, on the following page, canceling processes in the Requirements Generation System. The memo canceled the Mission Needs Statement (MNS) and Capstone Requirements Document (CRD) processes. One of the General Hawkins statements in the policy memo was as follows: The Requirements Generation System does not adequately support the development of an integrated and effective joint force. The current process frequently produces stovepiped solutions that are not necessarily based on the future capabilities required by the joint warfighter.... This combined effort [acquisition and requirements coordination] is undertaken in order to implement a more integrated and collaborative requirements and acquisition process. (JOINT STAFF, 2002) It is not evident that the processes to replace the MNS and CRD documents are being developed collaboratively with the revision of acquisition system policy documents, as called for in the Hawkins memo. Ironically, this leads to the potential of continued stovepiped processes and solutions. The policy memo mandated a revision to the Requirements > Generation System policy document within 120 days, making it due in February or March. The policy memo assumes that incorporation of mission area integrated architectures to replace MNS and CRDs will support the development of an integrated and effective joint force. ~ ' 5 and whether an integrated architecture improves roperability remain to be proven. 351 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. THE JOINT STAFF WASHINGTON, DC Reply ZIP Code: 20318-0300 DJSM -0921-02 07 October 2002 MEMORANDUM FOR: DISTRIBUTION LIST Subject: Changes to the Requirements Generation System 1. The Requirements Generation System, as delineated in CJCSI 3170.01B, “Requirements Generation System,” does not adequately support the development of an integrated and effective joint force. The current process frequently produces stovepiped solutions that are not necessarily based on the future capabilities required by the joint warfighter. 2. Effective immediately, CJCSI 3170.01B Enclosure C, “Mission Needs Statement Generation Process,” and Enclosure D, “Capstone Requirements Document Generation Process,” are cancelled. The mission needs statement (MNS) will be replaced by a mission area focused and capabilities-based document in the next revision to CJCSI 3170.01B. Concepts depicted in capstone requirements documents (CRD) will be captured within mission area integrated architectures as they are developed and refined. 3. CRD and MNS that have already been approved by the Joint Requirements Oversight Council will continue to be valid until absorbed into appropriate integrated architectures. CRD and MNS that have initiated staffing in the Joint Command, Control, Communications, Computers and Intelligence Program Assessment Tool will continue through the normal staffing process. Operational requirements documents will continue to support acquisition milestone B and C decisions until a revision to CJCSI 3170.01B is published. 4. This action is taken in coordination with acquisition community efforts to improve the Defense Acquisition System, as specified in DODI 5000.2, “Operation of the Defense Acquisition System,” and DODD 5000.1, “ The Defense Acquisition System.” This combined effort is undertaken in order to implement a more integrated and collaborative requirements and acquisition process. 352 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5. The Director for Force Structure, Resources, and Assessment (J-8) will prepare a revision to CJCSI 3170.0 IB within 120 days. JAMES A. HAWKINS Major General, USAF Vice Director, Joint Staff 353 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX L POPULATION OF NAVY MISSION NEEDS STATEMENT (MNS) Mission Needs Statements are created when warfighters determine that a need is not being met and only a materiel, or computer-based system, will satisfy the need. MNS’s are promulgated from the Requirements Generation System. This is one of the documents that is feeling the impact of the partial policy cancellation. And with good reason. The MNS focused on a single need without the context of the larger mission capability. ORDs created from a MNS produced a single system. This potentially perpetuates interoperability issues. The population of 140 Navy MNS’s is listed on the following pages. The list includes both classified and unclassified programs. MNS’s perpetuate interoperability problems, because they lack the context of overall mission. All DOD and Navy programs require MNS documents. Legacy plus acquisition systems comprise thousands of Navy systems acquired by these programs. Of the thousands of Navy legacy and acquisition systems, or even just the 517 systems that are implementing the acquisition system, only 140 have MNS documents. \ In DOD and DON, interoperability problems begin here, J \w ith the omission or inadequacy of MNS documents. / 354 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Population of Mission Needs Statements: August 2002 No. MNS # Title Class | Date ACAT 1. CAF 307-97 Tactical Air Control Party (TACP) Modernization U 27-Jul-98 III 2. CAF 328-93 Theater Airborne Reconnaissance System (TARS) U 15-Dec-95 II 3. CAF 353-92 Advanced Imagery Reconnaissance Capability (U) S/N 18-Apr-94 II 4. CAF-USN 308-93 Aerospace Control Helmet-Mounted Cueing System U 1-Sep-93 1 1 I/IV 5. JROCM 003-90 Close Range and Long Enduracne Reconnaissance, Surveillance, and Target Acquisition Capability (U) C 5-Jan-90 . 6. JROCM 003-90 Broad Area Coverage Imaging Capability (U) S 9-Mar-95 - 7. JROCM 003-90 Assured Receipt of Imagery for Tactical Forces (U) S 2-Jul-90 - 8. JROCM 003-90 Defense Information System Network (DISN) U 14-Feb-95 - 9. M000-002-90 Bi-Static Low Frequency Active (U) S 2-Feb-90 II 10. M000-003-91 Armed Navy Helicopoters u 10-Oct-91 III 11. M000-005-92 Deployable Flight Indent Recorders u 3-Apr-92 III 12. M001-002-91 Attack Submarine Force Capability (U) S/N 10-Oct-91 ID 13. M002-003-920 Advanced Minor Caliber Gun System U 5-Mar-92 III 14. M003-005-92 Adverse Weather Strike Capability U 6-Mar-92 I 15. M004-005-92 Airborne Active Adjunct (AAA) (U) S/N 22-Apr-92 III 16. M005-003-92 MCM Heavy Lift Ship (MHLS) (U) C 22-Apr-92 III 17. M006-003-92 MCM Command, Control & Support (MCS(X)) Platform (U) C 22-Apr-92 III 18. M007-003-92 Airborne Periscope Detection (U) S 22-Apr-92 III 19. M008-003-92 High-Speed, Over-the-Beach, Ship-to-Shore Amphibious Lift Capability (U) S 6-Mar-92 II 20. M009-094-92 Commercial Satellite Communications u 1-Jun-92 IV 21. M010-005-92 Deployable TACAIR Training System (DTATS) u 19-May-92 IV 22. M011-005-92 TACAIR Ranging (U) s 19-May-92 II 23. M012-005-92 VH-3D Survivability Enhancement Upgrade (U) s 8-Jun-92 III 24. M013-005-92 Multi-Option Rail Launcher u 21-May-92 IV 25. M014-003-92 Biological Agent Detection System (BADS) (U) s 3-Jun-92 IV 26. M015-005-92 VH-60N Executive Helicopter Mid-Life Ungrade (U) s 12-Jun-92 III 27. M016-002-92 Submarine Rescue Diving and Recompression System u 6-Jul-92 IV Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Population of Mission Needs Statements: August 2002 (continued) No. MNS # Title Class Date ACAT 28. M017-091-92 Supersonic Sea Skimming Targetr (SSST) U 6-Jul-92 II 29. M018-003-92 Electro-Optic Sensor Systems (U) S 3-Jun-92 III 30. M019-003-92 Auxiliiary Dry Cargo Carrier (ADC(X)) u 4-Sep-92 I 31. M020-003-92 Quick Reaction Combat Capability (QRCC) (U) S/N/W 25-Aug-92 II 32. M021-091-92 Open Ocean High Altititude Supersonic Dive (HASD) Aerial Target U 16-Sep-92 IVT 33. M022-003-92 Advanced Integrated EW System (AIEWS) (U) S 5-Oct-92 III 34. M023-06-92 Low Probability of Intercept (LPI)/Low Probability of Detection (LPD) (U) S 13-Oct-92 III 35. M024-003-92 Naval Surface Fire Support (U) C 11-May-92 II 36. M025-003-92 Shallow Water Mine Countermeasure (SWMCM) (U) S 3-Mar-92 IVM 37. M026-003-92 Surface Ship Periscope Dection (U) S 22-Apr-92 III 38. M027-091-92 Non-Cooperative Airborne Vector Scoring (NAVS) System u 10-Nov-92 IV 39. M028-004-92 Strategic Sealift u 15-Jun-92 IC 40. M029-091-93 Subsonic Aerial Target (SAT) Capability u 30-Jan-93 IV 41. M030-086-93 Cooperative Engagement (CE) (U) s 5-Feb-93 I 42. M031-086-93 Sea-Based Theater Ballistic Missile Defense (TBMD) (U) s 13-Feb-93 I 43. M032-088-93 Airborne Early Warning (AEW) Capability [JROCM 038-93] u 2-Mar-93 I 44. M033-086-93 Ship Defense Weapon with Improved Medium Range Anti-Air Combat Capability (U) S/N/W 2-Mar-93 II 45. M034-087-93 Undersea Surveillance in Littoral Waters (U) S 13-Mar-93 II 46. M035-088-93 Joint Attack Fighter u 18-May-93 I 47. M036-085-93 Forward Area Combined Magnetic & Acoustic Control (U) C 6-Jun-93 IV 48. M037-088-93 Flight Line Electronic Combat Systems Tester u 6-Jun-93 IV 49. M038-088-93 Improved Assault Support, Combat Utility Capability u 1-Sep-93 III 50. M039-088-93 P-3C Anti-Surface Warfare (ASUW) Improvement Program (AIP) (U) s 4-Sep-93 II 51. M040-088-93 E-6A Tacamo/Airborne Command Post (ABNCP) Consolidation Program u 27-Sep-93 III 52. M041-096-93 Supplemental Weather Radar u 1-Oct-93 IVM 53. M042-085-93 Mine Counter Measures (MCM) (U) c 1-Oct-93 III 54. M043-085-93 Explosive Ordnance Disposal (EOD) (U) S/N 1-Dec-93 IVM Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Population of Mission Needs Statements: August 2002 (continued) o s Ul ■ " J No. MNS # Title Class Date ACAT 55. M044-085-93 Submarine Launched Mobile Mine (SLMM) (U) C 13-Dec-93 III 56. M045-06-93 HF Counter-Communications (HFCCOM) (U) S 22-Dec-93 III 57. M046-096-94 Master Seafloor Digital Database (MSDDB) u 31-Jan-94 III 58. M047(1)-086-94 21st Century Surface Combatant (SC-21), Revision 1 (U) S/N 26-Aug-94 I 59. M048-88-94 Shallow Water ASW Localization & Attack System C 22-Mar-94 III 60. M049-88-94 Night Vision Sysgtem Capability in the H-46D Helicopter U 27-Mar-94 IV 61. M050-88-94 Shallow Water Undersea Warfare Training Range U 8-Apr-94 IV 62. M051-04-94 Enhanced Hearing Protector (EHP) for High Noise Environments U 11-Apr-94 IV 63. M052-06-94 Electronic Warfare Field Collection & Analysis Support C 19-Apr-94 III 64. M053-88-94 Integrated Diagnostic System U 8-Jun-94 IV 65. M054-85-94 Littoral Sea Mine LSM (U) U 20-Jun-94 IV 66. M055-88-94 Precision Approach and Landing Capability (PALC) u 28-Jul-94 I 67. M056-06-94 Specific Emitter Identification (SEI) (U) S 5-Aug-94 III 68. M057-06-94 Defense Broadcast System (DBS) u 27-Oct-94 III 69. M058-88-94 Accommodation of Women Aircrew in Aviation u 4-Nov-94 IV 70. M059-88-94 Fleet Combat Support Helicopter (HC) u 21-Nov-94 II 71. M060-096-94 Joint Army-Navy-USAF Theater Meteorological & Oceanographic (METOC) Communications Capability (JTMCC) u 23-Nov-94 1 1 I/IV 72. M061-88-94 Tactical Aircraft Moving Map Capability (TAMMAC) u 2-Dec-94 IVT 73. M062-88-95 Integrated Defensive Electronic Countermeasures (IDECM) Suite for Strike/Fighter Aircraftr (U) s 7-Feb-95 II 74. M063-06-95 Integrated Maritime Communications System (IMCS) u 15-Feb-95 III 75. M064-88-95 S-3B Weapons System Improvement Program Phase II (WSIP II) u 18-Apr-95 III 76. M065-88-95 Underwater Training System (Mobile) u 25-May-95 IVM 77. M066-88-95 DC-9/C-9B Upgrade Standardization Modification Program u 12-Jul-95 IV 78. M067-096-95 Meteorological Data Collection Capability u 2-Aug-95 IV 79. M068-86-95 Improved Shallow Water ASW Weapon (U) c 15-Dec-95 III 80. M069-85-96 Mine Warfare Tactical Training Range u 23-May-96 IVM 81. M070-88-96 21st Century Tactical Aviation Sea-Based Platform (U) s 13-Mar-96 I Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Population of Mission Needs Statements: August 2002 (continued) 0 5 05 0 0 No. MNS # Title Class Date ACAT 82. M071-88-96 Naval Aviation Chemical and Biological Warfare Survivability U 4-Jun-96 IV 83. M072-85-96 Mine Warfare C4I System U 22-Jul-96 IV 84. M073-96-96 Real Time Tactical Meteorological and Oceanographic (METOC) Assessment System (RTMAS) u 17-Sep-96 IV 85. M074-88-96 ES-3A C4I and Sensor Upgrade (U) s 18-Oct-96 IV 86. M075-88-96 C-12/C-20 Installation of Safety Enhancing Equipment Program u 26-Dec-96 IV 87. M076-JCS-96 Information Warfare (U) s 7-NOV-96 - 88. M077-88-97 UH-1, CH-46, and CH-53 Improved Crash Attenuating Passenger/Troop Seats [Proposed] u 21-Apr-97 . 89. M078-85-97 Non-Lethal Systems c 25-Apr-97 IV 90. M079-88-97 1st Marine Aircraft Wing (MAW) Flight Simulator Capability for MCAS Iwakuni and MCAS Futenma 23-May-97 IV 91. M080-4-97 Joinr Logistics Over the Shore (JLOS) Support Systems u 27-Aug-97 III 92. M081-88-97 Forward Deployed CVW-5 F-14 Simulator u 14-May-97 IVM 93. M082-88-97 Lightweight Reusable Expeditionary Airfield (EAF) Mat u 25-Jun-97 IV 94. M084-86-97 Computerized Dead Reckoning Tracer (CDRT) u 14-Jul-97 IVT 95. M085-88-97 Secure Voice, Long Range Communication System for the KC-130 u 14-Aug-97 IVM 96. M086-88-97 Aircrew Protection u 5-Dec-97 III 97. M087-87-97 Naval Tactical Missile System (NTAMS) (U) c 5-Dec-97 II 98. M088-096-97 METOC Numerical Modeling Capability for Military Operations u 5-Dec-97 IVM 99. M089-85-98 Remote Control of Undersea Mines (RECO) (U) c 1-Jul-98 III 100. M090-88-98 Squadron Management, Automated Risk Tolerance and Reporting System (SMARTR) u 9-Jul-98 III 101. M091-88-98 Helicopter Passenger Personal Protection System u 16-Jul-98 IV 102. M092-91-98 METOC On-Scene Analysis and Forecast Capability u 24-Aug-98 IV 103. M093-88-98 Systems to Enhance Aircrew Situational Awareness u 27-Aug-98 IVT 104. M094-96-98 Oceanographic Data Collection u 22-Sep-98 III 105. M095-88-95 Advanced (Strike/Amphibious) Anti-Radiation Guided Missile (AARGM) u 13-Mar-95 III 106. M096-88-98 Aircraft Wireless Intercommunication System (WICS) u 10-Jul-98 IVT Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Population of Mission Needs Statements: August 2002 (continued) No. MNS # Title Class Date ACAT 107. M097-88-96 Assault Support Aircraft Survivability Enhancements U 10-Jun-96 IV 108. M098-88-98 Improved External Lifting Device (IELD) U 7-Dec-98 IV 109. M099-88-99 CH-53E Secure Voice, Long Range Communikcations System (SVLRCS) u 1-Feb-99 IV 110. M0100-86-99 DOD Nuclear, Biological and Chemical (NBC) Defense u 1-Mar-99 III 111. M0101-91-99 Joint Modelling and Simulation System (JMASS) u 5-May-99 III 112. M0102-88-99 Computerized Simulator Debriefing System u 24-May-99 IVM 113. M0103-88-99 VH-60N Maintenance Trainer u 31-Aug-99 IV 114. M0104-86-99 Joint Command and Control Capability (JC C (X )) u 29-Sep-99 I 115. M0105-88-00 Broad Area Maritime (BAM) and Littoral Armed Intelligence, Surveillance and Reconnaissance (ISR) (U) s 29-Feb-00 ID 116. M0106-85-00 Landing Craft Utility (LCU(R)) u 17-6ct-00 IV 117. M0107-78-01 C/KC-130T Avionics Modernization Program u 30-Jan-01 II 118. M0108-75-01 Amphibious Assault Ship (LHA(R)) u 5-Mar-01 ID 119. M0109-75-01 Maritime Prepositioning Force for the 21st Century (MPF Future (MPF(F))) u 25-May-01 I 120. M0110-78-01 Tactical Acoustic Measurement and Decision Aid (TAMDA) u 17-Jul-01 III 121. M0111-78-01 Airborne Electronic Attack (AEA) in Support of Joint Suppression of Enemy Air Defense (JSEAD) u 28-Aug-01 ID 122. M0112-76-02 Naval Fires Network (NFN) u 13-Feb-02 III 123. M0113-96-02 Improved Tropical Cyclone Reconnaissance, Forecast and Warning u 12-Jun-02 IVM APPENDIX M POPULATION OF UNCLASSIFIED NAVY MISSION NEEDS STATEMENTS (MNS) The Mission Needs Statement (MNS) represents a specific need of users. The Navy has a population of 70 unclassified MNS, as listed on the following pages. As stated in Appendix L, Navy has thousands of MNS documents. This clearly does not reflect the needs for all of the systems. Though all DOD and Navy programs require a MNS document, of the thousands of Navy systems, Navy only has 70 unclassified MNS. Interoperability problems may be the result of omitted and/or inadequate MNS documents. 360 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Unclassified Mission Needs Statements: October 2001 No. Title 1. Aerospace Control Helmet-Mounted Cueing System 2. Tactical Air Control Party (TACP) Modernization 3. Theater Airborne Reconnaissance System (TARS) 4. Defense Information System Network (DISN) 5. Armed Navy Helicopters 6. Deployable Flight Incident Recorders 7. Airborne Weather Strike Capability 8. Commercial Satellite Communications 9. Deployable TACAIR Training System (DTATS) 10. Multi-Option Rail Launcher 11. Submarine Rescue Diving and Recompression System 12. Supersonic Sea Skimming Target (SSST) 13. Auxiliary Dry Cargo Carrier (ADC (X)) 14. Open Ocean High Altitude Supersonic Dive (HASD) Aerial Target 15. Non-Cooperative Airborne Vector Scoring (NAVS) System 16. Strategic Sealift 17. Subsonic Aerial Target (SAT) Capability 18. Airborne Early Warning (AEW) Capability 19. Joint Attack Fighter 20. Flight Line Electronic Combat Systems Tester 21. Improved Assault Support Combat Utility Capability 22. E-6A Tacamo/Airbome Command Post (ABNCP) Consolidation Program 23. Supplemental Weather Radar 24. Master Seafloor Digital Database (MSSDDB) 25. Night Vision System Capability in the H-46D Helicopter 26. Enhanced Hearing Protector (EHP) for High Noise Environments 27. Integrated Diagnostic System 28. Precision Approach and Landing Capability (PALC) 29. Defense Broadcast System (DBS) 30. Accommodation of Women Aircrew in Aviation 31. Fleet Combat Support Helicopter (HC) 32. Tactical Aircraft Moving Map Capability (TAMMAC) 33. Integrated Maritime Communications Systems (IMCS) 34. S-3B Weapons System Improvement Program Phase II (WSIP II) 35. Underwater Training System (Mobile) 36. DC-9/C-9B Upgrade Standardization Modification Program 37. Meteorological Data Collection Capability 38. Mine Warfare Tactical Training Range 39 Naval Aviation Chemical and Biological Warfare Survivability 40 Mine Warfare C4I System 361 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Unclassified Mission Needs Statements: October 2001 (continued) No. Title 41. Real Time Tactical Meteorological and Oceanographic (METOC) Assessment System (RTMAS) 42. C-12/C-20 Installation of Safety Enhancing Equipment Program 43. UH-1, CH-46, and CH-53 Improved Crash Attenuating Passenger/Troop Seats 44. Joint Logistics Over the Shore (JLOTS) Support Systems 45. Forward Deployed CVW-5 F-14 Simulator 46. Lightweight Reusable Expeditionary Airfield (EAF) Mat 47. Computerized Dead Reckoning Tracer (CDRT) 48. Secure Voice, Long Range Communication System for the KC-130 49. Aircrew Protection 50. METOC Numerical Modeling Capability for Military Operations 51. Squadron Management, Automated Risk Tolerance and Reporting System (SMARTR) 52. Helicopter Passenger Personal Protection System 53. METOC On-Scene Analysis and Forecast Capability 54. Systems To Enhance Aircrew Situational Awareness 55. Oceanographic Data Collection 56. Advanced (Strike/Amphibious) Anti-Radiation Guided Missile (AARGM) 57. Aircraft Wireless Intercommunication System (WICS) 58. Assault Support Aircraft Survivability Enhancements 59. Improved External Lifting Device (IELD) 60. CH-53E Secure Voice, Long Range Communications System (SVLRCS) 61. DOD Nuclear, Biological and Chemical (NBC) Defense 62. Joint Modeling and Simulation System (JMASS) 63. Computerized Simulator Debriefing System 64. Joint Command and Control Capability (JCC(S)) 65. Landing Craft Utility (LCU(R)) 66. C/KC-130T Avionics Modernization Program 67. Amphibious Assault Ship (LHA(R)) 68. Maritime Prepositioning Force for the 21st Century (MPF Future (MPF(F)) 69. Tactical Acoustics Measurement and Decision Aid (TAMDA) 70. Airborne Electronic Attack (AEA) in Support of Joint Suppression of Enemy Air Defenses (JSEAD...) 362 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX N POPULATION OF NAVY ACQUISITION CATEGORY (ACAT) SYSTEMS The Defense Acquisition System is the policy for acquiring computer-based systems. Programs responsible for acquiring or developing these systems are put into acquisition categories (ACAT) based on approval authority decision-makers, cost, and special interest in the implementation of the Defense Acquisition System. The Assistant Secretary of Navy for Research, Development and Acquisition (ASN (RDA)) keeps a list of Navy ACAT programs. These systems become legacy systems after successful approval of the final acquisition milestone and their installation and use by warfighters. At that time, or if they are canceled, the systems are removed from the ASN (RDA) ACAT list. The ACAT list is continually changing as new programs are approved or developing programs are canceled. The list beginning on the following page is from the July 2000 ASN (RDA) Web site. The 517 ACAT programs on the list individually expect approval of their systems by senior acquisition authorities. Yet, each program must certify the interoperability of their system(s) with systems that are not part of their acquisition milestone approvals. This certification has shown to be particularly challenging for systems that must be interoperable with legacy systems, especially those that lack ORDs. ORDs exist for only a fraction of these plus the legacy J systems. > / 363 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 AN lACATjSHORT TITLEf LONG TITLE |D a S n | PEO 1 PM ( LEAD j M/S o | M/S 11M/S ll|LR IP l(LRIP If M/S III ' '• iBAShLINbALivMUfcU ~ l \ ; " ------------' l " ' ' ’ 1 ; 01456 IAC BAIM IN DU STR IA L MANAGEMENT SHIPS;SEA 04 SEA 04D!NAVY i \ ! i MANUFACTURING 01603 IAC MRP II RESOURCE PLANNING II AIR NAVAIR PMA203 NAVY N/A N/A :N/A N/A HI A IN/A j ......... i NAVAL TACTICALCOMMAND SPAWAR • ; l" " 101396 IAC ■NTCSS SUPPORT SYSTEM 041 00 PMW151 NAVY 95/04 96/06 97/03 N/A HI A j00/01 DEFENSE MESSAGING ! > ; J 01478 IAM DMS SYSTEM 041 USD PMW 152 NAVY m /02 94/12 95/05 N/A In/a i 99/09 ; ■ADVANCED FIELD i !00084 IC AFATDS Ia r t il l e r y TACTICAL DATA EXPD MARCOR IS ARMY 81/03 ■ 89/08 89/08 N/A IN/A 95/12 : ; '00096 !IC AIM-9X ! AIM-9X(SIDEW INDER) AIR PEO(T) PMA259 NAVY N/A 12/94 12/96 00/09 N/A Q3/3Q ; ; I ADVANCED MEDIUM HP N G t I AIR :00121 ;ic AMRAAM | AIR-TO-AIR MISSILE AIR PEO(T) PMA268 i FORCE HI A ; 78/11 82/08 8 //0 5 91/OS f 100137 IC AN/BSY-2 SSN-21/BSY-2 ;MUW i ■ PEO(SUB) PMS425 NAVY i 86/06 88/03 !h /c [ AV-8B ) i ! ' !01092 IC ■REMAN AV-8B REMANUFACTURE AIR PEO(A) PMA257 iNAVY HI A N/A ;N/A N/A 94/03 , CH-60S VERTICAL j 01405 JC CH-60S REPLENISHMENT AIR PEO(A) PMA299 NAVY HI A HI A ; 98/05 00/01 In /a 01/03 COMMON MISSILE W ARNING ! ; ! / ■ ,01407 ■IC SCMW SYSTEM AIR PEO(T) PMA272 ARMY ;N/A 'HIA 95/02 !N/A N/A 03/4Q :NIMiT2 CLASS NUCLEAR PEO r' ' ■........ i ,00315 IC CVN-68 CL 'AIRCRAFT CARRIER SHIPS CARRIERS PMS312 NAVY . : ; 80/10 1 DDG-51 GUIDED MISSILE V i '00326 IC DDG-51 DESTROYER SHIPS PEO(TSC) ;PMS400 NAVY 81/06 83/12 191/01 92/04 [93/01 E-2C ! i . ; , ■ s I '01214 ic REPROD ;E-2C REPRODUCTION AIR PEO(T) PMA231 iNAVY HI A ‘N/A )HIA iN/A ; 94/09 i 1F/A-18 E/F -N A V A L STRIKE ; I : 00408 IC F/A-18 E/F i FIGHTER AIR PEO(T) PMA265 iNAVY N/A \HIA 92'05 9’ /03 98/11 ! 00/03 ; i JOINT PRIMARY AIRCRAFT 'AIR (" 1 ; 00508 IC JPATS TRAINING SYSTEM (T6A) AIR PEO(A) PMA273 (FORCE 93/02 (93/02 95/08 95/08 101/1Q JSOW JOINT STANDOFF W EAPON i i 01426 IC (BASELINE) (BASELINE) AIR PEO(W ) PMA201 iNAVY N/A 89/06 92/06 97/02 ! 98/10 i JSOW (BLU- JOINT STANDOFF W EAPON ' ( • 01427 IC 108) (BLU-108) AIR PFO(W ) PMA201 (NAVY N/A jN/A 95/04 98/12 02/3 Q ; I LHD 1 AMPHIBIOUS ( : i I00541 IC ;LHD-1 CL ASSAULT SHIP SHIPS; PEO(EXW ). PMS377 NAVY 81/10 82/07 HI A HI A 85 03 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) 8 c n 1 AN lACATlSHORT TITLEj LONG TITLE |D A S N | PEO I PM j LEAD !M /S 0 M/S I | M/S ll|LR IP l|LRIP l| M/S lllf LONGBOW | 00528 IC HELLFIRE [LONGBOW HELLFIRE [EXPD N/A ARMY ; I MULTIPLE LAUNCH ROCKET " r i i ' i ! ; 00617 I IC MLRS SYSTEM NATIONAL AIRSPACE EXPD : ; i ESC/GA ARMY AIR i . ■ I i i i [ j00639 IC NAS SYSTEM IC4I A FORCE 11/90 07/92 i 07/95 N/A N/A |01/00 j j ... NAS NATIONAL AIR SPACE | AIR ; I (01406 IC [MODERNIZA MODERNIZATION (a ir NAVMR [PMA213 FORCE 90/11 [92/11 95/07 N/A 00/02 101/2Q [ NAVSTAR NAVSTAR GLOBAL ? l AIR ! i [00667 IC GPS [POSITIONING SYSTEM [N A W E H F SATCOM !-C4l , ............. [FORCE ■ [ i j ......... i i00679 IC NfcSP [PROGRAM [AN/USC-38(V)] |C4I SPAWAR [PMW 176 NAVY N/A N/A ; 89/06 [89/06 :n /a 93/04 f " , [LAMPS MK III BLK II i ;.. <00522 IC SH-60R I UPGRADE AIR PEO(A) [PMA299 NAVY N/A N/A [7/93 [98/11 01/2Q 03/1Q f 'SHIPBOARD SINGLE I s ; I i ; !00868 IC SINCGARS [CHANNEL GROUND & •C4I SPAWAR [PMW 179 ARMY 84/03 [N/A 85/10 [N/A N/A 195/02 ! SM-2 (BLK [STANDARD MISSILE 2 ■ r J illlA- [ 1.01088 IC 1 1 I/I 1 1 A) [BLOCKS IIIVA VB N TCS PEO(TSC) PMS422 NAVY 85/06 [N/A N/A 2/92 [ i SM-2 (BLK [STANDARD SURFACE-TO- ’ "! ; 00880 i IC IV) SSN-21/BSY- ;AIR MISSILE (BLOCK IV) [SSN-21/BSY-2 SEAWOLF re s ; ' PEO(TSC) PMS422 NAVY N/A N/A 86/08 [95/05 i i ! ! ■ • • ! I (00916 IC 2 [c l a s s NUCLEAR ATTACK [SHIPS PEO(SUB) PMS350 NAVY N/A 83/12 85/06 [88/06 ! [88/06 j r STRATEGIC ! ....................................." PMS325 ' i [ 00929 IC SEALIFT [STRATEGIC SEALIFT SHIPS PEO(EXW );R NAVY N/A 93/04 93/09 93/09 [98/08 5 ] T-45 UNDERGRADUATE JET 100977 IC [T-45TS PILOT TRAINING SYSTEM AIR PEO(A) PMA273 NAVY 76/07 ! 84/09 84/09 (87/09 92/04 95/01 ! ' [TACTICAL TACTICAL TOMAHAWK ; 01425 IC [TOMAHAWK !(RGM109E/UGM-109E) jAIR PEO(W ) PMA280 NAVY N/A N/A 97/12 ;02/3Q 03/2Q 04/1Q r STRIDENT II TRIDENT II -SEA LAUNCHED DRPM- [01028 IC MSL BALLISTIC MISSILE [SHIPS SSP SSP NAVY 77/10 83/10 [87/04 j i V-22 V-22 OSPREY - JOINT i s ' i 101056 i IC OSPREY A D VA NC ED VERTICAL ADVANCED AMPHIBIOUS AIR PEO(A) DRPM(AA PMA275 DRPM- NAVY 81/12 82/12 94/09 97/04 01/1Q [00017 ID AAAV [ASSAULT VEHICLE EXPD A) AAV NAVY N/A 95/03 02/01 05/07 07/10 ! [ADVANCED EXTREMELY AIR [01424 ID AEHP [h ig h FREQUENCY [ADVANCED LAND ATTACK C4I FORCE [01607 ID ALAM [MISSILE [SHIP PEO(S) PMS520 NAVY i i : Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN |AC A T|SHO RTTITL^ LONG TITLE |D A S N | PEO j PM r ft > C M /S 0 j M /S I I M/S II {l r ip ILRIP l| M/S II i C O O P E RA TIV E................ 1 00256 ID CEC [ENGAGEMENT CAPABILITY {NEXT GENERATION TCS PEO(TSC) PMS465 NAVY N/A 94/11 95/05 99/05 00/04 01/11 [01615 ID CVN(X) [NUCLEAR AIRCRAFT [SHIPS PEO(EXW ) PMS378 NAVY 96/06 00/06 02/04 N/A N/A 20/03 r DD 21 TW ENTY FiRST [01422 ID DD 21 CENTURY DESTROYER SHIPS PEO(S) PMS500 NAVY 95/01 98/01 03/11 N/A N/A 11/08 i GLOBAL BROADCAST AIR [01486 ID GBS SERVICES USD PMW 176 TORCE N/A 97/05 97/05 97/11 N/A [ 00/09 • .. . ! JO INT AlR-SORFACE f. . . . . . . . . . . . . AIR [01309 [ID JASSM STANDOFF MISSILE (a ir PEO(W ) PMA201 i FO RCE'95/08 96/06 02/1Q N/A 03/2Q 03/4Q j ....... JAVELIN ADVANCED ANTI-TANK ; PEOTactic SFAE- [00500 j ID (AAWS-M) [W EAPONS SYSTEM - P O IN T DIRECT ATTACK [EXPD F '...... i al MSL MSL-AM ARMY AIR 00501 ID JDAM (MUNITIONS lAIR PEO(W ) PMA201 [FORCE 92/06 93/10 95/09 97/04 98/06 01/1Q ; ...... . . .. (JOINT PRECISION [ (AIR (01404 ID JPALS [APPROACH & LANDING [AIR NAVAIR PMA213 FORCE 96/05 02/1Q 02/1Q N/A N/A TBD . . . . . . . . . . . . . . . . . . . . . . . . j ....................................................... j .... A IR [01138 ID JSF [ JOINT STRIKE FIGHTER :AIR PEO(JSF) JSF FORCE 01/03 ! ....... JSOW IJOINT STAND-OFF ; [00512 ID (UNITARY) W EAPONS (UNITARY) JOINT TACTICAL IAIR PEOW) PMA201 NAVY AIR N/A N/A 95/04 02/1Q 03/1Q [00515 ID JTIDS INFORMATION LPD 17 CLASS AMPHIBIOUS [C4I FORCE [00568 ID LPD 17 ASSAULT SHIP SHIPS PEO(EXW )! PMS317 NAVY 93/03 96/06 N/A N/A 08/07 f [MULTI-FUNCTIONAL J 00596 ID MIDS-LVT (INFORMATION ;C4I PEO(T) PMW101 NAVY N/A N/A 93/12 00/05 01/1Q 01/3Q ; I ....................... i . . . . . . . . . i AIR 1 00597 [ID MILSTAR iMILSTAR C4I SMC/MC FORCE i N AVYARFA NAVY AREA THEATER ; : [01457 ID TBMD BALLISTIC MISSILE TCS PEO(TSC) PMS451 BMDO N/A ;N/A 97/02 N/A N/A 03/04 [ NAVV THEATER W IDE 101458 ID NTW TB M D THEATER BALLISTIC TCS PEO(TSC) PMS452 BMDO { 03/12 07/07 ■ F USM'CR-1 ; 101308 ID UPGD USMC H-1 UPGRADES AIR PEO(A) PMA276 NAVY N/A ■N/A 10/96 01/1Q 03/2Q 04/2Q [ VIRGINIA VIRGINIA CLASS i [00682 ID CLASS SUBMARINE (SSN 774) [SHIPS PEO(SUB) PMS450 NAVY 92/08 [94/08 95/06 97/09 07/10 I ADVANCED AIRBORNE I ................. [00019 II AAED EXPENDABLE DECOY (ALE- {AIR PEO(T) PMA272 NAVY N/A N/A 88/04 N/A 96/11 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN lACATjSHORT TITLEj LONG TITLE | DASN) PEO | PM | LEAD | M/S 0| M/S 11 M/S I|| l RIP l|LRIP l| M/S III j W 05 -s i i01098 II I 01293 II : 00080 II i00092 II !00026 ill i ; 101081 ill ?01371 ill : / 100118 ill i00128 ill F .. ' ' i 1 00063 ill ; - , . S 00194 ill j00229 ill 00242 ill :01592 ill 01319 II ■ ; ' 01295 I I 01244 II 00387 II 01600 ill IM UW SPAWAR iPM W 183 iNAVY i ‘ ' i ' " i i IAIR PEO(T) f PMA265 -NAVY ADVANCED DEPLOYABLE ADS SYSTEM F/A-18 ADVANCED ADV TFLIR TARGETING FORW ARD AEGIS W PN AEGIS W EAPONS SYSTEM SYS MODS MODS iSHIPS PEO(TSC) iPMS400 iNAVY iADVANCED INTEGRATED EW i AIEW S 'SYSTEM (AN/SLY-2) iTCS PEO(TSC) PMS473 NAVY AIRBORNE LASER MINE PEO(MUW ; ' ALMDS iDETECTION SYSTEM IM UW i) iPMS210 iNAVY ;ALR-67(V)3 AN/ALR-67(V)3 ADVANCED ; i(ASR) SPECIAL RECEIVER iAIR PEO(T) iPMA272 NAVY ADVANCED MISSION ; AMC&D COMPUTER & DISPLAYS AIR NAVAIR PMA209 iNAVY AIRBORNE MINE i ' iP E 0(M U W i AMNS NEUTRALIZATION SYSTEM M UW i) PMS210 NAVY AN/AQS-20/X SONAR MINE ! " " PEO(MUW AN/AQS-20/X DETECTING SET MUW ) PMS210 NAVY sss; A d v a n c e d s e a l i ASDS DELIVERY SYSTEM (ASDS)/ s EXPD SEA 92 PMS395 NSW ADVANCED TACTICAL AIR f ■ i ATARS RECONNAISSANCE SYSTEM ;AIR PEO(T) tPMA265 iNAVY COMMAND S CONTROL i iC2P PROCESSOR iC4l SPAWAR iPM W 159iNAVY CONSOLIDATED i i CASS AUTOMATED SUPPORT (AIR NAVAIR PMA260 iNAVY MARINE CORPS COMBAT AIR iMAEC :CID IDENTIFICATION (CID) EXW MARCOR iDEFENS iOR ; E-2C M ISSIO N COMPUTER "i E-2C MCU UPGRADE iAIR iPEO(T) SPMA231 iNAVY EA-6BICAP EA-6BTMPROVED illl CAPABILITY III AIR PEO(T) EXTENDED RANGE GUIDED ; ERGM ESSM MUNITION EX 171 iS H IP SP E O (S ) j PMA234 ; IPMS529 EVOLVED SEA SPARROW MISSILE TCS : PEO(EXW ) i PMS471 F/A-18 HIGHER ORDER i F/A-18 HOL iLANGUAGE iAIR iPEO(T) ;PMA265 NAVY NAVY NAVY NAVY ’N/A i 94/11 I i 00/02 iN/A N/A 05/02 N/A l iN/A ; i 97/11 |0 1 /2 Q N /A 03/1Q ' ! { i i i . 78/03 ; i ; i 97/11 i01/08 03/07 | : 00/04 i ; 04/03 N/A !n /a i 87/02 i 98/04 ■ 99/07 N/A : 98/04 98/04 ! i01/3Q 02/3Q 97/03 01/06 i 03/03 83/10 i I 86/04 j 92/06 00/09 99/04 02/12 ) 89/07 F i 94/09 i i ' i " i : ' I i i ! r ; i ■ F 94/12 i N/A 81/11 85/02 97/07 : 98/12 i 98/10 01/01 03/03 N/A N/A 04/07 N/A iN/A i 94/09 i 97/07 N/A 01/3Q N/A J n /a 98/03 [02/4Q: 03/3Q F i 96/06 i 96/08 ; 02/10 04/10 05/04 ; i 94/09 00/ 1 2 ; 02/09 N/A ;n /a m/A iN/A iN/A N/A : Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN lACATlSHORT T IT L ^ LONG TITLE |D A S N | P § 0 | PM | LEAD | M/S 0 | M/S 1| M/S ll|LR IP JLRIP l| M/S II ! " F/A-18 F/A-18 RADAR UPGRADE j i 00409 M l RADAR (APG-73) PHASE II AIR PEO(T) PMA265 iNAVY ;N/A ;N/A 8J/06 95/02 : : 96/08 i F/A-18 TAC F/A 16 TACTICAL ; ; 01294 ill REECE RECONNAISSANCE SYSTEM | AIR PEO(T) PMA265 iNAVY iN/A N/A 96/12 97/02 98/02 00/07 ....................... GLOBAL COMMAND & i 1........... i ; j 00695 II GCCS-M CONTROL SUPPORT ■ C4I SPAWAR PMW 157 JNAVY 98/06 :N/A iN/A i 98/06 ....... ................... INTEGRATED DEFENSIVE ; ; 01311 M l IDECM ELECTRONIC iAIR PEO(T) PMA272 iNAVY N/A iN/A 95/10 01/1Q 02/3Q v JOINT TACTICAL COMBAT i ' t j 00192 ill JTCTS TRAINING SYSTEM [AIR NAVAIR PMA248 [NAVY : N/A ; 92/10 95/03 :02/1Q N/A ... 03/1Q i 01598 M l KC-130J KC-130J AIRCRAFT AIR NAVAIR = PMA207 iNAVY iN/A w a iN/A In /a iN/A 97/07 LONG TERM MINE PEOfMUW ! 01313 II LMRS RECONNAISSANCE SYSTEM ‘MUW ) PMS403 ^ A V Y 95/05 *96/05 96/05 i 03/09 LIGHTW EIGHT 155MM i ; 01222 ill LW155 TO W ED HOW ITZER EXPD MARCOR LW155 iNAVY i 95/02 i 96/02 i 96/02 N/A N/A 02/03 MEDIUM TACTICAL VEHICLE I i - i 01108 II MTVR REPLACEMENT iEXPD MARCOR CSLE NAVY ;H/A 95/10 95/10 iN/A N/A i 00/12 N TD S lM P R NAVYTACTICAL DATA SYS ! " i i00698 II (ACDS BLK I) IMPRO (ADVANCE COMBAT TCS PEO(TSC) PMS4S1 NAVY ; 89/11 [ 99/12 iORGANIC AIRBORNE AND PEO(MUW ! 1 * 01589 II OASIS SURFACE INFLUENCE MUW ) PMS210 iNAVY i 00/11 : 00/11 04/03 | : 04/12 :AV-8B OPEN SYSTEM CORE j • :........... ; 01428 II OSCAR AVIONICS REQS iAIR PEO(A) PMA257 (NAVY N/A iN/A 597/03 N/A ;N/A ;02/3Q P-3 A SUW IMPROVEMENT : ; i \ I ' • ' 01100 II P-3 AIP PROGRAM iAIR PEO(A) PMA290 ;NAVY 94/09 i 94/09 94/09 I N/A 5 94/09 P-3 SUSTAINED READINESS' : ■ i " i r i ' 01105 II P-3 SRP PROGRAM iAIR iPEO(A) PMA290 iNAVY i 94/09 i 94/09 j 94/09 ;n /a 94/09 PHALANX PHALANX IMPROVEMENT ! . . : " ' j ; ' " ; • ' : 01168 ill IMPROVEME PROGRAM T C S PEO(EXW ) PMS472 iNAVY ; ? . 5 QRCC/SSDS QUICK REACTION COMBAT ; 00771 ill MK I CAPABILITY/ SHIP SELF I TCS PEO(TSC) PMS461 iNAVY : i '95/05 i 98/03 RAM BLK I SIN ROLING AIRFRAME i ..... i i i ! 01211 M l UPGD MISSILE BLOCK I iTCS PEO(EXW ) i PMS472 iNAVY 94/05 i 97/04 98/03 00/01 RAPID AIRBORNE MINE ! ! PFO (M UW j i 01590 II RAMICS CLEARANCE SYSTEM ;m u w ) PMS210 iNAVY ; : 01/03 05/03 REMOTE MINEHUNTlNG ; :PEO(MUW i i i ; 00783 II RMS SYSTEM ;m u w ) PMS407 NAVY 596/05 99/12 i 05/01 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN |ACAT|SHORT TITLEj LONG TITLE | DASN| PEO | PM | LEAD | M/S 0 | M/S 11 M /S ll|LR IP l|LRIP If M /S lllj ; ! STANDOFF LAND A T T A C K ....I....i I i....." I ‘ "I'" T ..." ! 100874 i ill SLAM-ER I MISSILE - EXPANDED [AIR PEO(W ) PMA258 NAVY N/A jN/A 9r /02 1 97/03 00/05 101314 ill ■ SPY-1 D(V) i SPY-1 D(V) TCS : PEO(TSC) PMS400 NAVY 97/01 05/06 j ....... SURTASS SURVEILLANCE TOW EO I i00963 II LFA jARRAY SENSOR MUW SPAWAR SPMW182 NAVY 85/10 .85/10 90/06 ‘90/06 N/A 02/10 | '... ) ............ [TACTICAL CONTROL i ...... i01326 ill TCS 'SYSTEM AIR PEO(W ) ■PMA263 INAVY IN/A 1 97/03 [00/02 N/A (N/A TBD ; T M P C .... THEATER MISSION j ..... ; i i01431 II iUPGRADE LANNING c e n t u p g r a d e AIR PEO(W ) ‘PMA281 INAVY jN/A N/A iN/A N/A ;N/A (94/02 ! i ........ t a c t ic a l u n m a n n e d i................ ! ....... i' • j01038 ill (UGV 1 GROUND VEHICLE ‘EXPD MARCOR ICBG ARMY 194/09 96/02 03/01 s ........ 1 VERTICAL TAKEGFF AND i........ ; [........ j01430 II IVTUAV ‘LANDING TACTICAL jAIR PEO(W ) >PMA263 NAVY N/A N/A 00/02 01/3Q N/A 03/3Q { A-RCI i ACOUSTIC-RAPID COTS i' i 101135 III PHASES l-lll 1 INSERTION (A-RCI) PHASES 1-iMUW PEO(SUB) |PMS425 NAVY } • 96/06 (98/04 99/04 00/10 I ’ [AREA AIR DEFENSE !' ! ' ...... 101419 illl ; AADC iCOMMANDER PROGRAM TCS PEO(TSC) PMS467 NAVY N/A 00/03 00/03 103/10 04/06 06/09 ! ........ AAR -47 1AAR-4T MISSILE W ARNING i00020 III MISSILE SYSTEM iAIR PEO(T) i PMA272 NAVY N/A 75/08 ! 82/08 I N/A 87/05 i.......- i ......... ANTI ^ARMOR W EAPONS 101374 III AAWS-H SYSTEM HEAVY EXPD MARCOR CBG NAVY 97/03 ! ADVANCED CHEMICAL SEA05R r ' |00246 III ACPG PROTECTIVE GARMENT, S H IP S S E A 05 ‘1 NAVY 95/05 95/05 >97/04 i ADAR a ir deployable Ac t iv e i"..... 1 00035 III ((AN/SSQ- RECEIVER (AN/SSQ-101) MUW PEO(A) [PMA264 NAVY iN/A iN/A >92/05 99/03 [99/05 : A D C M K 3 SAWS; ADC MK 3 MOD 0 i i........ j._ ... i i....... 1 00038 III MODO I (ADV TOPREDO DECOY 6)/ i MUW PEO(SUB) i PMS415 NAVY j 75/10 79/10 188/12 (95/08 I............ ADC MK4 I SOWS; ACOUSTIC DEVICE 1 ...... \ ........ > ......... I ....... |00039 III MODO ICOUNTERSEAURE MK4, jMUW PEO(SUB) PMS415 NAVY 82/10 88/06 94/05 i : IAOTOMATED DIGITAL '1 ' ...... !........... |01480 III ADNS NETW ORK SYSTEM iC4l SPAWAR PMW 158 NAVY IN/A N/A 99/12 00/01 N/A 00/09 i ADV ADV STRATEGIC AND S I >01355 III STRATEGIC TACTICAL IR EXPENDABLES [AIR PEO(T) PMA272 USAF < } j 95/05 02/2Q i - : AGILE GROUND LASER E ?£ MARCO \ ; (01167 III AGLE PROTECTION SYSTEM EXPD MARCOR R/ NBC NAVY \ 98/12 98/12 IN/A N/A ; -......... ! AGM-114K { j......... ........ [01357 III HELLFIRE II [AGM-114K HELLFIRE II AIR PEO(W) PMA242 ARMY IN/A N/A N/A \WA N/A [N/A Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) 03 -s i o {00168 III 01160 III i j >01533 III 1 AN |ACAT|SHORT TITL5 LONG TITLE |DASN| PEO I PM | LEAD | M/S 0 M/S I | M/S II | LRIP l|LRIP II M/S III I ALE-47 CM ALE-47C0UNTERMEASURES:...- AIR ’ {01079 '■ ...... III DISPENSER DISPENSER SYSTEM [AIR PEO(T) r PMA272 FORCE 80/05 83/08 .... j 88/08 92/08 f'" 93/08 j i '01432 .'III ALQ-164 ALQ-164 TACAIR ECM POD {AIR fpEO(T) PMA272 i (NAVY !N/A N/A iN/A N/A ]N/A 90/08 j i ..... AN/ALQ-144 (... " f ( <01356 III INFRARED AN/ALQ-144 INFRARED CM I AIR PEO(T) PMA272 {ARMY \ jN/A ).. . N/A N/A N/A 87/0! | 1 j00869 III AN/ARC-210 AN/ARC-210 COMBO RADIO C4I NAVAIR PMA209 I J navy S N /A N/A 85/05 >92/06 94/04 i ;1 AN/SLQ-10 an/blq-io electronic F .. I f '01463 III ELECTRONI SUPPORT (ES) SYSTEM [MUW PEO(SUB) PMS435 {NAVY ;92/10 [94/10 94/10 99/11 N/A 00/10 i...... < COMMAND & CONTROL SYS \ ..... j \ {00731 illl AN/KSQ-1 FOR AN/KSQ-1 (SHIPS PEO(EXW) PMS377 NAVY 89/05 95/03 95/12 j > AN/PVS-7B AN/PWS-7B NIGHT VISION i..... ........... {01153 III NVG GOGGLE {EXPD MARCOR CBG 'ARMY j i AN/SLQ-20 .................................. ....... {...... ! 100138 III UPGD AN/SLQ-20B UPGRADE > C 4I NAVAIR PMA213 NAVY N/A 93/09 93/09 N/A 97/02 { i AN/SLQ-48 " AN/SLQ-48 MISSION 1 PEO(MUWi s ■ i01364 III MP1 /MP2/MPI PACKAGE 3 Im uw ) PMS407 NAVY j 97/04 i ..... AN/SPQ-9B AN/SPQ-96’RADAR i > {01111 ;ih RADAR IMPROVEMENT (ANTI-SHIP {TCS PEO(EXW) i PMS440 | NAVY <94/10 01/07 { a n ;s q c e 32............ ( PEO(MUW f "..... {00149 mi AN/SQQ-32 SONAR/MINEHUNT {MUW ) PMS407 {NAVY ! 82/09 89/12 92/02 94/08 i I AN/TSC-96A AN/TSC-96A SATELLITE I i ? i .......... i |01182 in SATCOM COMMUNICATIONS (EXPD MARCOR IC iNAVY ! ! i S i...... A N /.W LY -1...................... ! i............. 1 i : i ; '00163 j m i . AN/WLY-1 ................ COUNTERMEASURES (MUW PEO(SUB) JPMS415 {NAVY i 88/10 (95/12 98/08 I 01/01 : ■ ............■ ] {01610 ini : > AN/WSX-6 SHF SATCOM TERMINALS iC4l SPAWAR PMW176 1 NAVY 74/10 74/10 178/10 N/A N/A 91/03 j ; 'ANTIPERSONNEL ........... Eng Supt t ! ......i 5 1 01345 hi APOBS OBSTACLE BREACHING {EXPD MARCOR Equip NAVY 88/10 (93/11 N/A N/A > 99/01 [ > APR 39A(V)2 RADAR i ” E {00126 in APR-39A(V)2 WARNING RECEIVER {AIR PEO(f) PMA272 ARMY ;N/A N/A >88/05 96/05 j i i I ! I i ! ! APS {AFLOAT PLANNING SYSTEM IAIR PEO(W) PMA281 iNAVY N/A iN/A 88/08 93/09 i94/08 ARMORED (ARMORED V E H I C L E i ........... ..... 1 ] VEHICLE DRIVER'S THERMAL VIEWER : EXPD i MARCOR iCBG {NAVY ; 1 ! ASSETTRACKING {MARC i ATLASS I LOGISTICS AND SUPPLY i MARCOR C4ISR iOR ; 93/08 >97/08 {97/08 N/A :N/A >99/05 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) j AN jACATjSHORT TITLEf LONG TITLE |DASN| PEO | PM | LEAD | M/S 0| M/S 1 1 M/S ll|LRIP l|LRIP 1 ( M/S iT T ! ASSET TRACKING....... f MARC , ( ■ " j01534 ■III ATL.ASS II 1 LOGISTICS AND SUPPLY 1 1 + MARCOR (C4ISR OR (93/08 97/08 97/08 (N/A N/A 00/01 i : : 1 ADVANCED TOMAHAvvk I01306 III ATW CS j W EAPONS CONTROL AIR PEO(W ) PMA282 NAVY N/A N/A 94/09 N/A 98/09 I AUTOSERD/ AUTOMATIC SUPPORT 101626 III SERMIS ‘EQUIPMENT/SUPPORT AIR (NAVAIR • PMA260 NAVY N/A N/A N/A (N/A [N/A 95/09 I .... AVR-2 1 AVR-2 LASER" W ARNING I i00207 III LASER (DEVICE AIR PEO(T) PMA272 ARMY (N/A (N/A N/A N/A > 89/11 !..... [BATTLE GROUP PASSIVE 00213 III BGPHES-ST (HORIZON EXTENSION C4I SPAWAR PMW 163 NAVY N/A 90/12 ■91/04 N/A (N/A 96/07 I .... BOL CHAFF • BOL CHAFF DISPENSER •00219 II! iDSIPENSER [(LAU-138A) (AIR ;PEO(T) IPMA272 (NAVY N/A N/A N/A N/A 92/11 i ; I (COMMONS AVIATION |....... I............... i 101380 II! CAC2S (COMMAND & CONTROL (EXPD(M ARCO R CIS NAVY 97/07 00/08 02/06 N/A N/A 04/10 ! S MK 48 ADCAP COMMON 1 ..........’ s " j01322 Ill CBASS BROADBAND AOVANCED (MUW PEO(SUB) (PMS404 NAVY 98/04 01/10 02/10 03/10 ( ............ iCDL-N COMM ON DATA LINK - NAVY \ !00266 III (FORMERLY (FORMERLY COMMON HIGH CONFIGURATION jC4l i SPAWAR PMW 163 NAVY N/A 89/05 91/09 (N/A N/A 96/07 •01627 III CMIS (MANAGEMENT (C4I (NAVAIR A IR -3.1.8N A V Y N/A N/A N/A N/A N/A 98/04 t " .. j CONFIGURATION (MANAGEMENT COOPERATIVE OUTBOARD > ■ i (01535 III CMIS MARCOR C4ISR NAVY 96/05 98/10 97/05 N/A [N/A 98/04 (01205 III COBLU LOGISTICS UPGRADE C4I SPAWAR PMW 163 (NAVY N/A [N/A (91/11 ,98.07 [N/A 00/03 i COMBAT DIRECTION [ I i " ' I ■ s i >00282 III I C OM BATDF FINDING SYSTEM (AN/SRS- ;C4I (SPAWAR PMW 163 NAVY N/A •N/A [91/02 'MIA •N/A [94/12 i COMBAT i........ ! ( [01231 (III iSHOTGUN (COM BATSHOTGUN EXPD MARCOR CBG NAVY I | ‘ :........ ' 1 ' ..... (COMBAT SURVIVOREVADER AIR • > [01436 III CSEL 1 OC4TO R (CSEL) (AF) AIR NAVAIR PMW 187 rO R C E 92/08 [N/A 95/11 01/3Q N/A 03/2Q AN/SQO-34A(V) AIRCRAFT P EO (M 0W j j 00308 III CV-TSC CARRIER TACTICAL MUW ) PMS411 NAVY j 81/06 91/04 94/08 ( iCOMMERClA WIDEBAND' I ■0148S III CW SP (SATELLITE C4I • SPAWAR PMW 176 ( NAVY N/A 98/07 38/07 98/07 99/10 01/03 ! [....... .............. .................. MARC • >01536 III DEPWL (DEPOT WORKLOAD DISTRIBUTED EXPLOSIVE MARCOR PEO(MUW C4USR OR i I [00971 III ;DET [TECHNOLOGY MUW ) PMS407 NAVY • 95/10 (96/06 01/01 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) 1 AN !a CAT|SHORT TITLS LONG TITLE |D A S N | PEO ! p m _ | LEAD I M /s o | M/S i | M/S II | LRIP l|LRIP l| M/S III j DISTANCE LEARNING MARC ......... ; J01583 III DL •PROGRAM MARCOR jCSLE OR ; '97/06 98/11 98/11 N/A N/A 00/02 : : ; ; |01387 III DMR DIGITAL MODULAR RADIO C4I SPAWAR PMW 179 i NAVY 98/08 98/08 98/08 00/02 01/2Q '01/09 ! f "" E-6B AIRBORNE COMMAND ! i {01096 II! E-6B ABNCP POST AIR PEO(A) PMA271 NAVY 95/01 95/01 96/01 95/01 ; i...... EA-6B Al Q- EA-6B ALQ-99 LOW BAND 1 ...... {01250 III 99 LBT TRANSMITTER iAIR PEO(T) SPMA234 [NAVY N/A N/A 96/09 03/3Q 04/1Q EA-6S ALQ- ! i ..... ,01359 {III 99 BAND • EA-6B ALQ-99 BAND 9/10 jAIR PEO(T) •PMA234 iNAVY ;N/A iN/A N/A N/A N/A 97/11 i ! .... i EMBEDDED G PS INERTIAL i {........... (AIR i 101604 Ill EG I INAV SYS (AF) (AIR NAVAIR •PMA209 'FORCE N/A N/A N/A N/A • N/A 94/03 I s 'EXPEDITIONARY i........ i ' MARC •01537 'III EICOC/UOC •INTEGRATED COMBAT 1 ! MARCOR •C4ISR OR 97/03 98/07 01/10 N/A N/A • 02/09 ! ' " ; j . . . . 'ENTERPRISE RESOURCE S....... AIR- j 101628 Ill ERP PLANNING !C4i NAVAIR 00/ESP In a v y N/A N/A N/A N/A :N/A N/A [ F-14 i ...... io i255 III PRECISION F-14 PRECISION STRIKE AIR PEO(T) PMA241 • NAVY N/A N/A N/A N/A 95/10 j01303 III F-14B UPGD F-14B UPGRADE AIR PEO(T) IPMA241 NAVY N/A N/A N/A N/A i i i 95/10 ! i FEM FACILITY & EQUIPMENT I j {01466 III PROJECT 'MAINTENANCE (FEM) SHIPS SEA 04 SEA04D NAVY 93/12 95/01 i 95/06 • FIBER OPTICS DATA SEA052 ! {01121 III FODMS 'MULTIPLEXING SYSTEM SHIPS SEA 0 5 B NAVY 91/01 95/03 ! 02/11 ; GEN-X IGENERIC EXPENDABLE I |00444 III DECOY •DECOY :• .....................................” AIR PEO(T) PMA272 NAVY . .. N/A 83/05 e9'"8 *"A ;................. 92/05 ; E I 101433 III GPS INT ! GPS INTEGRATIONS iAIR PEO(T) • PMW 187 ' n a v y .N/A N/A N/A N/A N/A N/A ' ' HARM HIGH SPEED ANTI- : 101391 III BLOCK VI RADIATION MISSILE AIR PEO(W ) {PMA242 NAVY N/A •N/A 98/11 N/A 03/3Q i HIGH FREQUENCY RADIO 100155 III HFRG GROUP C4I SPAWAR jpM W 179 NAVY N/A 90/05 92/09 92/11 95/10 96/05 ; AN/BSY-i HIGH FREQUENCY • 01245 III HFUG UPGRADE (HFUG) (A-RCI MUW PEO(SUB) [PMS425 NAVY '97/05 99/04 99/12 00/10 5 i . DEPT OF NAVY t • • ■ | t 101290 III INPO INFORMATION NETWORK G 4I ! • NAVY I ! ........ IMPROVED TACTICAL AIR r ; ........ ! '01305 III ITALD LAUNCHED DECOY AlR PEO(W) ;PMA208 [n a v y N/A N/A \ N/A N/A 94/12 j Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) 0 3 -"J w AN IACAHSHORT TITLE! LONG TITLE |D A S N | PEO | PM I LEAD I M /SO | M /S I | M/S ll| LRIPI|LRIP l( M/S III I 7INFANTRY W EAPONS NIG H T i ! 't j (...... ; • (01155 III : IWNTD TA R G ETING DEVICE EXPD MARCOR ICBG jNAVY t I | j JOiNT BIOLOGICAL POINT SEA05R i I i... 101468 III JBPDS DETECTION SYSTEM iSHIPS SEA 05 1 INAVY [96/06 196/12 • (01/01 j JOINT h e l m e t m o u n t e d AIR [ 101408 III JHMCS CUEING SYSTEM AIR NAVAIR PMA202 : FORCE N/A 195/11 96/11 0 1 /2 Q N /A 02/2Q i .... ~ (JO IN T SERVICE i IA IR 101409 llll IJSECST ELECTRONIC COMBAT AIR NAVAIR (PMA260 FORCE N/A 95/09 I95/09 }n /a I N/A 101/3Q ; i JOINT SERVICES IMAGERY i V " ' " \ 1 00510 III JSIPS-N I PROCESSING SYSTEM - IAIR PEO(W ) !p m a 28 i In a v y ;n /a N/A [90/11 95/08 97/07 j r •JOINT SERVICE i |MAR/NB ;........... ! ( 101193 III JSLIST j LIGHTW EIGHT INTEGRATED (EXPD MARCOR c In a v y 93/11 95/05 95/05 N/A I N/A 97/04 I j ..... i JOINT SERVICE ; jMARC 101544 mi JSLNBCRS I LIGHTW EIGHT NUCLEAR, ! MARCOR CSLE IOR 95/01 (98/02 i 00/08 N/A N/A i JOINT SERVICE I SEA05R | I 101400 in JSLSCAD LIGHTW EIGHT STANDOFF SHIP SEA 05 1 jNAVY N/A (95/09 96/09 N/A N/A 02/04 [ i JOINT STANDOFF W ARNING ■ S F A 05 R ! !01618 ;lll JSW ILD IDENTIFICATION LIDAR EFP SEA 0 5 1 INAVY 99/08 [01/07 04/01 N/A I N/A 107/07 | I JOINT TACTICAL TERMINAL ' [ |.... ; s j01489 Ill i JTT i MARINE I SPAWAR (PMW 179 ARMY N/A In/a 196/05 96/09 198/04 01/06 | [ .... NBC JOINT W A RNIN G A N D f IMARC j01545 III l J WARN REPORTING NETW ORK MARCOR CSLE |OR •97/12 .97/12 N/A N/A i I ( LAND ATTACK MISSILE FIRE ! (01619 III LAM FCS CONTROL SYSTEM SHIPS PEO(S) iPMS529 In a v y N/A |n /a 01 /IQ 04/2Q : LAND ATTACK STANDARD I j ! j" 101465 III LASM MISSILE (SHIPS PEO(TSC) PMS422 ' n a v y 00/01 00/01 03/09 s ' " LIGHT ARMORED VEHICLE f MARC (01542 III LAVC2 : COMMAND AND CONTROL ; MARCOR LAV OR 97/10 00/06 01/02 N/A N/A 02/03 l i g h t a r m o r e d v e h ic le 1 IMARC- 101543 III LAV EFSP ENHANCED FIRE SUPPORT j MARCOR LAV OR 99/05 i " ................. ............... f...... MARC 1 01540 III : LAV SLEP I LIGHT ARMORED VEHICLE MARCOR LAV IOR 97/10 99/02 100/01 N/A N/A 02/03 l ig h t ARMORED VEHICLE i MARC [01541 III •LAV-AAS ADVANCED ANTITANK MARCOR LAV OR \ 00532 III LAV-AD LAV-AIR DEFENSE EXPD MARCOR LAV NAVY 94/08 N/A In/a 195/12 | MK 54 MOD O LIGHTW EIGHT ; I i (01224 III LUT , HYBRID TORPEDO i MUW PEO(SUB) (PMS404 INAVY ;95/08 01/09 (02/08 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) w | AN lACATiSHORT TITLE) LONG TITLE | DASN | PEO | PM [L E A D |M /S 0 1 M /S I | M/S lljLR IP HLRIP l| M/S III i LIGHT TACTICAL'VEHICLE i ; (01376 III LTVR (REPLACEMENT (MAGNETIC COUNTERMINE (EXPD MARCOR •CSLE NAVY 95/02 98/04 98/04 N/A (N/A (98/04 i 101203 III MACS (SYSTEM (METROLOGY AUTOMATED (EXPD MARCOR iCSLE NAVY i. i 1 01629 III MEASURE (SYSTEM UNIFORM RECALL &(C4I NAVAIR AIR-3.6.BN AVY (N/A N/A (N/A N/A N/A In /a (MINIATURIZED DEMAND (00601 III MINI-DAMA MK 45 GUN ASSIGNED MULTIPLE MK 45 5IN GUN EXTENDED (C4I SPAWAR PMW 179 (NAVY !N/A (N/A 89/07 ;98/02 (99/08 (99/09 ( i01243 III MOUNT RANGE MODIFICATION (SHIPS PEO(S) PMS529 NAVY 96/01 |99/04 i 01/10 :MK 48 (M K 4 8 ADCAP 1 00608 III ADCAP (MODIFICATIONS MUW PEO(USW): PMS404 NAVY | (95/05 j 95/06 j 96/03 | ( PMW/A1 ; i ! ;01492 III ! MORIAH MORIAH NAVY AIRCREW COMMON AIR NAVAIR 87 NAVY (N/A (N/A (99/11 j (00636 III NACES EJECTION SEAT AIR NAVAIR PMA202 NAVY N/A (N/A 85/05 (89/11 j (91/02 : NAVAL AVIATION LOGISTICS (01630 III NALDA DATA ANALYSIS C4I NAVAIR AIR 3 6 2 NAVY (N/A N/A N/A N/A N/A 97/09 | (NAVAL FIRES CONTROL i (01467 III NFCS (SYSTEM SHIPS PEO(S) PMS529 NAVY 99/07 j 99/07 99/07 03/04 ( i NUl KA/SHIPBOARD ■ I . . . . . . . . . . ' i (00703 III NULKA IMPROVEMENT PROGRAM TCS PEO(TSC) (PMS473 NAVY (83/09 87/05 97/04 98/03 99/01 ( OCEAN SURVEILLANCE f ' ' i00706 HI (OBU/OED INFORMATION SYSTEM MULTIFUNCTION MAST C4I SPAWAR PMW 157 NAVY (N/A 5 N/A (N/A N/A N/A 99/03 ( (01206 III OE538/BRC ANTENNA C4I SPAWAR PMW 173 (NAVY (N/A N/A 99/05 (97/03 (99/05 00/02 ; OTCIXS/TADI OFFICER TACTICAL ; : ' i (01482 III XS COMMAND INFORMATION C4I SPAWAR PMW 15 8 ' NAVY N/A N/A N/A (N/A jN/A TBD \ P-3 BLOCK P-3 BLOCK MODIFICATION . ■ ■ - f i01435 (ill MOD PHOTONICS UPGRADE PROGRAM PHOTONICS AIR PEO(A) PMA290 NAVY N/A N/A N/A N/A (N/A 86/02 ■ (00750 III MAST PREDATOR/ MAST/NAVIGATION PREDATOR/SHORT RANGE MUW PEO(SUB) PMS345 NAVY MARC 94/07 94/07 00/11 i 07/10 ( (01498 III SRAW ANTITANK W EAPON MARCOR CBG OR MARC 98/09 98/9 98/9 N/A (N/A 99/09 j (01494 III RAM/RS RAM/RS PROGRAM SHALLOW WATER ASSAULT EXPD MARCOR PEO(MUW CBG OR N/A 93/06 97/12 N/A (N/A 98/12 j (00973 III SABRE BREACHING SYSTEM MUW ) PMS407 NAVY 93/03 (95/12 96/08 02/09 ; Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) co "Si d 1 AN lACATlSHORT TIT L ^ LONG TITLE |D A S N | PEO I PM | LEAD” | M /SO | M/S I | M/S IllLR IP l|LRIP | M/S It I ; SARTIS RAPID :........ " ‘ : ■ ! ; ( [ ' ‘00812 'ill SARTIS RDC ‘DEVELOPMENT CAPABILITY (C4I NAVAIR (PMA213 (NAVY N/A (90/02 (90/02 ‘N/A 97/12 I ; [SENSITIVE i ‘ : r ; " ’ j 5 ; 01481 ‘III SCI ADNS (COMPARTMENTED (C4I (SPAWAR (PMW 158 NAVY i i 00/01 i (99/11 [00/11 : j ......................................... i MARC V' * ! ■ > ; I 101538 III SCS (STOCK CONTROL SYSTEM : MARCOR ■IS ‘OR 97/05 i 98/02 ‘98/12 :N/A ‘N/A (99/08 j....... SH-60B ' ‘ I * ; ■ . I i |01240 III ARMED i SH-60B ARMED HELO AIR PEO(A) (PMA299 ‘NAVY N/A (N/A (N/A N/A ■ 500/03 ! SHALLOW ‘SHALL W ATER INFLUENCE PEO(MUW ( ‘NAVY ! " | \ 01460 III W ATER iMINESW EEP SYSTEM [MUW ) [PMS210 (N/A (N/A (99/10 102/10 (N/A 03/10 SHARED RECONNAISSANCE : i ! * " ‘01437 ‘III SHARP POD AlR PEO(T) • PMA265 (NAVY N//A (N/A 00/03 0 3 /1 Q T B D ■04/2Q I............ ‘ 'SHIPBOARD COLLECTIVE SEA05R i (NAVY c ‘ > 5 ‘00844 III SHBD CPS (PROTECTIVE SYSTEM, S HIPS‘SEA 05 1 ; j £3/03 (93/08 i , SHF ■SHF SATELLITE TERMINALS ‘ ! ? ■ *01217 ‘III TERMINALS A N /W SC -6(V)2, (V)5, (C4I SPAWAR PMW 176 (NAVY (N/A ! 74/10 (99/04 96/05 ;97/09 (00/04 ( .......... i ‘ SHIPBOARD SINGLE I ; j i j ‘00870 ‘III SINCGARS CHANNEL GROUND AND jC4l SPAWAR PMW 17 9 ‘NAVY ‘84/03 t ; 85/10 I (97/02 j ' ‘ SHORT RANGE ANTI-TANK / r ; I" j ‘00904 III SRAW W EAPON (PREDATORO EXPD MARCOR CBG (NAVY 90 02 ; 94/06 *94/06 N/A :N/A (00/09 5 SUBMARINE LAUNCHED i ! ; r ! ‘00876 ‘III SRS BALLISTIC MISSILE (SLBM) SHIPS SSP (NAVY j : | ( (SCOUT-SNIPER NIGHT • ; (01232 III SSNED ENHANCEMENT DEVICE EXPD MARCOR CBG-1 ‘NAVY (94/04 1 98/05 ; (99/01 I SUBMARINE HIGH DATA i ‘C4I ■ I i I ! ' ‘01299 ‘III SUB HDR RATE SPAWAR P M W 173‘NAVY (N/A ;n /a (96/09 97/03 (00/06 (01/02 i , ■SHALLOW W ATER ASW : ‘ * ‘00021 ‘III SWALAS ( LOCALIZATION AND ATTACK MUW ‘PEO(A) PMA264 (NAVY 94/02 96/09 (08/4Q N/A \HIA 513/4Q : NAVAL SPECIAL WARFARE PEO (M UW IPMSNS : j > | ‘00694 ‘III [SW MCM (VERY SHALLOW W ATER M U W ) W NAVY 95/06 ( 5 T-AGS 60 CLASS ‘ > ‘ ‘00981 ‘III [T-AGS 60 OCEANOGRAPHIC SURVEY SHIPS PEO(EXW ) PMS325 ‘NAVY ■N/A ‘89/08 i (92/05 j TACTICAL AIRCRAFT ‘ ' ! ! : ‘01288 III ‘TAMMAC (MOVING MAP CAPABILITY (a ir NAVAIR PMA209 NAVY N/A (96/12 96/12 00/04 (01/2q ( [TB-29A : ....................................... : ‘01459 in ‘TOW ED TB-29A TO W ED ARRAY ‘MUW PEO(SUB) PMS435 ‘NAVY ‘N/A N/A (98/09 00/03 (00/12 i 01/07 : TOOL AND INVENTORY ■ ; ! ‘01539 Til ‘TIMA (MANAGEMENT APPLICATION ( MARCOR C4ISR NAVY ( i j ( Q. 3 , W a O O C D C D c 7 O O U J U J j * O U J L U 2 O O o n ■ o : q : 88 8 E C < o xn o L u cc a: x a a: I I 376 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN |ACATlSHORTTITLEl LONG TITLE |DASN| PEO | PM | LEAD | M/S o| M/S I | M/S ll|LRIP l|LRIP l| M/S 1 1 1 | j01503 IV IRLP ! INFRARED LASER POINTER iMARCOR CBG NAVY 94/10 [98/07 . . . . ... ; ...... INTERNALLY i MOTOR MARC ' 1 " i \ ... |01582 IV IT-LTV TRANSPORTABLE-LIGHT MARCOR TRANSP OR • s i [ i i t ................ ......... jMARC ... > . . [ ....... i I I i01500 ;IV JSCS COMBAT SHOTGUN •MARCOR CBG (OR .94/05 !n/A 1 98/01 I N/A | N/A m m | ..... . i JSTAES JOlNff SURVEILLANCE IMARC r ..............i'......... > ......... l " " ...... 'i........ i •01521 riv CONNECT IVI TARGET ATTACK RADAR MARCOR C4ISR (OR 196/02 197/07 •99/08 N/A ? " .... i LAV LIGHT ARMORED VEHICLE i 1 ..........."1 " ' f ! 01343 | IV THERMAL DAY/NIGHT SIGHT/THERMAL EXPD MARCOR • LAV I NAVY i I \ ; i ..... ....... MAR/NB iMARC i..... < I ;01552 IV LWH LIGIITWEIGHT HELMET •MARCOR C I OR i.................. s i { MOBILE ELECTRIC POWER • Eng Supt i MARC • i ; ; {01516 IV IM EPD S DISTRIBUTION SYSTEM MARCOR • Equip I OR ! { i ! .MOBILE ELECTRONIC IMARC • j i '' i... ‘01522 IV IMEWSS PIP WARFARE SUPPORT MARCOR C4ISR OR i S i t 19 4/1 1 N/A N/A (00/11 I .......... i MAR/NB MARC j ........1 ' •.... • 01563 IV MLS MARINE LOAD SYSTEM ! MARCOR iC OR 196/12 •96/12 N A N/A • 99/04 ; ••••■ ■ ■ ■ ..... MODULAR LiGHTWElGHT MAR/NB MARC r ■ s ■ i •....... \01554 IV MOLLE LOAD CARRYING ’MARCOR C OR J96/12 • 98/12 | N/A •N/A [99/04 I multf PURPOSE HEALTH MAR/NB MARC I i ^ ' ■ 101555 IV MPHSF SERVICE FACILITY MARCOR IC OR •97/03 : : s j i MAR/NB MARC 1............... i (01556 IV OTV OUTER TACTICAL VEST iMARCOR C OR m n 0(5/10 N/A IN/A [99/04 j . MAR/NB MARC ) .................i I'" 1 01557 IV PALCON PALLET CONTAINERS iMARCOR jC •O R [80/12 81/12 [N/A IN/A [82/12 I i !............ . . . . . f MARC 'I 5 • ; 01508 IV RAC RIVERINE ASSAULT CRAFT MARCOR CBG OR 97/07 ! i •98/03 • ............ 5 RUGGEDIZED BEVERAGE MARC I ........... r ' T i {01561 IV RBC CONTAINERS IMARCOR CSLE OR i i ; < i REMOTE SENSING MAR/NB MARC T‘ [01560 IV RSCAAL CHEMICAL AGENT ALARM MARCOR C OR | : 9i/09 i SMAL ARMS PROTECTIVE (MAR/NB iMARC ! I ! i i01563 IV SAPI INSERTS MARCOR C OR 196/12 96/12 N/A N/A [99/06 i JOINT TACTICAL MARC I...... f • j ' ~' ;01496 IV TDCP INFORMATION iMARCOR C4ISR OR n/a ;N/a 1 96/04 t i..... . . ... TRAY RATION HEATING I MAR/NB [MARC I' j........ {01564 IV TRI-IS SYSTEM {MARCOR iC OR I ............. S f. _ ; 1 95/06 ASN (RDA) ACAT Listing December 2000 (continued) AN lACATlSHORT T IT L ^ LONG TITLE DASN| PEO j p m " |T E A D ' | M/S 0 | M/S 11 M/S II|LR IP ijLRIP l( M/S III 500131 IVM AN/AYK-14 = AN/AYK-14 (VPM) AIR i NAVAIR | PMA209 ! NAVY N/A •N/A 86/02 i {91/05 93/08 ; ; AiM/TPQ- 5AN/TPQ-36 (V)7 FIREFINDER i" I ........... i * : 01336 IVM 36(V)7 {RADAR EXPD MARCOR {CBG ‘NAVY : j j I : ; AN/TPS-59 { ' !' ! : ! ! ' {01344 IVM (PIP) AN/TPS-59 (PIP) E XPD iM A R C O R IC 4IA D 'NAVY { { ■ [97/03 : i" s i01440 : IVM AN/UPM-155 AN/APUM-155 AIR NAVAIR 'PMA213 {NAVY 'N/A M a IN/A N/A N/A {86/08 ; 5 ; ‘ ....... BARRACKS CRAFT-SMALL { ............... 5 5 I \ ; ; ' 101386 IVM APL(SMAl l; (Aru(S)) SHIPS; P EO (E XW )P M S 325 jNAVY N/A 1 95/03 j 95/09 N/A N/A [98/05 ; I AQM-37C SUPERSONIC i ! : I I 5 5 501307 'IVM AQM-37C 5TARGET AIR PEO(W ) ! PMA208 NAVY 5 N/A ]N/A \NIA [N/A ; [95/08 I 5 ARCADE RADIAC [SEA04L I : ■ i ; ‘00169 :IVM ARCADE DEVELOPMENT S H IP S S E A 04 RB [n a v y 5 {90/06 ; 92/03 j 194/10 { ; " 5 m a r c i \ j i ' : |01565 ‘IVM AS ASSAULT SNOW SHOE MARCOR c s l e {o r i ; 5 >98/04 { 5 i' 5 AUT OM ATIC TEST {MARC ‘ ‘ i ! : [01587 IVM ATE {EQUIPMENT MARCOR TMDE {OR ' • \ ; ; ; ; ....... f ............................... ‘MARC j ' 501509 IVM BFA {M2 b l a n k f ir in g a d a p t e r MARCOR CBG {OR 97/08 97/08 j 97/09 { 5 {BATTLE FORCE TACTICAL \ ; ! { 100211 IVM BFTT {t r a in in g im p r o v e m e n t C4I PEO(EXW ) PMS430 {NAVY i ; 92/10 93/09 93/09 [96/11 [ ; { {MARC ■ * " j' 5 5 ‘01571 IVM BIVY {IMPROVED BIVY SACK MARCOR [CSLE {OR 1 94/04 5 [94/04 5 5 ............. 5 BQM-74E [BQM-74E MOBILE SEA i 5 i ‘ ; ■ 500223 IVM MOBILE SEA i RANGE AERIAL TARGET AIR PEO(W) {PMA208 'NAVY N/A N/A 88/02 ‘N/A ^91/04 : i {BACKUP COMPUTER ] ’ j f ■ '< j \ 01331 5 IVM i BUGS (R) SYSTEM REPLACEMENT EXPD MARCOR CBG NAVY • \ ; 5 C-130 NVG 0 -1 3 0 NIGHT VISION ......................f 5 i , I 501219 IVM CIEL GOGGLE COMPATIBLE AIR PMA207 PMA226 {NAVY i ■ : i 5 C-9 C-9 REPLACEMENT i ' j ■ ‘ ' ' ! : 01328 ; IVM REPLACEME AIRCRAFT PROGRAM (C- AIR NAVAIR PMA207 {NAVY N/A ;n /a N/A N/A [97/08 { ' C-9B/DC-9 C-9B/DC-9 AVIONICS ; 01304 IVM AU UPGRADE AIR NAVAIR h MA207 {NAVY N/A In /a {N/A N/A ■97/06 [ i i • {MARC r ; { 01567 ;IVM CBS ‘COMBAT BOOT SOCK MARCOR CSLE {o r ; ! ; | ; NAVAL AVIATION ; i '! 01353 IVM CBT {COMPUTER BASED AIR NAVAIR PMA205 NAVY N/A ;N/A ;N/A N/A mm i Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) I AN |ACAT|SHORT TITLE| LONG TITLE | DASN| PEO | PM | LEAD | M/S 0 | M/S 11 M/S I|| l RIP l|LRIP H M/S liF | l ’ ' T................ ""......~......... I ’ T IMARC ; ' i 1 ...........}....' .....I ........... i 01588 .... IVM CE CALIBRATION EQUIPMENT CH 46E T58-16EN G IN E MARCOR ;... . [t m d e OR i ! I i.......... I I 01632 I IVM CH-46E .RELIABILITY IMPROVEMENT AIR (NAVAIR PMA226 iNAVY N/A • 01/2Q 01/2Q ! 5 (02/3Q COMPOSITE1SASD; COMPOSITE I i 00291 IVM PUMPS I PUMPS/SHIPBOARD AUX i SHIPS! PEO(S) PMS500 NAVY N/A 80/10 86/03 \ j 98/08 ■ ....... ............ CRASH SURVIVABLE FLIGHT \ (.......... 01291 IVM CSFIR INCIDENT RECORDER [a ir NAVAIR PMA209 ■NAVY N/A • N/A N/A N/A (97/07 ........ ........................ CT-39 REPLACEMENT " I ’ r ........ 01609 IVM CT-39 AIRCRAFT PROGRAM (UC- (AIR [NAVAIR SPMA207 ARMY N/A N/A N/A N/A N/A N/A ' ' : ■ ................................ ............ ! 1 m a r / n b MARC ; 01568 IVM CTFNT iCOM BATTENT I MARCOR c OR 5 I | , . ....... - .- COMBAT VEHICLE i ......... MARC i I 01175 IV M CVAT APPENDED TRAINER (EXPD MARCOR CSLE OR 6/97 00/05 00/05 COl D W EATHER SOCK j...... MAR/NB MARC 01566 IVM iCW SS SYS TEM i MARCOR C OR 96/09 .......... ! (SHiPBOARDUHF DIGITAL i..... s 01272 IVM DWTS W IDEBAND TRANSMISSION C4I SPAWAR : PMW 179 NAVY (97/06 (97/12 97/12 97/12 98/09 01/2Q ....... DIGITAL W IDEBAND MARC j r....... 01524 IVM DW TS/UPS TRANSM ISSION MARCOR IC OR i i .......... 99/09 ...... ' EXTENDED COLD W EATHER MARC 01569 IVM ECWG O-LOt/E MARCOR CSLE I OR ; ! 98/03 .... EXTREME c o l d w e a t h e r iMARC ! .... I i 01570 ;IVM ECW T iT tw r MARCOR •CSLE ;OR |............... { j 93/09 ............... (EXPENDABLE MOBILE ASW PEO(MUW !................ '(■■■■ r " | i .......... 00367 IVM EMATT TRAINING TARGET {MUW ) iPMS403 jNAVY [ (80/01 ! 87/08 91/06 : (93/04 .......................... El fcCTRO-OPTiC TEST ..... > : I 01325 IVM EOTS CASS SYSTEM OPERATIONAL AIR NAVAIR PMA260 iNAVY N/A N/A 97/06 N/A N/A 00/03 .EP 3E COMM ON ...... ; 01289 IVM EP-3E CIP EXPENDABL IMPROVEMENT PROGRAM A IR PEO(A) PMA290 NAVY • N/A iN/A N/A N/A 96/11 00399 IVM E W A V E EXPENDABLE W AVE BUOY CNR CNR NAVY ... FF FIREFIGHTER BREATHER . ! 00413 IVM BREATHER APPARATUS/PERSONNEL SHIPS SEA 05 ’SEA 05L4NA VY j =92/01 96/08 FLEET TRNG FLEET TRAINING RANGE I 1..... 00430 IVM iRANGE TELEMETRY SYSTEM AIR NAVAIR (PMA248 NAVY (84/08 [92/08 •93/08 N/A 93/11 FAMILY O F TACTICAL SOFT j .......... ................. ! i .......... 01242 IVM FTSS SHELTERS ;EXPD (MARCOR (CSLE NAVY (N/A !n /a 196/01 N/A N/A ,98/09 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN lACATlSHORT TITLE | LONG TITLE | DASN | PEO I r rr c | M/S 0 1 M /S I | M/S II|LR IP llLRIP l| M/S lll| GENERIC ACOUSTIC 02/3Q [ {00443 j' IVM GASS STIMULATION SYSTEM MUW PEO(A) (PMA264 NA./Y N/A N/A 97/02 N/A 02/2q ; GEN II 25MM GENERATION III 25MM i ; " : 01330 ! IVM 12 TUBE IMAGE INTENSIFIER TUBE HIGH PREQUENCY (HF) EXPD MARCOR CBG NAVY MARC ( ' • : I (01520 (IVM HF RADIOS MARCOR IC OR i : : i " j HIGH POW ER OFFLOAD TO ( ! i f ■ : (01415 i (IVM HP TO CASS CASS HIGH PO W ER AUTOMATED (AIR i NAVAIR PMA260 . | NAVY ! 'N/A N/A 94/06 (N/A jN/A 00/03 (01606 IVM (HPOC (TEST EQUIPMENT OFFLOAD ;AIR NAVAIR (PMA260 (NAVY ! ! i r i : ............. ( INTEGRATED CONDITION , . . . t............ : I : (01273 IVM (ICAS (ASSESSMENT SYSTEM SHIPS SEA 05 (SEA05J3(NAVY i ; • i ;' (ICE (ICE PENETRATION FOR ;......... j' i (00468 IVM (PENETRATI i ............... : (SENSORS i ............. :CNR ! ' ' ) CNR (MAR/NB (NAVY MARC ; ' ' ' ( ( (01572 IVM IFS IMPROVED FIBERPILE SHIRT; MARCOR C (OR ; 98/04 ......................................... ) MAR/NB (MARC j i ( (01573 IVM IGI IMPROVED GLOVE INSERTS i i MARCOR C (OR ( ! 98/07 ; I INTERNATIONAL m a r it im e t ‘ ( ( i ° 1487 i IVM INMARSAT SATELLITE INDOOR SIMULATED ! SPAWAR PMW 176 ^NAVY (N/A N/A 94/06 (N/A ! (n /a j 95/07 ! ( (01241 : IVM ISMT/IST MARKSMANSHIP IMPROVED TRIGGER LXPD MARCOR SST (NAVY MARC ; i ; : 94/11 ( '01574 ; IVM ITFM FINGER MITTEN MARCOR CSLE MAR/NB OR MARC ■ ! : 98/02 ( (01575 JVM ilVEST INNER VEST MARCOR C OR 96/12 96/12 N/A ;n /A 98/09 : ( COMBAT SYSTEM TESTER (AIRFO \ (01631 r (IVM IVM PROGRAM JOINT SVCE A /CREW LOW AIR : NAVAIR PMA260 RCE . N/A N/A 96 ! ( 01 /3Q ! (01382 IVM : JALEPV ENERGY MULTIPLE AIR NAVAIR PMA202 NAVY (N/A N/A (96/06 (01/2Q 02/2Q ( LEGACY ATEi LEGACY AUTOMATED TEST . j (01441 IVM OFFLOAD EQUIPMENT OFFLOAD TO AIR NAVAIR PMA260 NAVY 'N/A 01/1Q 01/1Q (N/A iN/A ;03/1Q ; i i LASER HEATED SEA04L ‘ (00542 (IVM L.HTDS THERMOLUMINESCENT SHIPS'SEA 04 RB NAVY 88/02 90/09 96/05 i 01/07 j ( .......... . . . 5.56 LIGHTW EIGHT MACnii'iE .................. : ) ' '[ (01624 IVM LMG GUN SHIPS PEO(EXW ) PMS325 NAVY MARC ; j (01586 IVM LOMAH LOCATION OF MISS AND HIT MARCOR CSLE OR ;97/07 ' J Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. A S N (R D A ) A C A T Listing December 2000 (continued) AN |ACAT|SHORT TITLEj LONG TITLE 1 DASN| PEO | PM | LEAD | M/S o| M/S 11 M/S ll|LR IP l|LRIP l| M/S III OS 0 0 [01321 [IVM LRLS [01517 (IVM LRTF [01338 (IVM LW CW US ! (01414 IVM M31 MARITIME [01454 j IVM FORWARD [01576 IVM MB (01401 i (IVM MCD MECHANICA (01151 IVM L TMDE [01577 IVM iMFSS i MINI-DRIFT [00602 IVM DATA BUOY [01490 IVM MIUW -SU [01280 .IVM MIUW -SU j MK-25 MOD !01470 [IVM .2 UBA : ; MK-30 M OD [01469 IVM 1 ASW * MK-30 MOD (00613 IVM 2 ASW [00620 ( IVM MMSD I 01578 IVM MPC i [01185 'IVM MTWS MULTI 00626 [IVM FUNCTION [NAVAIR (PMA251 [NAVY Eng SupT MARC MARCOR Equip !OR M A R C LONG RANGE LINE-UP SYSTEM (AIR LIGHT CAPABILITY, ROUGH | TERRAIN FORKLIFT | LIGHTW EIGHT COLD W EATHER UNDERW EAR SET EXPD MARCOR CSLE [OR MARINE CORPS EXPEDITIONARY ,EXPD NAVAIR PMA251 iNAVY MARITIME FORW ARD i iSHIPS PEO(EXW ) PMS325 iNAVY iMARC iMARCOR iCSLE sOR iPEO(M UW i N/A N/A i 96/09 ; 98/09 N/A 98/05 i 98/05 ;N/A N/A LOOKING INFRARED (MINIATURE BINOCULARS MAIN CHARGE DISRUPTER MECHANICAL TEST, MEASUREMENT AND ' . '{ MULTI-FUEL STOVE ! o c e a n /m e t e o r o l o g ic a l /A: (COUSTIC MINI-DRIFT DATA ;CNR : MARITIME INSHORE : UNDERSEA W ARFARE- MOBILE INSHORE UNDERSEA W ARFARE P M SEO DNA VY MARC OR MARC OR i 96/01 i 97/08 ; 97/08 99/08 ; i ; 94/09 i (0 2 /2 Q : i 94/09 ? i ; ; 00/01 i M UW i) r i ■ ■ ; EXPD iMARCOR TMDE < ' 'MARC ; i ' i i MARCOR CSLE OR i 1 90/09 i i j' | " ! ! CNR (NAVY i j i 1 1 ; " j ? f" ' T ' i " SPAW AR PMW 183 iNAVY N/A [N/A N/A [N/A [N/A [96/01 [EXPD [CNR iNAVY i iMK 25 MOD 2 UBA SHIPS PEO(EXW ) PMS325 iNAVY [ MK-30 MOD 1 ASW TRAINING [ : PEO (M UW j 'TARGET ;M UW '■ ) [PMS403 [NAVY iMK-30 MOD 2 A SW TRAINING i > PEO (M UW i i [TARGET !M UW ) PMS403 iNAVY (MASS MEMORY STORAGE ( [ 93/05 (DEVICE/STANDARD C4I PEO (EXW )iPM S440 NAVY MAR/NB MARC MARCOR C OR 96/07 ; 89/08 [92/12 [ MULTI-PURPOSE CART MARINE AIR-GROUND TASK [ i ! FORCE TACTICAL W ARFARE j EXPD MARCOR | CSLE j NAVY MULTI-FUNCTION RADlAC/ 'f (SEA04L j RADIAC DEVELOPMENT [SHIPS SEA 04 ;RB NAVY (93/09 ; 90/06 [92/03 [N/A [n /a 01/11 i i' i [94/05 [ ; \ 9 i/06 [ 94/10 i ASN (RDA) ACAT Listing December 2000 (continued) AN Ia c a tI s h o r t TITL^ LONG TITLE IDASNl PEO [ PM r n r > c | M/S0| M/S 1 1 M/S II|LRIP l|LRIP If M/S III (NEUTRON j NEUTRON DOSIMETRY....... r ~ .... i jSEA04C [ 1 " 00680 IVM [DOSIMETRY | SYSTEM/RADIAC [SHIPS SEA 04 |r b NAVY [88/10 01/07 \ .01/07 OPTICAL ! I ! I.... \ i 00725 IVM IINSTRUMEN OPTICAL INSTRUMENTATION! CNR (CNR i NAVY !.. .. L j | j .... ORDNANCE o r d n a n c e ............. j' ... ! MARC | I : r I 01510 IVM CONTACT CONTACT/MAINTENANCE j MARCOR [CBG OR ‘ (97/06 ! { 1 (97/06 PERSONAL FLOTATION \ | “ (MARC ? ....... i"' r i... I ] ' j 01511 IVM PFD [DEVICE i ) ; MARCOR (CBG OR | i ......... - j.,.. | i (PRECISION GUNNERY ......... j j (MARC j ........ ! j j f 01585 IVM PGTS STRAINING SYSTEM (MARCOR (CSLE OR [ i L.... I. . . 1 j .............. [PORTABLEINFANTRY T " " 1 " ' i j...... ' \ ........ s i ..... . . . . ..... 01177 IVM PITS ‘TARGET SYSTEM lEXPD iMARCOR (CSLE NAVY ]......... i - \ \ 91/07 QF-4S FULL SCALE A/C \ i ' ............ i h " j ' j \ 00770 IVM QF-4S FSAT TARGET SYSTEM (AIR !PEO(W) IPMA208 [NAVY (N/A | N/A (89/02 ! N/A \ i (96/09 ............................ ............. I..... i.................. s.............. MARC ■ r ? |......... I.....' I ....... I .... ; 01559 (IVM QUADCON QUADRUPLE CONTAINERS (MARCOR -CSLE OR i ; 180/12 (81/12 N/A m k 82/12 ....... ! i REMOTE ORDNANCE ~ i :PEO(MUWj ?..... I ........ \ ' 00800 IVM RONS [NEUTRALIZATION SYSTEM j EXPD i) PMSEOD-NAVY ! .97/02 \ . ... 99/03 i 01444 > IVM S-3CS s iS-3 CRITICAL STRUCTURES AIR jPEO(A) PMA290 NAVY 95/11 j 95/11 (95/05 N/A !n/a s (97/07 i SCM; AN/BOH-? SUB EXPEN f ""...... i""' r > I ! .... 01471 IVM SCM BATH'GRAPH (ARTIC MuW (PEO(SUB) PMS415 iNAVY j i i I I J ...... SHBDFIFE SHIPBOARD PlRETiGHTING f.......... ' ( i 00837 IVM FIGHTING , IR -J K (A/S32P-25) S AIR !n a v a ir PMA251 NAVY N/A N/A 93/05 j N/A 97/04 I : i ............. 1 s I....... . MAR/NB MARC ? ...... j 1 ' ' f 1 01579 IVM SMB [SKI MARCH BOOT | [MARCOR c OR ! 09/09 ; ..... ............ (SHIPBOARD" ............ ! !™ ............ i I f .. i 00884 ‘IVM SMOOS (METEOROLOGICAL & !C4I jSPAWAR PMW185 NAVY | N/A (N /A (N/A (N/A ;n/A i 92/12 ......... . [SUPERSONIC SEA j....~.... S .........! f ........ j" " ' j ........ ( i * 01438 IVM SSSTTC (SKIMMING TARGET THREAT (a ir iPEO(W) PMA208 NAVY (92/11 | N/A 99/07 N/A (N/A I03/4Q j ....... SUPPLMENTAL WEATHER r I I ....... ........ ..... r ....... i j........... i 01233 IVM SWR RADAR jC4l SSPAWAR PMW185 'NAVY (N/A N/A N /A N/A [N /A [97/08 i EC SHALLOW WATER j......... [.....' " .......... ( i I i i j ! t 01323 IVM SWUWTR UNDERSEA WARFARE {AIR (NAVAIR PMA248 jNAVY (94/04 96/06 1 96/06 [N/A | (97/09 | TANK TANKSYSTEMS .......... .■ . ........ ? ' '"] 01346 IVM SYSTEM (MODIFICATIONS EXPD(MARCOR CBG NAVY \ ; i I TARGET 21(21 ST CENTURY I r ! L ' ...... 01439 IVM TARGET 21 AFRIAL TARGET) AIR jPEO(W) PMA208 < NAVY 199/2Q [00/12 ? 01/2Q [N/A [N/A 05/4Q A S N (RDA) A C A T Listing December 2 0 0 0 (continued) S ’ C O 0 > 3 ■ C O'! — 0. Ill Ui CL C O ;l ll < 0 2 3 a - 3 1 2 O 2 « ; P > - j ’ < <m 3 iu 2 5 > 5< O 52 6 U J ■ i n i - 1 - 2 o ;_i I- W to z I ” P 1 o a < c o 383 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN lACATlSHORT TITLd LONG TITLE 1 DASN| PEO | PM | LEAD | M/S 0 | M/S 11 M/S ll|LR IP l|LRIP Ij M/S Ihl ; iEX 12 MOD 5 ACOUSTIC :PEC(M UW ] ' 101287 IV I AFS I FIRING SYSTEM M u W !) [PMSEOD NAVY [96/01 98/03 98/03 : ■ S ! 02/08 ; ................................... i [MARC [01513 IVT AMD ADVANCED MINE DETECTOR MARCOR [CSLE [OR 97/10 199/10 01/10 N/A | N/A 04/09 AM/BSG-1 AN/BGS-1 W EAPON ■ I : ; j01402 ; IVT WLS LAUNCHNG SYSTEM ;m u w ■PEO(SUB) PMS425 NAVY N/A 97/06 97/06 i 5 01/09 i j AN/MSC-63A [AN/MSC-63A i ; ■ [ ; 01251 jlVT PIP ' COMMUNICATIONS [EXPD |navy i ' i | i : ENVIRONMENTAL SATELLITE: ; T ■ ; i ! ; ; 00148 * IVT A N/SM Q-11 RLC -IVER-RECORDER C4I SPAWAR PMW 185 iNAVY HI A iN/A [N/A In/A 78/06 I86/09 ! I00154 IVT AN/TSC-96A AN/TSC-96A EXPD iMARCOR IC 1 [NAVY i ; } J : ; AN/UYQ- ,AN/UYQ--70(V) ADVANCED ; . i ' I i i01229 IVT :70(V) ADS d is p l a y s y s t e m C4I PEO (EXW )! PMS440 [NAVY | 94/01 i [97/11 ; AIR SURVEILLANCE & ; S : ! ; 101602 IVT ASPARCS PRECISION APPROACH AIR NAVAIR [PMA213 NAVY [N/A [N/A i 00/06 ; Hi A iN/A 03/2Q i00193 ivr ATACC ADVANCED TACTICAL AIR C2 EXPD MARCOR CIS NAVY i > ■ s ! !...... AV-8BATHS AV-8B AUTOMATIC TARGET i ; i " 01254 IVT II HAND-OFF SYSTEM II AIR PEO(A) PMA257 NAVY N/A [N/A [N/A N/A [97/08 SUBMARINE BASEBAND : '01282 IVT BBS SWITCH M UW [SPAWAR PMW 173 NAVY iN/A [N/A 96/08 96/08 N/A .97/08 C-2A(R) C-2A(R) SERVICE LIFE • ; " 01115 IVT SLEP EXTENSION PROGRAM AIR PEO(T) PMA231 NAVY N/A >94/01 HI A N/A 04/4Q COMPUTER AIDED DEAD : , 01385 IVT :CADRT RECKONING TRACER SHIPS PEO (EXW )jPMS440 ‘NAVY ; '' ; n n;n« [.. ; .. [01/10 s 00235 [IVT i CAINS II ;CAINS II (AN/ASN-139) AIR NAVAIR PMA209 NAVY [N/A iN/A 84/08 [90/03 i i91/07 ........ [CCS MK2 DO:COM BAT CONTROL SYSTEM .............. i i i i 01256 ilVT [BLK IC MK 2 DO BLOCK IC M UW iPEO(SUB) [PMS425 NAVY [96/06 [98/04 [ >00/10 ;...................... CLOSED LOOP DEGAUSSING P EO (M U W: SEA05R !'" [ i 00269 IVT CLDG SYSTEM/MCM M U W i) 27 NAVY 90/12 [96/03 ! [ 1 00/05 ; [COSSl(IMD h e l i c o p t e r in t e g r a t e d • PMA261/ , i ; ; 00810 f IVT HUMS) MECHANICAL DIAGNOSTICS iAIR PEO(A) 299 NAVY N/A HI A [N/A 00/4Q1N/A 1 02/1Q r : CLOSE QUARTERS BATTLE i i [ ..... ; 01216 i IVT [CQBW [WEAPON EXPD MARCOR CBG NAVY 94/04 i i [98/04 01352 | IVT ;c t COMBAT TENT EXPD MARCOR CSLE NAVY \ ; ; i r Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) AN [ACATfSHORT T IT L ^ LONG TITLE [ DASN) PEO | PM | LEAD | M/S 0| M/S I | M/S ll|LR IP l|LRIP l< M/S III) ■ \ 101445 I IVT CXP COMMON IFF DIGITAL TRANSPONDER AIR NAVAIR i (PMA213 NAVY N/A HI A :N/A 01/2Q IN/A 02/3Q 01239 IVT DACT DATA AUTOMATION COMMUNICATIONS EXPD MARCOR C4ISR NAVY 93/06 95/11 95/11 N/A • | N/A ; . . . 98/10 'r ■01447 IVT ,DDS i I DIGITAL DATA SET AIR NAVAIR PMW 187 NAVY N/A N/A N/A N/A ! N/A 93/12 01363 IVT ■DIGITAL ■ INTERROGA DIGITAL INTERROGATOR AN/UPX-37 AIR NAVAIR • PMA213 •NAVY ■ N/A N/A N/A N/A j 98/06 01125 IVT DMR DESIGNATED MARKSMANSHIP RIFLE " EXPD MARCOR CBG NAVY 93/10 ■ 95/05 96/06 N/A ■ N/A 98/04 • 01548 IVT OR ■DIGITAL RADIOGRAPHY ■MARCOR jCSLE ■ MARC jOR 97/03 ■ f- - • - ! ■ • 01169 IV r DSM ■ DUAL SOFT MOUNT EXPD MARCOR sCBG [n a v y ■ .............. ■ i < 01315 ivr DSVL i AN/W ON-2 DOPPLER SONAR • VELOCITY LOG ..........i................." ' I .............. SHIPS PEO(EXW ) IPMS440 s NAVY ■ ■ 79/12 98/07 ' i 01/01 [ 01221 IVT DTC ■DIGITAL TECHNICAL ■ CONTROL (AN/TSQ-1) EXPD MARCOR : C4ISR MARC OR •94/11 1'' 95/04 95/04 N/A N/A ■ ■ ■ i 01/01 ; 01420 IVT E-8 S/ids PROGRAM E 6'M ULTIFUNCTION d is p l a y s y s t e m (m d s j AIR PEO(A) PMA271 ! ■NAVY N/A N/A N/A N/A N/A ■ 99/04 ! 01417 IV I • E-6B MMRT E 6 8 MOD MINI RECEIVER TE k MINAL AIR PEO(A) PMA271 AlR 1 ORCE 95/11 f ’ • 95/11 .96/05 N/A N/A 00/05 ■ 01195 IVT Ie A-OB BLK I89A PROG FA 6 6 BLOCK 89A PROGRAM (OSiP 37-95) AIR PEO(T) PMA234 NAVY N/A ? ;N/A 96/05 98/03 j 99/12 • 01448 IVT EA-6B ■MMADTTAC EA 6B MULTI-MISSION ADV T A C T E R M /ID M AIR PEO(T) PMA234 • NAVY N/A !n /a : t\/r\ N/A t N/A 98/08 i 01246 ;iv t IEA-6B UEU EA-6B UNIVERSAL' EXCITER UPGRADE PROGRAM AIR PEO(T) PMA234 i ■ NAVY N/A N/A ■N/A N/A 96/03 | I [EA-6B OSQ- EA-6B USQ-113 RADIO CM ; i ) 01449 IVT !113 SET AIR PEO(T) PMA234 NAVY N/A ■N/A m i a N/A N/A 98/08 ! 01375 > IVT ■ ECHELON I & ECHELON I & II HEALTH ! 1 1 HSS SERVICE SUPPORT EXPD MARCOR CSLE NAVY 3/97 i • ■ .................. ' I 01351 01265 IVT IVT ■ ........ ............ i jECWCS EP-3E SSIP SECOND GENERATION EXTREME COLD W EATHER EP-3E SENSOR SYSTEM IMPROVEMENT PROGRAM EXPD AIR MARCOR PEO(A) CSLE PMA290 NAVY NAVY N/A ■ ■ N/A • : N/A 95/05 97 /0 1 ! ■ j 96/03 : 00404 ivr F-14 DFCS F-14 DIGITAL FLIGHT CONTROL SYSTEM AIR PEO(T) PMA241 NAVY N/A N/A ! ■ N/A 97/12 98/03 • A S N (RDA) A C A T Lii December 2 0 0 0 (conti co < 0 o c c O ) IC O) C D o o CM o o o o o < 5 < b ^ 25 o 5 C D © © © © < .....z C O c v W UJ < j c o U J dc W H- < i, , - j i= O C L 9 < 2 tt! g UJ :UJ f A T S O r * S Ofc3£gg|ut;ui U l £ X Z ^ J x 0 Q, ^ ^ u: uj y c o o < > 3 o ° S 2 9 c o q : ^ °- z -I 0 x o o o o C O <o tD i 5 § x C L 0 0 = C O C O 3 i g £ _ h < i- tr Z O 5 (3 2 1 1 O o m ~ K s < m tr,2 q h - H * h ~ > > > © £ to C O C O - « • o 8 3 P : 3 < 4* yr- lo CO o s D O t - O O C O c c 386 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ASN (R D A ) ACAT L is tin g D e c e m b e r 2000 (c o n tin u e d ) C O 2 < Z o co CD O ) 5 r- o > a. X C O C O < z < z I I CD < C £ < 05 o K G 5 >- < >- $ z x to O ill Q _ 1 1 1 -J t H o z o Q < U J X > < C O 2 < C O CM < X X X (B § o I D X o 3 3 o O < o C O 2 X < > X o O < U J < ; < U J U J 2 C O z 2 X X Q X X C O X X . X a X X 5 3 U J C O < U J 2 o c o c o o o o 05 a co o C D 05 s X ■ X p > z'§ < £ nr b h- C E o X C O I 1 < z < rr iU J o g 2= 2 5 2 Ul U J > C D IU $ D C 5 U J < £ 0 2 < lil ■ — 1 h- U J w =! 5 O S < iU O .< uj r ; I— • “ h i d o a . UJ -j G Q ~ < 3 C O .% o Q n Z U J ^ o 2 8 * D u < 2 > - u j y e *- x fc a “ g o 1 g< u g s 3 < n oc y U. U J O o in > > y o i_ 2 a: s ^ . 3 < 2 £ g t - t £ o 5 3 Q- g < (£ 3 - UJ L I O < h J 2 ° < m 2 O J -O 2 Q m uj s c c uj O 0 2 <i o c £ < UJ C O CC 2 a: < t uj « s c : | S g : £ -c c 2 < < 2 £ 2 O > P ={ iu iu - c c uj R C D Q .S Jr g a = J w S g <- 3 < a: 2 — Iq. C j q . CL C O 2 1 CM T“ o ;93/0: N - 0 5 C M z • 9 4 /O S 1 < £ < 1 ; s.- 5 < Z;_ Z ■ z Z ; z ; z CD O C M U J U J U J X : o < -J -j _! _ J 2 C O C O C O C O CQ X ...o ,. 9 o o O X X X X X X o o o o O < o ; o a o a 5 X x ; X X X < < < < <■ < z 2 2 _ 2 ' 2 2 a O a Q a fV ' X X X X X X X X X X X < ul ; U J U J U l U J o CO CD . Z CD ▼ “ O t - CO I* - 05 O < Z . >- o > & ■ < < a :.: 22 0 X C O O >- $ z X O o X < Q a. X UJ 2 UJ f e o O T C O ° 2 g | S g g ! * ! ( K ,g 2 :E < o o ■ < 2 2 0 2 uj fn o y Z 2 fi iii S o = * i H 2 Z U J < < z z > ■ 2 " > a < < z 2 tu 00 o C D 05 J z X to 03 0 5 O s < § X C O C M . to C O C Q U J 2 2 O C O C M X o X X X X o to < o . — . o o § o C O X < < X o < U J X < ; U J : C O C O 2 ; X C O X Q X C O X X o C O o U J : 1- >- O > a < < X Z 2 O C O o x O o x < o , CL X U J a o co U J ; _J ; O Q O : O - 5 ^ O g & o g So§U] U J O O tu UJ u j o — o < g o Q C U J X 2 c o 2 2 2 8 : ^ s i x < o y U J = I— C Q UJ O a < L L l O O C O O C O < o X X UJ o < 05 UJ o x •< •< 2 2 co < X o C O - J C O . 5 c o 0- 1 — <r u j u j Z j 2 2 0 X UJ UJ . N fe 2 2 g X S i w fc UJ ? I - < o 5 2 9 = a. co co b > Z j— ; 1 5 " S ? P CL ^ o < g U J o -J > X i l l 2 X o o Ul o. S i g 2 < § M - 2 i- O U J x 5 % , ...r s ■ H > IV T 5 5 IV T % IV T IV T IV T 5 ivr JLAI 05 C M C M ? " * » C M O C M o C M o . ^ ; ■ « “ to 5 s -- o co r - o o C O C O C O 05 C O h- h- « 5 j - . to C D M1 o O C M ■ M ’ C O to C O C D C O to C M T “ C O to C O C O C O to r* C M C M C M o o • ? - o T“ o v~ : T > “ o o o o . . P o o o o o - o o o o O o O o 387 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. p ; 05 0 5 05 < £ > i s o o a > o OO j 05 05 O < o : 3 1 O o < § < C M CM I E L L J * u_ g u j i t < h LL ar:o 2 yj £ E k > ~ ■ o < fZ Q - Z <0 ? Z Z & O 3 < C L C L C Q J Z C L O O f- 1 IO § \ C O T - ; O o o r * - C M 388 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A S N (RDA) A C A T Listing December 2 0 0 0 (continued) § ^ co o CM t n < 0 CM C L V J C O EJJ L U Dl ^ g S l S | P < 0 U J f - 111 I - O 4 - 2 t 1 3 C /3 C /3 C O § 389 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. ASN (RDA) ACAT Listing December 2000 (continued) | DASNl PEO | PM | LEAD | M/S 0 | M/S I 1 M/S lt|LR IP ijLRIP H M/S~i AN |a CAT)s HORT T IT L f LONG TITLE [01163 IVT TDN TACTICAL DATA NETW ORK EXPD (MARCOR C4ISR (NAVY 94/07 {95/04 95/04 N A |n /a [98/04 i • TACTICAL ELECTRONIC i..... j I ” *01146 IVT TERPES RECONN PROCESSING & ‘EXPD MARCOR C 4IS R INAVY i j.... 95/03 ! • _ [97/12 ;............ TESS/NlTES TACTICAL EN VIR O NM EN TALT I i . f “ i 199/12 (01014 IVT (2000 SUPPORT SYSTEM (3) iC4l SPAWAR P M W 185N A V Y (N/A <N/A (N/A sN/A [N/A I ashore TACTICAL HAND HELD ! : i . . . . ... i ... . . Soi189 IVT THHR RADIO (EXPD IMARCOR . C4ISR INAVY j ( i . [ ... : ! ? ■ (01379 IVT TMOD TRAINING MODERNIZATION (EXPD [MARCOR AW T (NAVY [6/97 j |............|....... i i i I r ' TPCS TEAM PORTABLE...................... I i j .... . (01329 IVT UPGRADE COLLECTION SYSTEM EXPD iMARCOR C4ISR NAVY : [89/01 97/03 j ; [99/08 TACTICAL PETROLEUM ...... Eng Supt ; I I ! I (01334 ivr TPLM LABORATORY, Med EXPD MARCOR Equip NAVY ! [ \ (93/08 i TRAY RATION HEATING MAR/NB j ■ 1 I 1 i01027 IVT TRHS SYSTEM (EXPD MARCOR C NAVY [95/05 95/05 iN/A -N/A [95/05 i TRSS TACTICAL REMOTE S E N S O R ' i ; j 1 j 01148 IVT (IMAGER SYSTEM PHASE V (IMAGER) [EXPD MARCOR C4I IS NAVY I 95/03 | j ! I TW IN AGENT TW IN AGENT UNIT MOBILE I I i ? I [01373 IVT UNIT PROGRAM EXPD MARCOR CSLE [navy . S " ■ i r • • i ! (01283 IVT TW S THERMAL W EAPONS SIGHT EXPD MARCOR CBG ARMY 96/04 I i ....... t i USMC PSP USMC POW ER SUPPLY j ....... r (01147 IVT (PS) PROGRAM |EXPD MARCOR NAVY I ? 5 j ; VIRTUAL IMAGING SYS FOR ! . ; .......... i ' v 1 (01370 IVT (VISUAL APP& LANDING »AIR NAVAIR [PMA251 (NAVY N/A (97/06 !00/04 {N/A <04/1Q W APPENDIX O POPULATION OF OPERATIONAL REQUIREMENTS DOCUMENTS (ORDs) Operational Requirements Documents (ORDs) were also canceled with the partial Requirements Generation System cancellation. ORDs document high-level requirements that must be translated into individual systems. The population of 325 ORDs is listed on the following pages. This list includes both classified and unclassified ORDs. ORDs specify the goals and threshold quantities for requirements of individual systems. A complete census consists of 325 Navy ORDs which, given the thousands of Navy systems, is another indicator of potential interoperability problems due to an inability to access information about other systems. Interoperability and information exchange requirements were mandatory in ORDs. Yet, ORDs were not available for each system; no context existed for each system; and all ORDs were not in a central accessible location for all who needed them. 391 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents O R D _ # Title Class Date ACAT 6 0 3 -7 7 -0 2 Advanced Deployable System (ADS) (U) S 25 Oct 02 II 602-61-02 Joint Interface Control Officer (JICO) Support System (JSS) u 24 Oct 02 III 601-76-02 Computer Aided Dead Reckoning Tracer (CADRT) u 11 Oct 02 IVT 600-77-02 Ohio Class Guided Missile Submarine (SSGN) c 23 Sep 02 ID 599-77-02 TB-29A Thin Line Towed Array (TLTA), Revision A S 19 Sep 02 III 597-75-02 Airborne Mine Countermeasures (AMCM) Annex B (Rev 1) to the Multi-Mission Combat Support (HC) Helicopter ORD u 14 Aug 02 IC 596-78-02 Multi-Mission Combat Support (HC) Helicopter u 14 Aug 02 IC 598-75-02 Noninvasive Filler Identification (NFI) System u 11 Aug 02 IVM 595-61-02 Navy Shipboard and Airborne Mark XII IFF System Upgrade Program u 22 Jul 02 IVT 594-78-02 ASW Target MK 30 Mod 2 (U) c 26 Jun 02 IVM 593-61-02 Afloat C4I Local Area Network (LAN) u 21 Apr 02 II 592-78-02 Joint Multi-Mission Vertical Lift Aircraft (JMVX): V-22 Osprey u 16 Mar 02 ID 589-75-02 Rapid Airborne Mine Clearance System (RAMICS) (U) c 1 Mar 02 II 591-77-02 AN/BQQ-10(V) Acoustic Rapid COTS Insertion (A-RCI), Revision A, Change 1 (U) s 1 Mar 02 III 590-96-02 MORIAH (U) S/N 1 Mar 02 IVT 588-76-02 Cooperative Engagement Capability (CEC) (U) s 31 Jan 02 ID 587-61-01 High Frequency Data System (HFDS) u 21 Dec 01 IVT 586-78-01 Advanced Targeting and Designating Forward Looking Infrared System (ATFLIR) (U) s 26 Nov 01 II 585-61-01 Joint Satellite Communication (SATCOM) Mobile User Objective System (MUOS) u 1 Oct 01 ID 582-42-01 Auxiliary Cargo and Ammunition Ship (T-AKE) u 27 Jul 01 I 580-06-01 Single Multifunctional Information Distribution System Low Volume Terminal (MIDS-LVT) u 20 Jun 01 ID 581-78-01 Consolidated Automated Support System (CASS) u 15 Jun 01 II 579-77-01 AN/BSY-1 High Frequency Upgrade, Revision A (U) s 31 May 01 III 578-75-01 Underwater Acoustic Firing System (AFS) u 31 May 01 IVT 392 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# Title Class Date ACAT JROCM 089- 01 Global Broadcast Service (GBS) U 25 May 01 ID 577-06-01 Improved MK XII Cooperative Identification Capability (U) S/N 27 Apr 01 II 576-77-01 Submarine High Data Rate (SubHDR) Antenna, Revision 1 U . 27 Apr 01 III 575-75-01 EX-8 M o d 0 Marine Mammal System (U) c 23 Apr 01 IVT 574-75-01 Lightweight, Disposable Disrupter (LIDD) u 20 Mar 01 IVT JROCM 035 01 Joint Tactical Radio System (JTRS), Revision 2.2 u 20 Feb 01 ID 573-76-01 Land Attack Missile Weapon System (U) s 25 Jan 01 III 572-75-01 Organic Airborne and Surface Influence Sweep (OASIS) (U) S/N 10 Jan 01 II 571-78-01 EP-3E Joint Airborne SIGINT Architecture (JASA) Modernization (JMOD) (U) S 9 Jan 01 III 570-77-00 Submarine Electronic Warfare Support (ES) System (AN/BLQ-10) (U) S 20 Dec 00 III 569-76-00 Joint Chemical Agent Detector (JCAD), (JTD J2- C001-III) MS III Final U 12 Dec 00 III 568-78-00 F/A-18E/F Active Electronically Scanned Array (AESA) (U) S 13 Nov 00 I 566-88-00 AN/ARC-210(V) Electronic Protection (EP) Radio Set u 25 Sep 00 III 567-06-00 DoD Teleport u 22 Sep 00 III 565-88-00 Advanced Tactical Airborne Reconnaissance System (ATARS) u 1 Aug 00 II 564-86-00 Smart Ship CG 47 Class Integrated Ship C ontrols (ISC) u 17 Jul 00 IVT 563-06-00 Sensitive Compartmented Information (SCI) Annex to ORD for Automated Digital Network System (ADNS) u 12 Ju n 00 III 562-06-00 Enhanced GPS User Equipment (UE) (U) S/N 7 Jun 00 III 560-88-00 Integrated Mechanical Diagnostics (IMD) System U 30 May 00 IVT 561-88-00 Tactical Aircraft Moving Map Capability (TAMMAC) u 24 May 00 III 559-85-00 Airborne Mine Countermeasures (AMCM) Helicopter (Annex B to Fleet Combat Support (HC) Helicopter ORD) u 21 May 00 IC 558-88-00 Standoff Land Attack Missile - Expanded Response (SLAM-ER) (U) S/N 17 May 00 III 556-86-00 Joint Service Lightweight Integrated Suit Technology (JSLIST) u 11 May 00 III 557-88-00 Low Probability of Intercept (LPI) Precision Radar Altimeter u 11 May 00 IVT 393 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# | Title Class Date ACAT AFSPC 004- 99 Wideband Gapfiller Satellite C om m unications System U 3 May 00 ID 555-88-00 Ground Proximity Warning System (GPWS) U 1 May 00 IVT 553-87-00 Submarine High Data Rate (SubHDR) Antenna u 13 Apr 00 III 552-88-00 Future Aircraft Carrier (CVNX) (U) S/N 12 Apr 00 ) 554-88-00 Joint Strike Fighter (JSF) (U) S 11 Apr 00 ID 551-85-00 AN/AQS-20/X Sonar Mine Detecting Set, Revision 1 (U) C 3 Apr 00 II 550-88-00 F/A-18E/F (U) S 22 Mar 00 IC 549-88-00 Advanced Mission Computer and Displays (AMC&D), Revision 2 u 21 Mar 00 II 548-85-00 Small Caliber Dearmer (SCO) u 24 Feb 00 III 547-86-00 Computer Aided Dead Reckoning Tracer (CADRT) u 15 Feb 00 IVT 546-86-00 Tomahawk Weapon System (TWS) Baseline IV, Revision 2 (U) s 10 Feb 00 IC 545-88-00 APR-39A(V)2 Radar Signal Detection Set (RSDS) (U) s 9 Feb 00 III 544-88-00 Onboard Jammers (OBJ) (U) s 27 Jan 00 III 543-85-00 Closed Loop Degaussing System for Mine Countermeasures Ships (CLDG), Revision 1 (U) c 5 Jan 00 IVT 542-86-99 Joint Warning and Reporting Network (JWARN), (JTD J1-001-III) MSIII Revision u 29 Dec 99 III 540-87-99 Advanced Deployable System (ADS) (U) s 16 Dec 99 II 539-06-99 Automated Digital Network System (ADNS) u 14 Dec 99 III 538-85-99 Main Charge Disrupter (MCD) u 14 Dec 99 IVM 541-04-99 Auxiliary Dry Cargo Carrier (T-ADC(X)) u 10 Dec 99 I 537-06-99 Shipboard Information Warfare/Cryptologic Systems (SIWCS) (U) s 9 Dec 99 III 536-85-99 Standoff Disrupter (SD) (U) c 6 Dec 99 A AP 535-88-99 Joint Protective Aircrew Ensemble (JPACE), J3- 004-H u 29 Nov 99 * 534-87-99 AN/BQQ-1Q(V) Acoustic Rapid COTS Insertion (A-RCI) (U) s 24 Nov 99 III 533-96-99 Tactical Environmental Support System (TESS) u 23 Nov 99 IVT 532-87-91 OE-538/BRC Antenna Group u 17 Nov 99 III 531-91-99 Subsonic Cruise M issile Target (T21) u 15 Nov 99 IV 530-85-99 Remote Minehunting System (RMS), Revision 1 (U) c 5 Oct 99 II 528-86-99 Joint Biological Standoff Detection System (JBSDS) u 1 Sep 99 III 529-86-99 Land Attack Missile (LAM) (U) S | 31 Aug 99 III 394 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD # Title Class Date ACAT 527-86-99 Joint Service General Purpose Mask (JSGPM) U 19 Aug 99 III 526-86-99 Rolling Airframe Missile (RAM) Block I Upgrade, Change 1 (U) S 8 Jul 99 II 525-88-99 Air Deployable Active Receiver (ADAR) Sonobuoy(U) s 8 Jul 99 III 524-44-99 Joint Transportable Collective Protection System (JTCOPS) U 8 Jul 99 III 523-86-99 Naval Fire Control System (NFCS) u 1 Jul 99 III 522-88-99 Shared Reconnaissance Pod (SHARP) u 21 Jun 99 III 521-88-99 Airborne Expendables (U) s 28 May 99 III 520-86-99 Advanced Tomahawk Weapon Control System (ATWCS), Revision A (U) s 13 May 99 III 518-88-99 Air Surveillance & Precision Approach Radar Control System (ASPARCS) u 12 May 99 III 519-91-99 Joint Modeling and Simulation System (JMASS) u 5 May 99 “ 517-85-99 Remote Ordnance Neutralization System (RONS) u 26 Apr 99 IVM 515-88-99 Joint Service Sensitive Equipment Decontamination (JSSED) u 13 Apr 99 “ 516-88-99 Joint Protective Aircrew Ensemble (JPACE) u 13 Apr 99 III 514-86-99 Area Air Defense Commander (AADC) Capability, Version F u 29 Mar 99 III 513-88-99 Aircrew Laser Eye Protection (ALEP) u 15 Mar 99 IV 512-96-99 MORIAH (U) s 22 Feb 99 III 511-85-99 EX 8 Mod 0 Marine Mammal System (U) c 18 Feb 99 IVT 510-06-99 Global Command and Control System - Maritime (GCCS-M) u 12 Feb 99 II 509-85-99 Vertical Takeoff and Landing Tactical Unmanned Aerial Vehicle (VTUAV) u 13 Jan 99 II 508-88-99 Aircrew/Ejection Seat Locating Radio/Beacon u 11 Jan 99 IVM 507-88-99 Improved Fresnel Lens Optical Landing System (IFLOLS) u 4 Jan 99 IVT 506-87-98 TB-290 Thin Line Towed Array (TLTA) (U) s 7 Dec 98 III 505-86-98 Supersonic Sea Skimming Target (SSST) u 27 Oct 98 II 504-86-98 Navy Aerial Targets u 27 Oct 98 III 502-86-98 Active Electronic Decoy (AED) and Decoy Launching System (DLS) (U) s 15 Oct 98 III 503-88-98 Joint Strike Fighter (JSF) [JIRD III] (U) s 11 Oct 98 ID 501-88-98 Advanced Mission Computer and Display (AMC&D) u 9 Oct 98 II 500-88-98 AAR-47 Missile Warning Set (U) s 8 Oct 98 III 499-88-98 Joint Service Aircrew Mask (JSAM) u 24 Aug 98 III Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD # Title Class Date | ACAT 498-88-98 E-6B Mercury-TACAMO/Airbome Command Post, Revision 2 (U) S 14 Aug 98 II 496-87-98 Countermeasures Detection and Control Set AN/WLY-1 (U) S 31 Jul 98 III 497-06-98 Video Information Exchange System (VIXS) u 31 Jul 98 IVM 495-85-98 Airborne Laser Mine Detection System (ALMDS) (U) c 21 Jul 98 III 494-88-98 integrated Defensive Electronic Countermeasures (IDECM) Radio Frequency Countermeasures (RFCM) & IDECM Suite (U) s 1 Jul 98 II 493-06-98 Navy Mark XII IFF Shipboard System Upgrade Program u 1 Jul 98 IVT 492-86-98 Naval Theater Ballistic Missile Defense (TBMD) System (U) s 25 Jun 98 I 491-85-98 Airborne Mine Neutralization System (AMNS) (U) c 23 Jun 98 III 490-85-98 Underwater Acoustic Firing System (AFS) u 12 Jun 98 IVT 489-87-98 Submarine Rescue Diving & Recompression System (SRDRS) u 3 Jun 98 IVT 488-88-98 Long Range Line Up System (LRLS) u 19 May 98 IVM 487-88-98 Shallow Water Undersea Warfare Training Range (SWUWTR) Program u 19 May 98 IVT 486-88-98 F/A-18 Digital Communications System (DCS) u 15 May 98 IVT 485-86-98 Launched Expendable Acoustic Device (LEAD) (U ) s 5 May 98 IVT 484-88-98 Fleet Combat Support (HC) Helicopter u 28 Apr 98 ID 483-06-98 Joint (UHF) MILSATCOM Network Integrated (JMINI) Control System u 27 Mar 98 IVT 482-87-98 Torpedo MK-48 Mod 6 Common Broadband Advanced Sonar System (CBASS) Upgrade (U) s 20 Mar 98 III 297(1)-05- 97 Air Deployable Active Receiver (ADAR), Revision 1 (U) s 29 Dec 97 III 481-87-97 Electronic Support (ES) System (U) s 5 Dec 97 III 469(1 )-04- 97 Barracks Craft - Small (APL(S)), Revision 1 u 5 Dec 97 IV 480-88-97 Navy Combat Edge (NCE) u 4 Dec 97 IVT 479-86-97 Land Attack Destroyer (DD-21) (U) s 3 Nov 97 I 478-06-97 Integrated Broadcast Service (IBS) u 31 Oct 97 III 477-87-97 Mobile Torpedo Countermeasures (U) s 28 Oct 97 IVT 476-01-97 Navy Standard Integrated Personnel System (NSIPS) u 24 Oct 97 lA M 475-88-97 AGM-88 HARM Block VI Upgrade (Tri-National S I 23 Sep 97 III 396 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# Title Class Date ACAT 473-88-97 Remote Landing Site Tower (RLST) U 25 Jul 97 - 474-88-97 EA-6B Prowler Aircraft System s (U) s 17 Jul 97 II 472-86-97 Mational Missile Defense (U) s 3 Jul 97 - 471-86-97 Joint Chemical Agent Detector (JCAD) U 29 Jun 97 Ill 470-86-97 Nuclear, Biological, and Chemical (NBC) Joint u 29 Jun 97 III 468-88-97 Marine C orps Expeditionary Arresting Gear System (MCEAGS) u 16 Jun 97 IV 464-88-97 Expeditionary and Night Vision Device Compatible Lighting and Landing Aid u 5 Jun 97 IV 467-86-97 Joint Service Lightweight Standoff Chemical Agent Detector (JSLSCAD) u 27 May 97 III 466-87-97 Tomahawk Land Attack Missile - Nuclear (TLAM- c 23 May 97 III 465-87-97 Doppler Sonar Velocity Log (DSVL) (U) c 23 May 97 IVT 463-6-97 Electronic Key Management System (EKMS) u 15 May 97 IV 354(1)-86- 97 Tomahawk Weapon System (TWS) Baseline IV, Revision 1 (U) s 6 May 97 IC 462-86-97 Advanced Integrated Electronic Warfare System (AIEWS) (U) s 24 Apr 97 II 461-6-97 Ocean Surveillance Information System (OSIS) Baseline Upgrade (OBU)/OSIS Evolutionary Development (OED) u 24 Apr 97 III 460-87-97 Submarine Antenna Distribution System (SADS) u 14 Apr 97 IV 459-88-97 Aviation Data Management & Control System (ADMACS) u 10 Apr 97 IVT 458-88-97 Shallow Water Undersea Warfare Training Range (SWUWTR) Program u 10 Apr 97 IVT JROCM 042 97 Global Broadcast System (GBS) u 7 Apr 97 “ 300(1 )-88- 97 F/A-18E/F, Revision 1 (U) s 1 Apr 97 ID 457-87-97 AN/BSY-1 High Frequency Upgrade (U) s 31 Mar 97 III 389(1 )-88- 97 E-6B Mercury-TACAMO/Airbome Command Post, Revision 1 (U) s 20 Mar 97 III 456-01-97 Navy Standard Integrated Personnel System (NSIPS) u 28 Feb 97 IAM 334(1 )-88- 97 MK 30 Mod 2 ASW Target, Revision 1 (U) c 25 Feb 97 IV 455-88-97 Advanced Medium-Range Air-to-Air Missile s 15 Jan 97 IC 451(1)-86- 97 Naval Theater Ballistic Missile Defense (TBMD), Revision 1 (U) s 6 Jan 97 I 454-85-96 Main Charge Disrupter (MCD) u 19 Dec 96 IV 311 (2)-88- 96 Joint Primary Aircraft Training System (JPATS), Revision 2 [AETC 005-88-II, Revision 1] u 9 Dec 96 IC 397 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# j Title Class Date ACAT 415(1)-88- 96 Helmet Mounted Cueing System (HMCS), Revision 1 [CAF-USN 308-93-lll-A] U 9 Dec 96 lll/IV USN- CAF(002) AIM-9X (U) S 12 Nov 96 ID 453-86-96 AN/SPY-1 Radar Upgrade (AN/SPY-1D(V)) (U) s 24 Oct 96 II 452-87-96 Submarine Baseband Switch (BBS) u 24 Oct 96 IV 450-86-96 Advanced Combat Direction System (ACDS) Block 1 (U) c 18 Oct 96 II 449-88-96 Shallow Water ASW Localization and Attack System (SWALAS) (U) c 27 Sep 96 III 438(1 )-04- 96 Enhanced Maritime Prepositioning Force (MPF(E)), Revision 1 u 25 Sep 96 III 448-06-96 Joint Tactical Terminal (JTT) and Common Integrated Broadcast Service Modules (CIBS-M) u 24 Sep 96 III 419(1)-88- 96 Long Range Line-Up System (LRLS), Revision 1 u 17 Sep 96 IVT 447-85-96 Remote Ordnance Neutralization System (RONS) u 12 Sep 96 IV 361(1)-86- 96 Shipboard Advanced Radar Target Identification System (SARTIS) AN/UPX-34(V) Radar Track Discriminator System (RTDS) for Aegis Ships, Revision 1 (U) S/N 10 Sep 96 III 446-88-96 F/A-18 Positive Identification System (PIDS) (U) S 23 Aug 96 III 445-86-96 Joint Biological Point Detection System (JBPDS) u 23 Aug 96 III 444-87-96 Long-Term Mine Reconnaissance System (LMRS) u 22 Aug 96 II 443-06-96 Shipboard Digital Wideband Transmission System (DWTS) u 15 Aug 96 IVT 367(1)-85- 96 Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ-94), Revision 1 u 24 Jul 96 IVM 308(1 )-85- 96 LPD-17 Amphibious Transport Dock Ship, Revision 3 (U) s 28 May 96 ID 441-096-96 Meteorological Mobile Facility Replacement (METMF(R)) u 23 May 96 IV 442-87-96 Combat Control System MK2 Program DO Block 1C (U) c 23 May 96 IVT 440-85-96 Lightweight, Disposable Disrupter (LIDD) u 30 Apr 96 IV 439-06-96 TACINTEL II+ Program (U) s 15 Apr 96 III 437-88-96 F/A-18 Targeting & Designating Forward Looking Infrared System (TFLIR) (U) s 8 Apr 96 II 398 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORDJf Title Class Date | ACAT 436-88-96 Joint Air to Surface Standoff M issile (JASSM ) (U) [CAF 303-95-I] S/N 3 Apr 96 I 435-06-96 Submarine LV/VLF Versamodule Eurocard Receiver (SLVR) U 30 Mar 96 III 434-88-96 Tactical Aircraft Moving Map Capability (TAMMAC) U 30 Mar 96 III 433-88-96 Modified Miniature Receiver Terminal (MMRT) VLF/LF Receiver for E-4B National Airborne Operations Center (NOAC) and E-6B Mercury [CAF-USN 330-92-ll-B] U 25 Mar 96 IV 333(1 )-06- 96 Electronic Protection (EP) Combination Radio AN/ARC-210(V), Revision 1 U 24 Mar 96 III 432-85-96 Remote Minehunting System (RMS) Program (U) C 16 Mar 96 III 431-096-96 Supplemental Weather Radar U 12 Mar 96 IVM 430-06-96 Hierarchical Yet Dynamically Reprogrammable Architecture (HYDRA) Communications System U 2 Mar 96 III 429-85-96 Underwater Acoustic Firing System (AFS) U 2 Mar 96 IV 318(1)-Q6- 96 Lightweight SHF Satellite Communications Terminals, Revision 1 (U) S 1 Mar 96 III 428-06-96 Commercial Satellite (COMMERSAT) Communication U 27 Feb 96 IV 427-88-96 Reconnaissance Capable F/A-18 (F/A-18(RC)) (U ) C 19 Feb 96 III 426-88-96 ES-3 Critical Avionics Upgrade (CAU) u 1 Feb 96 IVM 424-87-95 Countermeasures Detection and Control Set (AN/WLY-1) (U) s 22 Dec 95 III 381(1)-88- 95 Navy Combat Edge (NCE), Revision 1 u 22 Dec 95 IVT 425-06-95 Ship Automated Communications Control System (SACCS) u 22 Dec 95 IVT 322(1 )-06- 95 High Frequency Radio Group (HFRG), Revision 1 u 18 Dec 95 III 423-88-95 Common Missile Warning System (CMWS) for U.S. Army, Air Force, Navy, Marine Corps Aircraft and Electronic Attack (EA) Pods (U) s 29 Nov 95 IC 351(1)-06- 95 Message Processing Afloat, Revision 1 u 27 Nov 95 IVT 422-86-95 Sparrow Missile (AIM/RIM-7R) (U) s 18 Nov 95 II 421-86-95 Extended Range Guided Munition (ERGM) u 8 Nov 95 II 420-86-95 5 " MK 45 Gun Mount Modification (MK 45 MOD) u 8 Nov 95 III 399 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD # Title Class | Date ACAT 337(1 )-06- 95 Multifunctional Information Distribution System Low Volume Terminal (MIDS-LVT), Revision 1 U 1 Nov 95 ID 419-88-95 Long Range Line-Up System (LRLS) U 31 Oct 95 IVT 418-06-95 Navy Tactical Command System Afloat (NTCS- A) u 10 Oct 95 II 416-88-95 Joint Service Electronic Combat Systems Tester (JSECST) [CAF-NASC 325-92-l/ll-A] u 28 Sep 95 III 417-06-95 Maritime Cellular Information Exchange System (MCIXS) u 25 Sep 95 IV M 331(1)-88- 95 Joint Direct Attack Munitions (JDAM), Revision 1 [CAF 401 -91-II-A] u 11 Sep 95 I 415-88-95 Helmet Mounted Cueing System (HMCS) u 11 Sep 95 lll/IV 414-86-95 Infrared Search & Track (IRST) Sensor (U) S/N 8 Sep 95 III 344(1 )-88- 95 H-53E Service Life Extension Program (SLEP), Revision 1 U 29 Aug 95 III 413-85-95 Mission Package Three (MP-3) for the AN/SLQ- 48 Mine Neutralization System (U) C 27 Aug 95 III 412-85-95 QUICKSTRIKE Mines (U) C 22 Aug 95 III 411-06-95 Navy Shipboard Single Channel Ground & Airborne Radio System (SINCGARS) U 15 Aug 95 IVT 410-86-95 Thermal Imaging Sensor System (TISS) (U) c 7 Aug 95 IV 409-86-95 Air and Surface Launched ASW Torpedo Lightweight Hybrid Torpedo (LHT) (U) S/N 2 Aug 95 III 408-88-95 S-3 Critical Avionics Upgrade (CAU) Program U 13 Jul 95 IVT 407-06-95 AN/UYQ-70(V) Advanced Display System U 30 Jun 95 IVT 342(1 )-87- 95 New Attack Submarine (New SSN), Revision 1 (U ) c 29 Jun 95 ID 406-88-95 F-14 Forward Looking Infrared/Laser Targeting System (FLIR/LTS) (U) s 14 Jun 95 III 405-86-95 Lightweight Integrated Nuclear, Biological and Chemical (NBC) Protective Garment u 9 Jun 95 III 404-88-95 CINCLANTFLT Executive Transport Helicopter Upgrade u 6 Jun 95 IVM 403-06-95 Operations Support System (OSS) u 5 Jun 95 III 402-88-95 F/A-18 Radar Upgrade (RUG) (U) S/N/ w 31 May 95 II 401-88-95 Embedded GPS INS (EGI) u 25 May 95 III 400-88-95 Tactical Training Ranges Program (TTRP) u 25 May 95 IVM 399-88-95 Consolidated Automated Support System (CASS) u 11 May 95 II 398-86-95 Ship Self Defense System (SSDS) (U) S/N 17 Apr 95 II 397-85-95 Advanced Radiographic System (ARS) u 14 Apr 95 IVM 4 0 0 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# Title Class | Date ACAT 338(1 )-86- 95 AN/SLQ-20 Upgrade System, Revision 1 (U) S/N 6 Apr 95 III 396-86-95 Advanced Infrared (IR Expendables) (U) [Multi- Service, MS 323-88-l/ll-A] S/N 4 Apr 95 III 395-88-95 Low Probability of Intercept (LPI) Precision Radar A ltim eter U 30 Mar 95 IVT 394-86-95 Multi-Function Fuze (MFF) U 25 Mar 95 IVT 393-88-95 S-3B Aircraft Communications Improvement Program (CIP) u 23 Mar 95 IVT JROCM 036 95 Unmanned Aerial Vehicle - Short Range (UAV- SR) (U) C 9 Mar 95 ID 392-04-95 Explosive Ordnance Disposal (EOD) Personnel Dosimeter u 9 Mar 95 IVM 384-88-94 Joint Multi-Mission Vertical Lift Aircraft (JMVX) u 4 Mar 95 ID 391-88-95 Integrated Defensive Electronic Countermeasures (IDECM) Radio Frequency Countermeasures (RFCM) and Integration (U) s 3 Mar 95 II 390-86-95 Advanced Combat Direction System (ACDS) Block 0 (U) c 22 Feb 95 II 362(1 )-06- 95 Tactical Automated Mission Planning System (TAMPS), Revision 1 u 2 Feb 95 IVT 389 -88-95 E-6B Mercury-TACAMO/Airbome Command Post (U) s 14 Jan 95 III 388-86-95 Cooperative Engagement Capability (CEC) (U) s 4 Jan 95 IC 301(1)-88- 94 Joint Standoff Weapon (JSOW) System, Revision 1 (U) c 30 Dec 94 ID 387-06-94 Joint Tactical Information Distribution System (JTIDS) (U) c 22 Dec 94 ID 357(1 )-85- 94 Shallow Water Mine Countermeasures (SWMCM) Mine/Obstacle Clearance, Revision 1 (U) c 16 Dec 94 III 386-87-94 AN/BSY-1 Engineering Change Proposal 1000 (U) s 3 Dec 94 III 385-86-94 Evolved Seasparrow Missile (ESSM) Program (U) S/N 28 Nov 94 II 383-88-94 Standoff Land Attack Missile - Expanded Response (SLAM-ER) and SLAM plus (U) S/N 23 Nov 94 ll/lll 382-06-94 UHF Satellite and Line-of-Sight Communications Terminals U 21 Nov 94 III 380-86-94 Ring Laser Gyro Navigation (RLGN) System (U) C 4 Nov 94 IVT 379-87-94 Advanced Deployable System (ADS) (U) S/N 28 Oct 94 If 401 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD # Title Class Date ACAT 378-88-94 Advanced Airborne Expendable Decoy (AAED) (U) S 17 Oct 94 III 377-88-94 Navy H-60 Helicopter Enhanced Weaponization Kit (U) C 17 Oct 94 IV 376-86-94 AN/SPQ-9 Radar Anti-Ship Missile Defense (ASMD) Upgrade Program (U) S/N 11 Oct 94 III 375-87-94 Advanced Submarine Tactical Electronic Support Measures (ESM) Combat System (ASTECS) (U) S 1 Oct 94 III 373-88/6-94 Tactical Support Center (TSC) U 21 Sep 94 III 372-86-94 Improved (Chemical Agent) Point Detection System (IPDS) U 21 Sep 94 IVT 374-88-94 Improved Fresnel Lens Optical Landing System (IFLOLS) Portion of Improved Carrier Optical Landing System (ICOLS) U 21 Sep 94 IVT 371-88-94 E-2C Hawkeye Aircraft Mission Computer Upgrade (U) S 20 Sep 94 II 370-85-94 Forward Area Combined Degaussing and Acoustic Range (FACDAR) (U) c 14 Sep 94 IVM 369-096-94 Tactical Environmental Support System (TESS) U 11 Sep 94 IVT 315(t)-88- 94 VH-60N Executive Helicopter Mid-Life Upgrade, Revision 1 (U) S 5 Aug 94 III 367 -85-94 Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ-94) U 4 Aug 94 IVM 317(1)-88- 94 Joint Tactical Combat Training System (JTCTS) U 4 Aug 94 IVT 366-86-94 Standard Missile-2 Block IV (SM-2 BLKIV) (U) S/N 28 Jul 94 ID 365-87-94 Photonics Mast (U) C 22 Jul 94 III 368-85-94 Closed Loop Degaussing System for Mine Countermeasures Ships (CLDG) (U) c 22 Jul 94 IVT 363-86-94 Advanced Tomahawk Weapon Control System (ATWCS) (U) s 21 Jul 94 III 364-88-94 Improved Tactical Air Launched Decoy (ITALD) (U) c 21 Jul 94 III 361 -86-94 Shipboard Advanced Radar Target Identification System (SARTIS) AN/UPX-34(V) Radar Track Discriminator System (RTDS) for Aegis Ships (U) S/N 13 Jun 94 III 319(1)-88- 94 E-6A Avionics Block Upgrade, Revision 1 (U) S 6 Jun 94 III 360-88-94 Improved Radar Warning Receiver (U) S 27 May 94 III 402 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# Title Class Date ACAT 303(1 )-86- 94 Battle Force Tactical Trainer (BFTT) Improvement Program, Revision 1 U 21 May 94 IVM 336(1 )-86- 94 DDG 51 Flight 1 1 A, Revision 1 (U) s 25 Apr 94 ID 359-87-94 Submarine Offboard Mine Search System (SOMSS) (U) S/N 19 Apr 94 II 358-86-94 Launch Subsystems for Expendable Acoustic Devices (LEAD) (U) S 15 Apr 94 IVT 356-85-94 Shallow Water Mine Countermeasures (SWMCM) Marking (U) C 11 Apr 94 III 355-88-94 P-3 Anti-Surface Warfare Improvement Program (P-3C AIP) (U) C 30 Mar 94 II 354 -86-94 Tomahawk Weapon System (TWS) Baseline IV (U) S 28 Mar 94 IC 353-86-94 US/UK Surface Ship Torpedo Defense (SSTD) Joint Project (U) S 28 Mar 94 IC 352-88-94 C-2A(R) Service Life Extension Program (SLEP) U 11 Mar 94 IVT 320(1 )-85- 94 Near Term Mine Countermeasures Support Ship (MCS), Revision 1 (U) C 7 Mar 94 III 350-88-94 F-14 Positive Identification (U) S/N 24 Feb 94 III 349-86-94 Improved M9 9MM Pistol U 9 Feb 94 IV 323(1 )-86- 94 LAMPS MK III Forward Looking Infrared (FUR) Contingency Kits, Revision 1 (U) C 12 Jan 94 III 348-86-94 Rolling Airframe Missile (RAM) Block I Upgrade (U) S 10 Jan 94 II 311(1)-88- 93 Joint Primary Aircraft Training System (JPATS), Revision 1 [AETC 005-88-II] U 29 Dec 93 IC 347-86-93 Air and Surface Launched ASW Torpedo (MK- 50) (U) S/N 29 Dec 93 ID 346-06-93 Shipboard Cryptologic Systems (U) C 22 Nov 93 III 310-87-93 Torpedo Propulsion Upgrade (Revision A) (U) S 5 Nov 93 III 343-87-93 Acoustic Device, Countermeasure (ADC) EX-11 (U) S 27 Sep 93 III USN- CAF(001) AIM-9X (U) S/N/ W 1 Sep 93 I 341-88-93 Remote Landing Site Tower (RLST) u 1 Sep 93 IVT 340-88-93 P-3C Sustained Readiness Program (SRP) u 31 Jul 93 II 339-091-93 Non-Cooperative Airborne Vector Scoring (NAVS) System u 27 Jun 93 IVM 335-06-93 Tactical Related Applications (TRAP) Broadcast (U) S/N 6 Jun 93 III 334 -88-93 MK 30 Mod 2 ASW Training Target (U) c 10 May 93 IVM 403 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Operational Requirements Documents (continued) ORD_# Title Class Date ACAT 332-091-93 Vandal Extended Extended Range (EER) U 15 Apr 93 IVM 331 -88-93 Joint Direct Attack M unitions (JDAM) (U) c 7 Apr 93 I 330-06-93 High Frequency Data System (HFDS) u 1 Apr 93 IVT 329-09N/B- 93 Shipboard Physical Security u 4 Mar 93 IVT 328-88-93 Air Extended Echo Ranging (EER) System (U) S/N 18 Jan 93 III 327-86-93 Shipboard Automatic Liquid Agent Detector (SALAD) u 14 Jan 93 IVT 326-86-93 Vertical Launch ASROC (VLA) (U) c 8 Jan 93 II 324-86-92 AEGIS Near Term Tactical Ballistic Missile Defense (U) s 30 Dec 92 II 325-86-92 Standard Missile-2 (SM-2) Block IVA (U) s 30 Dec 92 II 321-88-92 AX Joint Attack Fighter (U) s 3 Dec 92 ID 308 -03-92 LX Amphibious Assault Ship, Revision 2 (U) s 2 Sep 92 ID 316-05-92 VH-3D Executive Helicopter Survivability Upgrade (U) s 21 Aug 92 III 314-03-92 LAMPS III Block II Upgrade (U) S/N 3 Aug 92 III 312-05-92 USN/USMC Long Range Medium Airlift Aircraft U 20 Jul 92 II 307-05-92 Advanced Rocket System (ARS) U 25 Jun 92 III 313A-04-92 Strategic Sealift COM-20 u 15 Jun 92 IC 313-04-92 Strategic Sealift CSP/S-24 u 15 Jun 92 IC 309-094-92 Slow Walker Reporting System (SWRS) (U) s 12 Jun 92 III 302-03-92 AN/AQS-20 Sonar, Mine Detecting Set (U) S/N 21 May 92 III 298-05-92 Multi-Option Rail Launcher U 21 May 92 IV 306-094-92 Precision Lightweight GPS Receiver (PLGR) U 21 May 92 IV 304-03-92 Single Ship Deep Sweep (SSDS) AN/SLQ-53 (U) C 11 May 92 IV 297 -05-92 Air Deployable Active Receiver (ADAR) (U) s 5 Mar 92 III 299-03-92 Stabilized Weapons Platform System (SWPS) u 31 Jan 92 III 305-05-92 Acoustic Intercept System (AIS) (U) S/N 1 Jan 92 III 300 -05-92 F/A-18E/F (U) S/N/ W 19 Dec 91 ID 295-05-92 Airborne Low Frequency Sonar (ALFS) (U) S/N 16 Dec 91 II 224-05-89 AV-8B Radar u 5 Aug 88 III 243-03-92 Advanced Minor Caliber Gun System (AMCGS) u III 404 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX P POPULATION OF UNCLASSIFIED OPERATIONAL REQUIREMENTS DOCUMENTS (ORDs) The Navy has a population of 158 unclassified Operational Requirements Documents (ORDs) as listed on the following pages. Interoperability among systems developed from these ORDs is difficult despite the interoperability requirement. Only a few were developed, because the requirement is relatively new. ^ 405 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. FdP llO m O N OF UNCLASSIFIED'1 NAVY '^pERja^iOfiAE" DOCUMENTS (ORDs) NO. ORD TITLE DATE 158. Joint Tactical Radio System (JTRS) 2001 157. Auxiliary Cargo and Ammunition Ship (T-AKE) 2001 156. Consolidated Automated Support System (CASS) 2001 155. Single Multifunctional Information Distribution System Low Volume Terminal (MIDS-LVT) 2001 154. EX 12 MOD 0 Acoustic Firing System (AFS) 2001 153. Submarine High Data Rate (SubHDR) Antenna, Revision 1 2001 152. Lightweight, Disposable Disrupter (LIDD) 2001 151. 2000 150. Joint Chemical Agent Detector (JCAD), (JTD J2-C001-III) MS III Final 2000 149. DOD Teleport 2000 148. AN/ARC-210(V) Electronic Protection (EP) Radio Set 2000 147. Advanced Tactical Airborne Reconnaissance System (ATARS) 2000 146. Smart Ship CG 47 Class Integrated Ship Controls (ISC) 2000 145. Tactical Aircraft Moving Map Capability (TAMMAC) 2000 144. Integrated Mechanical Diagnostics (IMD) System 2000 143. Airborne Mine Countermeasures (AMCM) Helicopter (Annex B to Fleet Combat Support (HC) Helicopter 2000 142. Low Probability of Intercept (LPI) Precision Radar Altimeter 2000 141. Joint Service Lightweight Integrated Suit Technology (JSLIST) 2000 140. Ground Proximity Warning System 2000 139. Submarine High Data Rate (SubHDR) Antenna 2000 138. Advanced Mission Computer and Displays (AMC&D), Revision 2 2000 137. Small Caliber Dearmer (SCD) 2000 136. Computer Aided Dead Reckoning Tracer (CADRT) 2000 135. Joint Warning and Reporting Network (JWARN), (JTD J1-001-III) MSIII Revision 99 134. Auxiliary Dry Cargo Carrier (T-ADC(X)) 99 133. Automated Digital Network System (ADNS) 99 132. Main Charge Disrupter (MCD) 99 131. Joint Protective Aircrew Ensemble (JPACE), J3-004-II 99 130. Tactical Environmental Support System (TESS) 99 129. Subsonic Cruise Missile Target (T21) 99 128. Joint Biological Standoff Detection 99 127. Joint Service General Purpose Mask (JSGPM) 99 126. Joint Transportable Collective Protection System (JTCOPS) 99 125. Naval Fire Control System (NFCS) 99 124. Shared Reconnaissance Pod (SHARP) 99 123. Joint Modeling and Simulatin System (JMASS) 99 122. Air Surveillance & Precision Approach Radar Control System (ASPARCS) 99 121. Remote Ordnance Neutralization System (RONS) 99 406 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Unclassified Operational Requirements Documents (ORDs) (continued) 120. Joint Protective Aircrew Ensemble (JPACE) 99 119. Joint Service Sensitive Equipment Decontamination (JSSED) 99 118. Area Air Defense Commander (AADC) Capability, Version F 99 117. Aircrew Laser Eye Protection (ALEP) 99 116. Global Command and Control System - Maritime (GCCS-M) 99 115. Tactical Unmanned Aerial Vehicle (VTUAV) 99 114. Vertical Takeoff and Landing 99 113. Aircrew/Ejection Seat Locating Radio/Beacon 99 112. Improved Fresnel Lens Optical Landing System (IFLOLS) 99 111. Wideband Gapfiller Satellite Communications System 99 110. Supersonic Sea Skimming Target (SSST) 98 109. Navy Aerial Targets 98 108. Advanced Mission Computer and Display (AMC&D) 98 107. Joint Service Aircrew Mask (JSAM) 98 106. Video Informatin Exchange System (VIXS) 98 105. Navy Mark XII IFF Shipboard System Upgrade Program 98 104. Underwater Acoustic Firing System (AFS) 98 103. Submarine Rescue Diving & Recompression System (SRDRS) 98 102. Long Range Line Up System LRLS) 98 101. Shallow Water Undersea Warfare Trainning Range (SWUWTR) Program 98 100. F/A-18 Digital Communications System 98 99. Fleet Combat Support (HC) Helicopter 98 98. Joint (UHF) MILSATCOM Network Integrated (JMINI) Control System 98 97. Navy Combat Edge (NCE) 97 96. Integrated Broadcast Service (IBS) 97 95. Navy Standard Integrated Personnel System (NSIPS) 97 94. Remote Landing Site Tower (RLST) 97 93. Joint Chemical Agent Detector (JCAD) 97 92. Nuclear, Biological, and Chemical (NBC) Joint Warning and Reporting Network (JWARN) 97 91. Barracks Craft - Small (APL(S)), Revision 1 97 90. Marine Corps Expeditionary Arresting Gear System (MCEAGS) 97 89. Joint Service Lightweight Standoff Chemical Agent Detector (JSLSCAD) 97 88. Expeditionary and Night Vision Device Compatible Lighting and Landing Aid 97 87. Electronic Key Management System (EKMS) 97 86. Ocean Surveillance Information System (OSIS) Baseline Upgrade (OBU/OSIS Evolutionary Development System (OEDS): 97 85. Submarine Antenna Distributin System (SADS) 97 84. Aviation Data Management & Control System (ADMACS) 97 83. Shallow Undersea Warfare Training Range (SWUWTR) Program 97 82. Navy Standard Integrated Personnel System (NSIPS) 97 81. Global Broadcast Service (GBS) 97 80. Joint Primary Aircraft Training System (JPATS), Revision 2 96 79. Main Charge Disrupter (MCD) 96 78. Submarine Baseband Switch (BBS) 96 407 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Unclassified Operational Requirements Documents (ORDs) (continued) 77. Joint Tactical Terminal (JIT) and Common Integrated Broadcast Service Modules (CIBS-M) 96 75. Joint Biological Point Detection System (JBPDS) 96 75. Remote Ordinance Neutralization System (RONS) 96 74. Long-Term Mine Reconnaissance System (LMRS) 96 73. Shipboard Digital Wideband Transmission System (DWTS) 96 72. Meterological Mobile Facility 96 71. Lightweight, Disposable Disrupter (LIDD) 96 70. Enhanced Maritime Prepositioning Force (MPF(E)), Revision 1 96 69. Submarine LV/VLF Versamodule Eurocard Receiver (SLVR) 96 68. Tactical Aircraft Moving Map Capability 96 67. Modified Miniature Receiver Terminal (MMRT) VLF/LF Receiver for E-4B National Airborne Operations 96 66. Supplemental Weather Radar 96 65. Hierarchical Yet Dynamically Reprogrammable Architecture (HYDRA) 96 64. Underwater Acoustic Firing System (AFS) 96 63. Commercial Satellite (COMMERSAT) Communication 96 62. ES-3 Critical Avionics Upgrade (CAU) 96 61. Long Range Line-Up System (LRLS), Revision 1 96 60. Helmet Mounted Cueing System (HMCS), Revision 1 96 59. Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ- 94) Revision 1 96 58. Electronic Protection (EP) Combination Radio AN/ARC-210(V), Revision 1 96 57. Ship Automated Communictions Control System (SACCS) 95 56. Extended Range Guided Munition (ERGM) 95 55. 5" MK 45 Gun Mount Modification 95 54. Long Range Line-Up System (LRLS) 95 53. Navy Tactical Comand System Afloat (NTCS-A) 95 52. Maritime Cellular Information Exchange System (MCIXS) 95 51. Joint Service Electronic Combat Systems Tester (JSECST) 95 50. Helmet Mounted Cueing System 95 49. Navy Shipboard Single Channel Ground & Airborne Radio System (SINCGARS) 95 48. S-3 Critical Avionics Upgrade (CAU) Program 95 47. AN/UYQ-70(V) Advanced Display System 95 46. Lightweight Integrated Nuclear, Biological and Chemical (NBC) Protective Garment 95 45. CINCLANTFLT Executive Transport Helicopter Upgrade 95 44. Operations Support System (OSS) 95 43. Embedded GPS INS (EGI) 95 42. Tactical Training Ranges Program (TTRP) 95 41. Consolidated Automated Support System (CASS) 95 40. Advancd Radiographic System (ARS) 95 39. Low Probability of Intercept (LPI) Precision Radar Altimeter 95 38. Multi-Function Fuse (MFF) 95 408 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Population of Unclassified Operational Requirements Documents (ORDs) (continued) 37. S-3B Aircraft Communications Improvement Provement (CIP) 95 36. Explosive Ordnance Disposal (EOD) Personnel Dosimeter 95 35. Navy Combat Edge (NCE) Revision 1 95 34. Tactical Automated Mission Planning System (TAMPS), Revision 1 95 33. Message Processing Afloat, Revision 1 95 32. H-53E Service Life Extension Program (SLEP), Revision 1 95 31. Multifunctional Information Distribution System Low Volume Terminal (MIDS- LVT), Revision 1 95 30. Joint Direct Attack Munitions (JDAM), Revision 1 95 29. High Frequency Radio Group (HFRG), Revision 1 95 28. Joint Multi-Mission Vertical Lift Aircraft (JMVX) 94 27. UHF Satellite and Line of Sight Communications Terminals 94 26. Improved Fresnel Lens Optical Landing System (IFLOLS) Portion of Improved Carrier Optical Landing System 94 25. Tactical Support Center 94 24. Improved (Chemical Agent) Point Direction System (1PDS) 94 23. Tactical Environmental Support System (TESS) 94 22. Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ- 94) 94 21. C-2A(R) Service Life Extension Program (SLEP) 94 20. improved M9 9MM Pistol 94 19. Joint Tactical Combat Training System (JTCTS) 94 18. Battle Force Tactical Trainer (BFTT) Improvement Program, Revision 1 94 17. Remote Landing Site Tower (RLST) 93 16. P-3C Sustained Readiness Program (SRP) 93 15. Non-Cooperative Airborne Vector Scoring (NAVS) System 93 14. Vandal Extended Extended Range (EER) 93 13. High Frequency Data System (HFDS) 93 12. Shipboard Physical Security 93 11. Joint Primary Aircraft Training System (JPATS), Revision 1 93 10. Strategic Sealift CQM-2Q 92 9. Strategic Sealift CSP/S-24 92 8. USN/USMC Long Range Medium Airlift Aircraft 92 7. Advanced Rocket System (ARS) 92 6. Precision Lightweight GPS Receiver (PLGR) 92 5. Stabilized Weapons Platform System (SWPS) 92 4. Multi-Option Rail Launcher 92 3. Advanced Minor Caliber Gun System (AMCGS) 92 2. i!3E-5357BRCr^nBinna Group 91 1. TtffaSITRadar 89 409 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX Q TABLE RELATING MNS TO ORDs MNS and ORDs are guiding documents for acquiring and developing computer-based systems. MNS provide high-level needs. ORDs establish measurable requirements that programs use to build systems that satisfy the needs. Interoperability and information exchange requirements are now included in newer ORDs. Without documents that provide standards and guidance for how systems should interoperate, programs are left to their own devices, and these may be conflicting. A mapping of MNS to ORDs and CRDs in the table on the following pages, shows a weak relationship between these guidance documents. Based on the Requirements Generation System, at leased one ORD, representing one system, should be derived from a MNS. Access to classified documents makes them more difficult to work with across organizations, but documents must be interoperable in much the same way as computer-based systems and organizations. Since ORDs are the primary means of documenting requirements by which developers build systems, their access and availability is critical to understanding potential sources of interoperability problems. 410 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs ORD# Title Class Date ACAT Related ORD Related MNS-CRD 603-77-02 Advanced Deployable System (ADS) (U) S 25 Oct 02 II M034-087-93; GIG CRD, CID CRD 602-61-02 Joint Interface Control Officer (JICO) Support System (JSS) U 24 Oct 02 III JROCM 056-01, GIG CRD, CID CRD 601-76-02 Computer Aided Dead Reckoning Tracer (CADRT) u 11 Oct 02 IVT M084-86-97; GIG CRD, CID CRD 600-77-02 Ohio Class Guided Missile Submarine (SSGN) c 23 Sep 02 ID M001-002-91; GIG CRD, CID CRD, DISN CRD, GCSS CRD, CRD01-87- 98 599-77-02 TB-29A Thin Line Towed Array (TLTA), Revision A S 19 Sep 02 III 591-77-02 CID CRD 597-75-02 Airborne Mine Countermeasures (AMCM) Annex B (Rev 1) to the Multi-Mission Combat Support (HC) Helicopter ORD u 14 Aug 02 IC 596-78-02, 495- 85-98, 491-85- 98, 551-85-00, 572-75-01, 589- 75-02 M042-85-93, M047(1)-86- 94, M072-85-96; CID CRD, IDM CRD, GATM Phase II CRD, GIG CRD 596-78-02 Multi-Mission Combat Support (HC) Helicopter u 14 Aug 02 IC 597-75-02, 560- 88-00 M059-88-94; CID CRD, IDM CRD, GATM Phase II CRD 598-75-02 Noninvasive Filler Identification (NFI) System u 11 Aug 02 IVM M043-85-93 595-61-02 Navy Shipboard and Airborne Mark XII IFF System Upgrade Program u 22 Jul 02 IVT 577-06-01 JROCM 027-92 13 Apr 92; TAMD CRD, CID CRD, GIG CRD 594-78-02 ASW Target MK 30 Mod 2 (U) c 26 Jun 02 IVM 593-61-02 Afloat C4I Local Area Network (LAN) u 21 Apr 02 II 539-06-99 IDM CRD, GIG CRD 592-78-02 Joint Multi-Mission Vertical Lift Aircraft (JMVX): V-22 Osprey u 16 Mar 02 ID IDM CRD, CID CRD, GATM Phase II CRD Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 589-75-02 Rapid Airborne Mine Clearance System (RAMICS) (U) C 1 Mar 02 II 484-88-98, 559- 85-00, 491-85- 98, 572-75-01, 495-85-98, 551- 85-00 M042-85-93 591-77-02 AN/BQQ-10(V) Acoustic Rapid COTS Insertion (A-RCI), Revision A, Change 1 (U) S 1 Mar 02 III 590-96-02 MORIAH (U) S/N 1 Mar 02 IVT M067-096-95; GIG CRD 588-76-02 Cooperative Engagement Capability (CEC) (U) S 31 Jan 02 ID M030-086-93, JROCM 065-99; TAMD CRD, CID CRD, GIG CRD, IDM CRD 587-61-01 High Frequency Data System (HFDS) U 21 Dec 01 nIV T M063-06-95, GIG CRD, IDM CRD 586-78-01 Advanced Targeting and Designating Forward Looking Infrared System (ATFLIR) (U) S 26 Nov 01 II 039-05-87, 300(1 )-88-97, 550-88-00, 437- 88-96 585-61-01 Joint Satellite Communication (SATCOM) Mobile User Objective System (MUOS) u 1 Oct 01 ID JROCM 035-01, DoD Teleport (Draft) 29 Mar 01 USSPACECOM 002-95 (JROCM 050-96), Advanced MILSATCOM CRD 24 Apr 98, GIG CRD 582-42-01 Auxiliary Cargo and Ammunition Ship (T-AKE) u 27 Jul 01 I M019-003-92 580-06-01 Single Multifunctional Information Distribution System Low Volume Terminal (MIDS-LVT) u 20 Jun 01 ID 387-06-94 ? MIDS in F/A18 13 Mar 90, JROCM 031-90 581-78-01 Consolidated Automated Support System (CASS) u 15 Jun 01 II “ Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 579-77-01 AN/BSY-1 High Frequency Upgrade, Revision A (U) S 31 May 01 III 534-87-99 M042-85-93 578-75-01 Underwater Acoustic Firing System (AFS) U 31 May 01 IVT M043-85-93 JROCM 089 01 Global Broadcast Service (GBS) u 25 May 01 ID ? JMNS 3 Aug 95, MILSATCOM CRD, TAMD CRD, IDM CRD 577-06-01 Improved MK XII Cooperative Identification Capability (U) S/N 27 Apr 01 II 493-06-98, 595- 61-02 MNS: JROCM 027-92 13 Apr 92; CRD: JROCM 064-01 576-77-01 Submarine High Data Rate (SubHDR) Antenna, Revision 1 u 27 Apr 01 II! 005-79-I/I I/I IIA, AFSPC 005-79-I- B, JROCM 042- 97, 318(1)-06-96 CRD01-87-98 575-75-01 EX-8 Mod 0 Marine Mammal System (U) c 23 Apr 01 IVT M025-003-92 574-75-01 Lightweight, Disposable Disrupter (LIDD) u 20 Mar 01 IVT 542-86-99 M043-85-93 JROCM 035 0 1 Joint Tactical Radio System (JTRS), Revision 2.2 u 20 Feb 01 ID ABCS CRD Revision 1b, 30 Jun 99 573-76-01 Land Attack Missile Weapon System (U) s 25 Jan 01 III 523-86-99, 354(1 )-86-97 M024-003-92, M087-87- 97 572-75-01 Organic Airborne and Surface Influence Sweep (OASIS) (U) S/N 10 Jan 01 II 484-88-98, 491- 85-98, 495-85- 98, 551-85-00, 559-85-00 MNS: M042-85-93; ? CRD: {draft} MCM 571-78-01 EP-3E Joint Airborne SIGINT Architecture (JASA) Modernization (JMOD) (U) S 9 Jan 01 II! MNS: M076-JCS-96, CAF 329-92, JROCM 027-92, M105-88-00; CRD: CAF 002-88 570-77-00 Submarine Electronic Warfare Support (ES) System ( A N / B L Q - 1 0 ) ( U ) S 20 Dec 00 Ill 342(1 )-87-95 " Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 569-76-00 Joint Chemical Agent Detector (JCAD), (JTD J2- C001-III) MS III Final U 12 Dec 00 III M071-88-96 568-78-00 F/A-18E/F Active Electronically Scanned Array (AESA) (U) S 13 Nov 00 I 402-88-95, 550- 88-00, 415(1)-88- 96 CRD: Imagery & Geospatlal 566-88-00 AN/ARC-210(V) Electronic Protection (EP) Radio Set u 25 Sep 00 1 1 1 486-88-98 - 567-06-00 DoD Teleport u 22 Sep 00 III MNS: JROCM 047-95; CRD: JROCM 048-96 565-88-00 Advanced Tactical Airborne Reconnaissance System (ATARS) u 1 Aug 00 II 402-88-95, 522- 88-99 CRD: Imagery & Geospatial 564-86-00 Smart Ship CG 47 Class Integrated Ship Controls (ISC) u 17 Jul 00 IVT 430-06-96 - 563-06-00 Sensitive Compartmented Information (SCI) Annex to ORD for Automated Digital Network System (ADNS) u 12 Jun 00 III 539-06-99, 439- 06-96 M063-06-95 562-06-00 Enhanced GPS User Equipment (UE) (U) S/N 7 Jun 00 III M055-88-94 560-88-00 Integrated Mechanical Diagnostics (IMD) System U 30 May 00 IVT 484-88-98 M053-88-94 561-88-00 Tactical Aircraft Moving Map Capability (TAMMAC) u 24 May 00 III M061-88-94 559-85-00 Airborne Mine Countermeasures (AMCM) Helicopter (Annex B to Fleet Combat Support (HC) Helicopter ORD) u 21 May 00 IC 484-88-98, 495- 85-98, 491-85- 98, 551-85-00 M042-85-93, M047(1)-86- 94, M072-85-96 558-88-00 Standoff Land Attack Missile - Expanded Response (SLAM-ER) (U) S/N 17 May 00 III 362(2)-06-97 - 556-86-00 Joint Service Lightweight Integrated Suit Technology (JSLIST) U 11 May 00 III 527-86-99, 535- 88-99 M100-86-99 557-88-00 Low Probability of Intercept (LPI) Precision Radar Altimeter U 11 May 00 IVT ” Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD AFSPC 004- 99 Wideband Gapfiller Satellite Communications System U 3 May 00 ID USSPACECOM 002-95 (JROCM 050-96) 555-88-00 Ground Proximity Warning System (GPWS) U 1 May 00 IVT - 553-87-00 Submarine High Data Rate (SubHDR) Antenna u 13 Apr 00 III JROCM 042-97, 318(1)-06-96 CRD01-87-98 552-88-00 future Aircraft Carrier (CVNX) (U) S/N 12 Apr 00 I M070-88-96 554-88-00 Joint Strike Fighter (JSF) (U) S 11 Apr 00 ID - 551-85-00 AN/AQS-20/X Sonar Mine Detecting Set, Revision 1 (U) C 3 Apr 00 II 530-85-99, 559- 85-00 M042-85-93, M047(1)-86- 94 550-88-00 F/A-18E/F (U) s 22 Mar 00 IC 402-88-95, 427- 88-96, 437-88- 96, 446-88-96, 486-88-98 549-88-00 Advanced Mission Computer and Displays (AMC&D), Revision 2 u 21 Mar 00 _ M061-88-94 548-85-00 Small Caliber Dearmer (SCO) u 24 Feb 00 III M043-85-93 547-86-00 Computer Aided Dead Reckoning Tracer (CADRT) u 15 Feb 00 IVT M084-86-97 546-86-00 Tomahawk Weapon System (TWS) Baseline IV, Revision 2 (U) s 10 Feb 00 IC 466-87-97, 523- 86-99, 529-86-99 ? Long Range Conventional Standoff Weapon 545-88-00 APR-39A(V)2 Radar Signal Detection Set (RSDS) (U) s 9 Feb 00 III “ 544-88-00 Onboard Jammers (OBJ) (U) s 27 Jan 00 III Augments 378- 88-94 & 494-88- 98 M062-88-95 543-85-00 Closed Loop Degaussing System for Mine Countermeasures Ships (CLDG), Revision 1 (U) C 5 Jan 00 IVT Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 542-86-99 Joint Warning and Reporting Network (JWARN), (JTD J1-001-III) MSIII Revision U 29 Dec 99 II! M071-88-96, M100-86- 9 9 540-87-99 Advanced Deployable System (ADS) (U) S 16 Dec 99 II M034-087-93 539-06-99 Automated Digital Network System (ADNS) u 14 Dec 99 III 563-06-00 M063-06-95 538-85-99 Main Charge Disrupter (M C D ) u 14 Dec 99 IVM M043-85-93 541-04-99 Auxiliary Dry Cargo Carrier (T-ADC(X)) u 10 Dec 99 I M019-003-92 537-06-99 Shipboard Information Warfare/Cryptologic Systems (SIWCS) (U) s 9 Dec 99 III " 536-85-99 Standoff Disrupter (SD) (U) c 6 Dec 99 AAP 517-85-99 M043-85-93 535-88-99 Joint Protective Aircrew Ensemble (JPACE), J3- 004-II u 29 Nov 99 - M071-88-96 534-87-99 AN/BQQ-10(V) Acoustic Rapid COTS Insertion (A-RCI) (U) s 24 Nov 99 Ill “ 533-96-99 Tactical Environmental Support System (TESS) u 23 Nov 99 IVT 441-096-96, 512- 96-99 M073-096-98, M092-91- 98 532-87-91 OE-538/BRC Antenna Group u 17 Nov 99 III - 531-91-99 Subsonic Cruise Missile Target (T21) u 15 Nov 99 IV App C to 504-86- 98 M029-091-93 530-85-99 Remote Minehunting System (RMS), Revision 1 (U) c 5 Oct 99 II M042-85-93, M047(1)-86- 94 528-86-99 Joint Biological Standoff Detection System (JBSDS) u 1 Sep 99 III 542-86-99 M014-003-92 529-86-99 Land Attack Missile (LAM) (U) s 31 Aug 99 III 523-86-99, 354(1 )-86-97 M024-003-92, M087-87- 97 527-86-99 Joint Service General Purpose Mask (JSGPM) u 19 Aug 99 III ? DoD Biological Defense 31 Aug 92 526-86-99 Roiling Airframe Missile (RAM) Block I Upgrade, Change 1 (U) s 8 Jul 99 II 512-96-99, 533- 96-99 “ 525-88-99 Air Deployable Active Receiver (ADAR) Sonobuoy(U) s 8 Jul 99 III 328-88-93 “ Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 524-44-99 Joint Transportable Collective Protection System (JTCOPS) U 8 Jul 99 III M071-88-96 523-86-99 Naval Fire Control System (NFCS) U 1 Jul 99 Ilf 420-86-95, 421- 86-95 M024-003-92 522-88-99 Shared Reconnaissance Pod (SHARP) u 21 Jun 99 III ? MNS for Aerial Recon Pod 521-88-99 Airborne Expendables (U) s 28 May 99 III M062-88-95, M097-88- 96 520-86-99 Advanced Tomahawk Weapon Control System (ATWCS), Revision A (U) s 13 May 99 III ? CINCLANTFLT Ltr 3600 Ser N99/05 dtd 28 Jun 91 518-88-99 Air Surveillance & Precision Approach Radar Control System (ASPARCS) u 12 May 99 III ? CAC2S MNS AAS 48 12 Apr 95 (95102DA) 519-91-99 Joint Modeling and Simulation System (JMASS) u 5 May 99 “ M101-91-99 517-85-99 Remote Ordnance Neutralization System (RONS) L J 26 Apr 99 IVM 536-85-99 M043-85-93 515-88-99 Joint Service Sensitive Equipment Decontamination (JSSED) u 13 Apr 99 M071-88-96 516-88-99 Joint Protective Aircrew Ensemble (JPACE) u 13 Apr 99 Ill M071-88-96 514-86-99 Area Air Defense Commander (AADC) Capability, Version F u 29 Mar 99 III 373-88/6-94, 387- 06-94, 388-86- 95, 510-06-99 JROCM 064-91 18 Nov 91 513-88-99 Aircrew Laser Eye Protection (ALEP) u 15 Mar 99 IV ■ 512-96-99 MORIAH (U) s 22 Feb 99 III Supersedes parts of 369-096- 94 M067-096-95 511-85-99 EX 8 Mod 0 Marine Mammal System (U) c 18 Feb 99 IVT M025-003-92 510-06-99 Global Command and Control System - Maritime (GCCS-M) u 12 Feb 99 II 512-96-99 ” Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 509-85-99 Vertical Takeoff and Landing Tactical Unmanned Aerial Vehicle (VTUAV) U 13 Jan 99 II JROCM 003-90 Jan 90; MC: MOB 40 6 Jan 98 508-88-99 Aircrew/Ejection Seat Locating Radio/Beacon u 11 Jan 99 IVM JROCM 006-92 Feb 92 (CSEL) 507-88-99 Improved Fresnel Lens Optical Landing System (IFLOLS) u 4 Jan 99 IVT ” 506-87-98 TB-29() Thin Line Towed Array (TLTA) (U) S 7 Dec 98 III 534-87-99 - 505-86-98 Supersonic Sea Skimming Target (SSST) u 27 Oct 98 II 504-86-98 M017-091-92 504-86-98 Navy Aerial Targets u 27 Oct 98 III 505-86-98 - 502-86-98 Active Electronic Decoy (AED) and Decoy Launching System (DLS) (U) s 15 Oct 98 III 462-86-97 " 503-88-98 Joint Strike Fighter (JSF) [JIRD III] (U) s 11 Oct 98 ID 311 (2)-88-96 - 501-88-98 Advanced Mission Computer and Display (AMC&D) u 9 Oct 98 II 434-88-96 M061-88-94 500-88-98 AAR-47 Missile Warning Set (U) s 8 Oct 98 III - 499-88-98 Joint Service Aircrew Mask (JSAM) u 24 Aug 98 III 381(1)-88-95 M071-88-96 498-88-98 E-6B Mercury-TACAMO/Airborne Command Post, Revision 2 (U) s 14 Aug 98 II M040-88-93 496-87-98 Countermeasures Detection and Control Set AN/WLY-1 (U) s 31 Jul 98 III " 497-06-98 Video Information Exchange System (VIXS) u 31 Jul 98 IVM M063-06-95 495-85-98 Airborne Laser Mine Detection System (ALMDS) (U) C 21 Jul 98 II! M042-85-93 494-88-98 Integrated Defensive Electronic Countermeasures (IDECM) Radio Frequency Countermeasures (RFCM) & IDECM Suite (U) s 1 Jul 98 II 396-86-95 & 423- 88-95; Augments 378-88-94 M062-88-95 493-06-98 Navy Mark XII IFF Shipboard System Upgrade Program u 1 Jul 98 IVT 577-06-01 JROCM 027-92 13 Apr 92 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 492-86-98 Naval Theater Ballistic Missile Defense (TBMD) System (U) S 25 Jun 98 I JROCM 064-91 18 Nov 91, JROCM 099-92 10 Dec 92, M031-086-93 491-85-98 Airborne Mine Neutralization System (AMNS) (U) C 23 Jun 98 III 559-85-00 M042-85-93, M047(1)-86- 94 490-85-98 Underwater Acoustic Firing System (AFS) u 12 Jun 98 IVT M043-85-93 489-87-98 Submarine Rescue Diving & Recompression System (SRDRS) u 3 Jun 98 IVT M016-02-92 488-88-98 Long Range Line Up System (LRLS) u 19 May 98 IVM - 487-88-98 Shallow Water Undersea Warfare Training Range (SWUWTR) Program u 19 May 98 IVT 400-88-95 M050-88-94 486-88-98 F/A-18 Digital Communications System (DCS) u 15 May 98 IVT 300(1 )-88-97, 333(1 )-06-96, 550-88-00, 566- 88-00 MC: 95047DA (004.1 16 Feb 95) 485-86-98 Launched Expendable Acoustic Device (LEAD) (U) S 5 May 98 IVT " 484-88-98 Fleet Combat Support (HC) Helicopter u 28 Apr 98 ID 559-85-00, 560- 88-00 M059-88-94 483-06-98 Joint (UHF) MILSATCOM Network Integrated (JMINI) Control System u 27 Mar 98 IVT 382-06-94 - 482-87-98 Torpedo MK-48 Mod 6 Common Broadband Advanced Sonar System (CBASS) Upgrade (U) S 20 Mar 98 III 297(1 )-05- 97 Air Deployable Active Receiver (ADAR), Revision 1 (U) s 29 Dec 97 ill " 481-87-97 Electronic Support (ES) System (U) s 5 Dec 97 III 342(1 )-87-95 - 469(1 )-04- 97 Barracks Craft - Small (APL(S)), Revision 1 u 5 Dec 97 IV " 480-88-97 Navy Combat Edge (NCE) u 4 Dec 97 IVT - Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 479-86-97 Land Attack Destroyer (DD-21) (U) S 3 Nov 97 I M047(1)-86-94 478-06-97 Integrated Broadcast Service (IBS) u 31 Oct 97 III 335-06-93, 448- 06-96 ? DoD IBS Plan 24 Oct 95 477-87-97 Mobile Torpedo Countermeasures (U) S 28 Oct 97 IVT - 476-01-97 Navy Standard Integrated Personnel System (NSIPS) u 24 Oct 97 IAM ? NSIPS MNS 475-88-97 AGM-88 HARM Block VI Upgrade (Tri-National s 23 Sep 97 III - 473-88-97 Remote Landing Site Tower (RLST) u 25 Jul 97 - - 474-88-97 EA-6B Prowler Aircraft Systems (U) s 17 Jul 97 II - 472-86-97 National Missile Defense (U) s 3 Jul 97 - JCSM 93-87 23 Jun 87 471-86-97 Joint Chemical Agent Detector (JCAD) u 29 Jun 97 Ill M071-88-96 470-86-97 Nuclear, Biological, and Chemical (NBC) Joint u 29 Jun 97 III ? MC: MNS 6 Aug 92 468-88-97 Marine Corps Expeditionary Arresting Gear System (MCEAGS) u 16 Jun 97 IV ” 464-88-97 Expeditionary and Night Vision Device Compatible Lighting and Landing Aid u 5 Jun 97 IV ? MC: MNS 5 Mar 96 467-86-97 Joint Service Lightweight Standoff Chemical Agent Detector (JSLSCAD) u 27 May 97 III M071-88-96 466-87-97 Tomahawk Land Attack Missile - Nuclear (TLAM- c 23 May 97 III - 465-87-97 Doppler Sonar Velocity Log (DSVL) (U) c 23 May 97 IVT - 463-6-97 Electronic Key Management System (EKMS) u 15 May 97 IV - 354(1 )-86- 97 Tomahawk Weapon System (TWS) Baseline IV, Revision 1 (U) s 6 May 97 IC “ 462-86-97 Advanced Integrated Electronic Warfare System (AIEWS) (U) s 24 Apr 97 II M022-003-92 461-6-97 Ocean Surveillance Information System (OSIS) Baseline Upgrade (OBU)/OSIS Evolutionary Development (OED) u 24 Apr 97 III 460-87-97 Submarine Antenna Distribution System (SADS) u 14 Apr 97 IV M063-06-95 N > o Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 459-88-97 Aviation Data Management & Control System (ADMACS) U 10 Apr 97 IVT “ 458-88-97 Shallow Water Undersea Warfare Training Range (SWUWTR) Program U 10 Apr 97 IVT 400-88-95 M050-88-94 JROCM 042 97 Global Broadcast System (GBS) u 7 Apr 97 - ? JMNS 3 Aug 95 300(1 )-88- 97 F/A-18E/F, Revision 1 (U) s 1 Apr 97 ID 550-88-00 " 457-87-97 AN/BSY-1 High Frequency Upgrade (U) s 31 Mar 97 III 534-87-99 M042-85-93 389(1 )-88- 97 E-6B Mercury-TACAMO/Airborne Command Post, Revision 1 (U) s 20 Mar 97 III M040-88-93 456-01-97 Navy Standard Integrated Personnel System (NSIPS) u 28 Feb 97 IAM ? NSIPS MNS 334(1 )-88- 97 MK 30 Mod 2 ASW Target, Revision 1 (U) c 25 Feb 97 IV “ 455-88-97 Advanced Medium-Range Air-to-Air Missile s 15 Jan 97 IC - 451 (1)-86- 97 Naval Theater Ballistic Missile Defense (TBMD), Revision 1 (U) s 6 Jan 97 I JROCM 064-91 18 Nov 91, JROCM 099-92 10 Dec 92, M031-086-93 454-85-96 Main Charge Disrupter (MCD) u 19 Dec 96 IV M043-85-93 311(2)-88- 96 Joint Primary Aircraft Training System (JPATS), Revision 2 [AETC 005-88-II, Revision 1] u 9 Dec 96 IC ? JSON 14 Sep 90 415(1)-88- 96 Helmet Mounted Cueing System (HMCS), Revision 1 [CAF-USN 308-93-lll-A] u 9 Dec 96 lll/IV CAF-USN 308-93 USN- CAF(002) AIM-9X (U) s 12 Nov 96 ID 415(1)-88-96 " 453-86-96 AN/SPY-1 Radar Upgrade (AN/SPY-1 D(V)) (U) s 24 Oct 96 II 452-87-96 Submarine Baseband Switch (BBS) u 24 Oct 96 IV M063-06-95 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 450-86-96 Advanced Combat Direction System (ACDS) Block 1 (U) C 18 Oct 96 II “ 449-88-96 Shallow Water ASW Localization and Attack System (SWALAS) (U) C 27 Sep 96 III M048-88-94 438(1 )-04- 96 Enhanced Maritime Prepositioning Force (MPF(E)), Revision 1 u 25 Sep 96 III MC: MOB 211.6 6 Mar 95 448-06-96 Joint Tactical Term inal (JTT) and Common Integrated Broadcast Service Modules (CIBS-M) u 24 Sep 96 III 478-06-97 ? DoD IBS Plan 24 Oct 95 419(1)-88- 96 Long Range Line-Up System (LRLS), Revision 1 u 17 Sep 96 IVT “ 447-85-96 Remote Ordnance Neutralization System (RONS) u 12 Sep 96 IV M043-85-93 361(1)-86- 96 Shipboard Advanced Radar Target Identification System (SARTIS) AN/UPX-34(V) Radar Track Discriminator System (RTDS) for Aegis Ships, Revision 1 (U) S/N 10 Sep 96 III JROCM 027-92 446-88-96 F/A-18 Positive Identification System (PIDS) (U) S 23 Aug 96 III 300(1)-88-97, 550-88-00 JROCM 027-92 445-86-96 Joint Biological Point Detection System (JBPDS) U 23 Aug 96 III M014-03-92 444-87-96 Long-Term Mine Reconnaissance System (LMRS) U 22 Aug 96 II M042-85-93 443-06-96 Shipboard Digital Wideband Transmission System (DWTS) U 15 Aug 96 IVT M063-06-95 367(1 )-85- 96 Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ-94), Revision 1 u 24 Jul 96 IVM 308(1 )-85- 96 LPD-17 Amphibious Transport Dock Ship, Revision 3 (U) S 28 May 96 ID ” Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 441-096-96 Meteorological Mobile Facility Replacement (METMF(R)) U 23 May 96 IV 533-96-99 ? MC TOR ASL- 44/METMF(R)SIZ.Z4J 13 Jun 88 442-87-96 Combat Control System MK2 Program DO Block 1C(U) C 23 May 96 IVT 520-86-99, 380- 86-94 - 440-85-96 Lightweight, Disposable Disrupter (LIDD) u 30 Apr 96 IV M043-85-93 439-06-96 TACINTEL II+ Program (U) S 15 Apr 96 III 563-06-00 - 437-88-96 F/A-18 Targeting & Designating Forward Looking Infrared System (TFLIR) (U) S 8 Apr 96 II 300(1 )-88-97, 550-88-00 436-88-96 Joint Air to Surface Standoff Missile (JASSM) (U) [CAF 303-95-I] S/N 3 Apr 96 I CAF 303-95 30 Jun 95 435-06-96 Submarine LVA/LF Versamodule Eurocard Receiver (SLVR) U 30 Mar 96 II! 433-88-96 - 434-88-96 Tactical Aircraft Moving Map Capability (TAMMAC) U 30 Mar 96 II! M061-88-94 433-88-96 Modified Miniature Receiver Terminal (MMRT) VLF/LF Receiver for E-4B National Airborne Operations Center (NOAC) and E-6B Mercury [CAF-USN 330-92-ll-B] U 25 Mar 96 IV 435-06-96 CAF-USN 330-92 333(1 )-06- 96 Electronic Protection (EP) Combination Radio AN/ARC-210(V), Revision 1 U 24 Mar 96 III 486-88-98 432-85-96 Remote Minehunting System (RMS) Program (U) c 16 Mar 96 III M042-85-93 431-096-96 Supplemental Weather Radar u 12 Mar 96 IVM M041-096-93 430-06-96 Hierarchical Yet Dynamically Reprogrammable Architecture (HYDRA) Communications System u 2 Mar 96 III 417-06-95, 425- 06-95 M063-06-95 429-85-96 Underwater Acoustic Firing System (AFS) u 2 Mar 96 IV M043-85-93 318(1)-06- 96 Lightweight SHF Satellite Communications Terminals, Revision 1 (U) s 1 Mar 96 ill Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 428-06-96 Commercial Satellite (COMMERSAT) Communication U 27 Feb 96 IV M009-094-92 427-88-96 Reconnaissance Capable F/A-18 (F/A-18(RC)) (U) C 19 Feb 96 III 300(1 )-88-97, 402-88-95, 550- 88-00 426-88-96 ES-3 Critical Avionics Upgrade (CAU) u 1 Feb 96 IVM - 424-87-95 Countermeasures Detection and Control Set (AN/WLY-1) (U) s 22 Dec 95 ill " 381 (1)-88- 95 Navy Combat Edge (NCE), Revision 1 u 22 Dec 95 IVT “ 425-06-95 Ship Automated Communications Control System (SACCS) u 22 Dec 95 IVT M063-06-95 322(1 )-06- 95 High Frequency Radio Group (HFRG), Revision 1 u 18 Dec 95 III ~ 423-88-95 Common Missile Warning System (CMWS) for U.S. Army, Air Force, Navy, Marine Corps Aircraft and Electronic Attack (EA) Pods (U) s 29 Nov 95 IC 494-88-98 M062-88-95 351(1)-06- 95 Message Processing Afloat, Revision 1 u 27 Nov 95 IVT “ 422-86-95 Sparrow Missile (AIM/RIM-7R) (U) s 18 Nov 95 II - 421-86-95 Extended Range Guided Munition (ERGM) u 8 Nov 95 II 420-86-95, 523- 86-99 M024-003-92 420-86-95 5" MK 45 Gun Mount Modification (MK 45 MOD) u 8 Nov 95 III 421-86-95, 523- 86-99 M024-003-92 337(1 )-06- 95 Multifunctional Information Distribution System Low Volume Terminal (MIDS-LVT), Revision 1 u 1 Nov 95 ID ? MIDS in F/A18 13 Mar 90 419-88-95 Long Range Line-Up System (LRLS) u 31 Oct 95 IVT - 418-06-95 Navy Tactical Command System Afloat (NTCS- A) u 10 Oct 95 II “ Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 416-88-95 Joint Service Electronic Combat Systems Tester (JSECST) [CAF-NASC 325-92-l/ll-A] U 28 Sep 95 III M037-88-93 417-06-95 Maritime Cellular Information Exchange System (MCIXS) U 25 Sep 95 IVM M063-06-95 331(1)-88- 95 Joint Direct Attack Munitions (JDAM), Revision 1 [CAF 401-91 -ll-A] u 11 Sep 95 I ? AF: TAF 401-91-ll-A 415-88-95 Helmet Mounted Cueing System (HMCS) u 11 Sep 95 lll/IV CAF-USN 308-93 414-86-95 Infrared Search & Track (IRST) Sensor (U) S/N 8 Sep 95 III 390-86-95, 398- 86-95 M018-003-92 344(1 )-88- 95 H-53E Service Life Extension Program (SLEP), Revision 1 u 29 Aug 95 III - 413-85-95 Mission Package Three (MP-3) for the AN/SLQ- 48 Mine Neutralization System (U) c 27 Aug 95 III M042-85-93 412-85-95 QUICKSTRIKE Mines (U) c 22 Aug 95 III - 411-06-95 Navy Shipboard Single Channel Ground & Airborne Radio System (SINCGARS) u 15 Aug 95 IVT JCSM 110-76 (JOR) 410-86-95 Thermal Imaging Sensor System (TISS) (U) c 7 Aug 95 IV M018-003-92 409-86-95 Air and Surface Launched ASW Torpedo Lightweight Hybrid Torpedo (LHT) (U) S/N 2 Aug 95 III M068-86-95 408-88-95 S-3 Critical Avionics Upgrade (CAU) Program u 13 Jul 95 IVT “ 407-06-95 AN/UYQ-70(V) Advanced Display System u 30 Jun 95 IVT - 342(1 )-87- 95 New Attack Submarine (New SSN), Revision 1 (U) c 29 Jun 95 ID " 406-88-95 F-14 Forward Looking Infrared/Laser Targeting System (FLIR/LTS) (U) s 14 Jun 95 III “ 405-86-95 Lightweight Integrated Nuclear, Biological and Chemical (NBC) Protective Garment u 9 Jun 95 III ? MC: NBC 215.2.1 404-88-95 CINCLANTFLT Executive Transport Helicopter Upgrade u 6 Jun 95 IVM ” 403-06-95 Operations Support System (OSS) u 5 Jun 95 III - Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 402-88-95 F/A-18 Radar Upgrade (RUG) (U) S/N/ W 31 May 95 II 300(1 )-88-97, 427-88-96, 550- 88-00 401-88-95 Embedded GPS INS (EGI) U 25 May 95 III - 400-88-95 Tactical Training Ranges Program (TTRP) U 25 May 95 IVM - 399-88-95 Consolidated Automated Support System (CASS) U 11 May 95 II " 398-86-95 Ship Self Defense System (SSDS) (U) S/N 17 Apr 95 II M020-003-92 397-85-95 Advanced Radiographic System (ARS) U 14 Apr 95 IVM M043-85-93 338(1 )-86- 95 AN/SLQ-20 Upgrade System, Revision 1 (U) S/N 6 Apr 95 III ? JROC CID MNS 13 Apr 92 396-86-95 Advanced Infrared (IR Expendables) (U) [Multi- Service, MS 323-88-l/il-A] S/N 4 Apr 95 III 494-88-98 CAF 323-88 SON; SAC SON 11-88; AFSOC MNS 01-91; AMC MNS 041-92 395-88-95 Low Probability of Intercept (LPI) Precision Radar Altimeter U 30 Mar 95 IVT “ 394-86-95 Multi-Function Fuze (MFF) U 25 Mar 95 IVT M024-003-92 393-88-95 S-3B Aircraft Communications Improvement Program (CIP) U 23 Mar 95 IVT “ JROCM 036 95 Unmanned Aerial Vehicle - Short Range (UAV- SR) (U) C 9 Mar 95 ID JROCM 88-106 392-04-95 Explosive Ordnance Disposal (EOD) Personnel Dosimeter U 9 Mar 95 IVM - 384-88-94 Joint Multi-Mission Vertical Lift Aircraft (JMVX) U 4 Mar 95 ID JROCM 048-93 391-88-95 Integrated Defensive Electronic Countermeasures (IDECM) Radio Frequency Countermeasures (RFCM) and Integration (U) S 3 Mar 95 II Augments 378- 88-94 M062-88-95 3 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 390-86-95 Advanced Combat Direction System (ACDS) Block 0 (U) C 22 Feb 95 II - 362(1 )-06- 95 Tactical Automated Mission Planning System (TAMPS), Revision 1 U 2 Feb 95 IVT - 389 -88-95 E-6B Mercury-TACAMO/Airborne Command Post (U) S 14 Jan 95 III M040-88-93 388-86-95 Cooperative Engagement Capability (CEC) (U) S 4 Jan 95 IC M030-086-93 301(1)-88- 94 Joint Standoff Weapon (JSOW) System, Revision 1 (U) C 30 Dec 94 ID - 387-06-94 Joint Tactical Information Distribution System (JTIDS) (U) c 22 Dec 94 ID MJCS-194-89 357(1 )-85- 94 Shallow Water Mine Countermeasures (SWMCM) Mine/Obstacle Clearance, Revision 1 ( U ) c 16 Dec 94 III M025-003-92 386-87-94 AN/BSY-1 Engineering Change Proposal 1000 (U) r s 3 Dec 94 III 385-86-94 Evolved Seasparrow Missile (ESSM) Program (U) S/N 28 Nov 94 II M033-086-93 383-88-94 Standoff Land Attack Missile - Expanded Response (SLAM-ER) and SLAM plus (U) S/N 23 Nov 94 ll/lll 382-06-94 UHF Satellite and Line-of-Sight Communications Terminals U 21 Nov 94 III * 380-86-94 Ring Laser Gyro Navigation (RLGN) System (U) c 4 Nov 94 IVT 442-87-96 - 379-87-94 Advanced Deployable System (ADS) (U) S/N 28 Oct 94 II M034-087-93 378-88-94 Advanced Airborne Expendable Decoy (AAED) ( U ) S 17 Oct 94 III - 377-88-94 Navy H-60 Helicopter Enhanced Weaponization Kit (U) c 17 Oct 94 IV M000-003-91 N 3 • > 1 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating M N S to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 376-86-94 AN/SPQ-9 Radar Anti-Ship Missile Defense (ASMD) Upgrade Program (U) S/N 11 Oct 94 III “ 375-87-94 Advanced Submarine Tactical Electronic Support Measures (ESM) Combat System (ASTECS) (U) S 1 Oct 94 III 373-88/6-94 Tactical Support Center (TSC) u 21 Sep 94 III C2 part of 373(1)- 88/6-96 re-issued in 510-06-99 372-86-94 Improved (Chemical Agent) Point Detection System (IPDS) u 21 Sep 94 IVT “ 374-88-94 Improved Fresnel Lens Optical Landing System (IFLOLS) Portion of Improved Carrier Optical Landing System (ICOLS) u 21 Sep 94 IVT 371-88-94 E-2C Hawkeye Aircraft Mission Computer Upgrade (U) s 20 Sep 94 II 382-06-94, 387- 06-94, 388-86-95 370-85-94 Forward Area Combined Degaussing and Acoustic Range (FACDAR) (U) c 14 Sep 94 IVM M036-85-93 369-096-94 Tactical Environmental Support System (TESS) u 11 Sep 94 IVT Parts superseded by 512-96-99 315(1 )-88- 94 VH-60N Executive Helicopter Mid-Life Upgrade, Revision 1 (U) s 5 Aug 94 III M015-005-92 367 -85-94 Combat System Integrated Training Equipment (CSITE) Program (AN/SQQ-94) u 4 Aug 94 IVM - 317(1)-88- 94 Joint Tactical Combat Training System (JTCTS) u 4 Aug 94 IVT - 366-86-94 Standard Missile-2 Block IV (SM-2 BLK IV) (U) S/N 28 Jul 94 ID 325-86-92 - 365-87-94 Photonics Mast (U) c 22 Jul 94 III 342(1 )-87-95 - Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating M NS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 368-85-94 Closed Loop Degaussing System for Mine Countermeasures Ships (CLDG) (U) C 22 Jul 94 IVT " 363-86-94 Advanced Tomahawk Weapon Control System (ATWCS) (U) S 21 Jul 94 III " 364-88-94 Improved Tactical Air Launched Decoy (ITALD) (U) c 21 Jul 94 III “ 361 -86-94 Shipboard Advanced Radar Target Identification System (SARTIS) AN/UPX-34(V) Radar Track Discriminator System (RTDS) for Aegis Ships (U) S/N 13 Jun94 III JROCM 027-92 319(1)-88- 94 E-6A Avionics Block Upgrade, Revision 1 (U) S 6 Jun 94 ill 360-88-94 Improved Radar Warning Receiver (U) S 27 May 94 III - 303(1 )-86- 94 Battle Force Tactical Trainer (BFTT) Improvement Program, Revision 1 U 21 May 94 IVM ” 336(1 )-86- 94 DDG 51 Flight IIA, Revision 1 (U) S 25 Apr 94 ID - 359-87-94 Submarine Offboard Mine Search System (SOMSS) (U) S/N 19 Apr 94 II “ 358-86-94 Launch Subsystems for Expendable Acoustic Devices (LEAD) (U) S 15 Apr 94 IVT * 356-85-94 Shallow Water Mine Countermeasures (SWMCM) Marking (U) C 11 Apr 94 ill M025-003-92 355-88-94 P-3 Anti-Surface Warfare Improvement Program (P-3C AIP) (U) C 30 Mar 94 II M039-88-93 354 -86-94 Tomahawk Weapon System (TWS) Baseline IV (U) S 28 Mar 94 IC ” 353-86-94 US/UK Surface Ship Torpedo Defense (SSTD) Joint Project (U) S 28 Mar 94 IC “ 352-88-94 C-2A(R) Service Life Extension Program (SLEP) U 11 Mar 94 IVT ” Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating M N S to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 320(1 )-85- 94 Near Term Mine Countermeasures Support Ship (MCS), Revision 1 (U) C 7 Mar 94 III M042-85-93 350-88-94 F-14 Positive Identification (U) S/N 24 Feb 94 III JROCM 027-92 349-86-94 Improved M9 9MM Pistol U 9 Feb 94 IV - 323(1 )-86- 94 LAMPS MK III Forward Looking Infrared (FLIR) Contingency Kits, Revision 1 (U) C 12 Jan 94 III - 348-86-94 Rolling Airframe Missile (RAM) Block I Upgrade (U) S 10 Jan 94 II “ 311 (1)-88- 93 Joint Primary Aircraft Training System (JPATS), Revision 1 [AETC 005-88-II] U 29 Dec 93 IC ? JSON 14 Sep 90 347-86-93 Air and Surface Launched ASW Torpedo (MK- 50) (U) S/N 29 Dec 93 ID - 346-06-93 Shipboard Cryptologic Systems (U) C 22 Nov 93 III - 310-87-93 Torpedo Propulsion Upgrade (Revision A) (U) S 5 Nov 93 III - 343-87-93 Acoustic Device, Countermeasure (ADC) EX-11 (U) S 27 Sep 93 III - USN- CAF(001) AIM-9X (U) S/N/ W 1 Sep 93 I - 341-88-93 Remote Landing Site Tower (RLST) U 1 Sep 93 IVT - 340-88-93 P-3C Sustained Readiness Program (SRP) U 31 Jul 93 II - 339-091-93 Non-Cooperative Airborne Vector Scoring (NAVS) System U 27 Jun 93 IVM 400-88-95 M027-091-92 335-06-93 Tactical Related Applications (TRAP) Broadcast (U) S/N 6 Jun 93 III - 334 -88-93 MK 30 Mod 2 ASW Training Target (U) C 10 May 93 IVM - 332-091-93 Vandal Extended Extended Range (EER) U 15 Apr 93 IVM M017-091-92 331 -88-93 Joint Direct Attack Munitions (JDAM) (U) C 7 Apr 93 I ? AF: TAF 401-91 330-06-93 High Frequency Data System (HFDS) U 1 Apr 93 IVT - c o © Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 329-09N/B- 93 Shipboard Physical Security U 4 Mar 93 IVT - 328-88-93 Air Extended Echo Ranging (EER) System (U) S/N 18 Jan 93 III - 327-86-93 Shipboard Automatic Liquid Agent Detector (SALAD) U 14 Jan 93 IVT - 326-86-93 Vertical Launch ASROC (VLA) (U) C 8 Jan 93 II - 324-86-92 AEGIS Near Term Tactical Ballistic Missile Defense (U) S 30 Dec 92 II 325-86-92 JROCM 064-91 18 Nov 9 1 325-86-92 Standard Missile-2 (SM-2) Block IVA (U) S 30 Dec 92 II 324-86-92, 366- 86-94 JROCM 064-91 18 Nov 9 1 321-88-92 AX Joint Attack Fighter (U) S 3 Dec 92 ID ? AX MNS 19 Jun 91 308 -03-92 LX Amphibious Assault Ship, Revision 2 (U) S 2 Sep 92 ID - 316-05-92 VH-3D Executive Helicopter Survivability Upgrade (U) s 21 Aug 92 III M012-005-92 314-03-92 LAMPS III Block II Upgrade (U) S/N 3 Aug 92 III - 312-05-92 USN/USMC Long Range Medium Airlift Aircraft U 20 Jul 92 II - 307-05-92 Advanced Rocket System (ARS) ( “I T ”1 25 Jun 92 III - 313A-04-92 Strategic Sealift COM-20 U 15 Jun 92 IC M028-04-92 313-04-92 Strategic Sealift CSP/S-24 u 15 Jun 92 IC M028-04-92 309-094-92 Slow Walker Reporting System (SWRS) (U) S 12 Jun 92 III ? JROC TES MNS 302-03-92 AN/AQS-20 Sonar, Mine Detecting Set (U) S/N 21 May 92 III - 298-05-92 Multi-Option Rail Launcher u 21 May 92 IV M013-005-92 306-094-92 Precision Lightweight GPS Receiver (PLGR) u 21 May 92 IV - 304-03-92 Single Ship Deep Sweep (SSDS) AN/SLQ-53 ( U ) c 11 May 92 IV - 297 -05-92 Air Deployable Active Receiver (ADAR) (U) S 5 Mar 92 III - Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating MNS to ORDs (continued) ORD# Title Class Date ACAT Related ORD Related MNS-CRD 299-03-92 Stabilized Weapons Platform System (SWPS) U 31 Jan 92 III - 305-05-92 Acoustic Intercept System (AIS) (U) S/N 1 Jan 92 III - 300 -05-92 F/A-18E/F (U) S/N/ W 19 Dec 91 ID - 295-05-92 Airborne Low Frequency Sonar (ALFS) (U) S/N 16 Dec 91 II - 224-05-89 AV-8B Radar U 5 Aug 88 III - 243-03-92 Advanced Minor Caliber Gun System (AMCGS) U III M002-003-92 APPENDIX R TABLE RELATING UNCLASSIFIED MNS TO UNCLASSIFIED ORDs The MNS and ORDs in this appendix are unclassified and, therefore, a subset of those in Appendix Q. A greater number of ORDs map to MNS for these unclassified documents; but, as previously stated, one ORD, representing one system, should be derived from a MNS. The mapping used the ORDs in Appendix M and ORDs in Appendix P. The numbers associated with each were retained. Availability of requirements documentation to programs' with potentially interoperating systems is lacking. Only 30 of the 158 unclassified ORDs are related to MNS. Only 21 of the 70 unclassified MNS are related to these ORDs. Navy has thousands of systems! How can they be interoperable without documented guidance? 433 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating Unclassified MNS to Unclassified ORDs Navy Unclassified Mission Needs Statements (MNS) Corresponding Operational Requirements Documents (ORDs) MNS ORD NO. MNS TITLE NO. ORD TITLE 1. Aerospace Control Helmet-Mounted Cueing System 50. Helmet Mounted Cueing System 60. Helmet Mounted Cueing System (HMCS), Revision 1 2. tactical’ Air Control Party (TACP) Modernization 3. Theater Airborne Reconnaissance System (TARS) 147. Advanced Tactical Airborne Reconnaissance System (ATARS) 4. JDefense Information System Network (DISN) 5. Armed Navy Helicopters 6. rDeployable Flight incident Recorders 7. Airborne Weather Strike Capability 8. Commercial Satellite Communications 63. Commercial Satellite (COMMERSAT) Communication 9. JDeployable TACAIR Training System (DTATS) 10. Multi-Option Rail Launcher 4. Multi-Option Rail Launcher 11. Submarine Rescue Diving and Recompression System 103. Submarine Rescue Diving & Recompression System (SRDRS) 12. Supersonic Sea Skimming Target (SSST) 110. Supersonic Sea Skimming Target (SSST) 13. Auxiliary Dry Cargo Carrier (ADC (X)) 134. Auxiliary Dry Cargo Carrier (T-ADC(X)) 14. Open Ocean High Altitude Supersonic Dive (HASD) Aerial Target 15. Non-Cooperative Airborne Vector Scoring (NAVS) k System 15. Non-Cooperative Airborne Vector Scoring (NAVS) System 16. Strategic Sealift 9. Strategic Sealift CSP/S-24 10. Strategic Sealift COM-2d 17. Subsonic Aerial Target (SAT) Capability 18. Airborne Early Warning (AEW) Capability I Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating Unclassified M N S to Unclassified ORDs (continued) 19. Joint Attack Fighter 20. Flight Line Electronic Combat Systems Tester 51. Joint Service Electronic Combat Systems Tester (JSECST) 21. mproved Assault Support Combat Utility Capability t 22. E-6A Tacamo/Airborne Command Post (ABNCPj Consolidation Program 23. Supplemental Weather Radar 67. Modified Miniature Receiver Terminal (MMRT) VLF/LF Receiver for E-4B National Airborne Operations 24. Master Seafloor Digital Database "(MSSDDB) 25. flight Vision System Capability in the H46D Helicopter 88. Expeditionary and Night Vision Device Compatible Lighting and Landing Aid 26. Enhanced Hearing Protector (EHP) for High Noise Environments 27. ntegrated Diagnostic System 144. integrated Mechanical" Diagnostics "(IMD) System 28. Precision Approach and Landing Capability (PALC) 29. Defense Broadcast System (DBS) 81. Global Broadcast Service (GBS) 30. Accommodation of Women Aircrew in Aviation 31. Fleet Combat Support Helicopter (HC) 99. 143. Fleet Combat Support (HC) Helicopter Airborne Mine Countermeasures (AMCM) Helicopter (Annex B to Fleet Combat Support (HC) Helicopter 32. Tactical Aircraft Moving Map Capability (TAMMAC) 68. Tactical Aircraft Moving Map Capability 145. Tactical Aircraft Moving Map Capability (TAMMAC) 33. ntegrated Maritime Communications Systems (IMCS) 34. S-3B Weapons System Improvement Program Phase II WSIP II) 35. Underwater training System "(Mobile) 36. DC-9/C-9B Upgrade Standardization Modification Program § Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating Unclassified MNS to Unclassified ORDs (continued) 37. Meteorological Data Collection Capability 38. Mine Warfare Tactical Training Range 39. Naval Aviation Chemical and Biological Warfare Survivability 40. ‘Mine Warfare C4I System 41. Real Time Tactical Meteorological and Oceanographic (METOC) Assessment System (RTMAS) 42. C-12/C-20 Installation of Safety Enhancing Equipment Program 43. UH-1, CH-46, and CH-53 Improved Crash Attenuating ^Passenger/Troop Seats 44. Joint Logistics Over the Shore (JLOTS) Support Systems 45. Forward Deployed CVW-5 F-14 Simulator 46. Lightweight Reusable Expeditionary Airfield (EAF) Mat 47. Computerized Dead Reckoning Tracer (CDRT) 136. iComputer Aided Dead Reckoning Tracer (CADRT) 48. "Secure Voice, Long Range Communication System for the KC-130 49. Aircrew Protection u107.j Joint Service Aircrew Mask (JSAM) 113.]Aircrew/Ejection Seat Locating Radio/Beacon 117. [Aircrew Laser Eye Protection (ALEP) "120. [Joint Protective Aircrew Ensemble (JPACE) 131.: Joint Protective Aircrew Ensemble (JPACE), J3-004-II 50. METOC Numerical Modeling Capability for Military Operations 51. Squadron Management, Automated Risk Tolerance and Reporting System (SMARTR) 52. Helicopter Passenger Personal Protection System Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Table Relating Unclassified MNS to Unclassified ORDs (continued) 53. METOC On-Scene Analysis and Forecast Capability 54. Systems To Enhance Aircrew Situational Awareness 55. ^Oceanographic Data Collection 56. Advanced (Strike/Amphibious) Anti-Radiation Guided Missile (AARGMJ 57. Aircraft Wireless Intercommunication System " ( w T c ’ sj 58. Assault Support Aircraft Survivability Enhancements 59. Jmproved External Lifting Device (I ELD) 60. CH-53E Secure Voice, Long Range Communications System (SVLRCS) 61. DOD Nuclear, Biological and Chemical (NBC) ^Defense 46. Lightweight Integrated Nuclear, Biological and Chemical (NBC) Protective Garment 92. Nuclear, Biological, and Chemical (NBC) Joint Warning and Reporting Network (JWARN) 62. Joint Modeling and Simulation System jjMASS) 123. Joint Modeling and Simulatin System (JMASS) 63. Computerized Simulator Debriefing System 64. L Joint Command and Control Capability (JCC(S)) 65. Landing Craft Utility (LCU(R)) 6 6 . C/KC-130T Avionics Modernization Program 67. Amphibious Assault Ship (LHA(R)) 68. Maritime Prepositioning Force for the 21st Century (MPF Future (MPF(F)) 70. Enhanced Maritime Prepositioning Force (MPF(E)), Revision 1 69. Tacticaf Acoustics Measurement and Decision Aid (JAMDAJ 70. Airborne Electronic Attack (AEA) in Support of Joint Suppression of Enemy Air Defenses (JSEAD...) 03 APPENDIX S POPULATION OF NAVY UNCLASSIFIED TIME-CRITICAL TARGETING SYSTEMS For the Program Objectives Memorandum for 2004 (POM 04), Navy counted a population of 517 unclassified Time Critical Targeting (TCT) Systems. This count was never officially approved and remained in the working papers used to prepare POM 04. For PR 05, Navy is creating new lists using the Assistant Secretary of Navy for Research Development and Acquisition (ASN [RDA]) Acquisition Category (ACAT) list and the Chief of Naval Operations (CNO) budget database. CNO uses a standard data base called WIN PAT to list ail budget related Program Elements (PE). A PE is any element of a program that receives direct funding, e.g., training, systems, weapons, clothing, et al. The WIN PAT data base lists include far more than computer-based systems. They must be filtered to separate computer-based systems from other resources. This practice of identifying collective systems related to a mission and that will be part of the budget or budget review is relatively new. Even so, it only focuses on certain Mission capabilities and does not necessarily represent all Navy systems. This appendix lists the population of Navy systems that were identified for the Time Critical Targeting systems that were candidates for the Program Objective Memoranda for 2004 (POM 04) budget. The list consists of working papers provided by OPNAV in June of 2001. The POM 04 working paper list is represented in table on the following pages. The lists for the 2005 budget review (PR 05) have not yet been consolidated and provided as a single list. /^O R Ds for many Time Critical Targeting Systems do n o t\ exist. This makes it difficult to know the requirements of the systems and whether they should exchange information with other systems— hence, the potential for \Jnteroperability problems. ___________________ 438 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 | AM | ACAT 1 SHORT TITLE { L O N S TITLE | PEG ] PM I LEAD M /SO I 3) |L R lP l|L R IP Il|M /S II if IOC I ‘ADVANCED FIELD 00084 IC AFATDS JSOW ARTILLERY TACTICAL DATA 1 JOINT STANDOFF WEAPON MARCOR IS ARMY 81/03 89/08 ‘89/08 iN/A :N/A 95/12 00/03 01426 j IC (BASELINE) JSOW (BLU- (BASELINE) ? JOINT STANDOFF W EAPON PEO(W) PMA201 S NAVY N/A 89/06 92/06 97/02 ' < I 98/10 HC ; 501427 IC 108) (BLU-108) PEO(W) ■PMA201 <NAVY N/A N/A 95/04 98/12 i 02/3Q I01/4Q { | LONGBOW I ■ ’ • ‘ I ; 00528 IC HELLFIRE LONGBOW HELLFIRE MULTIPLE LAUNCH ROCKET N/A ! V " ARMY :■ i f ; i s I 0061V ;IC IMLRS TACTICAL SYSTEM t a c t ic a l t o m a h a w k • ! . ‘ ARMY ‘ ■ ■ : i < i 01425 IC TOMAHAWK (RGM 109E/UGM-109E) ADVANCED LAND ATTACK PEO(W) {PMA280 ! NAVY N/A N/A ■ 97/12 02/3Q >03/20 04/1Q 04/4Q i 01607 < ... id <ALAM : i MISSILE | COOPERATIVE PEO(S) PEO jPMS520 t NAVY ............ \ ■ i 00256 ID ICEC i 'ENGAGEMENT CAPABILITY ‘JOINT AIR-SURFACE (TSC) PMS465 NAVY AIR N/A 94/11 ......... <95/05 r ■ < 99/05 00/04 ; 01/11 { I < 01309 ID : JASSM i STANDOFF MISSILE PEO(W) :PMA201 FORCE 95/08 {96/06 02/1Q N/A J03/2Q 03/4Q ; t i < < JAVELIN ADVANCED ANTI-TANK PEOTacti SFAE- i : t " j | 00500 ID (AAWS-M) W EAPONS SYSTEM - JOINT DIRECT ATTACK cal MSL < MSL-AM ARMY AIR i < .. i T ' ' ...... 00501 ID JDAM MUNITIONS PEO(W) <PMA201 C O o CM o > L U o C L O L L 93/10 95/09 97/04 <98/06 01/1Q i i : JSOW JOINT STAND-OFF ' "j.......... ; < ! ; 100512 ID (UNITARY) W EAPONS (UNITARY) PEOW) PMA201 NAVY N/A N/A 95/04 02/1Q ! 03/1Q sH/C ; ■JOINT TACTICAL < AIR I ..........t ’ < i 00515 i ID Ij t id s {in f o r m a t io n ! FORCE < ; i s i .................................. : I AIR r ; i j { |00597 ID MILSTAR I MILSTAR i SMC/MC: FORCE s i I | { < IF/A-18 ADVANCED i i ; i . ! I <01293 II A DVTFLIR TARGETING FORWARD PEO(T) {PMA265 NAVY N/A N/A {97/11 ‘01/2Q |N/A 03/1Q { < < i : A e g is w p n AEGIS W EAPONS SYSTEM P E O frsC | i .......’ ’ < ...... }' \ i 00080 II SYS MODS MODS > ;PMS400 NAVY < { i 78/03 ' ADVANCED MISSION i ....... I ! ........... i i 01371 II AMC&D COMPUTER & DISPLAYS NAVAIR PMA209 NAVY N/A 98/04 98/04 [01/3Q } 02/3Q 0 5 /3 0 < < SSS; ADVANCED SEAL . . { ■ < 100063 II ASDS DELIVERY SYSTEM (ASDS)/ ■ADVANCED TACTICAL AIR SEA 92 PMS395 NSW 89/07 94/09 i i i " " f 0 1 /03; ; { I00194 III ATARS RECONNAISSANCE SYSTEM PEO(T) PMA265 {NAVY ; < ; { i Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) [ AN I A C A Tl SHORT TITLE 1 LONG TITLE r e d f PM' LEAD | M/SO I M/S • I M/S II i i.prp i | l r ip i { M/S I: j IOC MARINE C O R P B C S M bAT ‘a ir MARC \ ... ........ 1 j01692 II (CID IDENTIFICATION (CID) MARCOR D E FE N S O R (98/10 01/01 03/03 !n /a N/A 04/07 05/05 I EXTENDED RANGE GUIDED i01244 ■ II Ie r g m MUNITION EX 171 PEO(S) PMS529 NAVY 96/06 96/08 (02/10 04/10 (05/04 05/01 ! " ! F/A-18 HIGHER ORDER : ■ j01600 ill F/A-18 HOL LANGUAGE PEO(T) : PMA265 NAVY N/A N/A N/A N/A N/A i N/A j (F/A-16 RADAR F/A-18 RADAR UPGRADE ■ i ' [00409 II UPGD (APG-73) PHASE II PEO(T) ; PMA265 NAVY N/A N/A (89/06 95/02 - - i 96/08 i • F/A-18 TAC F/A-18 TACTICAL' j : 101294 ill REECE RECONNAISSANCE SYSTEM PEO(T) 1PMA265 NAVY N/A N/A 96/12 97/02 >98/02 00/07 00/4Q ! GLOBAL COMMAND & !" ;00695 II GCCS-M CONTROL SUPPORT SPAWAR SPMW157NAVY 98/06 N/A jN/A ; 98/06 98/05 ! STANDOFF LAND ATTACK " | ....... f : j00874 i» SLAM-ER MISSILE - EXPANDED PEO(W ) 1PMA258 NAVY N/A N/A j 95/02 (97/03 nn,nt: 00/06 ;............ t " i TACTICAL CONTROL i .... I".......... i01326 ill TCS (SYSTEM PEO(W) (PMA263 (NAVY N/A 97/03 00/02 JN/A [N/A TBD i ; TACTICAL UNMANNED .............. i I i (01038 II UGV GROUND VEHICLE MARCOR CBG ARMY 94/09 :96/02 03/01 06/10 ■ ANTI-ARM ORW EAPONS ; .... ;' >01374 III AAWS-H SYSTEM HEAVY MARCOR CBG NAVY 97/03 I AUTOM ATEDDIGITAL ................. 101480 III ADNS NETW ORK SYSTEM SPAWAR (PMW158 NAVY N/A N/A 99/12 00/01 N/A (00/09 97/09 j AGM-114K I (01357 III HELLFIRE II AGM-114K HELLFIRE II PEO(W) PMA242 ARMY N/A N/A N/A (N/A N/A N/A i ! [ AN/TSC-96A AN/TSC-96A SATELLITE f j [01182 III SATCOM COMMUNICATIONS CENTRAL; MARCOR IC NAVY ... ; : 1 i (01610 (III (AN/WSX-6 SHF SATCOM TERMINALS ............... ......... ............ SPAWAR PMW 176|NAVY 74/10 . 74/10 " 78/10 !n /a N/A - 91/03 j 92/10 | (00168 HI APS AFLOAT PLANNING SYSTEM PEO(W1 PMA281 NAVY N/A N/A 88/08 [93/09 94/08 i | f .... ADVANCED TOMAHAW K .......... \ .......... " i | (01306 III (ATWCS W EAPONS CONTROL iPEO(W ) PMA282 NAVY N/A N/A 94/09 (N/A 98/09 j i COMMONS AVIATION ..... 'j......... "] ■01380 1 1 1 CAC2S COMMAND & CONTROL MARCOR U S NAVY 97/07 00/08 02/06 | N/A N/A 04/10 [06/01 [ r " ■'7................ COMMERCIA W IDEBAND ........... I > (01485 III (CWSP SATELLITE SPAWAR PM W 176NA VY N/A 98/07 98/07 (98/07 99/10 01/03 39/02 j S ' EMBEDDED GPS INERTIAL (AIR ; "' • ; t ■01604 III [EGI NAV SYS (AF) NAVAIR PMA209 FORCF N/A N/A N/A N/A N/A 94/UJ 0 O ; Si o © o CO o r-« 5 r- © F Q S 3 1 1 J 2 , O 1 - 2 o < 2 Is - o © © 1 I : a < jz ■ .....;..... K 0 ,- S ; S ' S'. t - CM h - a > o as I 1 T* o o O r- o © C O o 8 C M r— C M © o C O 5 C O © C O ; © o © . . . p ■ o ... p C O © o 5 © ; C O © o o s ...1 . © © 0 0 © . 2 SN/A 2 5 © .1 :....1 i \ 0 0 /0 1 n. : o © © © C O © ■ ....I . 1 :.... S C M C O © JN/A ;....1 ; ’ I 1 J , N/A 5: 2 < 2 <: 2 © o C O © V//N C M O O © < 2 < 2 1 N/A 1 H ! a I I a! £ < * •= o < a. © CM © CM CM CM C O 3 $ 2 2 0- C L C L C O j — UJ LLi L u y j § s SaS Sb PS C O iii > - q : c o c. 5 < co Q > O L U S 0 - . _ C O U . 0- ~ = = = — — = h - c o t o CO 5 r~ © C O C O o ; ’ « * o © CD I O ? ' 5 ? CM O o o o _ . . . 8 . O o O h - CO h - CO ' © CO : ^ ^ ^ = sc — iO © ^r © T ** © sc co CM C O o o o o S: CM 441 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Tim e Critical Strike Program December 2000 (continued) o o m , ' K I S I S ! C O o C O ^ p C M C M o C M V” ; < 3 5 ; O n: 05 z 05 o > C M O 55 © 05 . . . ..w .JP S ... 05 05 96/03 Q C D 3 — C M ' 00 05 05 • O O O ; s 1 o V/Ni j i L V/Nj 1 J V/Nj C O . £ 3 (O C J i < i < 1 < z Z z z .........'___ Z _ : 95/05 5 z C M a > 5 s - o 05 O C O o 05 05 <r C O § r*- 9 o r- : © . J C O 0 5 r> - 05 C O 05 r-« 05 ; z |n /a 00 o in 05 C M 5 00 05 94/10 ....s - .... C O 05 0 5 o * . CO O i O : CO C M 0 5 O 0 5 ; CO ; h- : o T ~ o n : CO 55 0 5 0 5 0 5 z < . < < ■ .... — Z J * ; < < : ; Z z z l i S l i l t .1= | c a : - e S < 2 ^ £ b § S I ;< 3 _ _ i § 8 S S SSSgSciSS o m y o! , , . ^ U J —' £s ss p - IA. «5 ~ u i u j 3 i 442 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Tim e Critical Strike Program December 2000 (continued) a in CO p T" o o 0 5 m 0 5 CO r- o o O o CM 0 5 I s - O) O) o > 0 5 > - ' > < Z C M < z z 0 5 O x— O CD O H C § C M § h- O o 05 o o O CD 0 5 o o in o C O 05 05 05 r~ O CO 0 5 0 5 O C M o CO o C M - O C M 0 0 05 CO 0 5 o CO 05 K 05 CO .......0 5 ; CD 0 5 05 ....... ......... < . ....Z Z < z ^ ; .....i < Z < z > o V/Nj < ......z < o in 0 5 ; .... 1 < . . Z , . ...... _ Z 9 5 / 1 1 < z - M- O in 05 1 C M i 5 O C M s 1 1 CO o 55 05 95/03 > • > • > > > > > < < < r < z z .....z _ z N - m .... o ’ g C O 5 s C_3 o a . C L q ; V C O o V C : C J o < < V C a : o > < < L U ; 2 a . z o C O 7 . _ 5Qz i n in Ijs ii S 28 £ O < : < O Q | ....% W 0 5 c o ; c o IU V C $ 5 ! 1 ... E S : w « a a :; 8 vc < . .8 ; V C o . o a : < S S 2 o b L D Q U U J O C O O T n O < o w 3 p 2 — o . o w >- I >< < c l O m u j P O l l l i l l ^ QUjf t l Z J _l a _t CL LU 2 : s s § 3 s s § § 5 a S S I s ?Pc hWf 0 - Q C C O o Q O 0. C O CO U i CO C l L U O C D 2 £ £. £ •« - in cm to CM CM C O •r- - T“ O Z o a: s U J L U 8 C O ff. a : P i gSST l o o - < 5 C O Z i— to s £ • a : s z j— |— 3 C O £ £ £: £ £ r-- 8 h- o o C O C O I o o o o CO CO r - . c o CO CM 443 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. t Time Critical Strike Program December 2000 (continued) I AN f A C A t] SHORT TITLE { 01092 IC LONG TITLE 00326 IC 01214 IC 00408 IC 00916 IC 01615 ID 01422 ID 01138 ID 00682 ID U1456 lAC 01603 IAC 01396 IAC ; 01478 Ha m ) 00096 IC 00121 IC 00137 IC 01405 IC 01407 IC 00315 IC AV-8B REMAN AV-8B REMANUFACTURE 1DDG-51 GUIDED MISSILE DDG-51 ; DESTROYER E-2C REPROD E-2C REPRODUCTION ; F/A-18 E/F - NAVAL STRIKE ! F/A-18 E/F FIGHTER f SSN-21/BSY-2 SEA W OLF 1SSN-21/BSY-2 i CLASS NUCLEAR ATTACK {NEXT GENERATION i CVN(X) NUCLEAR AIRCRAFT DD 21 TW ENTY FIRST DD 21 CENTURY DESTROYER | PEO } PM | LEAD | M/S 0 | M /S *{ M/S II | LRIP'ijLRIP ll| M /S Ifll IOC :PEO(A) PMA257 NAVY N/A N/A N/A N/A 94/03 97/08 PEO(TSC i S ) PMS400 NAVY 81/06 83/12 91/01 92/04 :93/01 591/04 PEO(T) PMA231 NAVY :N/A jN/A N/A : N/A : 94/09 j 92/04 PEO(T) PMA265 NAVY IN/A jN/A {92/05 '97/03 <98/11 00/03 I00/09 P EO (S U B ! ) f 1PMS350 NAVY N/A 83/12 85/06 88/06 88/06 97/07 JSF VIRGINIA CLASS BAIM MRP II NTCSS DMS {AIM-9X AMRAAM AN/BSY-2 O H -60S IC M W : ..................... CVN-68 CL i) jPEO(EXW ! i ■ j) iPMS378 iNAVY 96/06 00/06 02/04 N/A 14/03 j N/A : 20/03 :X1 ! N/A ;11/08 JOINT STRIKE FIGHTER 08/08 01/03 ; 107/10 06/06 i PEO(S) PMS500 NAVY 95/01 {98/01 103/11 SN/A i ' I AIR t jPEO(JSF) S JSF FORCE {VIRGINIA CLASS SUBMARINE!PEO(SUB : {(SSN 774) !) 'PM S450 .NAVY 92/08 {94/08 95/06 {97/09 BASELINE ADVANCED i I ]" INDUSTRIAL MANAGEMENT SEA 04 S SEA 04D1 NAVY i MANUFACTURING I j RESOURCE PLANNING II :NAVAIR PMA203 NAVY N/A IN/A N/A ;N/A N/A N/A NAVAL TACTICAL COMMAND SPAWAR i i ? ! i SUPPORT SYSTEM 1 00 PMW151 NAVY 95/04 !96/06 97/03 !N/A [N/A 00/01 00/01 j DEFENSE MESSAGING \ i i {SYSTEM I USD 1PMW 152NAVY ; 89/02 94/12 95/05 jN/A jN/A 199/09 >98/08 i AIM-9X(SIDEW INDER) ADVANCED MEDIUM RANGE AIR-TO-AIR MISSILE j PEO(T) 1PMA259 >NAVY N/A j 12/94 j 12/96 j 00/09 N/A {03/3Q (03/4Q j j AIR j PEO(T) PMA268 FORCE N/A j 78/11 >82/08 PEO(SUB i ) PMS425 NAVY 1 86/06 88/03 SSN-21/BSY-2 CH-60S VERTICAL REPLENISHMENT {PEO(A) >PMA299 NAVY N/A {N/A 98/05 COMMON MISSILE W ARNING ! ; SYSTEM iPEO(T) SPMA272 iARMY N/A jN/A ,95/02 ■NIMITZ CLASS NUCLEAR iPEO j i AIRCRAFT CARRIER CARRIER 1PMS312 {NAVY 87/05 f 09/93 I ! 91/05 i(NAVYj !.......> .......i H/C (H/C 00/01 jN/A =01/03 >01/12 I' T ; N/A N/A '03/4Q > 80/10 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. I Time Critical Strike Program December 2000 (continued) I ;-.,v 00508 j00541 [00639 [01406 00667 I00679 r . . . j00522 ! j00868 j01088 j00880 (00929 I" [00977 [01028 (01056 i....... [00017 (01424 [01486 [01404 I' !00568 ac a t{ s h o r t rrrcej lo n g t i t l e f peo { pm J lead jw/s o| m/s » | m/s n J lr ip rfiRip «|m/s w ,l ,oc I JOINT PRIMARY AIRCRAFT AIR JPATS STRAINING SYSTEM (T6A) iPEO(A) [PMA273 i FORCE 93/02 93/02 ! 95/08 95/08 ’ I01/1Q :03/4Q i SLHD1 AMPHIBIOUS ASSAULTS PEO (EXwj [ I , [ | ! LHD-1CL ISHIP i) IPMS3771 NAVY I [81/10 82/07 IN/A I N/A ! 85/08 >90/10 ’ [NATIONAL AIRSPACE 1 ESC/GA AIR 07/9 N/A [N/A 01/00 ! iF O R C E jH /9 0 ‘07/92 i i [air , ■ i " i i r ' i...... NAVAIR (P M A 213iFO R C E .90/11 192/11 [95/07 jN/A j00/02 [01/2Q 1 03/1Q !................... t AIR ''" I " ....t ..............] .............i ...........j........ ' " ! .......... I I FORCF NAS ‘SYSTEM NAS [NATIONAL AIR SPACE ‘MODERNIZATI (MODERNIZATION "" 1NAVSTARGL08AL.... NAVSTAR GPS: POSITIONING SYSTEM NAVY EHFSATCO M ■NESP ‘PROGRAM [AN/USC-38(V)J j SPAW AR jPMW 176[NAVY jN/A [N/A {89/06 [89/06 (N/A [93/04 [94/04 1 ................... LAMPS MK III BLK II................. "1................ j ............... | ............!.................... ' f iSH-60R (UPGRADE PEO(A) (PMA299 (NAVY N/A [SHIPBOARDSINGLE SPAWAR !PMW 179(ARMY [84/03 PEO(TSC ) (PMS422 jNAVY I i [85/06 (N/A I N/A (2/92 (1/94 j PEO(TSC *............................. 1 ........ S ‘............"............" " ........ ........... " ! • PMS422 (NAVY !N/A PEO(EXW jPMS325 ) R (NAVY |N/A (93/04 [SINCGARS ‘CHANNEL GROUND & I SM-2 (SLK [STANDARD MISSILE 2 ■ lll/IIIA) (BLOCKS lll\A\B\ ISTANDARD SURFACE-TO-AIR SM-2 (BLKIV) [MISSILE (BLOCK IV) STRATEGIC i ' ‘ ~ SEA! I FT STRATEGIC SEALIFT T-45 UNDERGRADUATE JET T-45TS , PILOT t r a in in g s y s te m TRIDENT II iTRIDENT II -SEA LAUNCHED MSL [BALLISTIC MISSILE [V-22 OSPREY- JOINT V-22 OSPREY [ADVANCED VERTICAL (AD VA NCEDAMPHIBIOUS" ASSAULT VEHICLE " ■ [ADVANCED EXTREMELY (HIGH FREQUENCY (GLOBAL BROADCAST (SERVICES | JOINT PRECISION [APPROACH & LANDING (AAAV AEHF ‘GBS JPAL 3 (LPD 17 N/A [7/93 (98/11 I01/2Q jo3/1Q j02/2Q j N/A 185/10 iN/A iN/A (95/02 [94/12 I i i flllA- IlilA- N/A 86/08 95/05 I 99/08 93/09 (93/09 98/08 97/10 j PEO(A) (PMA273 (NAVY (75/07(84/09 DRPM- : T . SSP [NAVY ( [77/10 83/10 SSP PEO(A) 84/09 ‘87/09 (92/04 95/01 92/11 94/09 97/04 (87/04 (90/03 ; IMV- 01/1Q (01/12 07/10 [07/12 j PMA275 > NAVY 181/12; 82/12 DRPM(AAfDRPM- } j |~ A) I AAV (NAVY jN/A [95/03 02/01 S 05/07 ~........ I.......... iA ( K I ......j' I" > 1 ........1....... ! •FORCE! I t t i i | | . , i ■ r i i ] PM W 176!FORCE!N/A [97/05 97/05 197/11 (N/A ‘00/09 1 00/09 i ;AIR j ........! j ! j i i i PMA213 FORCE196/05 [02/1QS02/1Q [N/A iN/A TBD (04/3Q i [USD [n a v a ir LPD 17 CLASS AMPHIBIOUS (PEOtEXW! ]...... ASSAULT SHIP j) (PMS317 [NAVY [93/03 96/06 N/A I N/A i 08/07 (H/C Tim e Critical Strike Program December 2000 (continued) 2g: 58 0 > O a o o 1 r * * - o , o 1 a C M CO O 0 5 $ o Z CD 1 O X z_ ; _ c o S ; e Z j _ o CM r - 5 ^ O N- O 0 > 0 5 0 ^ : CO a M - © CO • x , CD CD ,_ .0 : CO ■ CO CM CM CM 0 5 5 © o • 5 — •!— , O S a 5 CO CO CM © o o M- o O ) 0 5 o > 0 5 ___ • .. „ : S i CD O ; h - CM © , O O ; 0 0 1 O O o O ; 05 O ’’ J' CM ; CO CD CM o > 9 © O o h*. CM iO ■ S j- o co i ^ ' a t a> ^ , .. . ® ? ' ; c o ; o < r— < : CO 00 i z O S o 5 z a; <! z o C M i * » ■ © o > < Z I I U J UJ O U J o lQ.Sfi.5; C O o_ L__ I 1 < _ - m m 0 l < Q _ O- > U J O ; U J « < r y ~ t= C L z o 9 o u j o 5 is :' i a: < uj 3 446 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) * -s S f AK | ACAT [ SHORT TITLE I LONG TITLE f PEQ i PM I LEAD f M /S 0 | M/S It M/S it 3 1 - i ii| m /s i i i | io c MEDIUM TACTICAL VEHICLE ■01108 ; II MTVR N T D S im p r REPLACEMENT N i \V Y TACTICAL DATA SYS iMARCOR iPEO(TSC CSLE NAVY N/A ■ 95/10 i 95/10 ■N/A ;N/A i ■ 00/12 I ■01/06 ■ 1 00698 II (ACDS BLK 1 ) IMPRO (ADVANCE COMBAT I) PMS461 ■ NAVY i 89/11 | [99/12 ! . ; j ...... " ORGANIC AIRBORNE AND [PEO(MU i ; T [ 101589 ■ 1 ! OASIS SURFACE INFLUENCE iW) PMS210 NAVY [00/11 00/11 j 04/03 ! (04/12 i IAV-8B OPEN SYSTEM CORE | i ! i ........ 5 • ; - ! 'i' J01428 II [OSCAR [a v io n ic s r e q s :PEO(A) PMA257 NAVY N/A !n /a 97/03 ■ N/A !n /a (02/3Q ■ 03/3Q s [P -3X S U W IMPROVEMENT !“ ; ......... r i ' T ■01100 II jP-3 AIP ■PROGRAM 1 PEO(A1 PMA290 NAVY 94/09 i 94/09 94/09 !N/A i I 94/09 f |P-3 SUSTAINED READINESS 1 ! i.......... i 01105 II lP-3 SRP ‘PROGRAM |PEO(A) PMA290 [NAVY ■ 94/09 ! 94/09 (94/09 1 n /a ? 94/09 ] ■ PHALANX i PHALANX IMPROVEMENT TPEO(EXW ■ ; i -/ I ■ 01168 > 1 1 ■ IMPROVEMEN PROGRAM !) PMS472 NAVY ! I [ ■ 99/04 I QRCC/SSDS QUICK REACTION COMBAT [PEO(TSC ..... I (00771 II MK 1 CAPABILITY/ SHIP SELF 1 ) PMS461 ■NAVY 95/05 I _ 98/03 (97/06 j ! RAM BLK 1 ■ 5IN R O LIN G AIRFRAME jPEO(EXW f ; ■ |01211 II UPGD ■ MISSILE BLOCK I [RAPID AIRBORNE MINE !) |PEO(MU PMS472 NAVY ■ ? 94/05 97/04 98/03 00/01 HC f 01590 i > 1 1 ■ RAMICS [CLEARANCE SYSTEM REMOTE MiNEHUNTING (W) jPEO(MU PMS210 [NAVY 1 i 01/03 ; ■ 05/03 [00783 II RMS SYSTEM SURVEILLANCE TOW ED IW ) | PMS407 NAVY t [96/05 ! j 99/12 / j ■05/01 05/10 [00963 ll ■SURTASS LFA ARRAY SENSOR (SPAWAR PMW 182 NAVY [85/10 [85/10 90/06 ■ 90/06 N/A 02/10 99/01 i ........ i i TMPC THEATER MISSION I I ■ r [01431 !" UPGRADE PLANNING CENT UPGRADE jPEO(W ) PMA281 NAVY (N/A ■ N/A [ ' N/A [N/A I N/A ■ 94/02 ; ; j VERTICAL TAKEOFF AND j ( ' i [01430 [» VTUAV LANDING TACTICAL IPEO(W ) PMA263 NAVY N/A [N/A 00/02 01/3Q N/A 03/3Q 03/4Q j ......... ■ AREA AIR DEFENSE jP E O ffS C I J [01419 [in AADC COMMANDER PROGRAM 1 ) PMS467 ■ NAVY (N/A [00/03 00/03 03/10 104/06 [06/09 ‘06/09 i ■ AAR-47 AAR-47 MISSILE W ARNING I ■ ■ j ■00020 in MISSILE SYSTEM PEO(T) PMA272 NAVY I N/A [75/08 82/08 ■N/A 87/05 ADVANCED CHEMICAL S E A 0 5R | I " ■ ... 00246 in ACPG PROTECTIVE GARMENT, SEA 05 1 NAVY [95/05 95/05 97/04 [97/07 ADAR AIR DEPLOYABLE ACTIVE 1 ......... • " ■N/A i 1 i ■ [00035 [hi (AN/SSQ-101) RECEIVER (AN/SSQ-101) j PEO(A) PMA264 NAVY ■ N/A 92/05 (99/03 j [99/05 ■ ■ ADC MK3 MOD SAWS; ADC MR 3 MOD 0 (PEO(SU8 j .... , i I I i ' 00038 in 0 (ADV TOPREDO DECOY 6)1 !)........ PMS415 NAVY i 175/10 ; 79/10 [88/12 i [95/08 Time Critical Strike Program December 2000 (continued) I AN (ACATl SHO RT'^S'/" 1 LONG ~iTL£ 1 PEQ ( PM | LEAD |M/S 0 | M/S I { M/S II [ LRIP l{l RIP lljM/S llif IOC ,ADC MK4 MOD SDWS; ACOUSTIC DEVICE PEO (SU6 ' i 0 COUNTERSEAURE MK4, MODi) PMS415 NAVY I 62/10 '86/06 ADV j£D V STRATEGIC: AND 00039 III i “ (01356 III j i (01167 III i ~ i >01079 III >01432 lilt {01356 III r : j00869 III ? 1 : j01463 III 00731 III 01153 | III 00138 J >01364 I ....~ " i 101111 00149 ill 00163 1 1 1 01345 III 00126 III 01135 III ; (01160 (III STRATEGIC & -TACTICAL IR EXPENDABLES .................... AGILE GROUND LASER EYE AGLE j PROTECTION SYSTEM ALE-47 CM DISPENSER ALE-47 COUNTERMEASURES DISPENSER SYSTEM iALQ-164 jALQ-164 TACAIR ECM POD AN/ALG-144 f ~ ............ INFRARED CM lAN/ALQ-144 INFRARED CM 95/05 198/12198/12 |N/A [N/A PEO(T) ; PMA272 USAF j fMARCO ( ] MARCOR IR /N B C (NAVY i f ( air ' 7 " ..t PEO(T) (PMA272 >FORCEj80/05 [83/08 1 88/08 -92/08 { PEO(T) [PMA272 (NAVY I N/A (N/A IN/A |N/A jN/A PEO(T) (PMA272 ARMY N/A IN/A N/A I N/A j - 1 - MARCOR | CBG AN/ARC-210 i AN/ARC-210 COMBO RADIO AN/SLQ-10 'AN/BLQ-10 ELECTRONIC ELECTRONIC SUPPORT (ES) SYSTEM COMMAND &CO N TRO L SYS AN/KSQ-1 I FOR AN/KSQ-1 AN/PVS-7B A N /P W S TB NIGHT VISION (NVG (GOGGLE AN/SCO-20 1 ........ UPGD (AN/SLQ-20B UPGRADE AN/SLQ-48 A N /S L 0 -4 I MISSION MP1/MP2/MP3 PACKAGE 3 AN/SPQ-9B AN/SPQ-SB RADAR RADAR I IMPROVEMENT (ANTI-SHIP ..................AN/SQQ-32 ........................ AN/SQQ-32 j SONAR/MINEHUNT ................!'AN/mV-T .................. AN/WLY-1 (COUNTERMEASURES anti-personnei: APOBS (OBSTACLE BREACHING APR-39A(V)2 RADAR APR-39A(V)2 (WARNING RECEIVER A-RCI PHASES ACOUSTIC-RAPID COTS i I-III INSERTION (A-RCI) PHASES l~ ARMORED ARMORED VEHICLE I VEHICLE DTV (DRIVER’S THERMAL VIEW ER (MARCOR CBG NAVAIR (PMA209 (NAVY (N/A (N/A (85/05 92/06 PEO(SUB ) IPMS435 NAVY (9 2 /1 0 ‘94/10 (94/10 99/11 (N/A PE0(ExWf ! ( ..........I i PMS377 NAVY I i (89/06 95/03 I (ARMY I NAVAIR IPMA213 (NAVY IN/A (93/09 (93/09 (N/A j p e o (m u i r ■ j j i ............. :.............r W ) PMS407 (NAVY ; | j j PEO(EXW: f 94/05 02/2Q 101/09 93/08 . 90/08 i i...... 87/02 i ! ! j 94/04 95/01 j < ■ ( (0 0 /1 0 I | j95/12 95/10 | ! I {97/02 ; ! ! 97/04 (99/07 ! ) -PMS440 (NAVY PEO(M01 1 W ) [PMS407 (NAVY PE0(SUB1 ) |PM S41r NAVY (Erig Suptv MARCOR Equip (NAVY 194/10 ) j {01/07 (00/07 i (82/09 (89/12 j92/02 (94/08 >99/03 j 88/10 95/12 {98/08 i [01/01 i i [88/10 93/11 iN/A N/A 99/01 02/03 I PEO(T) (PMA272 fARMY iN/A [N/A 88/05 PEO(SUB f [ [96/05 >00/3(2 i PMS425 (NAVY NAVY 96/06 98/04 (99/04 00/10 HC Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. i < o Time Critical Strike Program December 2000 (continued) AN 1 A C A T fS H O R T T U IE I LONG TITLE I PEO t PM j LEAD { M/S 0| M /S (| M /S llJjjRIP ifuRIP ll|M /8 lti| IOC ASSET TRACKING MARC 5ATLASS LOGISTICS AND SUPPLY MARCOR C4ISR OR i93/08 97/08 197/08 N/A N/A 99/05 99/05 01533 01534 III ; 01626 : '00207 illl I 0 0 2 1 I |ift 00219 ; HI i i01322 jlll ( i i00266 illl ! 01627 III ! . (01535 III 01205 III 00282 III 01231 III 01436 III 00308 illl 01536 II! 00971 III 01583 illl j ' ' 01387 illl ASSET TRACKING ATLASS II i LOGISTICS AND SUPPLY II+ AUTOSERD/S AUTOMATIC SUPPORT MARCOR ■ MARC ■ ! i i C4ISR OR 93/08 1 97/08 f97/08 iN/A ;N/A 00/01 01/05 j [NAVAIR IPMA260 [NAVY N/A jN/A N/A iN/A I N/A 95/09 |PEO(T) [PMA272 SARM Y iN/A N /A i n /a ! N/A 89/11 iERMIS EQUIPMENT/SUPPORT A V R -2 LASER AVR-2 LASER W ARNING iW ARNING i DEVICE i BATTLE GROUP PASSIVE , , . ■ , iBGPHES-ST ^HORIZON EXTENSION SPAWAR :PMW 163 NAVY N/A 90/12 91/04 iN/A iN/A 196/07198/05 [BOLCHAFF BOL CHAFF DISPENSER (I AU i j i i i DSIPENSER ; 138A) !PEO(T) IPMA2721 NAVY N/A fN/A N/A *N/A I [92/11 i j MK 48 ADCAP COMMON ;PEO(SUBi IPMS404 NAVY i 38/04 101/10 S 02/10 i 03/10 CBASS BROADBAND ADVANCED ) C D L N iCOMMON DATA LIN K -N A V Y [ T f i ; ’(FORMERLY (FORMERLY COMM ON HIGH iSPAWAR 5PMW163iNAVY N/A S 89/05 91/09 |N/A N/A [96/07 [98/08 NAVY N/A jN/A [N/A |N/A N/A [98/04 [CONFIGURATION i A IR - CMIS [MANAGEMENT iNAVAIR .3.1.8 [CONFIGURATION j i r [ ) ; [ * * | ICMIS [MANAGEMENT (MARCOR C4ISR I NAVY 1 96/05 [96/10 (97/05 I N/A iN/A i98/04 (98/06 i i COOPERATIVE OUTBOARD ] i [ | i I iCOBLU LOGISTICS UPGRADE j SPAWAR IPMW163SNAVY N/A I N/A 191/11 :98/07 j N/A i 00/03 [02/3Q i COMBAT DIRECTION | ! i I ! ■ i COMBAT DF FINDING SYSTEM (AN/SRS- |SPAWAR :PMW163;NAVY N/A iN/A [91/02 iN/A [N/A (94/12 (99/01 | ■ COMBAT ; ...................... ................ j i i i i > ! I i COMBAT SHOTGUN I MARCOR CBG NAVY ! ! ; ■ < COMBAT SURVIVOREVADER I [AIR i ! i [ Y i i LOCATOR (CSEL) (AF) [NAVAIR !PMW 187IFORCE!92/08 iN/A 95/11 ;01/3Q IN/A ;03/2Q ITBD I AN/SOO-34A(V) AIRCRAFT PEO(Mu i ! ; j Y 1 CARRIER TACTICAL iW) IPMS411 |NAVY ! | 581/06 [91/04 *94/08 !94/08 j i I \MARC i [ : I I DEPOT WORKLOAD !MARCOR iC4USR lOR I ! i98/08 \ DISTRIBUTED EXPLOSIVE SPEO(MU i i ; i TECHNOLOGY IW ) IPMS407 (NAVY ! *95/10 96/06 I 101/01 *0 3 /1 0 ! DISTANCE I EARNING Y MARC ] J I I i PROGRAM [MARCOR *CSLE OR !97/06 i98/11 j98/11 [N/A N/A i00/02 *01/07 i SHOTGUN jCSEL C v T S C DEPWL ; DET *DL i............ iDMR [DIGITAL MODULAR RADIO [SPAWAR [PMW 179jNAVY 98/08 98/08 98/08 00/02 01/2Q [01/09 [00/05 i Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) § l AN IACAT | SHORT TITLE | LON® TITLE PEO | PM I LEAD tM/S 0{ M/S 11 M/S M| LRIP l|LRIP fl| M/S III] IOC E-6B AIRBORNE COMMAND 01098 M il b 6B ABNCP POST PEO(A) PMA271 NAVY 95/01 95/01 95/01 (95/01 98/09 ; t i EA 6B ALQ-99 EA-6B ALQ-99 LOW BAND i i j01250 M il LBT ( EA-6B ALQ-99 TRANSMITTER PEO(T) PMA234 NAVY N/A N/A 96/09 ! 03/3Q i r {04/1Q 05/1Q 101359 illl BAND 9/10 EA-6B ALQ-99 BAND 9/10 PEO(T) PMA234 (NAVY N/A N/A | N/A N/A ;N/A (97/11 ,99/11 > ‘ ENTERPRISE RESOURCE AIR j ' : ; >01628 III ERP (PLANNING I ACILITY & EQUIPMENT NAVAIR j 00/ESP |......... (n avy 1 ■ N/A N/A N/A N/A N/A l N/A > ... " " i 01466 (III ■ FEM PRO/PC MAINTENANCE (FEM) SEA 04 (SEA04D (n avy 93/12 95/01 ! I (95/06 5 i FIBER OPTICS DATA (SEA05Z ( ■ ■ ; ■ i ; (0 1 1 2 1 ini FODMS MULTIPLEXING SYSTEM SEA 05 B NAVY 91/01 95/03 i 02/11 00/05 ! GENERIC EXPENDABLE I i j00444 ini GEN-X DECOY DECOY PEO(T) PMA272 NAVY N/A 83/05 89/08 N/A >92/05 * j ..H.CH FREQUENCY RADIO ........... {00155 (in HFRG (GROUP SPAWAR PMW179 NAVY N/A 90/05 92/09 92/11 95/10 93/05 (05/06 i......... ' (AN/6SY-1 HIGH FREQUENCY |PEO(SUB ■ (01245 ! m HFUG (UPGRADE (HFUG) (A-RCI DEPT OF NAVY ) (PMS425 iNAVY 97/05 i 99/04 I ■ 99/12 i 00/10 (01290 in INPO INFORMATION NETWORK NAVY | i ! IMPROVED ta c t ic a l a ir i I j (01305 ! in ITALD (LAUNCHED DECOY INFANTRY WEAPONS NIGH i PEO(W) PMA208 NAVY N/A N/A ‘N/A i ' " • iN/A I I" ' ■ 94/12 *01155 J in IWNTD TARGETING DEVICE JOINT BIOLOGICAL POINT MARCOR (CBG (SEA05R ■ NAVY ’ . i i " I (01468 in : JBPDS DETECTION SYSTEM SEA 05 ( 1 NAVY 96/06 (96/12 0 1 /0 1 ; JOINT SERVICE ELECTRONIC r AIR ! 5 ; '01409 in ■JSECST COMBAT SYSTEM TESTER NAVAIR ■PMA260 (FORCE N/A 95/09 95/09 N/A jN/A •01/3Q ■01/1Q : : > " ........ JOINT SERVICE MAR/NB ' ; i ' ■01193 in (JSLIST LIGHTWEIGHT INTEGRATED (MARCOR ,C NAVY 93/11 95/05 95/05 N/A iN/A (97/04 97/04 ; JOINT SERVICE MARC i 01544 m (JSLNBCRS LIGHTWEIGHT NUCLEAR, JOINTSERVICE MARCOR CSLE SEA05R OR 95/01 ■ 98/02 00/08 N/A iN/A I 02/04 01400 jm JSI SCAD LIGHTWEIGHT STANDOFF JOINT STANDOFF WARNING SEA 05 ;1 •SEA05R NAVY N/A 95/09 96/09 N/A N/A 02/04 (01618 »[ JSWILD IDENTIFICATION LIDAR SEA 05 ( 1 NAVY 99/08 01/07 04/01 N/A ;n /a (07/07 ( ( - JOINT TACTICAL TERMINAL ,96/05 i ' i ■ ■ ■ ■ i (01489 in iJTT MARINE SPAWAR r MW179 ARMY N/A N/A 96/09 (98/04 (01/06 (99/10 E5 Pig co 2= * 2 0 < co cl a s j tr <0 ; i § § > O < < : < UJ C L C L z a. < to co co Is < f? Q 3 Offl q ' “ P < 1 a l i i I B I 9 * IB 0 0 ._ ] S® o U J : C ? O C L s . s , 451 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Tim e Critical Strike Program December 2000 (continued) z C M O o < Z - W o © o o o o o > 1 a > o 05 05 1 Z C M 5 C O 05 in o 05 0 5 O 0 5 05 0 3 2 ^ 3 I Z f j n il 5 5 ^ 9 § w a . w » I w 1 o § o o o 00 < r - , © © c o C O o o -___ 05 o 05 < o Z 05 © in o C M 3 o ■ 05 O ^ . C O Q S 05 05 C O 00 1 o < z I'*' < < 7 t z > >- >• > > > < < < . Z : _ . z z o q: C O h- t ; to C M o g < ! 2 U J C L <0 „r~' a . i m o 1 < < uj C L ...... C O ; C O I O v O § o C O o o in 00 05 05 ... n 1 f— ■ o o R CM ^ CO 05 o 05 o i n o o i n o C O 0 5 o Q hi O t -y t L-». C O £ jsci ADN! m o C O <9 O X C O C O ! < ! < — ■ = = ! z r C M 00 o o : t o s ? in ▼ - : o m in 5 C D L U :< Z U J iu C D uj Q -J Z O X w^ e rio 3 <n3S C D L L [V C O < 0 00 o o 8 CM 05 05 CM e 5 : == E == E : 05 05 o CO 05 c o i n C O i n CO CO 05 M * i n o o o o o o o o o o 452 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. O S O l U 453 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. I AN fA C A T i SHORT TFTLE | U M 5 T J T U E "MULTI PURPOSE HEALTH ■01555 iIV (MPHSF (SERVICE FACILITY Time Critical Strike Program December 2000 (continued) ! P EO I PM t fcEAD iw /S Of MAS1 | M /S It j LFttP fjLRIP UjM /S ttt| IOC 'MAR/NB m a r c I MARCOR 1C (OR (97/03 I i l l *01/09 101556 IV jOTV "\.... =01557 (IV JF A LC O N ; : I j01508 IIV (RAC I i ( {01861 IV ;RBC i ( ” 1 (01560 (IV IRSCAAL i ! ''"''j............. " " (01563 IV iSAPI ITRHS i OUTER TACTICAL VEST ! PALLET CONTAINERS “ f .............. .................. ............................................ ! RIVERINE ASSAULT CRAFT RuGG EDlZED BEVERAGE CONTAINERS REMOTE SENSING * (CHEMICAL AGENT ALARM 1SMAL ARM S (PROTECTIVE | INSERTS (TRAY RATiONREATING (SYSTEM 101564 IV i l l i jC0131 IVM (AN/AYK-14 AN/AYK-14 (VPM) IC1440 IVM (AN/UPM-155 AN/APUM-155 ........ b a r r a c k s c r a f t -s m a l l J1386 IVM iAPL(SMALL) I (APL(S)) 1 ........ ...\ ~ ' .......... AQM-37C SUPERSONIC =01307 I IVM [AQM-37C (00169 ilVM ! ARCADE (TARGET IA R C a O E R A D Ia C ' I DEVELOPMENT (01565 ilVM (AS P !.......I....... (01587 IVM j ATE ]01509 IVM )BFA 100211 (IVM BPTl io 1571 IVM iBIVY (BQM -74E (ASSAULT SNOW SHOE (AUTOMATIC TEST “ ' EQUIPMENT I M2 BLANK FIRING ADAPTER BATTLE FORCE TACTICAL. TRAINING IMPROVEMENT (IMPROVED BIVY SACK ( BQM-74E MOBILE SEA (00223 IVM (MOBILE SEA I RANGE AERIAL TARGET |MAR/NB (MARC I M A R C O R jC iOR j MAR/NB JMARC ] MARCOR !C iOR 196/12 (96/12 ;N/A [n /A i 99/04 99/09 MARCOR:CBG MARCOR MARCOR MARCOR jOR {Ma r c c s l e IOR M AR/NB [MARC C iOR MAR/NB [MARC j C (OR MAR/NB (MARC MARCOR C OR NAVAIR SPMA209 (NAVY iN/A PEO(E5(Wf~ > ..___ PEO(W ) JPMA208 [NAVY ~ |SEAo4LT" ... SEA 04 |RB (NAVY f (MARC MARCOR I CSLE iOR MARCOR ITMDE (OR j “ iMARC MARCOR jCBG [OR p e o (e x w ; i .... ) P M S430IN A VY j ...........[MARC MARCOR I CSLE JOR PEO(W ) JPMA208 (NAVY IN/A ............ 80/12 ...... - ■ - 81/12 N/A j N/A ... . !...... .. 82/12 94/03 97/07 } i 98/03 i \ ................. | ..................I (01/10 .......j... ........ 91/09 ]91/12 i .................. 96/12 96/12 HIA jN/A 99/06 99/09 , 95/06 96/09 N/A ........... N/A 86/02 91/05 93/08 (92/04 N/A N/A N/A N/A iN/A 86/08 N/A 95/03 95/09 N/A N/A 98/05 00/10 i'......... N/A N/A i I N/A jN/A j 95/08 i [ ...... . ' 90/06 92/03 94/10 (97/01 ........... : 4: 98/04 99/09 ............ 97/08 97/08 ............. ... j .................. ......... "f............ 97/09 98/09 ....... " .... . 92/10 93/09 j 93/09 j 96/11 97/09 ... . 94/04 I \ 94/04 96/09 N/A N/A 88/02 \ N/A I 91/04 Tim e Critical Strike Program December 2000 (continued) a C M C O T“ o 0 3 ' __ _ _ C O C O C O © O N- 0 3 0 3 0 3 ■ s r O 03 to 03 03 to © © o a o V * O O O : O © O C O CO T ” CO 0 4 03 03 Q © 2 5 C M o 03 o . . . . . . . . . . . 03 O 03 03 .. © © © © a CO 03 a 03 C O © " J - C O O o < O C M e : o o 00 p - CO © 0 0 C O © 03 03 Z , 03 O © © © © o LU LU 81 £ < h © u j 0 1 O u j r n < 0 3 W 3 1 U J 55 X w i < § « y D e a l - ? o . o _ o < t o o iss o d | co (3 0 1 V 0 9 O O O in m c q < o < m — 1 S < L L j C L O < O w m OITM C O U J p C O S 2 & °- t | S X C - 3 U O 0 . U J © uo.6 455 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 0 ) £ 8 ■ £ 3 ’C o 0 ) £ F o o o C M % £ s 0 ) O 0 5 C M O i CO ; o o V O O CM C O in C O 05 CO o: o o o > o © •94/11 C M © 25 S ? I [98/09 01/3Q 02/2Q 2 CO o CM CM C/5 c o Q . CO C l . a l i d I s i 3 > 0 ) U J ° ' 5 P w ic o 5 W ? K CO X % . ill U- p Si S 2 < S 3 S £ w W M j o i i o i P S < 2 s x . > UJ W C D § i ? l C D w < U J o o 456 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) •>i f AN | ACA'I f S H O R T T n x e | IO M G T IT L E PEO ] PM j LEAD ! M/R Q M/r-1 : M /s n ft RL’ :J: r ip :ij M/S M : 5.56 LIGHTW EIGHT MACHINE !PEO(EXWi 01624 IVM LMG I GUN ) 1PMS325 NAVY MARC r i I 01586 IVM LOMAH I LOCATION OF MISS AND HIT MARCOR(CSLE OR 97/07 I f i LONG RANGE LINE-UP........ j I i t 101321 IVM LRLS SYSTEM NAVAIR (PMA2M NAVY N/A N/A 96/09 98/U9 199/06 (01/1Q I'" ’ - (LIGHTCAPABILITY, ROUGH jErig SuptiMARC ! '! ' j ; j01517 I IVM LRTF TERRAIN FORKLIFT LIGHTW EIG HT COLD MARCOR lEaulo OR iMARC ! \ ^ i ' ' i |01338 r ; IVM [LWCW US W EATHER UNDERW EAR SET i MARINE CORES MARCOR 1CSLE (OR [ ' j i 1 194/09 ; 96/09 ;.......... i01414 [IVM ;M31 i EXPEDITIONARY ARRESTING NAVAIR 1PMA251 (NAVY jN/A 98/05 98/05 1 N/A ! N/A 0 2 /20 03/1Q !............ ! ; MARITIME iM ARITIM ETO RW ARD p e O (e x w ; j ........ j .......... I |01454 IlVM FORWARD (LOOKING INFRARED ) 1PMS325 [NAVY s i ! ■ i j i....... j' ( ........................................... ...................j ” iMARC i j f ? 01576 IlVM MB MINIATURE BINOCULARS M ARCO RjCSLE OR ; 94/09 96/09 : ............ ! .......................................... PEO(MU PMSEO I"" \ i01401 IVM MOD MECHANICAL MAIN CHARGE DISRUPTER MECHANICAL TEST, w ) Id INAVY [MARC 96/01 97/08 .......... 97/08 I i...... 1 100/01 00/12 01151 IVM ITMDE MEASUREMENT AND M A RC O RiTM D E i lOR MARC ........... ! ; I j ■ " 01577 IVM MFSS MINI-DRIFT MULTI-FUEL STOVE OCEAN/METEOROLOGICAL/A MARCOR | CSLE !o r r - j ? ; \ j 90/09 96/09 00602 IVM DATA BUOY COUSTIC MINI-DRIFT DATA MARITIME INSHORE CNR j (NAVY j i ■ J . .. 5 01490 IVM MIUW -SU UNDERSEA WARFARE- SPAWAR [PMW 183; NAVY ,N/A N/A N/A j N/A {N/A [96/01 N/A ! MOBILE INSHORE “ .................. j........... f .. ! { ■ 101280 IlVM MIUW -SU i UNDERSEA W ARFARE ICNR j NAVY i j.......... i ; i MK-25 MOD 2 I .................. ......................... .............. PEO(EXWi r i ' i 101470 IVM UBA MK 25 M OD 2 UBA ) (PMS325 NAVY i j \ ! i MK-30 MOD 1 MK-30 MOD 1 ASW TRAINING PEO(MU i ! ....... 1 I ' i 01469 IVM ASW TARGET TARGET W ) PMS403 NAVY i j j... J... MK-30 MOD 2 MK-30 MOD 2 ASW TRAINING iPEO(MU 1 1 i i 00613 IVM (ASW TARGET TARGET W ) iPMS403 NAVY I 93/05 96/07 ! f I [01/11 02/03 MASS MEMORY STORAGE PEOjEXW 1 ........... f j ! :00620 j IVM MMSD DEVICE/STANDARD i ) P M S440IN AVY MAR/NB IMARC j ' 89/08 192/12 i ........ [94/05 95/03 101578 IVM MPC ’MULTI-PURPOSE CART MARCOR C O R j i ( J Tim e Critical Strike Program December 2000 (continued) ■ W m 00 ! O if) o o 35 o > < 0 o o *- o > 0 5 1 1 : 05 CO ! " * • O o o CO ? 3 O) o > o * CO o CD o • « — o o C O 05 CO 05 C O C O 05 C O C M C M 1 o 5 5 ; o o o . 05 C O C O 05 C O 05 ...... o > 05 05 05 05 05 N. 05 C M C O f". M * ; § © O $ O C D C M 05 1 ^ Si 05 05 CD 05 05 . . < < : ... . ... z z < < < z z z : z ■ C M C M C M to id o O o § : 05 ^ : L O C O ..... C O C O _C 5 05 05 C M ; < • » * * • < ■ 2 O C O to 05 z ! < • 2 a < ; .....Z .... 05 ...x o a >- > o ’ >- >- > < V C oc s > V C > 5 > > < V C < V C < < < V C < < < < 5 0 5 0 z Z 5 O z z z Z ■ ; CM a < O 3T CO C M 05 O C M O CO 0 5 j - ■ ■ o O CM CO £ 0 5 j O . 0 5 ___ G D _ ; < < < ; ; .....A . z j . _ 2 < < < < ; z z A ......2 . r - CO < § < o ^ S i A CO _ 05 < < < o ; : Z § S ; 1 a: I: s o C O U J £ 2 3 L U E D o co a: co a: LU LU 0. 0. — U J u s 3 W L = O £ O > ■ S fe c o : ID ! t C L O O ? ; < U J 458 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. cn to Time Critical Strike Program December 2000 (continued) AN fACATj SHORT TITLE} LONG TITLE TANK SYSTEM TANK SYSTEMS 01346 IlVM MOD 'MODIFICATIONS TARGET 21 (21 ST CENTURY 01439 01154 IVM TARGET 21 AERIAL TARGET) J" p k r i PM ' | LEAD M/S CijM/S t| M/SIIjtRiPlfLR'P™'[M/s"''K V OC !MARCOR[CBG INAVY i I I i I I i ipEO(W) [pMA208 |NAVY j99/2ojo0/12 j01/2Q jN/A jN/A |05/4Q [o6/2Q IVM TETS THIRD ECHELON TEST SET 01227 IVM TISS THERMAL IMAGINGSENSOR jSYSTEM TRACTORRUBBER TIRED iO 518 VM iTRAM RELIFE ARTICULATED STEERING f f ........ TECHNICAL SURVEILLANCE [01235 jlVM [TSCM COUNTERMEASURES f i 1 ...." ~ UNIT LEVEL CIRCUIT [01269 | IVM [ULCS PIP MARCOR ATE iNAVY 95/05 [95/05 98/06 >N/A 98/06 [00/06 PEO(EXW; ) PMS440 [NAVY I jEng SuptjMARC } MARCOR [Equip [OR j : 93/05 95/10 MARCOR IC4ISR [NAVY j 1 [MARC i MARCOR IlC I OR 194/09 101442 I . ! 01484 MARCOR jTMDE INAVY PEO(W) [PMA208 [NAVY [92/11 93/05 [93/05 N/A ....... ....j...............i' i f" f ! NAVAIR IPMA260 NAVY N/A I N/A IN/A N/A [SWITCH PRODUCT jUSMCGENERAi: PURPOSE 01202 I IVM IUSMC GPETE i ELECTRONIC TEST 1 ~ “ ..... ' I MARINE CORPS SIMULATOR IVM (U S M C S M P [MASTER PLAN [NAVAIR 1PMA205 NAVY iN/A I.............. [ VERY LOW FREQUENCYI ...............[ f IVM [VALUE [ASHORE LIFETIME UPKEEP iSPAWAR |PMW 173lNAVY N/A " 1..............i ................... . I VANDAL EXTENDED ......... 01057 j IVM i VANDAL EER EXTENDED RANGE TARGET ' 1 “ I VAST TO VERSATILE AVIONICS SHOP 01320 ! IVM i CASS T E S T SET TO CASS *"| [ WEAPONS IMPACT SCORING 01068 [IVM W lSS iSET VERSION 4 i W R [ W I D E RANGE RADIOLOGICAL RADIOLOG 'SURVEY METER/RADIAC ......................* | PALLETIZED LOAD SYSTEM FLATRACK [FLATRACK PROGRAM .............. control d i s p l a y r (NDI) CD I NAVIGATION UNIT (NDI) CD j NAVAIR [ADVANCED COMSAT............f 01347 [IVT iACVCH VEHICLE CREW MAN'S [MARCOR j EX 12 MOD 0 ACOUSTIC [PECpO IVT jAFS [FIRING SYSTEM 1W) 01072 IlVM 01377 01633 IVT IVT 95/11 [95/11 |..... N/A j N/A N/A | N/A 96/08 97/04 [98/07 I N/A [N/A [97/07 99/09 . I I N/A ;N/A N/A j N/A NAVAIR IPMA248 INAVY :N/A IN/A 1 89/08 iN/A 1SEA04L 1........... 1 i RB INAVY i i90/06 92/03 | MOTORS ' J [" j I....... TRANSPINAVY 15/97 SEA 04 MARCOR 101287 01*"13 PMW187INAVY [N/A MAR/NBt i C NAVY i PMSEO 1 [D INAVY i96/01 j ........ i ............................. T........ .......j........... [makC i ....... IVT [AMD ADVANCED MINE DETECTOR [MARCOR jCSLE OR [97/10 N/A 02/3Q! 99/01 101/10 j 94/11 96/12 [95/11 94/08 96/12 94/10 199/11 [98/11 N/A !92/02 | N/A 193/12 I j =97/03 [N/A IN/A 97/03 [99/09 j i i i i -"1 ............... ! 98/03 98/03 j I 102/08 103/04 j r i s 99/10 01/10 [N/A IN/A [04/09 U5/09 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) I Art } A C A 71 oi-'ORT T TLiT { L O N G T iT lf- •AN/BSG-1 AN/BGS-1 W EAPON ! 01402 IV r IW LS iLAUNCHNG SYSTEM i AN/MSC-63A AN/MSC-63A 101251 IVT :PIP (COMMUNICATIONS CENTRAL j ENVIRONMENTAL SATELLITE 100148 i IVT AN/SM Q-11 i RECEIVER-RECORDER I P E O I PM | LEAO {M /S 0 | M/S t | M/S il P E O (S U B , i) PMS425 NAVY IN/A 97/06 i 97/03 •NAVY F??ir,_iLv ?ip roc •01/09 I SPAW AR IPM W 185INAVY N/A N/A N/A jN/A [78/06 186/09 189/10 [ (01602 IVT jASPARCS i ! I [01282 IVT [BBS SPAWAR PMW 173; NAVY N/A N/A 96/08 AN/UYQ-70(V) AN/UYQ-70(V) ADVANCED FPEO(EXW [ 01229 iIVT jADS [DISPLAY SYSTEM i) PMS440 NAVY f ‘ AIR SURVEILLANCE & (PRECISION APPROACH SUBMARINE BASEBAND ! SW ITCH i i C-2A(R) SERVICE 'LI FE j ■ I • 01115 IVT fC-2A(R) SLEP EXTENSION PROGRAM |PEO(T) PMA231 iNAVY [N/A 94/01 N/A t COMPUTER AIDED DEAD [PEO(EXW i 01385 SlVT jCADRT RECKONING TRACER !) PMS440 iNAVY : [00/05 (CCS MK2 DO 1COMBAT CONTROL SYSTEM TPEO(SuB i.......... 01256 ;IVT BLKIC IMK 2 DO BLOCK 1 C j) iPMS425 NAVY ! 96/06 closed loop degaussing rpEO(Mu (seaosr i [00269 IVT iCLDG ISYSTEM/MCM j COSSl(IMD i HELICOPTER INTEGRATED W ) 127 NAVY ! 1PMA261/I i 100810 (IVT [HUMS) [MECHANICAL DIAGNOSTICS |PEO(A) {299 [NAVY jN/A m 216 [IVT ICQBW [01352 [IVT iCT [01445 [IVT fCLOSEOUARTERS BATTLE 1 (WEAPON [COMBAT TENT jCOMMONW DIGITAL •CXP TRANSPONDER { r DIGITAL DIGITAL INTERROGATOR (01363 IVT INTERROGAT AN/UPX-37 I DESIGNATED [01125 IVT ;DMR [MARKSMANSHIP RIFLE ■MARCOR CBG INAVY (94/04 " I ....................r i ...... (MARCOR CSLE iNAVY i 1....... i ..I' [NAVAIR PMA213 iNAVY N/A I NAVAIR PMA213 NAVY iN/A (94/01 j I i 97/11 [96/11 j.......i ■ T N/A IN/A i0 3 /2 0 {04/2Q ( 96/08 iN/A (97/08 [98/03 j 1 j i ? N/A i j04/4Q I j i " j- ' .... i i [01/10 joi/10 I 98/04 i 100/10 ! ! V " ' j ' - 90/12 96/03 j I j 00/05 [02/04 N/A [N/A (00/4Q IN/A I02/1Q (03/2Q i N/A [N/A N/A N/A [01548 : IVT DR I i' " i [01169 [IVT !DSM \ I [01315 I IVT ;DSVL DIGITAL RADIOGRAPHY DUAL SOFT MOUNT (MARCOR (CBG iNAVY 193/10 [95/05 96/06 j ...... !'............... iMARC I ' 1" (MARCOR CSLE 'OR 97/03 I j (98/04 [99/07 1 ' f I j I.. j (01/2Q jN/A I02/3Q j jN/A | 98/06 j i jN/A [N/A 98/04 99/03 I i i 101/09 ■MARCOR CBG NAVY AN/W ON-2 DOPPLER SONAR ]PE0(EXW ! i VELOCITY LOG j) [PMS440 [NAVY [ i (79/12 S 98/07 101/01 *99/04 Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) | A M I a c a t ! s h o r t t i t l e I l o n g t i t l e ( P E O f P M S L E A D I M /S O j M / 3 " i f M /S » | L R IP jf t R I P lit M /S II! I IO C i E -6 M D S SE-6 M U L T IF U N C T IO N 0 1 4 2 0 ; IV T [P R O G R A M I (D IS P L A Y S Y S T E M (M D S ) (E -6 B M O D M IN I R E C E IV E R P E O (A ) [P M A 271 | N A V Y A IR N /A N /A i IN /A f N /A N /A 9 9 /0 4 0 3 /4 Q ! 101 417 IV T (E -6 B M M R T (T E R M IN A L P E O (A ) IP M A 271 -F O R C E 195/11 195/11 (9 6 /0 5 N /A N /A 0 0 /0 5 N /A i r e A ^ S B B L K 8 9 ^ E A -6 B B L O C K 8 M P R O G R A M !........... | (0 1 1 9 5 IV T P R O G i( O S IP 3 7 -9 5 ) P E O (T ) P M A 2 3 4 • N A V Y N /A iN /A (9 5 /0 5 9 8 /0 3 •9 9 /1 2 0 0 /4 Q ! E A -6 S M M A D T iE A - 6 B M U L T I-M IS S IO N A D V ] .. •0 1 4 4 8 i ' i v r T A C T E R M i ..........~................... (T A C T E R M / ID M IE A -6 B U N IV E R S A L E X C IT E R P E O (T ) P M A 2 3 4 N A V Y (n / a N /A N /A IN /A N /A 9 8 /0 8 101 246 IV T (E A -6 B U E U C A 6 8 U S Q - (U P G R A D E P R O G R A M • E A -6 B U S Q - 1 1 3 R A D IO C M P E O (T ) P M A 2 3 4 M A \/V N /A N /A • N /A (N /A 9 6 /0 3 0 0 /0 4 (0 1 4 4 9 (IV T 11 3 (S E T P E O (T ) P M A 2 3 4 N A V Y iN /A N /A (N /A | N /A ;N /A 9 8 /0 8 j' E C H E L O N 1 & (E C H E L O N 1 & II H E A L T H ............... i : i - (0 1 3 7 5 i v r (II H S S (S E R V IC E S U P P O R T M A R C O R IC S L E IN A V Y 3 /9 7 i j ! j ! ! (S E C O N D G E N E R A T IO N ...................... .............. i f j i ........ : 0 1 3 5 1 IV T (E C W C S (E X T R E M E C O L D W E A T H E R M A R C O R C S L E N A V Y j (9 7 /0 1 i 9 7 /1 1 i ............ )F -1 4 D IG IT A L F L IG H T ............. ' j ' ' ’ ? (0 0 4 0 4 IV T F 1 4 D F C S (C O N T R O L S Y S T E M P E O (T ) P M A 241 N A V Y N /A N /A •N /A (9 7 /1 2 ’ 9 8 /0 3 ■ : I f F A M IL Y O F r ..... ........................... .................. .......... I j ' ! (0 1 3 4 8 IV T B O D Y A R M O R F A M IL Y O F B O D Y A R M O R M A R C O R C S L E IN A V Y N /A 9 6 /1 2 9 6 /1 2 j 9 8 /0 6 9 8 /0 6 i I M a r c • ? (0 1 5 4 9 IV T jF S U F IE L D S A N IT A T IO N U N IT G P S IN E R T IA L N A V IG A T IO N M A R C O R C S L E P M W /A 1 O R 9 8 /0 1 i I • i i ' j............. .. (0 1 1 9 7 r IV T G IN A A S S E M B L Y , A N /A S N -1 6 (G R O U N D P R O iX IM lT Y “ N A V A IR 8 7 N A V Y I N /A N /A 9 3 /0 5 (9 6 /0 3 I ; 9 6 /0 5 (9 7 /1 1 !0 0 4 4 9 i v r .G P W S C A T I G P W S C A T Ml (w a r n i n g S Y S T E M C P W S /C A T E G O R Y III N A V A IR P M A 2 0 9 N A V Y N /A N /A 8 9 /0 2 N /A 9 6 /0 9 j 9 9 /0 4 '(........ •0 1 3 6 2 IV I (H E L O S ) i ........................ (H E L O S ) H -4 6 C O M M O N iC A T IO N N A V A IR P M A 2 0 9 N A V Y N /A : N /A 9 3 /0 7 N /A •9 7 /0 6 > 9 9 /0 4 i I (0 1 1 3 7 IV T H -4 6 C N C S (N A V IG A T IO N C O N T R O L N A V A IR P M A 2 2 6 N A V Y JN /A N /A IN /A 9 4 /0 2 iN /A i 9 5 /0 8 (9 5 /0 8 ! j............... ...... I IM P R O V E D H E A V Y M A C H IN E ................ I .......... 1 r " 1 8 C O o IV T H M G T G U N G R O U N D M O U N T M A R C O R C B G N A V Y 9 4 /1 0 9 6 /0 5 9 6 /0 5 9 9 /0 2 0 1 /0 1 ; i ............. H lG 1 S P E E D A S S A U L T P E O ( £ X W ........ ............ .............. I j o i 4 7 3 IV T IlS A C C R A F T H Y J R A C O M M U N IC A T IO N S )..................... P M S 3 2 5 S E A 5 3 Z N A V Y ' ....... - i (0 1 4 0 3 IV T H Y D R A (S Y S T E M (A N /S R C -5 5 ) S E A 0 5 2 N A V Y jN /A N /A N /A 9 8 /0 4 0 1 /0 1 0 3 /0 4 (9 7 /1 0 i I"' (IM P R O V E D D IR E C T A IR ' : ! ! ............ i (0 1 1 3 4 i v r ID A S C P IP (S U P P O R T C E N T E R M A R C O R C IS N A V Y • : i ? ! CD O O o C O o CM O o > o > CD 03 O O CD O O o > 0 3 03 <D c o ; 0 3 ; c o } S to c o CO j c 03 ir> U J o L L O < 0 < 0 CM [ < 0 ( X : CO O iii a E LU P a gisiS! £ 5 a w| 3 y H i < ^ £ Ul Q_ 0 3 C O CO o CO CO C M C O 00 CD O i © i o o 03 CM CM f - CO O O O o © ! o 462 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Tim e Critical Strike Program December 2000 (continued) c o £ 3 0 0 o > CO C M O O <35 0 5 lO r * ; 5 CO o O o V“ ■ 0 0 04 C O cS 2 5 2 5 CO , J P o o 0 5 ... ? - _ co ® ........... o > W O V a O ) CM CO o o © ; o o 0 5 t" CO co S : 2 5 co C D C O o o o > o > I tr o c 22 o £ Q O O < f i CM LU § h § uj s i § o = = isl o o I s g S sisii S s lS 3 S LU LU z z 463 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced w ith permission o f th e copyright owner. Further reproduction prohibited without permission. Time Critical Strike Program December 2000 (continued) \ AN jA C A T f SHORT TITLE I LONG TITLE NAVY KEY DISTRIBUTION PEO f PM | LEAD f M/S 0{ MLS 1 [ M/S It |L R 1>|(LR IP lljM /S H lf IOC •00674 ■01507 l ■ ■ IVT IVT NKDS(EKMS) Inlrf ■ 'SYSTEM (ELECTRONIC KEY NON-LETHAL RIGID FOAM NAVY STANDARD SPAWAR MARCOR •PMW161 NAVY j MARC (CBG OR i......... • i •N/A • N/A 99/01 (89/08 •00/07 ■N/A N/A [N/A [N/A i • N/A N/A 02/03 [00675 ■IVT • " " INST [TELEPRINTER (AN/UGC- ..... i •NAVY i ■ ........... i . . . I ; i [01188 'IVT j".......... : .......... ■ P19 IP-3 GPS iP19 CRASH FIRE TRUCK iP-3 GLOBAL POSITIONING MARCOR CSLF NAVY 1 i ; r j \ i I f i.......... • • . I [01212 i IVT i i INSTALLATION!SYSTEM INSTALLATION •plastic {Plastic waste PEO(A) ■PMA290 jSEA05R NAVY N/A N/A • N/A S n /a ! j ...........; [94/11 s ’ ” [96/05 ■01117 IVT [w a s t e PROCESSOR/SHIPBOARD SEA 05 (2 • NAVY [93/06 •95/01 [96/04 i.......... [01558 r......... ! |01234 r « IVT IVT [PMB RATPACC i ............. POW ERED MULTI-FUEL BURNER r u g g e d iz e d a l l -p u r p o s e TACTIAL PACKING AND •REMOTE LANDING SITE MARCOR MARCOR 5 ................ [CSLE CCR •MARC OR NAVY (98/01 ! ■ i J I...........j. . . 1' (01/09 [01411 IVT ;RLST TO W ER (MATCALS MOD) NAVAIR P M A2I3 NAVY N/A N/A (N/A ■N/A !N/A 98/11 00/4Q ! {01252 j............ IVT 5 - R-REP RADIO RECONNAiSSANCE EQUIPMENT PROGRAM !S-3 CRITICAL AVIONICS MARCOR i • IC NAVY ...... i ■"" i ' ' !. . j. \ • I ! ■ j01209 t IVT S-3 CAUP [UPGRADE PRGRAM 3B COMMGNICATiONS PEO(A) PMA290 NAVY 95/10 95/10 95/10 n /a : ■ ; > 95/10 02/3Q j d 199 I IVT S-3B CIP IM PROVEMENT PROGRAM S 3U CO-PROCESSOR PEO(A) PMA290 NAVY 95/06 95/06 95/06 i N/A i ; | ■ 95/06 (99/07 • ■ •00806 r ' ■ IVT IS-3B CPMU ! • MEMORY UNIT • SEMI-AUTONOMOUS PEO(A) P E0(M U PMA290 i NAVY N/A N/A [88/02 i 96/06 j : t 99/07 ■99/10 i •01476 ■ ■ iv r SAHRV SEL AREA ’HYDROGRAPHIC (SELECTED AREA W ) PMS325 SEA05R NAVY ■98/05 !......... 00/01 • 00/01 \...........i 01/05 ■ 02/02 i ....... 00827 IVT COLL COLLECTIVE submarine l f a / l f v m e b u s SEA 05 ,1 NAVY ! , 87/10 1 92/06 •94/04 i 01611 01106 IVT IVT ■SLVR •SMALL PULPER f RECEIVER • SMALL PULPER/SHIPBOARD W A STE MANAGEMENT AN/SPN-35C AIRCRAFT SPAWAR SEA 05 PMW 173 NAVY SEA05R ; 2 NAVY N/A N/A N/A 9 3 /0 / N/A N/A ,98/06 96/09 ; [00/03 98/07 [01605 ■IVT !SPN-35C CONTROLAPPROACH [SUBMARINE RESCUE DIVING NAVAIR PMA213 SEA00C NAVY N/A N/A N/A 99/12 • [03/2Q ■00905 (IVT jSRDRS (AND RECOMPRESSION [SEA 91 3 NAVY 92/12 94/07 .98/08 j 05/04 ,05/04 Tim e Critical Strike O 00 i O C M o * 0 5 I 05 0 5 O \ c S ) go ; o 11 co ; C M til L U O o CM C_ ! f t J j : c o p cl h - CM C O j 00 0 5 05 ml Si r * - ^ o : o i o j o 465 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX T DIRECTION MEMORANDUM FOR THE FAMILY OF INTEROPERABLE PICTURES (FIOP) The Joint Requirements Operational Committee directed the development of an all-source operational picture to provide warfighters with common views of the battle space. The Family of Interoperable Pictures is the initiative started to implement the direction. The JROC direction is as follows: • Reset original concept “Provide an all-source picture of the battle space containing actionable, decision-quality information to the warfighter through a fusion of existing databases” JROCM 203-00. Determine and list current “ stovepipe” systems to “link up.” • Develop Web-enabled technology for improved GCCS COP. The graphic and memorandum in this appendix document the requirement. f The military Services and organizations within the 1 Services were each developing operational pictures, but they were not coordinated. FIOP provides the coordination to link the pictures and their underlying information. Interoperability is needed to assure the coordination of the diverse Service pictures. 466 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. JROCM 203-00, December 2000 ■ ■ ■ "— 'r"-""', • : = PEO Interchange 5 MEMORANDUM FOR THE DEPUTY SECRETARY OF DEFENSE SUBJECT: Joint Requirements Oversight Council fJROC} Planning Directive, Family of Interoperable Operational Pictures (FIO P) L The overarching goal of FIOP is to provide an all-source picture of the battlespaee Containing actionable, decision-quality, information to the warfighter through a fusion', / of existing databases, 'The FIOP team will begin work immediately to Identify the / critical information requirements through a comprehensive concept of operations and requirements definition. The team will be initially focused on “how" and “ what a commander requires in the execution phase of an operation. The FIOP team will also develop an implementation strategy in order to bring the requisite capability to the warfighter at all levels of warfare. The final phase of the FIOP effort is to articulate an implementation strategy that will begin to identify the priorities and a way ahead. TH E JO INT S TA FF W AS H IN G TO N , D.C. 20318-8Q0U JROCM 156-01 17 Oct 01 JOINT REQUIREMENTS OVERSIGHT COUNCIL MEMORANDUM FOR: U nder S ecretary of D efense. A cquisition, T echnology and Logistics Vice C h ief of Staff, U nited States A ir Force Subject: J o in t Requirem ents O versight Council (JROC) - D irected F am ily o f Interoperable O perational Pictures (FIOP) 1. The JROC directed th a t the overarching goal of FIOP was to provide an all-source picture o f the battlespaee con tain ing actionable, decisinn-qnality, in fo rm a tio n to the w arfighter through a fusion o f existing databases (JROC M em orandum 203-00). The JROC reviewed and approved the A ir Force-led (m ulti-Service) FIOP FY02-03 priorities, and recom m ends the Defense Inform ation Systems Agency (DISA) support the effort w ith system s engineering. In addition, the JROC supports the cu rre n t funding level for the Task 1 FIOP effort ($9M in FY02, $15M per y e a r FY03-07) and requests th a t any recom m endations to change this level be coordinated w ith the JROC. 2. The JROC requests the A ir Force-led FIOP team to develop a m anagem ent plan, w hich w ill be used b y the Services to coordinate system developm ent and funding. The A ir Force is also requested to b rie f the contents o f th is m anagem ent plan, along w ith a report on the progress tow ard m eeting the FY02-03 p rio ritie s, to the JROC process w hen ready. T his plan should include an assessment o f w h e th e r increased exchanges o f Service systems engineering personnel among the appropriate commands is desired to achieve be tte r cross-service synergies. 3. The goal o f FIOP rem ains unchanged. However, the plan nin g d irective issued under JROC M em orandum 203-00 is cancelled. Its purpose was overtaken by the recently com pleted FIOP scope and cost effort, and the forthcom ing m anagem ent plan. General, U nited States M arine Corps Vice Chairm an o f the J o in t Chiefs o f S taff Enclosure Copy To: Under Secretary o f Defense. D irector, Interoperability Assistant Secretary o f Defense, Com m and, Control, C om m unications, and Intelligence Deputy Com m ander in Chief. US C entral Com m and 468 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX U TELEPHONE INFRASTRUCTURE Amy Friedlander (1995) developed infrastructure studies for the Corporation for National Research Initiatives (CNSI). The intent was to discover potential methods that may be applicable to development of the National Information Infrastructure. Below is Dr. Friedlander’s abstract for the telephone infrastructure study. Preface Robert E. Kahn, President Corporation for National Research Initiatives March 1995 "Natural Monopoly and Universal Service" describes the development of the telegraph and telephone systems in the United States and is the second in a series of explorations into the history of specific infrastructures, commissioned by the Corporation for National Research Initiatives (CNRI). This volume addresses a dimension of the communications infrastructure.... In this volume, Dr. Friedlander brings together a wide range of historical, economic, and technical perspectives to provide practical insights into these and other important topics in technology and culture. The past is, in many ways, a foreign country, but in other ways, it is surprisingly familiar. The combined story of telegraphy and telephony resonates with contemporary issues, as inventors and entrepreneurs gradually solved problems that arose from developing and disseminating new communications technologies. In so doing, they transformed their present and set up our tomorrow. Abstract This study examines the history of the telegraph and telephone industries in the United States from the perspectives of technology, corporate strategy, politics, and economics. Under the aegis of the Bell Company and its successors, the telephone followed a path similar to that pioneered in the 1860s by the telegraph giant, Western Union. Indeed, the telephone itself was invented in the 1870s as an unanticipated product of efforts to solve technological limitations of telegraphy. Like Western Union, Bell targeted communications among urban, commercial interests (as opposed to private residential and/or rural users). And, like Western Union, Bell was eventually organized as a private sector monopoly. 469 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Limitations in telephone transmission capability in the 1870s and early 1880s initially confined the telephone company to local service, while telegraphy remained the only means of long distance communication. After 1885, Bell also began to move toward long distance service by forming a subsidiary, American Telephone and Telegraph (AT&T). However, technology represented a constraint on long distance service until the introduction of the loading coil in 1900-1901. What drove AT&T's research and development in long distance telephone technology in the late 1880s was the coming expiration of key patents in 1894, when AT&T foresaw intense competition that did, indeed, occur. Between 1894 and 1907, independent telephone companies proliferated to meet consumer demand that AT&T (re-structured in 1899 as the holding company of regional operating companies) had ignored. This partially organized independent movement challenged the Bell companies in key regions, notably the Midwest and the North Central states. To counter it, AT&T through its affiliates similarly expanded its scope of service. AT&T gradually assumed technological and organizational control of an integrated system of local and long distance service through a policy of interconnections with selected independent companies as well as through acquisitions, mergers, and (after 1907) a willing acceptance of state and federal regulation. Although dual service (i.e., access either to the Bell System or to telephone service offered by an independent company) persisted into the 1920s, the independents operated within the technological standard set by AT&T. The telephone system was not fully extended to provide potential access to the entire population, particularly the dispersed rural poor, until the Rural Electrification Act (REA) and other federal programs provided the incentive after World War II. Thus, state and federal programs, which were designed for other purposes, were also instrumental in the expansion of telephone service to serve national needs. Amy Friedlander As a monopoly, AT&T had technology and organizational controls of local and long distance service and was able to set technology standards before competition was introduced. Federal Regulations moderated social system access \ and competition. _ _ ___ 470 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX V ELECTRICITY INFRASTRUCTURE Below is the abstract for Dr. Friedlander’s (1996) electricity infrastructure study. Preface Robert E. Kahn President, Corporation for National Research Initiatives January 1996 "Power and Light" is the third in a series sponsored by the Corporation for National Research Initiatives (CNRI) on the historical development of large-scale infrastructure in the United States. It concerns the technology and infrastructure of electricity.... In this survey of the literature on electricity and electrification, Dr. Friedlander traces the inter-relationships among technology, economics, society, and politics. These dynamics have often been conveniently reduced to the adage, "technology push; demand pull." But as the following discussion will show, the "push" and the "pull" are two extremes in a complex continuum in which electrical technology was pushed to meet demand even as advances in technology increased expectations. Abstract After disparate experiments in the U.S. and abroad, beginning with Michael Faraday's in 1831, electricity owes its origins as an energy infrastructure in the U.S. to Thomas Edison's work in the late 1870s. Edison was not just exploring the properties of electricity. Rather, he and the members of his laboratory were examining the attributes of electricity in the context of solving a particular problem: devising a system of interior illumination that was competitive with gas. The gas companies also provided Edison with his model of organization, distribution, and delivery of services to prospective customers. Thus, he conceptualized a specific product—lamps—in terms of a technological and an organizational system that contained generation, transmission, regulation, and delivery of electrical power together with a mass production manufacturing process and a corporate management structure. 471 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Quickly, however, electric illumination split off into separate but related companies that manufactured and sold appliances and equipment or provided services to power users. Eventually, power generation and distribution itself divided into the power producers (whether hydro or coal), the electrical transmission companies, and the local utilities. Separate from these companies were the financiers. Most of these entities formed interlocking relationships that culminated in the organization of holding companies after 1910. The advantages of the holding companies were that they stabilized financially precarious small utility companies and supplied management and engineering expertise, thus implicitly standardizing operations and equipment. The disadvantages were that they tended to reduce competition and were said to be unresponsive to local needs. Moreover, since the companies were highly leveraged, a tremor in one part of the organizational system could and did have far-reaching repercussions for consumers. Samuel Insull's electric power holding company controlled and generated one-eighth of the nation's power in 1931, and when the company failed, it affected over 1 million stock and bond holders as well as 41 million customers. Unlike gas, electricity cannot be effectively stored in large quantities. Thus, plant size was a function of maximum or peak demand. Despite decentralized alternatives offered by batteries or self-contained generating plants that served one or two buildings or perhaps an industrial complex, the American model was central station generation and distribution on an increasingly expansive scale. The focus on central station electric power generation and distribution derived partly from Edison's vision and partly from Insull's strategy, which called for encouraging energy use to achieve greater production capacity and increased revenues, while passing off savings to the consumer in the form of lower prices to stimulate even greater consumption. Edison's system had been based on direct current (DC), which had a practicable transmission range of about one mile. From 1880 to 1920, most of the innovations, including the use of alternating current (AC), were designed to increase the range, scale, and capacity of the central power station concept. Indeed, the Niagara project (1895) demonstrated the possibility of a regional system based on a hydroelectric generating station, high voltage transmission lines, substations, and local distribution, improvement in coal-fired, steam-powered generators achieved similar increases in capacity. In the 1920s, inter-connection of generating plants and distribution systems together with pooling of energy sources enabled transmission grids to integrate coal- and hydro-powered generating plants into an expansive distribution system that served a diverse range of demands. Interior electric illumination in the 1880s was initially a luxury for the average consumer. It was introduced first into commercial establishments, like theaters and department stores, as well as into affluent residences. Electricity was first adopted by industry in small, labor- intensive and new industries, which took advantage of its fractional attributes—meaning that the same system could support small machines, which used motors of less than 1 horsepower, and larger ones, such as motors of 1 to 10 horsepower. Central power station delivery allowed them to pay only for what they consumed and did not have to meet the relatively high threshold cost of installing and maintaining a self-contained power source, like a steam engine or an independent electric power plant nor find a means of exhausting the generated heat. Electricity was subsequently adopted by the large scale, heat-intensive industries, such metallurgy or food processing, in which the thermal properties possessed value for the industrial process. Electrification of industry led to substantial re-engineering of 472 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the industrial plant to achieve ancillary benefits in the form of more efficient uses of space as well as unit drive systems (i.e., one energy source per machine). The 1920s were the era in which electricity permeated the home. By then, occupants of cities and burgeoning suburbs had access to multiple energy technologies. Although electricity continued to be most intensively used by the affluent, the presence of interproduct competition from gas and oil meant that prices for electricity tended to stay low. Falling prices, increased wages, and the decrease in the number of servants willing to staff middle and upper-middle class households fundamentally increased the material standard of living for the working class, while increasing the burden of housework for many women. With improvements in several household energy systems, which brought about gas and electric ranges, hot water heaters, irons, vacuum cleaners and refrigerators, Americans began to enjoy and to expect a cleaner personal and environmental standard. Laundry, which in an earlier time might have been sent out or assigned to a laundress who came in once a week, now became a routine household chore for the lady of the house. From Edison's lab in New Jersey to John Ryan's copper mines in Montana, electrification was largely a private sector phenomenon. Cities, of course, were among the earlier consumers, and municipal regulation was a constant from the 1880s onward. From experience with both water and gas, which predated the Civil War (1861 -1865), it was obvious that municipal franchises, which implied a degree of regulation, would be necessary to obtain access to rights-of-way within which to construct the conduits. State regulation of electric utilities was instituted in 1887 in Massachusetts, and state regulation, exercised through setting rates, has remained the dominant form of public oversight. For the most part, industry executives pursued a cooperative policy toward state regulatory agencies, with the savings they achieved through improved technology passed along to consumers in the form of lower rates. Interproduct competition from gas and oil for heat (if not for interior illumination) as well as the specter of public regulation or even public acquisition became powerful incentives for cooperation with regulatory agencies as well as for price discipline by the utility companies themselves. Regulation tended to manifest itself primarily through setting rates, and the rate structure itself became a marketing tool, designed to attract large, industrial users who might otherwise have installed self-contained, independent plants which potentially competed with central station power. Although residential consumers paid more per unit of power on average than large industrial consumers did, and, indeed, generated more profitable revenues for the power companies, stable or falling prices relative to higher wages, particularly in the 1920s, muffled consumer discontent. Federal New Deal programs were aimed toward dismantling holding companies and limiting interstate operation of electric holding companies. Regulation was believed justified in order to protect the public from widely perceived abuses. It is unclear how successful this regulatory function has been, based on studies of consumer prices and the extent to which early regulatory agencies in fact protected power companies from competition. It is, however, evident that federal intervention, in particular, was instrumental in expanding electric power to underserved, predominantly rural populations through the REA and other New Deal and Truman-era programs. Amy Friedlander 473 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. /^Cooperating holding companies formed controls, established standards, stabilized finances, and centralized energy distribution, but gas and oil energy competition kept consumer costs low. Federal intervention coordinated equity. 474 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX W RAILROAD INFRASTRUCTURE The railroad infrastructure is the next of Dr. Friedlander’s (1995) studies. Preface Dr. Robert E. Kahn, President Corporation for National Research Initiatives October 1994 "Railroad Infrastructure" is the first in a series of explorations into the history of specific infrastructure developments in the United States commissioned by the Corporation for National Research Initiatives (CNRI).... In this study Dr. Friedlander brings together a wide range of historical, economic, and technical literature to provide practical insights into these and other important questions. Some have argued that "history is destiny;" others, that "those who do not know history are doomed to repeat it." As we design and build a national information infrastructure, experiences drawn from infrastructure developments in other times may help us to understand better the choices we make today, and their ramifications for tomorrow. Abstract This paper examines the historical literature with respect to three related questions about the development of railroads: When and how did take-off occur? What were the public and private roles? And, how did an integrated infrastructure emerge from a web of independently owned lines with frequently incompatible physical attributes? Railroad construction in the U.S. began in the late 1820s and 1830s and took place over the next 70 years in the context of enormous geographical, demographic, social, and economic growth in the country as a whole. The railroads do not appear to have caused this growth, as has sometimes been alleged. But they did profoundly affect its course, and in so doing, became the dominant element of the national transportation system. By all accounts, "take-off' for the railroads occurred in the 1850s. Before that time, the lines were mostly local. During and after the 1850s, however, construction accelerated rapidly, and relatively short routes were linked to provide longer distance traffic. Much of this traffic went from eastern urban centers to Chicago, which emerged as a transportation/processing hub between 1850 and 1860. By the Civil War, several companies had begun construction west of the Mississippi River in anticipation of a transcontinental railroad. Between 1860 475 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and 1890, the national rail system became increasingly elaborate and uniform, characterized by standardization of gauge and administrative practices, and increasingly dominated by an emerging, informal group of major companies. As the first "Big Business," the major railroad companies pioneered modern business practices and organizational structures to cope with their own size, expansive operations, and internal complexities. With increasing size, moreover, they also became more similar and discovered advantages to cooperation in a climate otherwise characterized by fierce competition. Construction of railroads, like public works projects since the 1780s, was a joint public/private enterprise. The majority of the funding appears to have come from private sources. But public intervention played an important role, both in increasing investors' confidence and ensuring that sufficient funds would be available to complete construction. Amy Friedlander ^Cooperation and Collaboration among a dominant group of major companies, standardization of gauge and administrative practices, and modern organizational structures resulted in an elaborate and uniform railroad system infrastructure. \C o o p e ration was achieved in a competitive climate. 476 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX X BANKING INFRASTRUCTURE Banking is the closest infrastructure to information technologies than the others already discussed. It is the last of Dr. Friedlander’s (1996) studies in this document. Federal intervention set the guidelines, but cooperation among private banks worked best to standardize and stabilize the financial system. v ................_ y Preface Robert E. Kahn, President Corporation for National Research Initiatives December 1996 "In God We Trust" is the fourth in a series sponsored by the Corporation for National Research Initiatives (CNRI) on the historical development of large-scale infrastructure in the United States. In this volume, we look at the notion of banking infrastructure, which includes the cooperative arrangements along with the shared assumptions and procedures that enabled funds to flow (actually information about funds, to be precise) among banking institutions and across regions. The banking area is of particular interest in that it was not derivative of a particular technological innovation or group of innovations. CNRI is a not-for-profit organization, formed in 1986 to foster research and development for the National Information Infrastructure (Nil). Among CNRI's major goals is a program of research to identify and nurture infrastructural technologies and services that will unlock the world of information and knowledge and enhance the nation's productivity, particularly in science and engineering. Banking offers us a clear example of a technology-independent industry in which there were positive incentives to develop cooperative arrangements and hence to invent forms of organizational networking. Inextricably linked to evolving political and economic processes, its history has much to tell us that is relevant to understanding the possible development of the Nil. Prior studies of railroads, telephones and telegraphs, and electricity hinted at the importance of finance in the development and diffusion of technology, Here, Dr. Friedlander 477 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. steps back one level and asks the question, how did the system of finance itself evolve, and what role did non-technological infrastructure play in the process? She concludes that the information infrastructure of banking rested on the idea of money as a "currency of information exchange." Its beginnings lie deep in the past, but like so many American institutions, it came across the Atlantic and grew up with the country. Abstract This paper is the fourth in a series of historical discussions of large-scale infrastructures in the United States. It is based on three questions: When and how did take-off occur? What were the public and private roles? And, how did an infrastructure—characterized by access, "shareability," and economic advantage—emerge? It argues that banking is inherently a system of information transactions rather than a technology-driven infrastructure. Although its form and function has changed and expanded, banking is basically an information infrastructure, and has been a feature of economic life in the U.S. since the eighteenth century when it provided credit and was a mechanism for transferring the collective savings of the population into large and small-scale investments. Subject to chronic instability, banks runs, and panics, commercial banks gradually evolved systems of cooperation among banks and other financial institutions, which tended to reduce the instability and hence to increase their respective profitability. Over time, federal interventions came to dominate the distinctive American system comprising concurrent state and federal banking systems, brokerages, investment houses, and financial concerns that evolved piecemeal over the nineteenth century. Of these, commercial banks have historically been the most important. At the national level, Alexander Hamilton's proposal to organize the federally chartered but privately owned First Bank of the United States set fundamental terms of American banking: it would use privately owned banks to serve a public mission, namely, the stabilization of the national debt and the management of currency (or the money supply). The First National Bank of the U.S. also helped fan the controversy in the early 1790s over the extent of federal power, which led to the formation of the first political parties. The bank's charter expired in 1811, and the Second Bank of the United States was granted a federal charter in 1816, but the bank did not become operational until after a panic in 1819. During this period, from the 1790s onward, the states also continued to charter banks. Between the expiration of the charter of the Second Bank of the United States in 1836 and the passage of Civil War-era banking and currency reform legislation in the early 1860s, the country was served only by state banks. This was the period of so-called "free banking" in which banks that met legislated criteria could go into business without obtaining individual charters or licenses. Although minting money in the form of coin was reserved to the federal government by the Constitution, the circulating medium was largely paper. Prior to the introduction of checking in the 1850s, the ability to issue widely accepted paper money or notes, backed by specie reserves, was critical to banking. The net result was a plethora of paper currencies of varying value. Both the First and Second Banks of the United States attempted to stabilize the monetary system, but the efforts of these institutions do not appear to have been as consistently successful as cooperative structures developed by the banks themselves. Domestic money markets provided a means of winnowing weak bank notes from the strong, and published discount rates provided information on levels of risk, captured in the 478 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. discount rate, which was associated with various instruments (e.g., promissory notes), interbank arrangements that were intended to stabilize the value of money, and hence to stabilize banking, included the Suffolk System in New England 1818-1858); state-mandated and voluntary insurance programs in New York, Michigan, Vermont, Indiana, Ohio and Iowa between 1829 and 1860; and the clearinghouse system, which originated in New York in 1853. In all of these enterprises, cooperation was in the immediate self-interest of the participants, because it appears to have increased public confidence in the banking system , and therefore reduced the likelihood of a panic. On the other hand, increased interdependence in the form of the bankers' balances and fractional reserve system also meant that sudden demands on one bank might be easily transmitted to others. Yet another component in the emerging financial system that directly affected the stability of banking was the call loan market, a mechanism whereby funds deposited in commercial banks were made available for short-term investment in the securities market. Hierarchical, correspondent relationships and bankers' balances deposits by one bank in another resulted in pooling funds in the major cities, with New York at the apex; this emergent set of relationships was, in fact, codified by the Civil War banking legislation. Commercial banks habitually invested the bankers' balances in the call loan market where investors and brokers sought short-term capital for which they were willing to pay high interest rates. It became evident in 1857 that tremors on Wall Street—resulting from any one of a number of sources, from international gold prices to bad news from Washington—were transferred to commercial banks. And increased demand on city banks from country banks, which were required to maintain minimum reserves in the face of unexpected demand from th eir depositors, might force city bankers to call in their loans and/or drive up the cost of money on Wall Street, resulting in sales of bonds and stocks in a weak market, tight money, or both. Thus, reserve requirements, which had been invented to safeguard first notes and then deposits, actually contributed to instability during periods of high demand by compelling country banks to withdraw their deposits from their city correspondents and by setting a threshold on the assets that a bank might liquidate for short-term use. This was to some degree ameliorated by clearinghouse strategies that made short-term loans available to their members so that sudden demands for liquidity might be more easily met. Over time, public authority over banking increased in part to stabilize periodic dislocations in the system—panics—and in part to help it work more smoothly. Substitution of a national currency, for example, eliminated efficiencies that resulted from intrastate money markets. But many of the features of federal banking legislation were based on the experience of the states, particularly New York, and the federal banking structure did not, therefore, offset inherent weaknesses. For example, hierarchical interdependent relationships, which obligated banks to deposit funds on account with other banks, meant that tremors in a few key markets might be more easily transmitted. More over, banks continued to operate under state banking laws and to make investments in real estate mortgages and other instruments that were legislatively closed to the federally authorized national banks. And indeed, some of the most recent research suggests that the least stable sector of the commercial banking industry in the 1920s were the state-insured state banks, which might choose to remain outside of the Federal Reserve system, and which were most heavily invested rural mortgages at a time when agriculture was slowly collapsing. Even the Federal Reserve Act (1913), which created a lender of last resort, perpetuated many earlier forms, such as the clearinghouse and hierarchical interdependence. The Federal Reserve also relied on a fairly weak regulatory approach that created incentives for banks to conform rather than mandates to which they must comply. New Deal legislation in 479 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the 1930s marked a significant departure from what had proceeded by positing a series of requirements that state and national commercial banks were obligated to meet in order to do business and by separating commercial from investment banking. But although bank reform in the 1930s reflected the New Deal's positive obligation to ensure a minimum threshold of financial stability, banking reform under FDR maintained the long-standing commitment to executing public goals through privately owned banking institutions. Amy Friedlander 480 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. APPENDIX Y INTERNET INFRASTRUCTURE The Internet infrastructure is a viable candidate to satisfy the connectivity and access needed to achieve interoperability. It is lacking, though, in accommodating common system functions, data, and process standards. These are needed to integrate and coordinate computer-based systems towards accomplishing a common mission or goal. Dr. Robert Kahn and Dr. Vinton Cerf are co-originators of the Internet. Below is most of their paper summarizing the Internet infrastructure development.1 Navy initiatives, though, are exploring use of the Internet as a means of achieving interoperability. Navy and Marine Corps, for example, are implementing the Navy Marine Corps Intranet (NMCI) to connect shore- based organizations. Instead of each organization developing, managing, and maintaining their own business networks, they are using an Internet-like infrastructure. Many of these are business systems that use commercially- based equipment and standards. This made shifting them to standard commercial equipment and networks easier. The intent is to do the same for warfighting networks and sea-based organizations. This is proving to be more challenging, because making real time changes to warfighting systems and sea-based organizations introduces greater risk to national defense. Additionally many of these systems are not commercially based, which will make the shift more difficult. Potential exists, though, for these systems and networks to use the Internet common bus, while retaining existing networks and system structures. With relatively minimal change, both legacy and new systems could use this bus. This solution retains capabilities of new systems and provides for gradual replacement of legacy systems. Interoperability may be within reach. 1 Robert E. Kahn and Vinton G. Cerf, W h a t Is T h e Internet (A n d W h a t Makes It W ork), December, 1999. 481 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 'he Internet was the breakthrough needed to connecrv computer-based systems, telephone systems, \ information systems, and banking systems. Drs. Kahn and Cerf relate the tremendous degree of cooperation and standardization expended just to get connectivity among the systems. Even more cooperation is needed to attain the common system functions, data, and processes needed to achieve interoperability. The material below is extracted from a paper by Dr. Robert Kahn and Dr. Vinton Cerf on the Internet. THE EVOLUTION OF THE INTERNET . . . The procedures by which computers communicate with each other are called "protocols." While this infrastructure is steadily evolving to include new capabilities, the protocols initially used by the Internet are called the ’TCP/IP" protocols, named after the two protocols that formed the principal basis for Internet operation. The telephone network started out with operators who manually connected telephones to each other through “patch panels” that accepted patch cords from each telephone line and electrically connected them to one another through the panel, which operated, in effect, like a switch. The result was called circuit switching, since at its conclusion, an electrical circuit was made between the calling telephone and the called telephone. Conventional circuit switching, which was developed to handle telephone calls, is inappropriate for connecting computers because it makes limited use of the telecommunication facilities and takes too long to set up connections. Although reliable enough for voice communication, the circuit- switched voice network had difficulty delivering digital information without errors. For digital communications, packet switching is a better choice, because it is far better suited to the typically "burst" communication style of computers. Computers that communicate typically send out brief but intense bursts of data, then remain silent for a while before sending out the next burst. These bursts are communicated as packets, which are very much like electronic postcards. The postcards, in reality packets, are relayed from computer to computer until they reach their destination. The special computers that perform this forwarding function are called variously "packet switches" or "routers" and form the equivalent of many bucket brigades spanning continents and oceans, moving buckets of electronic postcards from one computer to another. Together these routers and the communication links between them form the underpinnings of the Internet. 482 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Without packet switching, the Internet would not exist as we now know it. Going back to the postcard analogy, postcards can get lost. They can be delivered out of order, and they can be delayed by varying amounts. The same is true of Internet packets, which, on the Internet, can even be duplicated. The Internet Protocol is the postcard layer of the Internet. The next higher layer of protocol, TCP, takes care of re-sending the “postcards” to recover packets that might have been lost, and putting packets back in order if they have become disordered in transit. Of course, packet switching is about a billion times faster than the postal service or a bucket brigade would be. It also has to operate over many different communications systems, or substrata. The authors designed the basic architecture to be so simple and undemanding that it could work with most communication services. Many organizations, including commercial ones, carried out research using the TCP/IP protocols in the 1970s. Email was steadily used over the nascent Internet during that time and to the present. It was not until 1994 that the general public began to be aware of the Internet by way of the World Wide Web application, particularly after Netscape Communications was formed and released its browser and associated server software. Thus, the evolution of the Internet was based on two technologies and a research dream. The technologies were packet switching and computer technology, which, in turn, drew upon the underlying technologies of digital communications and semiconductors. The research dream was to share information and computational resources. But that is simply the technical side of the story. Equally important in many ways were the other dimensions that enabled the Internet to come into existence and flourish. This aspect of the story starts with cooperation and far-sightedness in the U.S. Government, which is often derided for lack of foresight but is a real hero in this story. It leads on to the enthusiasm of private sector interests to build upon the government funded developments to expand the Internet and make it available to the general public. Perhaps most important, it is fueled by the development of the personal computer industry and significant changes in the telecommunications industry in the 1980s, not the least of which was the decision to open the long distance market to competition. The role of workstations, the Unix operating system and local area networking (especially the Ethernet) are themes contributing to the spread of Internet technology in thel 980s into the research and academic community from which the Internet industry eventually emerged. Many individuals have been involved in the development and evolution of the Internet covering a span of almost four decades if one goes back to the early writings on the subject of computer networking.2 The ARPANET, described below, was the first wide-area 2 Leonard Kleinrock’s dissertation thesis at MIT was written during 1961: "Information Flow in Large Communication Nets," RLE Quarterly Progress Report, July 1961 and published as a book "Communication Nets: Stochastic Message Flow and Delay," New York: McGraw Hill, 1964. This was one of the earliest mathematical analyses of what we now call packet switching networks. • J.C.R. Licklider & W. Clark, "On-Line Man Computer Communication", August 1962. Licklider made tongue-in-cheek references to an "inter-galactic network" but in truth, his vision of what might be possible was prophetic. • [BARAN 64] Baran, P., et al., "On Distributed Communications", Volumes l-XI, RAND Corporation Research Documents, August 1964. Paul Baran explored the use of digital "message block" switching to support highly resilient, survivable voice communications for military command and control. This work was undertaken at RAND Corporation for the US 483 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. computer network. The NSFNET, which followed more than a decade later under the leadership of Erich Bloch, Gordon Bell, Bill Wulf and Steve Wolff, brought computer networking into the mainstream of the research and education communities. It is not our intent here to attempt to attribute credit to all those whose contributions were central to this story, although we mention a few of the key players. A readable summary on the history of the Internet, written by many of the key players, is available on the Internet.3 From One Network to Many: The role of DARPA The [ARPANET] program was led at DARPA by Larry Roberts. The packet switches were built by Bolt Beranek and Newman (BBN), a DARPA contractor. Others directly involved in the ARPANET activity included the authors [Robert Kahn and Vinton Cerf], Len Kleinrock, Frank Heart, Howard Frank, Steve Crocker, Jon Postel and many, many others in the ARPA research community. Back then, the methods of internetworking (that is interconnecting computer networks) were primitive or non-existent. Two organizations could interwork technically by agreeing to use common equipment, but not every organization was interested in this approach. Absent that, there was jury-rigging, special case development and not much else. Each of these networks stood on its own with essentially no interaction between them—a far cry from today’s Internet. In the early 1970s, ARPA began to explore two alternative applications of packet switching technology based on the use of synchronous satellites (SATNET) and ground-based packet radio (PRNET). The decision by Kahn to link these two networks and the ARPANET as separate and independent networks resulted in the creation of the Internet program and the subsequent collaboration with Cerf. These two systems differed in significant ways from the ARPANET so as to take advantage of the broadcast and wireless aspects of radio communications. The strategy that had been adopted for SATNET originally was to embed the SATNET software into an ARPANET packet switch, and interwork the two networks through memory-to-memory transfers within the packet switch. This approach, in place at the time, was to make SATNET an “embedded” network within the ARPANET; users of the network would not even need to know of its existence. The technical team at Bolt Beranek and Newman (BBN), having built the ARPANET switches and now building the SATNET software, could easily produce the necessary patches to glue the programs together in the same machine. Indeed, this is what they were under contract with DARPA to provide. By embedding each new network into the ARPANET, a seamless inter-networked capability was possible, but with no realistic possibility of unleashing the entrepreneurial networking Air Force beginning in 1962. • L. Roberts & T. Merrill, "Toward a Cooperative Network of Time-Shared Computers", Fall AFIPS Conf., Oct. 1966. • Davies, D.W., K.A. Bartlett, R.A. Scantlebury, and P. T. Wilkinson. 1967. "A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals," P ro ce ed in g s o f the A C M S ym posium on O peratin g S ystem Principles. Association for Computing Machinery, New York, 1967. Donald W. Davies and his colleagues coined the term "packet" and built one node of a packet switching network at the National Physical Laboratory in the UK. 3 Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff, "A Brief History of the Internet," www.isoc.org/internet/history/brief.html. 484 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. spirit that has manifest itself in modem day Internet developments. A new approach was in order. The Packet Radio (PRNET) program had not yet gotten underway so there was ample opportunity to change the approach there. In addition, up until then, the SATNET program was only an equipment development activity. No commitments had been obtained for the use of actual satellites or ground stations to access them. Indeed, since there was no domestic satellite industry in the U.S. then, the only two viable alternatives were the use of Intelsat or U.S. military satellites. The time for a change in strategy, if it was to be made, was then. THE INTERNET ARCHITECTURE The authors created an architecture for interconnecting independent networks that could then be federated into a seamless whole without changing any of the underlying networks. This was the genesis of the Internet as we know it today. In order to work properly, the architecture required a global addressing mechanism (or Internet address) to enable computers on any network to reference and communicate with computers on any other network in the federation. Internet addresses fill essentially the same role as telephone numbers do in telephone networks. The design of the Internet assumed first that the individual networks could not be changed to accommodate new architectural requirements; but this was largely a pragmatic assumption to facilitate progress. The networks also had varying degrees of reliability and speed. Host computers would have to be able to put disordered packets back into the correct order and discard duplicate packets that had been generated along the way. This was a major change from the virtual circuit-like service provided by ARPANET and by then contemporary commercial data networking services such as Tymnet and Telenet. In these networks, the underlying network took responsibility for keeping all information in order and for re-sending any data that might have been lost. The Internet design made the computers responsible for tending to these network problems. A key architectural construct was the introduction of gateways (now called routers) between the networks to handle the disparities such as different data rates, packet sizes, error conditions, and interface specifications. The gateways would also check the destination Internet addresses of each packet to determine the gateway to which it should be forwarded. These functions would be combined with certain end-end functions to produce the reliable communication from source to destination. A draft paper by the authors describing this approach was given at a meeting of the International Network Working Group in 1973 in Sussex, England and the final paper was subsequently published by the Institute for Electrical and Electronics Engineers, the leading professional society for the electrical engineering profession, in its Transactions on Communications in May, 1974.4 The paper described the TCP/IP protocol. Vinton G. Cerf and Robert E. Kahn, "A Protocol for Packet Network Intercommunication," IE E E T ran sactio ns on C o m m un icatio ns, Vol. COM-22, May 1974. 485 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DARPA contracted with the Cerf group at Stanford to carry out the initial detailed design of the TCP software and, shortly thereafter, with BBN and University College London to build independent implementations of the TCP protocol (as it was then called—it was later split into TCP and IP) for different machines. BBN also had a contract to build a prototype version of the gateway. These three sites collaborated in the development and testing of the initial protocols on different machines. Cerf, then a professor at Stanford, provided the day-to-day leadership in the initial TCP software design and testing. BBN deployed the gateways between the ARPANET and the PRNET and also with SATNET. During this period, under Kahn's overall leadership at DARPA, the initial feasibility of the Internet Architecture was demonstrated. The TCP/IP protocol suite was developed and refined over a period of four more years and, in 1980, it was adopted as a standard by the U.S. Department of Defense. On January 1, 1983 the ARPANET converted to TCP/IP as its standard host protocol. Gateways (or routers) were used to pass packets to and from host computers on “local area networks.” Refinement and extension of these protocols and many others associated with them continues to this day by way of the Internet Engineering Task Force.5 GOVERNMENT’S HISTORICAL ROLE Other political and social dimensions that enabled the Internet to come into existence and flourish are just as important as the technology upon which it is based. The federal government played a large role in creating the Internet, as did the private sector interests that made it available to the general public. The development of the personal computer industry and significant changes in the telecommunications industry also contributed to the Internet’s growth in the 1980s. In particular, the development of workstations, the Unix operating system, and local area networking (especially the Ethernet) contributed to the spread of the Internet within the research community from which the Internet industry eventually emerged. The National Science Foundation and Others in the late 1970s, the National Science Foundation (NSF) became interested in the impact of the ARPANET on computer science and engineering. NSF funded the Computer Science Network (CSNET), which was a logical design for interconnecting universities that were already on the ARPANET and those that were not. Telenet was used for sites not connected directly to the ARPANET and a gateway was provided to link the two. Independent of NSF, another initiative called BITNET ("Because it's there" Net)6 provided campus computers with email connections to the growing ARPANET. Finally, AT&T Bell Laboratories development of the Unix operating system led to the creation of a grass-roots 5 URL 1: The Internet Engineering Task Force (IETF) is an activity taking place under the auspices of the Internet Society (www.isoc.org). See www.ietf.org. 6 From the BITNET charter: BITNET, which originated in 1981 with a link between CUNY and Yale, grew rapidly during the next few years, with management and systems services provided on a volunteer basis largely from CUNY and Yale. In 1984, the BITNET Directors established an Executive Committee to provide policy guidance. (See http://www.geocities.com/SiliconValley/2260/bitchart.html. 486 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. network called USENET,7 which rapidly became home to thousands of “newsgroups” where Internet users discussed everything from aerobics to politics and zoology. In the mid 1980s, NSF decided to build a network called NSFNET to provide better computer connections for the science and education communities. The NSFNET made possible the involvement of a large segment of the education and research community in the use of high-speed networks. A consortium consisting of MERIT (a University of Michigan non-profit network services organization), IBM and MCI Communications won a 1987 competition for the contract to handle the network’s construction. Within two years, the newly expanded NSFNET had become the primary backbone component of the Internet, augmenting the ARPANET until it was decommissioned in 1990. At about the same time, other parts of the U.S. government had moved ahead to build and deploy networks of their own, including NASA and the Department of Energy. While these groups originally adopted independent approaches for their networks, they eventually decided to support the use of TCP/IP. The developers of the NSFNET, led by Steve Wolff who had the direct responsibility for the NSFNET program, also decided to create intermediate level networks to serve research and education institutions and, more importantly, to allow networks that were not commissioned by the U.S. government to connect to the NSFNET. This strategy reduced the overall load on the backbone network operators and spawned a new industry: Internet Service Provision. Nearly a dozen intermediate level networks were created, most with NSF support,8 some, such as UUNET, with Defense support, and some without any government support. The NSF contribution to the evolution of the Internet was essential in two respects. It opened the Internet to many new users and, drawing on the properties of TCP/IP, structured it so as to allow many more network service providers to participate. For a long time, the federal government did not allow organizations to connect to the internet to carry out commercial activities. By 1988, it was becoming apparent, however, that the Internet's growth and use in the business sector might be seriously inhibited by this restriction. That year, CNRI requested permission from the Federal Networking Council to interconnect the commercial MCI Mail electronic mail system to the Internet as part of a general electronic mail interconnection experiment. Permission was given and the 7 Usenet came into being in late 1979, shortly after the release of V7 Unix with UUCP. Two Duke University grad students in North Carolina, Tom Truscott and Jim Ellis, thought of hooking computers together to exchange information with the Unix community. Steve Bellovin, a grad student at the University of North Carolina, put together the first version of the news software using shell scripts and installed it on the first two sites: "unc" and "duke." At the beginning of 1980 the network consisted of those two sites and "phs" (another machine at Duke), and was described at the January Usenix conference. Steve Bellovin later rewrote the scripts into C programs, but they were never released beyond "unc" and "duke." Shortly thereafter, Steve Daniel did another implementation in C for public distribution. Tom Truscott made further modifications, and this became the "A" news release. (See http://www.ou.edu/research/electron/intemet/use-soft.htm. 8 A few examples include the New York State Education and Research Network (NYSERNET), New England Academic and Research Network (NEARNET), the California Education and Research Foundation Network (CERFNET), Northwest Net (NWNET), Southern Universities Research and Academic Net (SURANET) and so on. UUNET was formed as a non-profit by a grant from the UNIX Users Group (USENIX). 487 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interconnection was completed by CNRI, under Cerfs direction, in the summer of 1989. Shortly thereafter, two of the then non-profit Internet Service Providers (UUNET9 and NYSERNET) produced new for-profit companies (UUNET and PSINET,1 0 respectively). In 1991, they were interconnected with each other and CERFNET.1 1 Commercial pressure to alleviate restrictions on interconnections with the NSFNET began to mount. In response, Congress passed legislation allowing NSF to open the NSFNET to commercial usage. Shortly thereafter, NSF determined that its support for NSFNET might not be required in the longer term and, in April 1995, NSF ceased its support for the NSFNET. By that time, many commercial networks were in operation and provided alternatives to NSFNET for national level network services. Today, approximately 10,000 Internet Service Providers (ISPs) are in operation. Roughly half the world's ISPs currently are based in North America and the rest are distributed throughout the world. A DEFINITION FOR THE INTERNET The authors feel strongly that efforts should be made at top policy levels to define the Internet. It is tempting to view it merely as a collection of networks and computers. However, as indicated earlier, the authors designed the Internet as an architecture that provided for both communications capabilities and information services. Governments are passing legislation pertaining to the Internet without ever specifying to what the law applies and to what it does not apply. In U.S. telecommunications law, distinctions are made between cable, satellite broadcast and common carrier services. These and many other distinctions all blur in the backdrop of the Internet. Should broadcast stations be viewed as Internet Service Providers when their programming is made available in the Internet environment? Is use of cellular telephones considered part of the Internet and if so under what conditions? This area is badly in need of clarification. The authors believe the best definition currently in existence is that approved by the Federal Networking Council in 1995, http://www.fnc.gov and which is reproduced in the endnote 9 UUNET called its Internet service ALTERNET. UUNET was acquired by Metropolitan Fiber Networks (MFS) in 1995 which was itself acquired by WorldCom in 1996. WorldCom later merged with MCI to form MCI WorldCom in 1998. In that same year, Worldcom also acquired the ANS backbone network from AOL, which had purchased it from the non-profit ANS earlier. 1 0 PSINET was a for-profit spun out of the NYSERNET in 1990. 1 1 CERFNET was started by General Atomics as one of the NSF-sponsored intermediate level networks. It was coincidental that the network was called "CERF'Net— originally they had planned to call themselves SURFNET, since General Atomics was located in San Diego, California, but this name was already taken by a Dutch Research organization called SURF, so the General Atomics founders settled for California Education and Research Foundation Network. Cerf participated in the launch of the network in July 1989 by breaking a fake bottle of champagne filled with glitter over a Cisco Systems router. 488 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. below1 2 for ready reference. Of particular note is that it defines the Internet as a global information system, and included in the definition, is not only the underlying communications technology, but also higher-level protocols and end-user applications, the associated data structures and the means by which the information may be processed, manifested, or otherwise used. In many ways, this definition supports the characterization of the Internet as an “information superhighway.” Like the federal highway system, whose underpinnings include not only concrete lanes and on/off ramps, but also a supporting infrastructure both physical and informational, including signs, maps, regulations, and such related services and products as filling stations and gasoline, the Internet has its own layers of ingress and egress, and its own multi-tiered levels of service. The FNC definition makes it clear that the Internet is a dynamic organism that can be looked at in myriad ways. It is a framework for numerous services and a medium for creativity and innovation. Most importantly, it can be expected to evolve. WHO RUNS THE INTERNET The Domain Name System The Internet evolved as an experimental system during the 1970s and early 1980s. It then flourished after the TCP/IP protocols were made mandatory on the ARPANET and other networks in January 1983; these protocols thus became the standard for many other networks as well. Indeed, the Internet grew so rapidly that the existing mechanisms for associating the names of host computers (e.g., UCLA, USC-ISI) to Internet addresses (known as IP addresses) were about to be stretched beyond acceptable engineering limits. Most of the applications in the Internet referred to the target computers by name. These names had to be translated into Internet addresses before the lower level protocols could be activated to support the application. For a time, a group at SRI International in Menlo Park, CA, called the Network Information Center (NIC), maintained a simple, machine- readable list of names and associated Internet addresses which was made available on the net. Hosts on the Internet would simply copy this list, usually daily, so as to maintain a local copy of the table. This list was called the "hosttxt" file (since it was simply a text file). The list served the function in the Internet that directory services (e.g., 411 or 703-555-1212) do in the US telephone system—the translation of a name into an address. 1 2 October 24,1995, Resolution of the U.S. Federal Networking Council RESOLUTION: "The Federal Networking Council (FNC) agrees that the following language reflects our definition of the term "Internet". "Internet" refers to the global information system that: (i) is logically linked together by a globally unique address space based on the Internet Protocol (IP) or its subsequent extensions/follow-ons; (ii) is able to support communications using the Transmission Control Protocol/Internet Protocol (TCP/IP) suite or its subsequent extensions/follow-ons, and/or other IP-compatible protocols; and (iii) provides, uses or makes accessible, either publicly or privately, high level services layered on the communications and related infrastructure described herein." 489 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As the Internet grew, it became harder and harder for the NIC to keep the list current. Anticipating that this problem would only get worse as the network expanded, researchers at USC Information Sciences Institute launched an effort to design a more distributed way of providing this same information. The end result was the Domain Name System (DNS)1 3 which allowed hundreds of thousands of "name servers" to maintain small portions of a global database of information associating IP addresses with the names of computers on the Internet. The naming structure was hierarchical in character. For example, all host computers associated with educational institutions would have names like "stanford.edu" or "ucla.edu." Specific hosts would have names like "cs.ucla.edu" to refer to a computer in the computer science department of UCLA, for example. A special set of computers called "root servers" maintained information about the names and addresses of other servers that contained more detailed name/address associations. The designers of the DNS also developed seven generic "top level" domains, as follows: Education—EDU Government—GOV Military—MIL International—INT Network—NET • (non-profit) Organization—ORG Commercial—COM Under this system, for example, the host name "UCLA" became "UCLA.EDU" because it was operated by an educational institution, while the host computer for "BBN" became "BBN.COM" because it was a commercial organization. Top-level domain names also were created for every country: United Kingdom names would end in “.UK,” while the ending “.FR" was created for the names of France. The Domain Name System (DNS) was and continues to be a major element of the Internet architecture, which contributes to its scalability. It also contributes to controversy over trademarks and general rules for the creation and use of domain names, creation of new top-level domains and the like. At the same time, other resolution schemes exist as well. One of the authors (Kahn) has been involved in the development of a different kind of standard identification and resolution scheme1 4 that, for example, is being used as the base technology by book publishers to identify books on the Internet by adapting various identification schemes for use in the Internet environment. For example, International Standard Book Numbers (ISBNs) can be used as part of the identifiers. The identifiers then resolve to state information about the referenced books, such as location information (e.g. multiple sites) on the Internet that is used to access the books or to order them. These developments are taking place in parallel with the more traditional means of managing 1 3 The Domain Name System was designed by Paul Mockapetris and initially documented in November 1983. Mockapetris, P., "Domain names - Concepts and Facilities", RFC 882, USC/lnformation Sciences Institute, November 1983 and Mockapetris, P.,"Domain names—Implementation and Specification," RFC 883, USC/lnformation Sciences Institute, November 1983. (See also http://soa.granitecanyon.com/faq.shtml.) 1 4 URL 2: The Handle System. See www.handle.net. 490 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Internet resources. They offer an alternative to the existing Domain Name System with enhanced functionality. The growth of Web servers and users of the Web has been remarkable, but some people are confused about the relationship between the World Wide Web and the Internet. The Internet is the global information system that includes communication capabilities and many high level applications. The Web is one such application. The existing connectivity of the Internet made it possible for users and servers all over the world to participate in this activity. Electronic mail is another important application. As of today, over 60 million computers take part in the Internet and about 3.6 million web sites were estimated to be accessible on the net. Virtually every user of the net has access to electronic mail and web browsing capability. Email remains a critically important application for most users of the Internet, and these two functions largely dominate the use of the Internet for most users. The Internet Standards Process Internet standards were once the output of research activity sponsored by DARPA. The principal investigators on the internetting research effort essentially determined what technical features of the TCP/IP protocols would become common. The initial work in this area started with the joint effort of the two authors, continued in Cerfs group at Stanford, and soon thereafter was joined by engineers and scientists at BBN and University College London. This informal arrangement has changed with time and details can be found elsewhere.1 5 At present, the standards efforts for Internet is carried out primarily under the auspices of the Internet Society (ISOC). The Internet Engineering Task Force (IETF) operates under the leadership of its Internet Engineering Steering Group (IESG), which is populated by appointees approved by the Internet Architecture Board (IAB), which is, itself, now part of the Internet Society. The IETF comprises over one hundred working groups categorized and managed by Area Directors specializing in specific categories. There are other bodies with considerable interest in Internet standards or in standards that must interwork with the Internet Examples include the International Telecommunications Union Telecommunications standards group (ITU-T), the International Institute of Electrical and Electronic Engineers (IEEE) local area network standards group (IEEE 801), the Organization for International Standardization (ISO), the American National Standards Institute (ANSI), the World Wide Web Consortium (W3C), and many others. As Internet access and services are provided by existing media such as telephone, cable and broadcast, interactions with standards bodies and legal structures formed to deal with these media will become an increasingly complex matter. The intertwining of interests is simultaneously fascinating and complicated, and has increased the need for thoughtful cooperation among many interested parties. 1 5 Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff, "A Brief History of the Internet," www.isoc.org/internet/history/brief.htmI. 491 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Managing the internet Perhaps the least understood aspect of the Internet is its management. In recent years, this subject has become the subject of intense commercial and international interest, involving multiple governments and commercial organizations, and recently congressional hearings. At issue is how the Internet will be managed in the future, and, in the process, what oversight mechanisms will insure that the public interest is adequately served. In the 1970s, managing the Internet was easy. Since few people knew about the Internet, decisions about almost everything of real policy concern were made in the offices of DARPA. It became clear in the late 1970s, however, that more community involvement in the decision-making processes was essential, in 1979, D