7
Adjusting Department of the Navy Organization and Management to Achieve Network-Centric Capabilities
7.1 KEY DECISION SUPPORT PROCESSES AND THEIR INTERRELATIONSHIPS
The Navy-Marine Corps team takes pride in giving the United States the means to implement national policy unconstrained by national boundaries. The core of the naval capability is an integrated forward-deployed battle force of Navy and Marine Corps combat units. When joined by a robust network-centric command and control (C2) system, the battle force will be adaptable to a wide variety of situations across the whole spectrum of operations from peacetime presence and training to full-scale war. Unfortunately, the committee found that the integrated battle force concept is not reflected in integrated decision making for four key management processes that are basic to better implementing the concept of network-centric naval forces for more effective operations. These four key decision support processes include:
-
Requirements generation: clearly stating operators’ mission needs;
-
Mission analyses (assessments) and resource allocation: aligning program and budget resources to meet mission needs;
-
Systems engineering, acquisition management, and program execution: integrating, acquiring, and deploying for interoperability; and
-
Personnel management: acquiring personnel and managing careers to meet network-centric needs.
The first three are key for determining who has responsibility for what missions and functions both within the Department of the Navy and across the
Department of Defense (DOD). The fourth, personnel management, concerns acquiring and retaining high-quality, trained individuals to execute all of the Navy Department’s missions.
The objective in the integrated management of all of these decision support processes is to field the best mix of forces, materiel, and support to accomplish national security objectives and strategy within applicable funding constraints. This objective applies for the DOD in total as well as the Department of the Navy. The effective implementation of network-centric operations (NCO) will require the cooperative actions of all the military departments; none can reach maximum effectiveness within its own boundaries of responsibilities and resources. Jointness, interoperability (i.e., the ability for systems to work together), and the sharing of information across all boundaries within the DOD are essential.
In the same vein, the actions within the three major decision support processes are interrelated and so have to be mutually supporting and well integrated. Effectiveness in the three, individually and collectively, is central to rigorous assessment of important issues and informed decision making. To provide the leadership required for a successful transition to network-centric operations, the Department of the Navy will have to adjust its thinking and key processes from a platform focus to a network-centric orientation.
As illustrated in Figure 7.1, each of the three key decision support processes serves different elements of the Navy Department leadership. This differentiation is a result of the functions assigned in law to the Secretaries of the military
![](/openbook/0309069254/xhtml/images/p2000a42ag290001.jpg)
FIGURE 7.1 Major decision support processes in the Navy. Acronyms are defined in Appendix H.
departments, the Chairman of the Joint Chiefs of Staff, the Service Chiefs, and the military departments’ Assistant Secretaries for Research, Development, and Acquisition. Box 7.1 gives details regarding the division of support for requirements generation and for acquisition management.
Effective integration among the processes is essential for achieving interoperability and will be even more important as the Department of the Navy shifts to a network-centric focus. This shift will require the cooperation of the combined military and civilian leadership in the Department of the Navy and the DOD to gain the full benefits of network-centric operations.
Transformations from one method of operation to another, such as from a platform-centric to a network-centric naval force, do not succeed in large organizations without strong support from the top. An organization’s leaders are responsible for ensuring that those involved in change are meeting goals and objectives and that they persist in making progress. An important related aspect in transforming the forces is to develop concrete measures of output for the forces—i.e., measures of the ability to accomplish assigned military missions.
The first four of the following six sections cover the key decision support processes related to implementing the network-centric concept. Each covers the process as currently implemented, some weaknesses as they relate to implementing good practices for improving network-centric operations, and findings. The fifth section addresses current organizational responsibilities (and weaknesses) for implementing more effective network-centric operations. Suggestions and specific recommendations for improving the individual processes and, more importantly, for promoting their integration to achieve the larger goal of implementing more effective network-centric capabilities are offered in the last section.
7.2 REQUIREMENTS GENERATION: CLEARLY STATING OPERATORS’ MISSION NEEDS
7.2.1 The Requirements Generation Process
A requirement can be defined as “an established need justifying the timely allocation of resources to achieve a capability to accomplish approved military objectives, missions or tasks.”1 Preparing a requirement that has a reasonable chance of successful development and acquisition depends on the balancing of capability, resources, and timeliness among the operational, technical, and financial communities. An intense and continuing dialogue among the three communities is required to avoid a failed development, i.e., one leading to a system that
Box 7.1 Division of Responsibility for Requirements Generation and Acquisition Management Requirements generation supports the Chairman of the Joint Chiefs of Staff (CJCS) across the DOD and supports the Chief of Naval Operations (CNO) and the Commandant of the Marine Corps (CMC) (beginning with the operating force commanders) within the Department of the Navy. Following passage of the Gold-water-Nichols Act of 1986, which strengthened the role of the CJCS, the Services still are responsible for the functions of manning, training, and equipping the forces to be provided to the joint regional and functional commanders-in-chief (CINCs). The Joint Requirements Oversight Council (JROC), chaired by the Vice Chairman of the Joint Chiefs of Staff (VCJCS), is responsible for reviewing and approving all requirements that have “joint interest,”1 but the Service Chiefs retain the responsibility to develop requirements for the forces that they provide to the joint CINCs, who command U.S. military operations. The joint CINCs participate in the JROC process through their advice to the CJCS and the VCJCS (and also by stating their views on needs to their Service component commanders). Acquisition management supports the Under Secretary of Defense for Acquisition and Technology (USD (AT)) across the DOD and the Assistant Secretary of the Navy for Research, Development, and Acquisition (and the Systems Commands (SYSCOMs)) within the Department of the Navy. Program managers for major new acquisition programs, whose primary function is managing the development and procurement of new systems, are responsible to the USD (AT) and, under law, are to report to the USD (AT) through no more than two intermediate levels in their management chain. The acquisition management process falls under the purview of the civilian (Service Secretariat) side of the military departments, and the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN (RDA)), is the designated Service acquisition executive. The Planning, Programming, and Budgeting System (PPBS) supports the Secretary of Defense across the DOD and both the Secretary of the Navy and the two Service Chiefs within the Department of the Navy. The Service Secretary is responsible for submitting program and budget proposals to the Secretary of Defense for approval, and the individual Service Chiefs (and their staffs) retain responsibility for developing the proposed programs for their Service. The requirements generation and the acquisition management processes are event based (decision points occur based on readiness to proceed). They are intended to support the time-driven PPBS, which assists the military departments and the Secretary of Defense in preparing budgets presented to the Congress on specific dates. The fact that two of the systems are event based and the third, the most dominant, is driven by external calendar constraints (and also more recently by externally imposed funding constraints) has created tension rather than cooperation among the staffs responsible for managing the processes. Moreover, in recent years other circumstances have also proved detrimental to good integration. Some major programmatic decisions have been delayed until late in the budget preparation process; some long-term modernization plans have been destabilized during annual budget development cycles; and worldwide contingencies have required larger-than-expected operating funds. |
will be obsolete, ineffective in the field, or too expensive. This is particularly true for developments involving rapidly changing technology.
The rapid evolution of information technology, the inherent jointness of information networks, and the loss of technical leadership to the commercial market have made the generation of requirements for sensors and information systems difficult in all the Services. The implementation of the relatively new joint processes, the Service and platform orientation of the acquisition systems, and the need for Navy personnel to acquire new skills and understanding have contributed to the difficulty of the challenge. However, achieving the necessary dialogue is essential, whether by a linear or a spiral process.
Currently, a formal process is not in place to produce the integrated requirements for more effective NCO. Also, there does not exist a Navy (or DOD) element whose position, longevity, and interests are adequate to control the evolution of capabilities to support NCO. Historical precedent can be found in the Navy’s General Board of the 1920s and 1930s. In that period of great uncertainty about the future, the General Board was invaluable in maintaining a map of what had been decided and why, and then in enforcing consistent, synchronized allocation of resources. However, the board may have been less innovative than what is needed today to lead the current transformation to more effective network-centric operations.
A formal requirement in the Navy is the responsibility of the Chief of Naval Operations (CNO), who uses the Office of Naval Operations (OPNAV) to provide top-down guidance and oversight of what is a very diffuse and diverse requirements generation process. In this process a formal requirement is staffed by OPNAV and approved by the CNO or Vice Chief of Naval Operations (VCNO) or their designated authorities. It is then sometimes approved by others within the DOD. Upon final approval it then may become the basis for an acquisition program, to be approved by Congress (if it is large enough to require that specific attention). Generally, platform sponsors dominate the early formulation of Navy requirements, while the requirements process in the Marine Corps rests with the Commandant of the Marine Corps (CMC) staffed by the Marine Corps Combat Development Command (MCCDC).
Occasionally requirements are discovered or generated by top-down analysis. Much more frequently they flow up informally from the operational community, which complains about deficiencies in existing systems, or from the technical community, which sees new opportunities in emerging technologies. Rarely is a formal requirement developed for a new system; most requirements are for modifications to existing systems.
Fixing deficiencies and embedding new technologies in existing systems are most often funded through repair and modernization efforts. In most cases no formal requirement is written, and OPNAV’s visibility is limited.
7.2.1.1 Requirements Through Analysis
Over the last four decades requirements have been developed principally through operational analysis or, in the absence of such analysis, by assertion.2 This process generally has been linear, with the desired end result specified in terms of performance parameters (sometimes with technical specifications written in as part of the “requirement”). However, for areas where the technology is changing rapidly, this approach is weak if the development and procurement of a required military system cannot be achieved within a reasonable time.
The committee believes that a new paradigm is needed to develop requirements for rapidly changing technology areas in the future network-centric world.
7.2.1.2 Requirements Through Experimentation
Experimentation provides a means to explore alternative doctrine, operational concepts, and tactics that are enabled by new technologies or required by new situations. That is, new technologies or situations may call for different ways of conducting operations. But without actual operational experience in using new technologies or in using existing technologies in new situations, experiments are the next best thing. For making informed decisions on future doctrine and requirements, experiments provide a better basis than does reliance on analytical studies and/or simulations.3
Experimentation can be performed on different scales, in different echelons, within different mission types, and with different operational communities. Experiments should complement modeling and simulation activities. Although they can fail in their ability to find the right solution, experiments should always provide knowledge about the ramifications of new ideas and technologies, to assist those who write requirements by reducing the likelihood that they will specify requirements for too much (something that cannot be achieved within reasonable bounds) or too little (improvement insufficient to justify development).
7.2.1.3 The Spiral Process
The spiral process, also called evolutionary development of requirements and systems, is an innovative method for fielding a system quickly by using
commercial and government off-the-shelf equipment, with maximum user involvement throughout the process. The first spiral is usually regarded as the first development cycle of a system. Subsequent spirals allow technology insertion, the addition of new mission capabilities and upgrades, and enhancement of interoperability and integration, all in an environment of continuous user feedback.
The spiral process characteristically partitions the more traditional requirements generation and acquisition cycle into shorter, incremental cycles in which operators get hands-on access to the evolving system in each cycle and provide their feedback and modified requirements to a development team that is prepared to respond with adjustments. In so doing, the operators may modify their own operational processes and concepts based on use of the emerging capability. As such, the spiral process can also support reengineering of the operational concepts and doctrine. Each spiral has its own defined activities, performance objectives, schedule, and cost; and each spiral concludes with a user decision to field the system based on the requirements developed to date, continue with evolution, or stop.
The spiral process is a powerful alternative to the traditional requirements generation and acquisition processes. One of its advantages is that it offers a sound replacement in areas in which technology is changing rapidly and cycle times in the commercial sector are short compared to the traditional DOD requirements and acquisition processes. A major key to success is the involvement of operators, requirement generators, and technical personnel with appropriate resource allocation support from the financial sector. The spiral process also accelerates fielding of innovative operational processes and systems. Some of the successful innovations carried out by the military services are described in Chapter 2.
7.2.2 Requirements for Interoperability in Joint Operations
The DOD requirements generation process for joint operations is hampered by Title 10 language that assigns the Services the primary responsibility for equipping, manning, and training the Service component forces. The Joint Requirements Oversight Council is responsible for overseeing and prioritizing DOD requirements affecting joint operations and can review any requirement proposed by a Service. In addition, the Secretary of Defense and other elements of the Executive Branch have established separate entities to procure and operate major C4ISR systems (e.g., DISA, DIA, NRO, NSA).4 Unfortunately, this ununified approach can further exacerbate the separation between users and
producers, hinder their dialogue, and result in “stovepipes” of communication and information.
Although it specifies that the Services define operational and system architectures, the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD (C3I)) does not spell out the missions or any other taxonomy to guide building a comprehensive set of interlocking architectures across Services or stovepipes. As a result, responsibility for definition of systems’ architectures has fallen largely to each individual Service, and lateral connectivity on the battlefield among Services has suffered. Even the Joint Tactical Information Distribution System is implemented differently within the various Services, thus limiting interoperability. A positive action has been the recent effort by the Joint Staff Joint Theater Air and Missile Defense Organization (JTAMDO) to identify fixes for existing problems and to anticipate problems with regard to tactical ballistic missile defense.
In addition, the Office of the Secretary of Defense has begun to require a command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) supportability annex for every new major platform program. This annex is supposed to define the platform’s interface requirements for information support. A great deal of effort has been spent on these annexes for the next generation surface combatant for the Navy (DD-21) and the joint strike fighter. However, refinement of the process is needed so that not every new acquisition program is forced to create its own similar infrastructure and architecture, which may not be consistent with those already developed.
Commanders-in-chief (CINCs), who provide input to the Joint Requirements Oversight Council (JROC) through the Vice Chairman, Joint Chiefs of Staff, often focus on their immediate needs rather than on longer-term systems. However, the CINC’s specification of the Navy’s numbered fleets as potential joint task force commanders is a positive step that has increased the numbered fleets’ sensitivity to the requirements for interoperability and to the need for development of updated capabilities—for example, those aboard the USS Coronado.
All requirements for potential acquisitions with “joint interest” as defined by the Joint Staff are subject to JROC review, which provides for some examination of joint interoperability and commonality. However, the Joint Staff lacks the significant technical capability required to ensure meaningful scrutiny of each system. Smaller acquisition programs not designated as having joint interest are not reviewed. The JROC does use the C4ISR Decision Support Center, which is staffed almost entirely by contractors, to identify potentially important interface and connectivity requirements.
A recent joint event of some portent is the emergence of the U.S. Joint Forces Command (USJFCOM), which has begun to have an impact on the requirements generation process. USJFCOM, with its recently acquired Joint Battle Center and others, now has a significant operational experience base and an intense if not always friendly training relationship with the other regional CINCs. It may
become an important agent for generation of joint interoperability requirements including hardware, software, and tactics, techniques, and procedures (TTPs).
USJFCOM is currently preparing the Capstone Requirement for Joint Tactical Communications, Command, Control, and Computers. This draft document identifies generic deficiencies and establishes top-down requirements, such as, “Survival information must be delivered within a threshold of 6 seconds and planning information within 30 seconds from when the information is initially processed and ready for transmission within the Joint area of operation.” The effort is an interesting first step toward a top-down approach to specifying architectural constraints on all C4ISR systems, but the connection to specific Service system contract specifications has not yet been made, nor is the relationship to the Joint Interoperability Testing Center clear. Capstone requirements for NCO also may be a useful concept within the Navy, the leader in NCO among the Services.
A first step in this direction is the Capstone Battle Force Requirements Document being developed under the NAVSEA Battle Group Systems Interoperability Testing. The objective is to solve problems with regard to common time reference, data registration, combat identification, navigation, correlation algorithms, and metrics identified repeatedly in the All Service Combat Identification Evaluation Team exercises. The capstone document has a decidedly joint focus—Joint Integrated Air Defense System’s Interoperability Working Group and the joint interface control officer are participating in its development.
USJFCOM is also the executive agent for the DOD experimentation program to support the evolution of Joint Vision 2010. This effort, which is just beginning, could become an important step in the spiral development of the NCO concept and of requirements for C4ISR systems.
In summary, the OSD, the Joint Staff, and defense agencies provide sporadic, conflicting, and sometimes onerous guidance with regard to C4ISR requirements rather than a well-structured, consistent, and testable process for elicitation and validation of cross-Services information needs. Promising exceptions are emerging, but a stronger mechanism for ensuring joint interoperability is required within the Services, even if only to supply points of contact for the joint efforts.
7.2.3 Tools for Developing Interoperability and Related Requirements
Rapidly evolving information technologies present serious challenges to but also opportunities for dealing with the evolution to NCO. New, commercially driven technologies are becoming available to the Department of the Navy far faster than would be possible with military research and development (R&D) only.
The refreshment of existing information systems at 2- to 3-year intervals may be possible and economically feasible because of reduced costs for procurement and operation. The new joint Global Command and Control System (GCCS)
was built at a significantly lower cost than had been budgeted for continuation of its predecessor, the Worldwide Military Command and Control System. If the military systems incorporating commercial building blocks can adjust to a stepped-up pace for embedding new components in operational platforms as well as addressing related training, supportability, and security and other concerns, it should be possible to break out of the traditional 15-year acquisition cycle. Commercial communications services may take over large parts of the Joint Planning Network, for example, relieving the Navy of operating its own extensive communications utilities and applications.
Accomplishing a rapid evolution will place demands for change on all Navy Department processes, including the requirements generation process. Synchronization of the changing requirements across a battle force is a primary concern. Merely keeping track of the changes and ensuring interoperability on deployment have already become difficult.5 New communications technology has made it possible to realistically link hardware-in-the-loop simulators of the major sensor, communications, and combat systems of the battle group. This distributed simulation capability, called the distributed engineering plan, can serve as a testbed for interoperability across the battle force. In addition, distributed simulations less expensive than the DEP can drive experiments leading to the development of new operational concepts, subsequent new or revised doctrine, and requirements for system modifications and new systems and components.
The combination of operational analysis capabilities and distributed simulation tools, the war gaming and fleet battle experiment capabilities at the Naval War College, and the doctrine development and experimentation program of the NWC’s Navy Warfare Development Command (NWDC) could be extremely useful in defining future mission interdependencies and requirements. Inclusion of the U.S. Marine Corps in such an effort could be an excellent step toward closer synchronization of littoral requirements. An example of such a combined effort is that of the Air Forces’ joint expeditionary force experiments (JEFXs) conducted under the auspices of the Air Combat Command’s Aerospace Command and Control, Intelligence, Surveillance, and Reconnaissance Center (AC2ISRC). As a related effort, the AC2ISRC is procuring the software to support the aerospace expeditionary force (AEF), the new form of the deployed U.S. Air Force. The Electronic Systems Command at Hanscom Air Force Base has a new system program office for all command and control systems that is handling the acquisition for the AC2ISRC. These agencies are working closely together to iterate the development of the software through the EFXs and intermediate testing with users at intervals of about 1 year.
The Navy’s requirements generation process should change to include interactive participation. Use of the spiral process for evolutionary acquisition has
been mandated for Air Force C2 systems, and the process is being used by the Air Force to develop the C2 system for its AEF. In general, the initial requirement in the spiral process should be a statement of functional performance at an easily accomplishable level, in order to provide a prototype rapidly and give the operational community a testable item with limited financial risk. After testing, the requirement may become tighter, evolve in another direction, or disappear entirely. In the spiral process, the operational community and the requirements writers are continually involved in an integrated products team (IPT)-like setting with the acquisition team.
New distributed simulation technology has given the Department of the Navy tools for improving the requirements generation process to respond to rapid technological change. The Department of the Navy should capitalize on the technology to reap the benefits of NCO.
7.2.4 Requirements for Synchronization Among Cross-Platform Capabilities
In addition to shortfalls in the requirements generation process, the committee believes that there are deficiencies in the resource prioritization and acquisition processes for support of NCO by the Navy (addressed in subsequent sections). In all three areas, the lack of focus, inflexibility, and lack of a capability to plan and deliver across platforms, and in conjunction with other Services, are key deficiencies. Because the platform communities place higher priority on the number and performance of their platforms than on the performance of the total networked system, cross-platform interoperability, including networking requirements, cannot be defended well and is often sacrificed when funding is scarce. To put it another way, the Navy provides resources for its platforms, not its battle forces.
Consensus is needed on operational architectures and synchronization of migration away from legacy systems as systems change. Furthermore, all parties must stick to the schedule if the transition to network-centric operations is to be accomplished as rapidly as is technically and economically possible. One hold-out can delay the transition for the whole fleet.
The requirements generation process must have a firm basis in the operational community, which provides expertise for new ideas on how existing systems can be improved in terms of readiness, efficiency, and effectiveness for current missions; how existing systems can be adapted to emerging missions; and when such systems are no longer suitable or supportable. Some organization in, or with strong ties to, the operational community will have to be in charge of developing the requirements for the interfaces that join various different platforms and operational organizations. Priorities for changes should also come from the operational community. Because the NCII will become a matter of life and death to the operational forces, it is imperative to have a single commander
who will be responsible for establishing requirements for all operational network services and improvements. Unfortunately, there is no one community within the Department of the Navy with operational credibility and authority for establishing requirements for the systems supporting NCO.
7.2.5 Requirements Generation Process—Summary of Findings
As discussed above, the committee believes that weaknesses in the requirements generation process are currently inhibiting or slowing the Navy’s transition to network-centric operations.
Finding: The Office of the Secretary of Defense, the Joint Staff, and the defense agencies provide sporadic, conflicting, and sometimes onerous guidance with regard to C4ISR requirements. There is no well-structured, consistent, and testable process for elicitation and validation of cross-Service requirements for information. Although the ASD (C3I) is trying to help the Services remedy this problem, the efforts as yet lack a unifying structure across Services and stovepipes, and the C4ISR supportability annex process needs refinement to eliminate repetitive efforts.
Finding: The Department of the Navy lacks an architectural transition plan tied to a defined program of experimentation. Lack of a plan precludes designing experiments that will permit the Navy to evolve mature NCO concepts and develop related requirements.
Finding: The Department of the Navy permits discretionary rather than directed implementation of the results of current experimentation. As a result successes are not systematically incorporated to enhance and evolve a common information infrastructure (the NCII) architecture. Currently no one organization is accountable for ensuring the implementation of results Service-wide.
Finding: The spiral process offers increased opportunities for fast-track acquisition to accelerate implementation of system architectures in the field.
Finding: New distributed simulation technology offers the Department of the Navy tools for improving the requirements generation process to respond to rapid technological change in information systems.
Finding: Successful development of more effective naval network-centric operations will require that some organization within, or with strong ties to, the operational community be in charge of developing the requirements for the interfaces for different platforms and operational organizations. No one community within
the Navy has the operational credibility and authority for preparing requirements devoted to the systems supporting NCO.
Finding: Inter-Service and joint efforts to improve interoperability have to be expanded. This could include better leveraging of emerging advanced capabilities of other Services and defense agencies. For example, capabilities being provided or developed by DARPA, DISA, NIMA, and NSA6 are essential for the NCII and require incorporation into the NCII as they mature.
7.3 MISSION ANALYSES AND RESOURCE ALLOCATION: ALIGNING PROGRAM AND BUDGET RESOURCES TO MEET MISSION NEEDS
The Navy uses its integrated warfare architecture (IWAR) process led by N81 to develop assessments for each of its missions and supporting areas (see Figure 1.2 in Chapter 1). The purpose of the IWAR process is to provide the following:
-
A current road map for warfare and support areas;
-
A focus on capabilities vice components or subsystems;
-
Cost-constrained coverage (i.e., costs constrained to 100 percent of total obligational authority;
-
A linkage across the Navy’s strategic vision, threat assessment, and programs;
-
A translation from vision to guidance for the acquisition community;
-
A foundation for allocation of resource; and
-
An integrated product team approach.
The IWAR process, guided by CNO/4-Stars, is envisioned to do the following:
-
Analyze end-to-end capabilities;
-
Achieve total force capability with synchronized pieces;
-
Accomplish battle force integration across platforms;
-
Improve rigor and discipline;
-
Prioritize capability areas inside the Navy total obligational authority;
-
Tie together program execution, budget, programming, and out-years; and
-
Provide early vision and stability for sponsors, claimants, program executive officers, and vendors to achieve efficiency.
7.3.1 Mission Analysis: The IWAR Challenge
The committee believes that network-centric operations demand the integration of component systems into a coherent system, and progress toward NCO will surely involve some evolutionary improvements that integrate legacy systems. Ultimately the full power of NCO will be realized only if the network of sensors, weapons, and information is planned and developed as a coherent system. To emphasize the point, the notional example of a future power projection operation, as presented in Chapter 3 and shown in Figure 3.2, is referred to here. This scenario illustrates the complexity of the interactions among systems, the tight time lines associated with these interactions, and the difficulty of assessing and integrating the contributions of component systems to network-centric operations within one particular mission area.
Assessing the contributions of components and subsystems to the combination of the Navy’s four major missions (see Figure 1.2) is even more difficult. Moreover, as is discussed below, the Navy currently lacks good measures of output for operational analyses and systems analyses of many of its existing missions and functions. Thus, assessing the contributions of network components to mission performance first requires developing preferred metrics and adjusting (or developing) analytic tools to evaluate them.
7.3.1.1 Depth and Continuity of Assessments
There are several shortcomings in the current IWAR assessment process. First, the process has limited resources available (both personnel and time). For example, only about 60 personnel are available in the N81 staff to lead and manage the entire IWAR process containing the 12 major analytic areas, each with multiple subdivisions.7,8 Although other parts of OPNAV and the Department of the Navy provide analytic support, the committee believes that overall support by the IWAR process is inadequate to provide the CNO the needed decision-support information. Currently most of the IWAR assessments are qualitative and judgmental rather than quantitative (e.g., stoplight charts indicating green, yellow, or red status in particular areas), in part because supporting operational analysis and systems analysis capabilities in different functional areas lack adequate measures of output and models to support good trade-offs within or across missions. The key point is that there is a need to significantly improve quantitative results provided to decision makers.
7 |
The entire N81 staff contains about 90 personnel, about two-thirds of whom are involved in the IWAR process. |
8 |
The 12 major analytic areas are maritime dominance, deterrence, information superiority and sensors, power projection, air dominance, sustainment, infrastructure, manpower and personnel, readiness, training and education, technology, and force structure (see Figure 1.2 in Chapter 1). |
Second, the IWAR process is used primarily to make recommendations for the CNO’s programming guidance to the resource sponsors and has limited impact outside the CNO’s program objective memorandum (POM) development process. To be fully effective, the IWAR process must continue through the budget and execution processes to ensure that conclusions and decisions derived in the POM process are not overtaken by events. Ideally, the assessments should be based on analytic tools and assessment methods that the individual resource sponsors and claimants understand and use; be used throughout the planning and execution processes; and be available to the CNO and the Secretary of the Navy whenever resource decisions are required. However, the IWAR process and supporting operational and systems analyses capabilities do not currently enable continuous assessments from requirements generation through programming, budgeting, and execution.
7.3.1.2 Measures of Effectiveness and Performance
A major reason for the lack of depth in the IWAR assessment process (including its supporting elements in the resource sponsor and claimant communities) is that there are no good, analytical, objective measures of effectiveness (MOEs) and/or measures of performance (MOPs) for C4ISR, particularly for mission C2 systems. And, although an IWAR analysis may provide an assessment of how well a current or projected battle force performs in some network-centric operations, it does not provide the means for making system trade-offs. That is, would an investment in the NCII provide more or better warfighting capability than an equal investment of resources in another warfighting component (e.g., such as an improved weapon or sensor)? This situation exists because there are insufficient means to measure the warfighting value of systems for a battle force; there is as yet not a good integrated campaign effectiveness model for naval forces. Examples of what exists and what is missing are provided in the following list:
-
Combat system operational requirements documents (ORDs) specify detection ranges, engagement envelopes, and raid kill probability;
-
C4I ORDs specify throughput, net cycle time, and probability of corruption;
-
Given a target, detection range, and weapons envelope, raid kill probability within a time window is determined by reaction time and weapon/delivery subsystem reliability;
-
More time to react allows more depth of fire and supports higher probability of kill;
-
The composition of battle force component systems predetermines a set of detection ranges, engagement envelopes, weapons reliability, and communications network;
-
However, the reaction time of the battle force as a whole is not specified, and no good measures of battle force campaign effectiveness are provided because naval battle force dynamics are especially difficult to model.
Currently, the Navy lacks good MOEs and MOPs for evaluating network-centric operational capabilities and the contributions of different components to the larger goal. A means of developing better metrics for battle force mission capabilities lies in the design reference mission (DRM) concept. A DRM is a set of one or more mission scenarios describing what needs to be accomplished in a particular mission. It indicates the range of capabilities of the adversary, the environment, rules of engagement, the range of capabilities of friendly forces, and any other factors that bear on the outcome of the mission. It must be comprehensive enough to cover the full range of mission possibilities, must have agreement from the warfighters that it is comprehensive, and must be kept up-to-date.
Battle force DRMs are being developed by NAVSEA, and DRMs are in place for theater ballistic missile defense and DD-21. DRMs are in progress for theater air defense (TAD) battle management command, control, communications, computers, and intelligence (C4I), TAD overland cruise missile defense, next-generation aircraft carrier (CVX), and the nuclear-powered aircraft carrier, CVN-77. However, DRMs for other warfare areas are lacking. If other DRMs were completed, it would be possible to determine, in quantifiable terms, such attributes (effective MOEs) as battle force reaction time for a range of sensors, weapons, and NCII capabilities. This in turn would allow for analysis of overall NCO capabilities to determine the “right” mix of components across missions and across platforms.
Another major deficiency in the IWAR assessment process is the treatment of new versus legacy components. Legacy components are generally inadequate to some degree because they were developed years ago for a different purpose and have evolved to where they are today. However, all have not evolved in the same way and, because they are closed subsystems, they are difficult to upgrade and standardize. On the other hand, a new component subsystem can incorporate the latest technological advances. All things being equal, operators would want the new component subsystem, but it takes significant resources and years to develop and field a new component subsystem. The fielding part is often overlooked in making component and component subsystem trade-offs.
Because developing and fielding a new component take years, forces will be required to continue operating with the legacy components, and during this time there is some likelihood that the component will be required for combat. To the extent that the legacy component is inadequate for new or revised concepts of operation, there is a risk that it, and the mission, will fail. Therefore, some resources will be required to extend the life of the legacy component or to improve its performance. Since resources are a zero-sum trade, the challenge is to determine how much to devote to maintaining and improving legacy components
at the risk of lengthening the development and fielding time of new components. However, the Navy lacks an agreed-upon methodology for assessing the risk of failure of a military operation (i.e., a methodology that consistently arrives at the same answer for a given set of circumstances).
To make the choices about how much to spend on maintaining and improving legacy components versus buying new ones requires knowing exactly what is inadequate about the legacy component. Each year the All Service Combat Identification Evaluation Team conducts a joint Service exercise that is highly instrumented and provides the raw data for an engineering analysis. NAVSEA has been working on root-cause analysis from exercises and has amassed a considerable data bank. The distributed engineering plant will allow for hypotheses to be tested in a controlled and repeatable environment, thus allowing some degree of confidence in the success of proposed modifications to legacy systems. Given DRMs, it is possible to measure how much warfighting improvement can be obtained for a given investment in modifying legacy components,9 as well as to measure the probability that a component will fail in an operational setting. However, the risk associated with warfighting failure must continue to be a judgment call on the part of Navy leadership.
7.3.2 Resource Allocation
There are three pieces to the resource allocation process in the Department of the Navy: mission analysis (assessment), programming, and budgeting. The current responsibilities for these portions of the process are as follows:
-
Mission analysis (assessment), discussed in the previous section, is currently chaired by N81 using the IWAR assessment process, with NAVSEA providing root-cause analysis and development of DRMs.
-
In the programming phase the resource sponsors are generally (a) N6 for Navy-wide telecommunications, computer centers, and the higher-level command applications and (b) the platform sponsors (N86, N87, and N88) for the mission/combat component subsystems for domain-specific applications and dedicated tactical data links.
-
Budgeting and execution are handled by the system commands in parallel with their OPNAV sponsors in the programming process.
In the programming phase, the Department of the Navy uses program ele-
ments (PEs) in the Navy portion of the Future Year Defense Program (FYDP)10 to allocate resources to resource sponsors, who then propose changes to their programs to accommodate changing requirements and fiscal constraints. The PEs correspond primarily to platforms (e.g., cruisers, aircraft carriers, F/A-18 squadrons) and include all the resources associated with that platform (R&D, procurement, operations, manpower, and so on). Unlike the Army, which has PEs for divisions, the Department of the Navy has no PE for battle forces, and so Navy programming tends to be more platform-centric. Any oversight in resource allocations for battle forces must be identified based on separate analysis and is handled primarily on a case-by-case basis.
Since DRMs are lacking for many mission areas, comprehensive oversight of resource allocation for naval battle forces is spotty at best. There is a significant potential for resource mismatches between and lack of coordination among programs (e.g., the ES-3 program was discontinued by N88 but the shipboard data links developed for the ES-3 continued to be funded by N6—and are now used for the U-2).
In short, because utilities (i.e., information infrastructure) and applications (which ride on the infrastructure) are handled by different sponsors and systems commands whose jurisdiction depends on arbitrary definitions in vogue at the time, there is inadequate oversight for network-centric operations as a whole. There are often seams,11 particularly between closed legacy system components, with deficiencies (and mission needs) in both the utilities and the applications, and there is no systematic means of ensuring that the seams are consistently covered. While the support for resourcing of individual programs is usually well addressed, the resourcing of the seams for the battle force as an entity is not. Unfortunately, the capabilities of the whole force may be less than the sum of the individual parts if seams and integration are not dealt with sufficiently. For example, when parts of this committee were reviewing land-attack targeting within force projection, they found, among other things, the following:
-
Inadequate targeting for naval surface fire, including lack of an agreed-upon method for transmitting target coordinates from a deep-inland forward observer to an over-the-horizon firing ship; and
-
Inadequate capability to detect, identify, track, and engage moving targets.
10 |
Cohen, William S., Secretary of Defense. 2000. “Chapter 17: The FY 2001 Defense Budget and Future Year Defense Program,” Annual Report to the President and the Congress, U.S. Department of Defense, Washington, D.C. Available online at <http://www.dtic.mil/execsec/adr2000/chap17.html>. Secretary of the Navy. 2000. Budget of the Department of the Navy, U.S. Department of the Navy, Washington, D.C., February. Available online at <http://navweb.secnav.navy.mil/pubbud/o1pres/db_u.htm>. |
11 |
The term “seams” refers to the interfaces in which compatibility and interoperability must exist between assets. |
Although power projection is one of the four major Department of the Navy and IWAR missions, the seams among the deputy N8 platform resource sponsors for carrying out naval missions appear to be receiving less attention in resource allocation than the major platforms themselves. This situation is critical for major mission areas such as power projection (or even major portions of power projection such as striking land targets). These areas involve many parts of the Navy and Marine Corps team that in the resource allocation process are represented by different parts of the OPNAV staff (both in and beyond the N8 organization). This arrangement makes it particularly difficult to address the system component trade-offs for such mission areas.
In the budgeting and execution phases, too, more resources are provided for platforms than for the seams within and around battle forces. With the exception of the Navy’s interoperability initiative in NAVSEA, programs are handled individually and the seams continue to exist. NAVSEA does look at the entire battle force but has limited or no authority to effect changes in individual programs. A corollary problem is that network-centric programs in particular are viewed as Navy, not joint—there is no formal joint advocate in either OPNAV or the systems commands.
The net result is an unfulfilled need to provide comprehensive oversight of network-centric operations in the programming, budgeting, and execution processes. Such oversight is the only way to ensure that the seams are adequately addressed and that there is joint advocacy in all three phases of the broader resource allocation.
A second problem is that the allocation of resources is insufficient for spiral acquisition. In an environment of tight fiscal constraints, the tendency is to specify an end product that can be fully justified to the Office of the Secretary of Defense and Congress. Spiral acquisition is often viewed as counter to this approach and as a process that puts Navy Department resources unnecessarily at risk. Such an outcome can be mitigated to some degree by specifying phased end products (e.g., baselines) that are the result of implementing spiral development in a homogeneous product line. However, current Department of the Navy and DOD resource allocation procedures discourage rather than encourage the good commercial practice of spiral acquisition for systems and applications dominated by rapidly changing technologies.
7.3.3 Mission Analyses and Resource Allocation Process—Summary of Findings
As discussed above, the committee believes that the following findings are important elements for the mission analyses and resource allocation process needed to better implement capabilities for network-centric operations.
Finding: The IWAR assessment process is not adequately staffed to provide good quantitative assessments of mission area capabilities and deficiencies.
Finding: The IWAR assessment process and supporting operational and systems analyses capabilities do not currently enable continuous assessments from requirements generation through programming, budgeting, and execution.
Finding: The Navy lacks good measures of effectiveness and measures of performance for evaluating network-centric operational capabilities and the contributions of different systems to the larger goal.
Finding: A comprehensive set of defense reference missions does not exist across all mission areas. A comprehensive set would provide the basis for developing good metrics for battle force mission capabilities.
Finding: The distributed engineering plan could provide considerable information that would be useful in testing potential modifications to legacy systems.
Finding: The Navy has no program elements that specifically identify the resources for funding the “seams” among individual programs within battle forces.
Finding: No one office in the Navy has the responsibility and authority to address the trade-offs among system components for major Navy and naval force missions (or even major portions thereof). The existing capabilities are more focused on trade-offs among components for major platforms.
Finding: Comprehensive oversight of network-centric operations as a whole within the programming, budgeting, and execution processes is needed to ensure an adequate consideration of “seams” and jointness.
Finding: Current Navy and DOD resource allocation procedures discourage the good commercial practice of spiral acquisition for systems and applications dominated by rapidly changing technologies.
7.4 SYSTEM ENGINEERING, ACQUISITION MANAGEMENT, AND PROGRAM EXECUTION
The process for acquiring networking capabilities is not at all straightforward, nor are there “silver bullet” management solutions that, once adopted, will address the management challenges for all time.
Previous sections stress that information superiority will require information systems interoperability (at the technical and data levels) that cannot be realized without eliminating or mitigating several major obstacles. This section examines
the system engineering, acquisition, and program execution processes whereby the needs and requirements for new network-related capabilities can be managed within the mechanisms embodied in Goldwater-Nichols reforms and DOD acquisition directives.12
7.4.1 Acquisition Challenges to Achieving Operational Interoperability
Different military organizations approach their missions differently and implement mission-supporting doctrine and systems accordingly. For example, normal use for the Army Patriot Air Defense System was assumed to mean no friendly aircraft in the zone of fire; consequently, identification friend or foe capabilities were initially lacking. With Patriot now envisioned as a forward-deployed weapon system, such major shortcomings need to be eliminated. Lessons from operations in Grenada (1983) through Desert Storm (1991) have shown that joint operations as well as ad hoc assemblages of units from a single Service face serious obstacles in collaborating to achieve a common objective.
To avoid such difficulties in the future, system components that will be coupled for NCO must fit into a joint operational architecture. To ensure success, that architecture must be developed and maintained by operators, analysts, and system engineers throughout the development and acquisition programs.
7.4.2 Acquisition Challenges to Achieving Technical Interoperability
To succeed in making modern computer and communication systems interoperate, academic, industrial, nonprofit, and government organizations have contributed to a set of system and subsystem architectures and interface standards designed to reduce the barriers to technical interoperability. Although the Navy and the DOD should use these commercial standards whenever practical, the committee could not find comparable efforts for tactical networks. Successful automation of networked processes for tactical portions of the NCO system will require adopting standards and organizational discipline at the data, data definition, data structure, and processing algorithm level.
The Navy has taken some recent steps to enhance the systems engineering process within the SYSCOMs (i.e., NAVSEA) and within the Office of the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN (RDA)) (i.e., the appointment of a Chief Engineer). However, the systems engineering discipline is still insufficient for integration and interoperability of cross-platform and cross-SYSCOM system components within the Navy and
Marine Corps. In addition, no single Navy organization below the CNO is in charge of each of the operational, systems, and technical architectures for network-centric operations. One or two responsible agents will be essential to enforce the necessary discipline across multiple acquisition programs.
7.4.3 Acquisition Challenges to Acquiring Information Networks
7.4.3.1 Legacy Component Constraints
In the past, communication and data processing design methodologies did not distinguish adequately between “closed” and “open” architectures, and specific application-dependent features were often embedded in generic, general-purpose computer and communications transport mechanisms. Consequently, changes on either side of the “interface” were difficult. Existing shipboard combat direction components, aircraft mission components, and tactical data links reflect these design approaches, making replacement an unlikely near-term option. More recently the Department of the Navy has taken steps toward open systems architectures, which should alleviate the problem of upgrades in the future. However, there are no specific Department of the Navy or DOD acquisition provisions or regulations that encourage or enforce the separation of utilities (transmission media and control processes for their management) from domain-specific applications (those that directly serve warfare mission areas and command functions) in the development of new system components.
7.4.3.2 Subsystem Acquisition by Independent Offices
Within individual program management offices and elements of the Department of the Navy military and civilian staffs, there is undue emphasis on accountability for the performance, cost, and schedule of the individual program, and limited oversight of and coordination among related programs. This management approach often leads to stovepiped programs with little regard for interfaces, interoperability requirements, or synchronization of procurement, installation, and training schedules. Often each program manager is encouraged to optimize his solution to his own program’s “requirement” or some other directive.
Within the Department of the Navy acquisition community there is no one below the ASN (RDA) with the responsibility to oversee all aspects of battle force system interoperability and integration for new programs and to coordinate program execution across the SYSCOMs to ensure synchronization in development, production, and installation of systems important to network-centric operations. This makes it particularly difficult to ensure interoperability of components for major naval force missions that may involve five or more program executive officers (PEOs). The committee is concerned about the ability of the
Navy acquisition community, working under the existing structure, to achieve good system engineering results for NCO systems. For example, when the committee looked at the Department of the Navy’s management approach for the power projection mission, it was concerned about the ability to achieve good system trades-offs with five or more PEOs having responsibilities for some portions of the power projection mission.
7.4.3.3 Managing Backward Compatibility versus New Technology Offerings
Legacy component constraints have often forced postponement of both potentially important improvements and new capabilities. A possible solution for the Navy and Marine Corps is to develop new capabilities that have two attributes: (1) interoperability through component partitioning, thus permitting insertion of new technology while enforcing compatibility with older generations, and (2) a preplanned technology refreshment cycle that will make legacy components obsolete in a coordinated and synchronized way.
7.4.3.4 Heterogeneously Equipped Units and Platforms
Typically, system component improvements on ships, submarines, or aircraft can be made only when platforms are not in use. Battle forces comprise diverse units, which are first brought together for an extensive period of workup, then deployed for several months, and then dispersed. The likelihood of having the same networked facilities aboard all platforms in a battle force is low unless such a capability becomes a top-command matter. The most likely acceptable solution, given the naval forces’ operating environment, will be to continue to upgrade individual battle forces as the ships go through overhaul or prepare for a new deployment cycle. More importantly, there is no set of efficient practical procedures, or organization below the Secretary of the Navy, the CNO, and the CMC, with the authority for making postprogram and postbudget adjustments. Such adjustments are sometimes needed to accommodate exigencies occurring during development, production, and fielding of systems that could introduce asynchrony in component subsystems that must be interoperable in the battle force. Some of the constraints placed on the Navy are external (i.e., reprogramming limits), but others could be alleviated by improved Department of the Navy procedures and enhanced cooperation toward meeting top management goals.
Examples follow of how battle force programs can get out of phase. When a budget is approved, it should be internally consistent (e.g., what NAVAIR is doing with the E-2 should be on track with what NAVSEA is doing with Aegis). However, if Congress directs undistributed reductions to acquisition appropriations that each SYSCOM then may take differently, high-priority programs may have cost overruns that cause internal reprogramming; or a crisis such as in
Kosovo may cause the Administration or the Congress to redirect portions of the budget, and each SYSCOM might implement changes differently. Such events, which might appear to be solely financial problems, involve technical issues, and financial personnel do not necessarily have the expertise to recognize technical disconnects. What is needed is real-time budget execution oversight to advise top leadership when programs are getting out of phase, plus a mechanism to manage the consequences. This oversight should help to get the battle force components to work together for deployment. Getting the money to integrate across programs is a part, but not all, of the process.
7.4.4 The Acquisition Process
The committee believes that the DOD requirements process, including the JROC, and the DOD 5000 series of acquisition directives, offer sufficient flexibility to acquire and upgrade NCO system components. Success lies in intelligent and disciplined application by senior officers and civilians who understand how to build and operate information infrastructures. The same leaders also must understand funding so that critical applications and elements of the information infrastructure evolve across sensors, weapons, and platforms. The Department of the Navy and the DOD could benefit from applying good commercial practices based on lessons learned in the rapidly changing commercial information businesses.
7.4.4.1 Commercial Sector Lessons in Acquiring Network-Centric Capabilities13
Commercial enterprises have successfully developed and used network-centric capabilities with applications involving heterogeneous systems and complex interconnectivity. They have learned how to manage several essential development and operating processes. The Navy can tailor its acquisition and system engineering policies and practices accordingly. Several key process-oriented activities should provide a mechanism to separate development of applications and domain-specific capabilities from those processes associated with the development and evolution of the common information infrastructure. Seven such process-oriented activities are discussed below.
-
Design and development methodology. Both spiral development and the contrasting “waterfall,” or sequential, approach involve competent planning,
-
analysis, design, construction, and test phases. Successful projects always involve incremental phased development and some degree of iteration regardless of the name given to the methodology. Successful projects often provide prototype solutions and obtain feedback as a result of extensive user involvement. A good acquisition methodology will incorporate processes that (a) encourage and focus activity on definitive objectives, (b) are complete and verifiable for correctness, (c) produce deliverables that can be measured and easily used in the next phase of the activity, (d) include the operational user throughout, and (e) result in useful increments of capabilities in 18- to 24-month cycles.
-
Program directives and organization. The commercial program directive is the contract requiring all participants to agree to participate materially in the decisions to be made during the life of the program. A good program directive should state in some detail the goals, objectives, measurements to be used, roles of users and acquirers, and other relevant factors including interoperability.
The accuracy of the time and resource estimates will depend on the quality and scope of analysis and preliminary design undertaken as part of the program definition phase. Normally, networked system component developments will support more than one mission or application area. Each of these application areas must have a manager responsible for ensuring that the mission evaluation criteria are met within the time, budget, and quality standards established. Managing the technical components is a major undertaking involving architectures, networks, information standards, and infrastructure operations.
A systems engineer must be responsible for interoperability and interfaces, including those that extend to other systems beyond the scope of the program. Most successful network-centric information system developments have full-time user participation in the program office. Such interaction can ensure that user concerns are being heard and also that the user community is developing the necessary changes in its own practices and procedures in anticipation of a phased delivery of capabilities.
-
Architectures—Operational, Systems, and Technical. Development of information support for network-centric system operations must respect three architectural requirements:
-
Operational architecture: a model that shows the relationships of all the stimuli flowing into the mission area and all the responses flowing back across the boundary into the outside world;
-
Systems and technical architectures: the components that provide automation and communication support for an application. Technical architectures employ the set of standard building blocks, hardware, and software involved in an application; and
-
Legacy component linkages: legacy components’ expected contributions to meeting the required objectives, empowerment of the system engineers of all affected legacy components to resolve compatibility and transition issues, and resources for accomplishing these purposes.
-
-
Information and data modeling. An information model provides the detailed foundation for all data design decisions affecting all applications throughout a networked enterprise. Such a model includes entity-relationship diagrams, transaction and static volume estimates, attribute listings and properties, unambiguous definitions, state-transaction diagrams, and entity matrices. Lessons from the commercial world show that this kind of detail is critical to the success of networked applications.
-
Network design and delivery. Communication technology has evolved so rapidly that the term “networks” represents the convergence of computing and communication theory and practices. The network design and implementation segments of a program can be separated from the applications development segments, once the functional capabilities desired in the applications are known. Application specialists are not typically strong in networking, and communication specialists are not usually conversant with modern networking technology. Therefore, ensuring end-to-end consistency, performance, and fault management will require operational staffing that crosses mission, applications, and information system organizational boundaries.
-
Applications design and implementation. Systems, hardware, and software engineering methodologies need to be tailored to become part of a larger development and test environment. End-to-end testing of each component requires a development infrastructure capable of replicating realistic operational environments.
-
Management of change. Management of change is a relatively new management dimension. A major network-centric-oriented development team can itself be an agent of change, since users must accept and implement changes in the operating environment favored by the system solution. In an ideal setting, highly motivated, skilled users are involved from the beginning in developing the concept of operations and in interacting meaningfully in every phase of system evolution. User participation is the most effective means for enhancing communication, provided that information on status and other essential items is given to all higher levels of management and formal reviews with project sponsors are conducted. Managing expectations must become a key objective, especially for programs that take a long time to complete.
7.4.4.2 Acquiring Battle Force and Tactical Interoperability
Numerous deconfliction problems occurred in managing the air war in Desert Shield/Desert Storm. Furthermore, the Navy has been experiencing compatibility and interoperability problems in fielding new or upgraded combat direction system components for three classes of ships (Aegis, carriers, and non-Aegis combatants). These and other shortcomings have caused the DOD and Navy leadership to implement several organizational and process changes needed across
a number of independent programs and platforms. Three of the most important are as follows:
-
Establishment of JTAMDO (1998), intended to resolve conflicts dealing with concepts of operations, operational architectures, measures of effectiveness and assessments, and other interoperability issues;
-
Chartering of the new Commander, Naval Sea Systems Command, to be responsible for battle management C4I/combat systems interoperability for deploying battle groups among all SYSCOMs and PEOs; and
-
Establishment of the ASN (RDA) Chief Engineer to be responsible for the architecture, integration, and interoperability of current and future C4I/combat/ weapon systems used by the Department of the Navy.
The committee endorses these DOD and Department of the Navy efforts to (1) align requirements, assessments, and the acquisition process with a network-centric philosophy, (2) make battle force and joint interoperability a system requirement, and (3) bring discipline to the system engineering process and provide benefits to meet the need for competent officers and civilians to have rewarding career paths.
However, the committee believes that more must be done to make the major cultural shift from platform-centric to network-centric naval operations. As a specific example, no office similar to JTAMDO exists to resolve conflicting demands associated with concepts of operations, operational architectures, and other interoperability issues for important operational areas such as land attack within the power projection mission. With sensors, aircraft, missiles, and other systems from all four Services working in the same airspace, interoperability across Service lines is essential. To be fully effective, network-centric forces must go beyond any one Service or military department.
7.4.5 Systems Acquisition and Program Execution Process—Summary of Findings
Based on the above discussion, the committee believes the following findings are important to making improvements in the acquisition and program execution processes and to achieving more effective network-centric operations.
Finding: System components that are tightly coupled for network-centric operations must fit into a joint operational architecture that is developed and maintained by operators, analysts, and system engineers over the life of the development and acquisition program.
Finding: While the Department of the Navy has taken some recent steps to enhance the systems engineering process within the SYSCOMs (i.e., NAVSEA)
and within the ASN (RDA) (i.e., the appointment of a Chief Engineer), use of systems engineering methodology is insufficient for integration and interoperability of cross-platform and cross-SYSCOM systems.14
Finding: No single Navy organization below the CNO is in charge of each of the operational, systems, and technical architectures for network-centric operations.
Finding: No one below the ASN (RDA) has the responsibility for overseeing and coordinating all aspects of battle force interoperability and integration for new network-centric operations system components. Furthermore, no one below the ASN (RDA) coordinates program acquisition across the SYSCOMs to ensure synchronism in the development, production, and installation of new components important to network-centric operations for all naval missions.
Finding: There are no procedures, or an organization with authority below the Secretary of the Navy and CNO, for making postprogram and postbudget adjustments. Such adjustments are sometimes needed to accommodate exigencies that occur during development, production, and fielding of systems. As a result asynchrony might occur in the fielding of network-centric operations system components that must be interoperable in the battle force.
Finding: The Department of the Navy has not developed a policy or a set of procedures for deciding what is the most applicable design and development methodology for particular system developments. It has not adopted the spiral development approach for software and hardware applications for systems in which technology is changing at a very rapid rate.
Finding: The Department of the Navy has not yet found an effective and timely means to couple its experimentation process with the development portion of its acquisition process.
Finding: The Department of the Navy has not yet found a mechanism or management team approach for prioritizing the development, procurement, and installation of network-centric elements key to improving interoperability across platforms, or for managing the significant cultural change from platform-centric to network-centric operations.
Finding: No office similar to JTAMDO exists to resolve conflicting demands associated with concepts of operations, operational architectures, and other
14 |
The need for system engineering is discussed in Section 2.3 of Chapter 2. |
interoperability issues for important operational areas, such as land attack. With sensors, aircraft, missiles, and other systems from all four Services working in the same airspace, interoperability across Service lines is essential.
7.5 PERSONNEL MANAGEMENT: ACQUIRING PERSONNEL AND MANAGING CAREERS TO MEET NETWORK-CENTRIC NEEDS
7.5.1 Context and Introduction
“… the people are still the most important part of our military—their quality and their training and their morale ….”
—President Clinton, news conference, July 21, 1999
Meeting the needs for network-centric operations will require people with different kinds of information and knowledge. Commanders will need the intellectual capabilities to apply information technology in complex and sustained operations and to encapsulate higher-level thinking in the context of information technology. Other individuals steeped in the fundamentals and concepts of information technology (e.g., computer scientists and software designers) will be needed to design architectures and networks to meet operational needs and to ensure that information dissemination equipment can be adequately installed and maintained. And future Navy, Marine Corps, and civilian personnel at all levels should have, and will need to maintain, computer skills sufficient to plug and play equipment components (e.g., sufficient skills to operate versus design and maintain essential terminals).
However, the potential gains from modern technology, and getting the knowledge from those who have it to those who need it, are not likely to be achieved with current DOD personnel management practices.
The current status of education and training for personnel in the information technology (IT) workforce (defined in the next section) is representative of specialty training in the U.S. Navy as a whole. This training supports multiple platforms and mission areas. The officers are given graduate education at the Naval Postgraduate School to meet billet subspecialty requirements, and the program is managed by the N6 organization on the CNO’s staff. Officer training in IT-related functions, which are platform specific, is provided and managed by the platform or warfare community sponsor. There is limited and sporadic training/education of the officer corps at large.
Enlisted personnel are trained to meet equipment-specific requirements and in many cases gain their knowledge through on-the-job training while on ships or at shore stations. Their training is managed by the Chief of Naval Education and Training for quality and content but is controlled through the enlisted personnel detailers for training beyond entry-level skills. Community involvement is gen-
erally limited to the warfare specialties, with minimal oversight in the support ratings used throughout the Navy.
Civilian personnel receive the least training of any of the three groups of the IT workforce. A basic assumption in civilian personnel management is that civilians are “best qualified” when they are hired. Therefore it is assumed that they do not need training. This sizable element of the workforce generally receives no or minimal training. There is no career management or training preparation for civilian personnel during their career progression.
7.5.2 Identifying the Information Technology Workforce
Of the 826,000 people in the department of the Navy, 372,000 are active-duty Navy, 92,000 Navy selected reserves, 171,000 active-duty and reserve Marines, and 191,000 civil service personnel. Of the total, about 49,000 (6 percent) are considered to be in the information technology workforce even though almost everyone now uses computers on the job.
This apparent dichotomy results because the IT workforce is still identified by industrial age designators (see Table 7.1 for the IT workforce designators for civilians) and because the use of computers is becoming as common as the use of telephones. The military and the civil service IT job codes are both out-of-date and too rigid to accurately reflect the skills of the workforce. Enlisted IT specialists were called “radiomen” until October 1999. The civil service codes were last updated in 1985, long before the World Wide Web became an integral part of work. As a result, the Navy Department’s “IT workforce” as interpreted today probably has few if any of the individuals described above as being needed for command positions (e.g., information-to-knowledge converters), many operational specialists (e.g., computer scientists), and only a small portion of computer users. Most likely the latter group includes only those individuals specifically assigned to jobs whose primary job requirement is computer skills.
The Office of Personnel Management (OPM) is updating the civil service codes, but it may be years before they are officially implemented. Tag codes do not exist to indicate the skills that have been accumulated by individuals in the workforce (i.e., to understand the existing skills, locations, and needs). In addition, there is no dated IT certification in personnel records to indicate how up-to-date an individual’s certification is.
7.5.3 Understanding the Changing Environment
Information technology is changing more rapidly than any segment of warfighting doctrine or force implementation. It is changing the way we work and the way we live. Many of the new jobs in the expanding economy are in IT.
In 1998, the Defense Manpower Data System estimated there were 2.5 million information technology jobs in the United States, with another 1.3 million IT
TABLE 7.1 Department of the Navy Civilians Considered as Being in the Information Technology Workforce as of June 1999
Code |
Title |
Navy |
Marine Corps |
Total |
334 |
Computer Specialist |
7,553 |
471 |
8,024 |
335 |
Computer Clerk and Assistant |
836 |
124 |
960 |
391 |
Telecommunications |
774 |
50 |
824 |
850 |
Electrical Engineering |
1,140 |
29 |
1,169 |
854 |
Computer Engineering |
431 |
19 |
450 |
855 |
Electronics Engineering |
9,703 |
45 |
9,748 |
856 |
Electronics Technician |
4,208 |
177 |
4,385 |
1515 |
Operations Research |
654 |
19 |
673 |
1520 |
Mathematics |
744 |
0 |
744 |
1550 |
Computer Science |
1,671 |
35 |
1,706 |
|
Other categories |
2,097 |
283 |
2,380 |
|
Total |
29,811 |
1,252 |
31,063 |
SOURCE: Compilation of data courtesy of Defense Manpower Data Center, Office of the Under Secretary of Defense for Personnel and Readiness, Arlington, Va., November 1999. |
jobs to be added in the next 10 years.15 The demand for IT workers is estimated to outstrip the supply by 50 percent. According to a study done in February 1998 by the Information Technology Association of America (ITAA), there is a 346,000-person shortage of IT workers in the United States, including a 20,000 to 25,000 shortage in Northern Virginia alone.16
The DOD believes that since 1992, it has lost 23 percent of its IT workforce through downsizing and attrition. In addition, 50 percent of federal civil service
personnel will be eligible for retirement in 5 years. A further complicating concern is that most DOD workers in IT are supporting outdated legacy systems.
Young IT workers today are not looking for security. Most young workers do not expect to be in a particular job more than 3 to 5 years, and in the IT world it is less. Companies are stealing IT and knowledge manpower from one another by offering training, a better work environment, and higher pay. IT workers are looking for interesting work and high pay. In the DOD, starting pay for a GS-7 is $26,000, while the starting range in the private sector goes from the mid-$30,000s to the high $40,000s. This disparity makes it very difficult to recruit bright and competent IT personnel to the DOD. In 1999, for example, a Web-site manager was ranked the most desired job for the young worker.17 In contrast, military careers ranked 74th for officers and 160th for enlisted personnel. Recruiting and hiring skilled DOD personnel have become daunting challenges, with a Navy recruiting shortfall in 1998 of 7,000 personnel, and a shortfall of 18,000 enlisted for shipboard manning. Although FY99 results were better for the Navy, the problem cries for near-term attention.
Since IT work in the military is changing rapidly, it is not known what skills will be needed for future work. The Department of the Navy (and all of the DOD) needs to evaluate who should do the work and what is the right balance among military members, government civilians, and contractors.
Competent personnel will be required to address the following critical areas:
-
Information and knowledge management (extraction, presentation, application, and sharing);
-
Technical design and sustainment (architectures, network design, and connectivity maintenance); and
-
Applications (functional users).
All of these areas require markedly different kinds of education and training, some of which have not yet been addressed by the Department of the Navy or the DOD. Most important, all future Navy Department personnel will need some level of information technology knowledge.
7.5.4 Links and Interdependencies Among People, Technology, and Information
The Clinger-Cohen Act of 1996 established a Chief Information Officer (CIO) with the responsibility to “… assess and address hiring, training, classification and professional development needs of the Federal Government with respect to Information Resource Management.” More specifically, the National
Defense Authorization Act of 199918 gives the CIO authority to do the following:
-
Review budget requests for all information technology;
-
Recommend IT budgets to the Secretary of Defense;
-
Ensure interoperability and system standards within and between Services, DOD agencies, and national security agencies, and between other government agencies;
-
Eliminate duplicate information within and between Services and DOD agencies; and
-
Coordinate with the Joint Chiefs of Staff. However, no one has the responsibility for the following:
-
Understanding who can and should do the IT work—military active duty, reserve, civil service, and/or contractor;
-
Developing career paths for personnel with significant IT capabilities;
-
Developing the training plans to keep the Department of the Navy up-to-date on IT;
-
Understanding the content of IT work and defining codes to keep classifications up-to-date in a rapidly changing world; and
-
Integrating IT workforce considerations for both military and civil service personnel.
Present job skill codes are inadequate to provide the detail needed to truly understand the current work structure and desired manning skills. However, some progress is being made. In April 1999, the Space and Naval Warfare Systems Command (SPAWAR) initiated an analysis of the “technical” job codes used to identify needed information technology skills in the military.19 The new job codes and specialty titles recently proposed by OPM are designed to reflect the major categories of IT work in the federal government. They will be available for implementation in 2000. OPM has also released a set of IT skills and competencies that will be used in recruiting and selecting job candidates. The competencies allow agencies and organizations much greater flexibility in identifying people who have the necessary skills to perform the job functions.
7.5.5 Training and Education—What Is Being Done?
The IT education and training needs for the Department of the Navy have been fragmented, not only for officers, but for enlisted personnel as well. The needs cross all warfare and community resource sponsor lines and encompasses numerous programs, (e.g., the Global Command and Control System-Maritime (GCCS-M), data management system). Training is further complicated and is a constantly moving target because technology and training demands change for successive generations of equipment.
Both N6 and SPAWAR are making an effort to address the education and training problems of the military. To date civilians are included in this plan only marginally.
The N6 training strategy (developed in 1998) is called Navy Communications, Information Systems and Networks (CISN) training to support C4ISR information operations (IO). However, there is not yet any consistent record with regard to training for implementation of NCO. An oversight board has been set up, jointly chaired by N1, N6, and N7. The N2, N8, the fleet CINCs, and SYSCOMs have representatives on the board. This is an essential first step for achieving the right mix and quality of personnel for NCO, but the benefits are not yet visible.
The board’s job is to validate training requirements, identify and allocate resources, and implement training initiatives. The CISN C4ISR/IO training working group has representatives from all of the above organizations represented on the oversight board and the Chief of Naval Education and Training.
The training objectives are to (1) link all programs and systems, (2) identify training requirements and resources, (3) identify officer communities, enlisted ratings, and civilian positions, and (4) establish system acquisition and training development standards.
N6 wants to take the training to the sailor rather than have training only in the classroom. Training centers of excellence have been established to focus on quality education for the fleet.
In addition, there is a large push for “distance learning,” and some training is being collocated with afloat technical support. But distance learning is a mode of delivery. If the courses are not well designed for the learner and learning, they can be a waste of time. Distance learning courses should be field tested before being provided broadly, and once available to all, a learner feedback system should be built. Feedback from students should address questions such as: How easily understandable was the material? How long did it take to finish? Would you recommend the course to others? Feedback should also be obtained from students’ supervisors to get their assessment of the value of the courses.
7.5.6 Training and Education—What Do People Know Is Available?
Considerable effort appears to be under way to expand the training and education opportunities for Department of the Navy personnel, but finding them is a treasure hunt. Existing IT education and training opportunities are not well distributed and therefore not well understood within the Department of the Navy workforce. The Web sites that exist are not linked, and knowing the Web address is essential to finding the training opportunities. The productivity payoff from the Web comes from easy access to information that is entered only once and then linked for many to find. What is needed in the Department of the Navy is improved easy access to eliminate the scramble for information.
7.5.7 Career Paths
Career paths have been established for the enlisted IT specialist rating. However, there are no established career paths for civil service employees.
The national IT worker shortage could become a serious problem for the Navy. While the technical work to provide the Navy/Marine Corps intranet is projected to be provided by contractors, the application of this type of solution to other IT areas could present a problem with respect to sea/shore rotation assignments for experienced IT enlisted personnel. The Department of the Navy will never be able to compete with the commercial sector solely on a financial basis to attract IT workers, but it should consider special pay for critical skills in the fleet and take advantage of the signing bonus authority for recruiting skilled civilians. In addition, the Navy should take full advantage of term appointment authority for 3- to 5-year term appointments to attract civil service personnel with desired skills. Young people in IT fields may be attracted more by challenges and opportunities to work on critical problems than by longer-term job security. However, some clear delineation of career paths for both military members and civil employees with strong IT capabilities should provide significant promotion opportunities for those who want to stay with the Department of the Navy and, more generally, the DOD. Other productive actions could include training civilians along with military members when comparable skills are required and developing “career banding” for civilian personnel to provide for more interesting career paths.
Workforce planning should begin now to meet requirements for civilian employees and military members with significant IT skills. Timely planning is particularly important with respect to the civilian community, to take advantage of the potentially large number of retirements and the resulting opportunity to realign the IT workforce during the next 5 years.
7.5.8 Personnel Management Process—Summary of Findings
Based on the above discussion, the committee believes that the following findings are important for improving the personnel management process as it applies to achieving more effective network-centric operations.
Finding: All future Department of Navy personnel will need some level of information technology knowledge.
Finding: Civil service codes for IT workers, including those essential to network-centric operations, are out-of-date. The Office of Personnel Management is updating a limited set of IT civil service codes, but it may be years before they are officially implemented.
Finding: Existing IT education and training opportunities are not well distributed and, therefore, are not well understood within the Department of the Navy workforce.
Finding: There is a need to analyze the content of the desired IT work for both the military billet and civilian position structures.
Finding: There is a need to analyze existing job skills to assess the current functions being done and how they are carried out. Present job skill codes are not adequate to provide the detail needed to understand the present work structure and manning skills. The manning, technology, training, and resource requirements analysis done for both the military billets and civil service jobs was last updated in 1985.
7.6 ORGANIZATIONAL RESPONSIBILITIES FOR EFFECTIVE NETWORK-CENTRIC OPERATIONS INTEGRATION
The committee believes that successful network-centric operations will require high degrees of cooperation, trade-offs, and interaction among the stakeholders responsible for the management functions that must be integrated to implement network-centric operations, depicted in Figure 7.2.
Historically the functions have been carried out more or less sequentially, although there have been exceptions when threat or other circumstances were sufficient to cause some acceleration of events. Within the Department of the Navy, the lead responsibilities (oversimplified with emphasis on the Navy versus the Marine Corps) for the major functions are as shown in Table 7.2. However, all functional areas in the Navy/Marine Corps involve continuous relationships among representatives of the fleet commands, type commands, OPNAV and Marine Corps staff, and the SYSCOMs.
![](/openbook/0309069254/xhtml/images/p2000a42ag325001.jpg)
FIGURE 7.2 Functions involved in network-centric operations integration.
TABLE 7.2 Lead Responsibilities for Selected Navy and Marine Corps Functions
Function |
Lead Responsibility |
Concept development, experimentation, and requirements generation |
CNO through NWDC and CMC through MCCDC |
Assessments and resource allocation |
CNO, CMC, and SECNAV with N8 staff lead |
Acquisition including new technology development |
ASN (RDA) and Navy/Marine Corps SYSCOMs |
Personnel, training, logistics, and other infrastructure management |
Navy and Marine Corps sponsors (e.g., N1, N7, N4) and numerous claimants |
Forces management and operations |
Fleet/fleet Marine force commanders and type commanders |
NOTE: Acronyms are defined in Appendix H. |
Within the Navy the concept of “clusters” as used below describes the force management and operations organization and how it functions in these portions of the key decision-making support processes. Figure 7.3 shows the basic, simplified relationships in the uniformed side of the Navy between the CNO, the CNO staff (OPNAV), and the principal Echelon 2 Commands. For completeness, the relationship of the SYSCOMs to the ASN (RDA) in the civilian side of the Department of the Navy is also shown because the SYSCOMs have three “customers” (the CNO, the fleet CINCs, and the Service acquisition executive).
![](/openbook/0309069254/xhtml/images/p2000a42ag326001.jpg)
FIGURE 7.3 Basic structure of the uniformed side of the Navy. Acronyms are defined in Appendix H.
![](/openbook/0309069254/xhtml/images/p2000a42ag326002.jpg)
FIGURE 7.4 Air community cluster. Acronyms are defined in Appendix H.
In practice, because the various communities within the Navy have different requirements, the next echelon down is divided into clusters by platform communities, as shown in Figure 7.4 (for the air community). A similar structure exists for the submarine community, as shown in Figure 7.5.
Similar relationships exist for the surface and amphibious communities. However, these relationships are by no means exclusive—for example, the aircraft carrier desk in N88 deals with NAVSEA, and the Tomahawk desk in N86 (Surface Warfare) deals with NAVAIR. However, the primary relationships, such as in the aircraft and submarine communities, deal with fundamentally different operational, engineering, and programmatic needs. These organizational relationships allow for a continuous focused flow of information between the principal players throughout the requirements generation, allocation of resources, acquisition, in-service engineering, and execution processes. However,
![](/openbook/0309069254/xhtml/images/p2000a42ag327001.jpg)
FIGURE 7.5 Submarine community cluster. Acronyms are defined in Appendix H.
the community cluster does create an artificial division between the various entities that will make up the battle force, and there is no formal mechanism or structure to relate the various functions to battle force requirements, allocation of resources, acquisition, in-service engineering, and execution processes. Simply, what is missing is an integrating function to ensure cross-mission and cross-platform consistency.
This lack of a suitable mechanism to promote network operations and interoperability is even more apparent when considering the C4I organizational relationships depicted in Figure 7.6.
-
Note the differences that exist between those responsible for the information infrastructure and those responsible for platform communities. There is no one like a type commander for C4I reporting to the fleet commanders to represent the fleet operational view. While the fleet commanders’ N6 have significant expertise, they do not have the resources or responsibilities of a type commander.
-
Whereas the operational units (type commands, numbered fleets) are in the fleet commander’s chain of command, the C4I supporting activities (e.g., Naval Computer and Telecommunications Command, Naval Security Group) are Echelon 2 commands under the CNO and other supporting activities (e.g., the Navy Network Design Facility is a field activity under SPAWAR).
-
There is no direct linkage between requirements for individual platforms and the requirements of the battle force as an entity, particularly as it relates to C4I.
This lack of a formal, institutionalized operational focus makes the integration of C4I (and network-centric operations) difficult across the entire spectrum of requirements generation, resource allocation, acquisition, and in-service engineering for the battle force.
Another dimension of the issue can be seen in the relationships between the
![](/openbook/0309069254/xhtml/images/p2000a42ag328001.jpg)
FIGURE 7.6 C4I community cluster. Acronyms are defined in Appendix H.
various offices in OPNAV and their counterparts in the SYSCOMs that are responsible for engineering support and portions of the acquisition function, as depicted in Figure 7.7 (the Secretariat and the Marine Corps are also shown in simplified form).
In Figure 7.7, NAVSEA is shown three times in support of the warfare community sponsors (N85, N86, and N87), but they all are different branches within NAVSEA. Note the Chief Engineer’s (CHENG) office under ASN (RDA). This new position was established to overcome the obvious potential for seams between the various branches within NAVAIR, NAVSEA, and SPAWAR. The three systems commanders also agreed that NAVSEA would act as an integrator between them for interoperability,20 and work closely with the CHENG. Although this arrangement appears to be working, there is no formal organizational structure that will sustain it beyond the tenure of the present incumbents. Furthermore, NAVSEA has no formal authority to enforce interoperability standards over other SYSCOM branches. Today it works because of the quality of the people in the job and the commitment of the three systems commanders to make it work. However, it is not clear that the “bully pulpit” method of management will continue to be effective when other priorities emerge.
As noted in Table 7.2, the lead responsibilities in the Department of the Navy for assessments and resource allocation are the CNO, CMC, and Secretary of the Navy with N8 staff lead, and for acquisition are the ASN (RDA) and Navy/
![](/openbook/0309069254/xhtml/images/p2000a42ag329001.jpg)
FIGURE 7.7 OPNAV offices and SYSCOM counterparts responsible for engineering support and some acquisition functions. Acronyms are defined in Appendix H.
Marine Corps SYSCOMs. The committee believes that these lead responsibilities are appropriate but it does have concerns regarding integration for NCO in both of these functions. When the committee looked at the major missions of the Navy/Marine Corps and the resource allocation and acquisition functions, it noted that there is still a strong platform versus mission orientation in the management organizations under the N8 and the ASN (RDA). For example, the committee observed the following for the power projection mission (one of the four major missions of the Navy/Marine Corps team):
-
The network-centric approach is not being emphasized within the OPNAV resource allocation process (compared to the approach of emphasizing the contributions provided by individual platforms); and
-
Within the PEO structure under the ASN (RDA), the management mission for key components of the force projection mission is distributed among six PEOs.
Although the committee does not have a specific recommended solution for improvement, it is concerned about the degree to which system trade-offs and systems engineering can be accomplished.
7.6.1 Organizational Responsibilities—Summary of Findings
Based on the above discussion, the committee believes that the following findings are relevant to achieving more effective network-centric operations.
Finding: The fleet OPNAV/SYSCOM organizational relationships, which are primarily platform-centric, have served the Navy well for many years and ensure a tightly integrated focus across the requirements generation, resource allocation, acquisition, engineering, and execution processes within each community. However, an integration function for cross-platform and cross-mission needs of the battle force in these processes is missing.
Finding: The lack of a functional type commander resource for C4I that can interact with the other platform type commanders exacerbates the cross-platform integration problem.
Finding: No formal organizational structure crosses platforms and missions within the systems commands (including the Marine Corps Systems Command) to enforce C4I interoperability standards.
Finding: There is uncertainty about the extent to which the CNO staff and the Navy acquisition structure are suited to end-to-end acquisition of NCO-oriented subsystems in the system context, especially with reference to the power projection mission.
During the committee’s extensive discussion of the organization of the Navy structure for coordinating NCO system requirements, some members of the committee expressed the belief that, owing to the legacy of earlier maritime strategies, the Navy has not put sufficient emphasis on the power projection mission in the N8 organization and in the PEO structure. The N8 organization reflects submarine warfare, surface warfare, and air warfare, with power projection a part of each office but not the focus of any. Meanwhile, air dominance is well served by the focus of the office of surface warfare, and strategic deterrence is served by the office of submarine warfare. It appears that power projection lacks a true advocate in N8. The same may be true of sea dominance, although this issue was not examined in as much detail by the committee. In the PEO structure, air dominance is the focus of PEO (Theater Surface Combatant (TSC)). At least five PEOs strongly relevant to power projection are primarily product oriented, the products being platforms and weapons in many cases. Therefore, management of end-to-end system designs and acquisitions as such is considered to be problematic. The same may be true for such system designs in other areas, although both the N8 and the PEO structures have been successfully adapted to the need in areas such as antisubmarine warfare (ASW), cooperative engagement capability (CEC),
and in the growing theater missile defense (TMD) effort. The ASN (RDA) has recently announced the redesignation of the Program Executive Office for DD-21 as PEO (Surface Strike), assigning it responsibility for NAVSEA Program Manager, PMS 429’s Naval Surface Fire Support, including the Advanced Land-Attack Missile program, as well as the DD-21. This represents a major step in the direction of concentrating attention on power projection systems as a whole, in parallel with the concerns the committee expressed in this area. The committee’s recommendations also pertain to making targeting an integral part of the strike system, to strike warfare from the air, and to the relationship between and coordination of naval surface warfare and air strike warfare. The committee commends the entire power projection area to further scrutiny of the kind that led to this most recent PEO reorganization, in both the PEO and the N8 contexts.
Within the context of this study, other members of the committee addressed and argued against making recommendations on these two issues; they favored what they regarded as more pragmatic recommendations to improve implementation of network-centric operations. Among other things they believe that recommendations on the issues above will deflect Navy attention from recommendations made in more important network-centric challenge areas—i.e., the recommendations focused on (1) improving integration within and across all decision support processes and (2) developing improved output measures and mission/system component trade-off analyses and assessments. Given these divergent views and the uncertainty they reflect about the true management situation applicable to overall network-centric operations system planning and acquisition, the committee concluded that recommendations to the Navy Department and the CNO would be in order, to review the N8 and the PEO structures and adjust them if necessary and as appropriate to accommodate end-to-end system designs for NCO subsystems, including especially those relevant to the power projection mission. These recommendations are included with the others that follow.
7.7 RECOMMENDATIONS
7.7.1 Committee’s Approach
In the “Findings” sections and related text, the committee identifies more than 30 problem areas in management functions and processes that are key to achieving fully effective network-centric operations. These shortfalls are summarized in Box 7.2, where they are organized by management function. However, the benefits of network-centric operations will not be achieved if these areas are addressed individually and in isolation from each other. Consequently, the committee did not develop individual recommendations for each finding. An effective dialogue and integration among the different decision support processes are needed for successful implementation of the network-centric operations con-
Box 7.2 Gaps in Management Functions That Have to Be Addressed for Effective Implementation of Network-Centric Operations Requirements generation
Mission analyses
Resource allocation
System engineering
|
Acquisition
Program execution
Operations
Personnel management and training
|
![](/openbook/0309069254/xhtml/images/p2000a42ag334001.jpg)
FIGURE 7.8 Functions and their relationships for effective integration of network-centric operations.
cept. The committee also believes that any set of recommendations to be implemented should be viewed as an integrated whole. To achieve this integration the committee believes that the Department of the Navy should build on its existing organizations with some changes in emphasis, rather than attempt to totally restructure the department or create a new additional stovepipe for all network-centric responsibilities. The difficulty with even attempting to create a new entity to be responsible for all or a major portion of network-centric operations is that such operations span almost all Navy and Marine Corps activities. Therefore, the committee strove to develop a pragmatic approach, taking into consideration the restrictions that exist within the DOD and the Department of the Navy as a result of laws and culture developed over many decades.
The goal is to create a better-integrated set of the basic functions needed for effective NCO and to achieve shorter cycle times for applications involving rapidly changing technology. Compared to the more or less sequential set of functions shown in Figure 7.2, the committee believes it has developed specific recommendations to make the processes work more as depicted in Figure 7.8.
7.7.2 Specific Recommendations
The committee’s integrated set of recommendations, summarized in Figure 7.9, contains a few major organizational changes described below in this section. Because some of the organizational recommendations have applicability to multiple functions and processes, additional clarification is appropriate.
![](/openbook/0309069254/xhtml/images/p2000a42ag335001.jpg)
FIGURE 7.9 Key recommendations for managing network-centric operations. BF, battle force; DEP, distributed engineering plant; DRM, design reference mission; FMF, fleet Marine force; ISR, intelligence, surveillance, and reconnaissance; IWAR, integrated warfare architecture; MOE, measure of effectiveness; MOP, measure of performance; PE, program element; POM, program objective memorandum; TYPE CDR, functional type commander.
In reviewing these recommendations, note that only one new position is recommended: the creation of a functional type commander for Operations Information and Space (shown in Figure 7.9 under the requirements and operations functions). Two new boards (with individuals in existing Navy Department positions as members) are also recommended. The first is proposed to improve the overall implementation of the integrated network-centric operations concept in the Department of the Navy (a “board of directors”); the second is proposed to improve the integration of network-centric requirements (“requirements board”) in the Navy. The committee recommends that one of the Navy SYSCOM commanders be double-hatted as a Navy deputy to the ASN (RDA) to integrate and oversee a number of Navy network-centric acquisition-related activities. The committee further recommends that the Navy/Marine Corps push J8 to set up an organization, similar to JTAMDO, for land attack to deal with cross-Service
integration issues with that aspect of NCO. One last broadly based recommendation is to expand the type and quality of systems analyses and systems trade-off evaluations to be performed in the decision support processes. These evaluations should assist those leaders making the important resource allocation decisions affecting the mission capabilities and outputs of Navy and Marine Corps forces. Although this last type of recommendation does not affect any organizational alignments or responsibilities, its implementation will require some changes in emphasis in the duties of the OPNAV staff.
The following sections describe the first three of the above recommendations (those for the functional type commander and the two boards affecting multiple functions) in some detail and then pull together in one place the full set of recommendations made in this chapter and summarized by title only in Figure 7.9.
7.7.2.1 Three Major Recommendations Crossing Current Functional Lines of Responsibility
Recommendation
1. Create a functional type commander for a new Operations Information and Space Command. Navy combat operations in the information age currently suffer from the fragmentation of responsibility for operations information and information warfare. This lack of focus is the natural outgrowth of stovepipe product lines, the hallmark of successful procurement, fielding, and training of separate mission-specific platforms. The essential idea of information sharing and weblike interactive processes has not yet permeated the development and fielding of C4ISR systems to the level needed to ensure open-architecture connectivity.
There is currently no focal point for information aspects of naval warfare below the level of the VCNO. The deputy chiefs of naval operations (DCNOs) for Intelligence (N2), for Plans, Policy, and Operations (N3/5), for Space and Electronic Warfare (N6), and for Resources, Warfare Requirements, and Assessments (N8) all have important roles in this critical area of naval warfare, but no one has the primary responsibility. In addition, multiple organizations have uncoordinated responsibilities for fleet operations and support and for manpower and budgeting, as well as for operational, system, and technical architectures for information systems.
From the battle group and battle force level there is no single point of contact for integration of operational architectures and networks, or for integration of requirements for intelligence, surveillance, and reconnaissance (ISR) and for the Marine Corps fleet Marine force into the battle group or battle force. Information assurance, vulnerability management, and computer network defense have no coherent visibility at the fleet level. Finally, with the evolving career paths for
officers, enlisted, and civilian personnel, there is no focused community management that will ensure viable career paths for individuals with critical skills.
The time is propitious for making information operations a warfighting mission with a fleet role and with responsibility comparable to that represented by the current type commanders. Such a warfighting mission with the appropriate organization (see Appendix F) not only would give a single point of contact for fleet support and a single provider of network services but also would provide the requisite warfighting focus and emphasis at the fleet level. Creating a new organization, a functional type commander for Information Operations and Space, reporting to all fleet commanders, would provide the integrating mechanism to enable the proper fielding and testing of new network-centric systems, hardware, and TTPs.
In arriving at this recommendation, the committee considered various alternate approaches to carrying out the necessary functions, and the likely problems and benefits that would attend the creation of the new position. One alternative was leaving the organizational situation as it is now, with a lower-ranking officer functioning with each fleet to deal with its information network matters. This arrangement would not provide adequately for the broad and fundamental nature of the change needed to fully implement network-centric operations in the fleets. The committee also considered a recommendation for creating multiple flag positions for each fleet, but this approach did not appear to resolve the problems of achieving consistency of equipment, planning, and operational techniques in the operational forces throughout the Navy. Only a single individual could achieve that.
After considering the pros and cons of various alternatives, the committee concluded that the need to achieve assured consistency and interoperability warrants having the functions be the responsibility of a single individual with a high enough rank such as the functional type commander suggested below.
This new functional type commander would be responsible for the following areas, many of which are covered in a piecemeal manner within the CNO’s staff:
-
Be (i) the single point for information support to the fleets, (ii) the information provider for network-centric operations, (iii) keeper of the fleet portions of NCII, and (iv) the Navy operator for space assets.
-
Through an integrated information warfare operations center, perform real-time network-centric information technology asset allocation, conduct information assurance and vulnerability management, provide trained personnel for fleet support, and manage and deploy red teams for vulnerability management.
-
Be responsible for the network operational architecture (including the integration of that architecture with the systems architecture developed under the cognizance of the ASN (RDA)) and battle force integration.
-
Perform battle force requirements integration for ISR and prepare the
-
fleet’s priority list for network-centric information operations POM submissions and for short-term resource reallocation.
-
Be responsible in the Navy for integration of Marine Corps fleet Marine force requirements with fleet NCO requirements and fleet experimentation support.
-
Be the community personnel manager for all IT personnel in the Navy—officers, civilians, and enlisted personnel—including career field planning, rotation assignments, and training requirements.
-
Serve as the Navy component commander to CINC Space, which has been assigned responsibility for DOD network assurance.
-
Provide operational support to the fleet experimentation program.
This functional type commander should report only to the three fleet commanders and represent them in the POM and budget process for information operations issues. When this role is combined with the committee’s two other recommendations that provide a mechanism to reallocate resources during a given budget cycle, this functional type commander should be able to respond to emerging fleet requirements, to maintain cutting-edge technology, and to support the development and fielding of new systems. This commander’s role in providing operational advice and support to the fleet experimentation program should enhance the quality of experiments and add value to battle group and battle force operations.
The recommended Commander, Operations Information and Space Command, should be supported by the Commander, Naval Security Group Command, the Commander, Navy Space Command, and the Commander, Naval Computer and Telecommunications Command in their entirety and by the fleet operational support function of the Space and Naval Warfare Systems Command. The new commander should assume command of a major portion of the DCNO for Space and Electronic Warfare (N6), except for the policy function. An organizational view of the recommended command is provided in Appendix F.
Recommendation
2. Create a requirements board. The current requirements generation process is not sufficiently responsive to the demands of information technology development. Computer technology and related processes can become outmoded before the POM process can even react to the fielding of the results of the prior requirements generation process. In addition, multiple organizations have uncoordinated responsibilities for operations and fleet support, requirements generation, manpower planning, and budgeting. These disparate, and sometimes overlapping, activities are not effective and clearly do not optimize the Navy’s efforts in future systems development. With the Navy on the threshold of conducting warfare in the information age, bold new initiatives are necessary.
A requirements board should be established to deal with information operations and to integrate the various competing requirements as presented by the fleets for rapid improvement of complex at-sea operations. This board should be responsible for the following areas:
-
Coordinate and rank requirements for the NCO decisions across all naval platforms with a view to the future. The board would control the evolution of connectivity and capacity requirements to mesh with platform networking capabilities. Through the VCNO, it would ensure that the Navy speaks with one voice at the joint level.
-
Encourage the full requirements dialogue among the communities and ensure that requirements trade-offs have been examined and validated by the best possible means, including use of the battle group engineering plan. The requirements board would make sure that the requirements remain flexible within the spiral development process in acquisition and improve the visibility into the repair and modernization programs.
-
Validate the requirements for all NCO systems.
The requirements board members would have four broad functions:
-
Develop policy and implement strategy for conducting information operations;
-
Advise the CNO on the strategy and doctrine, personnel, education, training, technology, and resource requirements for moving the Navy from platform-centric to network-centric warfare;
-
Establish the linkage to the Navy After Next21 from this new level of warfare operations; and
-
Rank emerging NCO requirements based on fleet commanders’ recommendations and the results of fleet experimentation.
The requirements board should be chaired by the VCNO and have the N6 as the executive director (until the recommended Information Operations and Space Command is established). The membership of the board should consist of the deputy fleet commanders, the president of the Naval War College, the DCNO for Plans, Policy and Operations (N3/5), and the DCNO for Resources, Warfare Requirements, and Assessments (N8).
The Board should specifically address four broad areas of information operations: (1) battle force operations, (2) NCO requirements, (3) IT manpower, and (4) NCO budgets. The area of operations should be much broader than current
forums and should focus on the warfighting impact of new and emerging developments. Since the fleets will all be properly represented, progress should be possible in areas such as sensor-to-shooter priorities, long-range land-attack targeting, mobile targeting, and friendly fire. In all of these areas the board should seek solutions for the Navy After Next.
The board’s responsibilities should cut across the current stovepipes, both by platform and by mission. It would be small enough and senior enough to make the necessary trade-off decisions and implement priorities in the requirements area, with concurrent fleet input. This forum for the prioritization of requirements could be a forceful lever to compel attention and achieve progress in the cross-platform areas.
The board should also approve a general education program for all officers, enlisted personnel, and civilians with continuity throughout each career path to ensure familiarity with the basic language, thought processes, and skills required to perform at a high level in their specialty.
The budget is an important area for this group, which should provide recommendations on priorities for funding, particularly across platforms and stovepiped areas. Again, since the fleets and the requirements leadership are adequately represented, this could be a very effective forum to ensure that information operations and its specific programs receive the visibility and priority they require.
Recommendation
3. Create a board of directors. The above two organizational changes are designed to focus the operational development of network-centric naval operations and to integrate the many priorities within the requirements sphere. There is also a need to provide focus for the acquisition and program execution portions of information operations. This review, oversight, and prioritization of the acquisition, installation, integration, and program execution portions of network-centric operations should be conducted by a new board of directors consisting of individuals with the authority to make adjustments in different areas.
The recommended board of directors should have the Under Secretary of the Navy as the chairman, and the VCNO and Assistant Commandant of the Marine Corps (ACMC) as members. Other members should be the three Navy system commanders of NAVSEA, NAVAIR, and SPAWAR, and the Marine Corps Systems Command, along with the ASN (RDA) (who should serve as the executive director). The DCNO for Plans, Policy, and Operations (N3/5) and the DCNO for Resources, Warfare Requirements, and Assessments (N8), as well as the Assistant Chief of Staff (ACOS) for Plans, Policy, and Operations and the ACOS for Programs and Resources of the Marine Corps staffs, should also be members. Requirements sponsors (N2, N4, N6, N85, N86, N87, and N88) should be advisory members to be consulted concerning the operational impact of potential program adjustments.
The 12-member board of directors should replace or augment the informal arrangements that now exist between the systems commanders and could oversee the coordination of the scheduling and funding of all cross-platform systems. The board should also ensure that the technical standards and components for interoperability being developed for new systems will be installed in an integrated manner to provide the necessary battle group and battle force compatibility, including that with units of the fleet Marine force. The board should be responsible for establishing battle group and battle force system response times. It also should recommend priorities among fleet modernization efforts and new system developments from a technical and operational standpoint.
Emergent and in-year funding requirements for deploying critical systems should also be dealt with by this group, through reprogramming, if necessary. This board of directors should function as a Navy Department resource board for information operations and for the supporting systems and R&D programs. In turn, this establishment would provide a network-centric operational focus, at the appropriate level, for the entire acquisition and program execution effort (including installations in battle groups) for both new systems and upgrades to existing systems. The results should include improved judgments regarding priorities and trade-offs among new systems and fixes to legacy systems that are more responsive to integrated fleet needs.
7.7.2.2 Requirements Generation Recommendations
The committee’s recommendations for the requirements generation area are as follows:
-
Provide the resources for and expand the role of the Navy Warfare Development Command in generating concepts of operations and operational architectures, and designing and analyzing the results of operational experiments. NWDC and MCCDC should coordinate Navy and Marine Corps experimentation efforts. Also, involve the NWDC in the IWAR process.
-
Create a requirements board. This board of Navy senior leadership headed by the VCNO should act as the institutional memory and keeper of the integrity of the requirements generation process. (Details are described above.)
-
Create an Information Operations and Space Command, a functional type command, to provide a focal point for NCO activities, consolidate responsibility for information support, and prepare requirements for NCO systems. (Details are described above.)
-
Propose the establishment of a joint office, similar in scope to JTAMDO, for joint fire and land attack. JTAMDO has expertise from all the Services and the major agencies. It is defining the operational architecture and the inter-
-
operability requirements for air and missile defense. Thus, an analogous effort for joint fire could be a step toward jointly identifying the operational architecture and information requirements for land-attack, strike, and time-critical targets. A continuing joint fire testbed would be a step forward from the biannual Roving Sands exercises,22 which have demonstrated continuing difficulty in integrating intelligence and command and control systems to pinpoint time-critical targets.
7.7.2.3 Mission Analyses and Resource Allocation Recommendations
The committee’s recommendations for the mission analysis area are the following:
-
Staff and provide resources for the IWAR process to enable continuous assessments from requirements generation through programming, budgeting, and execution.
-
Make developing of output-oriented MOEs and MOPs for network-centric operations a high priority.
-
Put more emphasis on and provide sufficient resources for developing a comprehensive set of DRMs across all mission areas and keep them current. Up-do-date DRMs are the single biggest improvement that can be made to mission analysis.
-
Make more use of the distributed engineering plan in testing potential life extensions of and improvements to legacy systems.
-
Develop a methodology that everyone agrees to for assessing the risk of failure of a military operation. Recognizing that it will be a subjective assessment, strive to achieve a methodology that consistently arrives at the same answer for a given set of circumstances.
The committee’s recommendations in the resource allocation area are as follows:
-
Create a board of directors to add comprehensive oversight of network-centric operations as a whole to all three major decision support processes (requirements generation, resource allocation, and acquisition and program execution). The oversight should also ensure that network-centric operations are always considered in the joint context. In addition, the CNO/CMC should review
22 |
Roving Sands is a field training exercise that is the world’s largest joint theater air and missile defense activity sponsored by the U.S. Joint Forces Command. Information is available online at <http://www.af.mil/news/May1996/n19960523_960496.html>. |
-
how system trade-offs and resource allocation balances are addressed in the Navy/Marine Corps staffs to assist them in achieving maximum mission effectiveness for all naval force missions. This is particularly important for the power projection mission, which may be the most stressful to the Navy/Marine Corps team in terms of achieving the full benefits of network-centric operations. (Also see details on the recommended board of directors as described above in Section 7.7.2.1.)
-
Strengthen the assessment process along the lines discussed in the mission analysis section (e.g., develop better measures of effectiveness and measures of performance) and expand assessments so that they continue through budgeting and program execution.
-
Put more emphasis on and resources toward phased implementation of spiral acquisition in homogeneous product lines. Include resources for backfit where appropriate.
Therefore, the committee recommends that
-
The organization of the Navy’s N8 office should be reviewed and adjusted as appropriate and necessary to increase emphasis on all aspects of the power projection mission, including strike and countermine warfare, amphibious and airborne assault, and fire support and logistics support of Marine Corps forces from the sea.
7.7.2.4 Acquisition and Systems Engineering Recommendations
The committee’s recommendations in the acquisition and systems area are as follows:
-
Create a board of directors for NCO integration, acquisition, and program execution. (Details are described above.)
-
Establish a three-star deputy for Navy NCO integration to the ASN (RDA). This deputy should be a designated Navy SYSCOM commander and be double-hatted into this role. The deputy should oversee all aspects of battle force system interoperability and integration and coordinate program execution across the SYSCOMs to ensure synchronism in development, production, and installation of systems that implement network centricity. This responsibility specifically includes these same functions for the NCII. The deputy should be the executive agent of the board of directors for NCO integration, acquisition, and program execution for Navy systems. The deputy also should oversee the activities of the Navy Chief Engineer and the NAVSEA battle force interoperability engineering function.
-
Institutionalize system engineering in the acquisition of Navy systems and in the execution of programs. Under the recommended deputy for NCO integration, strengthen the role of the Navy Chief Engineer in institutionalizing system engineering as a methodology for achieving the integration and interoperability of cross-platform and cross-SYSCOM systems. The Navy Chief Engineer should oversee a system engineering cadre drawn from the three Navy SYSCOMs for this purpose. The SYSCOMs should receive the resources and staff to support this activity. In addition, the ASN (RDA) should look at the best means to address system engineering for the entire system and not just the functional parts. (This latter portion of the recommendation applies to all naval missions and particularly to the power projection mission, which affects so many elements of the Navy/Marine Corps team. All elements of the combined joint team must work as an integrated whole to achieve maximum NCO effectiveness. This result cannot be achieved if system trade-offs and system engineering efforts are addressed at the component level.)
-
Assign the Navy Chief Engineer the responsibility and authority to develop and maintain the system and technical architectures (consistent with the Chief Information Officer standards and policies) and the interface, interoperability, and other standards required for compatibility of network-centric systems. This responsibility should include coverage of the same functions for the development of the NCII.
-
Institutionalize a process of spiral acquisition for network-centric systems, focusing on domain-specific applications that serve individual mission domains. Network-centric systems should be funded and planned for continual technology refreshment and functional evolution both during development and throughout the full life cycle. Provision should be made for continuous operator involvement in the development and evolutionary cycle, preferably by assignment of operational user representatives from the operating forces to the program management offices. Budgetary allocations should be included in these programs for technology refreshment and functional evolution. The recommended Commander, Operations Information and Space Command, should assist the fleet in providing user feedback and choosing priorities for system upgrades overseen by the general board. The board of directors (for NCO integration, acquisition, and program execution) should recommend program adjustments necessary for expediting the spiral acquisition process.
-
In keeping with the committee’s findings above regarding mission balance in the management of requirements generation review and system acquisition, the ASN (RDA) should seek the best means to address the design and engineering of NCO systems to eliminate as nearly as possible any distortion of the overall NCO perspective through undue emphasis on any single naval force mission or any one platform. In particular, the Navy Department PEO structure
-
should be reviewed and provision made, as is found appropriate and necessary, for management of the acquisition and the oversight of mission-oriented, networked major subsystems of the overall NCO system. In doing this, special attention should be given to end-to-end (surveillance and targeting through effectiveness assessment), fleet-based, land-attack (strike and fire support) subsystems for Navy, joint, and coalition missions.
-
Institutionalize the fleet experimentation process with increased rigor, and establish a mechanism for injecting its products into acquisition. Designate the Navy Warfare Development Command as the Navy Fleet Experiment Commander and provide resources to NWDC for this role. Charter the Navy Chief Engineer to provide system engineering support for the design of experiments and for the definition of MOPs and success criteria, and provide resources to the SYSCOMs for this role. Charter the recommended Commander, Operations Information and Space Command, to represent the fleet in providing operator insight in the design and evaluation of experiments. The recommended Navy requirements board should rank the requirements of successful products for acquisition. The recommended board of directors for NCO integration, acquisition, and program execution should recommend budgetary adjustments for the transition to network-centric operations.
-
Propose the establishment of a joint office, similar in scope to JTAMDO, for joint fire and land attack. Until such an office is set up, the Navy and Marine Corps should participate more actively in the “Attack Operations” pillar (one of four) in JTAMDO in which a working integrated process team is looking at the targeting of time-critical targets, such as mobile missile launchers.
7.7.2.5 Personnel Management Recommendations
The committee’s recommendations in the personnel and career management area are as follows:
-
Institute network-centric operations education and training for all naval personnel at all levels within the Navy and Marine Corps. All elements of the Navy need to be more appreciative of the principles, benefits, and risks associated with network-centric operations.
-
Develop career paths for both military and civil service employees with significant information technology expertise. Provide opportunities for those personnel with significant NCO critical IT expertise who wish to make a career in the Navy/Marine Corps military or civilian team to achieve very high (if not the highest) positions in the Department of the Navy. Ensure that all Navy/Marine Corps line and field-grade officers have expertise in IT and are capable of effectively using operational information in network-centric operations. Train mili-
-
tary personnel and civilians together when the IT learning requirements are shore based to better integrate the military and civilian parts of the combined team.
-
Analyze the current and projected IT work so that more informed decisions can be made about who should do the work—active duty personnel, reserve military personnel, civil service employees, or contractors. Assess how functions can be expected to be performed in 5 years and 10 years. Evaluate manning, technology, training, and resource alternatives for those periods.
-
Update military and civilian IT job codes to match the desired IT specialty work. Analyze present job skills to assess current functions and how they are carried out (present job skill codes are not adequate to provide the detail needed to understand the existing work structure and manning skills).
-
Distribute IT education and training opportunities well within the Department of the Navy workforce and make them readily accessible.
7.7.3 Recommendations Summary
This chapter sets forth the collective judgment of the committee on the keys to implementing improved network-centric capabilities. The chapter shows how to modify the decision support and personnel management processes to achieve network-centric capabilities as major enablers in the conduct of naval operations. The key management processes (i.e., defining what is needed, allocating resources, acquiring systems, staffing critical billets, and operating a global information infrastructure) are described. In Figure 7.10, the committee’s major recommendations that affect the processes necessary for effective NCO integration are shown below the functions that would be most affected by the specific recommendations. The committee believes that the changes recommended could be implemented by the Navy, without revisions to law or DOD directives, and that their implementation will make a significant improvement in the success of future naval operations.
![](/openbook/0309069254/xhtml/images/p2000a42ag347001.jpg)
FIGURE 7.10 Functions for effective integration of network-centric operations shown in relation to major recommendations made in this report. CHENG, Chief Engineer of the Navy; DRM, design reference mission; IWAR, integrated warfare architecture; MOE, measure of effectiveness; MOP, measure of performance; NAVSEA, Naval Sea Systems Command; NWDC, Navy Warfare Development Command; SYSCOM, Systems Command; TYPE CDR, functional type commander.