A FUTURE STATE OF SBA
|"Future commanders must be able to visualize and create the "best fit" of available forces needed to produce the immediate effects and achieve the desired results."|
Joint Vision 2010
This chapter portrays the implications of an SBA approach for future defense systems acquisition, by projecting SBA capabilities and trends. While it is difficult to predict exactly how change will be implemented or to describe the resultant organizational structure, it is possible to envision what an SBA approach holds for the future. Within this acquisition process of the future, systems will be thoroughly modeled and simulated prior to "bending metal." Beginning with initial user needs, requirement definition, through design, testing, manufacturing, logistics, training, operational usage, and disposal, the synthetic environment and integrated teams will play a major role. Ideally, the acquisition process becomes a continuum without a definable beginning or end, continually assessing projected threats and needs against the ability to meet those needs. One senior acquisition official put it best when he said, "If the models are done correctly, the simulations will tell us when we need to start a new program."1
As the Joint Vision 2010 quotation above states, commanders must be able to project and select the best fit of systems available to accomplish their mission. This applies to not only the existing systems available today, but also to looking ahead at the deficiencies and opportunities in accomplishing future missions. SBA will provide this capability to warfighting commanders by giving them a synthetic view of future battlefields, where conceptual systems can be integrated and their operational effectiveness assessed.
In describing this future process a key assumption is that the systems acquisition process will continue to be centered on programs. The purpose of the acquisition process will be, as it is now, to produce superior systems in response to mission needs. An SBA approach will not change this product focus, but instead will enhance DoD's ability to acquire the "best fit" of new systems to meet the warfighter's needs. Some argue that in order to achieve the full potential of SBA it is necessary to move from a "product-centric" focus of systems acquisition, to a "mission-centric" view.2 The argument is that during the earliest stages of turning a mission need into a material solution, it is necessary to have the broadest possible view in order to optimize the tradeoffs across service boundaries. This broad view could only be achieved by merging similar mission areas across the services, and divesting the services of control of the funds for these mission areas. The managers of these mission areas would have budget and decision authority to determine where best to invest funding to meet user requirements.
But just because the technology will enable the possibility of doing business this way does not necessarily make it desirable or a necessary pre-condition for implementing SBA. In fact it would be a major barrier to implementing SBA, as the services have no intention of giving up their ability to determine the requirements for the material solutions to their mission needs. This cuts to the very foundation of how the services interpret their roles and missions. There is nothing inherent about this new way of doing business that requires the services to give up their right to determine their future, so we reject the argument that implementing SBA requires a "purple," or multi-service, acquisition corps. Instead, our assumption is that acquisition will remain in the province of each service and be program-centric. There are good reasons for maintain-ing separate services, and they are continuing to learn how to interoperate and function as a joint team. So too can the acquisition system.
Another assumption is that a primary objective of SBA is to get the design right before building a system, when in effect the design becomes frozen. Any changes required after the start of production result in costly engineering changes and/or system modifications. If the design is kept mostly in the synthetic environment prior to production, the cost and time required to make the change is significantly reduced. In an SBA process, the defining point is when the program moves out of the synthetic environment and begins production.
The new ability to bring systems together while they are still in design will be key to ensuring that systems will work together when they are fielded, and that they are not over-or under-designed. Competing new systems can be evaluated side-by-side on equal terms to determine the best alternative. Duplication of capability within and across Services will be more readily apparent, resulting in significant cost avoidance. According to Dr. Peter Cherry, Vice President of Vector Research, Inc., "The tools we're using are getting better, but now we need a richer context in which to make decisions, otherwise we'll continue to only make acquisition decisions on the margin. We make marginal decisions now - the challenge is to provide a system of systems context so we can do better than decisions on the margin. Previously we only made incremental changes program by program. Today, systems of systems require the total integration of systems. We need to be able to walk the system's impact on the battlefield all the way from the platoon, to the company, to the battalion level. We have a lack of the full understanding of system supportability issues. We still talk about systems from the cockpit perspective - we need to elevate up to a higher level, and talk to Congress about battlefield effectiveness, not how much faster or how stealthy a system is. For example, we need to be able to show the value of the JSTARS [Joint Surveillance and Target Attack Radar System aircraft] to the artillery, not how many targets it can track and it's mean time between failure."42
System of systems issues are a primary concern of the Service Chiefs and the Joint Requirements Oversight Council (JROC); however, these concerns are now primarily handled at a very high level through the use of a Capstone Requirements Document (CRD). A CRD is used to identify overarching requirements for a system, or several programs that form a system of systems. It contains performance-based requirements to facilitate development of individual program requirements.43
Programs implementing SBA will be able to give the users the necessary insight to balance these needs and deficiencies in time to influence the design, rather than waiting for the Services and JROC to validate ever-increasing point design solutions during Milestone reviews. At this high level it's too late to impact the design cost-effectively, as all of the assumptions and tradeoff decisions have already been made in getting ready for the review. What are being presented are the results of the program optimized against the static requirements dictated in the Operational Requirements Document (ORD), which assumed the user fully understood the impact of those requirements.
With this in mind, we will start by looking at the beginning of a program. This chapter discusses a future state of SBA by looking at four major phases over the life cycle of a program, beginning with:
- generating a mission need;
- iterative design and development activities;
- production; and
- operations and sustainment.