As DoD policy, JCIDS has certainly helped to correctly align the requirements-generation process with the way the military actually fights as a joint force. But JCIDS is more than policy; it is also an analytical process. The inventors of JCIDS, in effect, asserted a theory of requirements development and acquisition that has come to be known generally as capabilities-based analysis.
The problem is that capabilities-based reality has never quite lived up to capabilities-based theory.
An assumption of the capability-based approach is that one should be "agnostic" with respect to specific solutions--the theory being that this frees the analysis from potential bias toward particular commercial or developmental solutions. The idea is to evaluate the military problem from a functional standpoint. First, you have to articulate what success looks like for the military task set in question. Then you have to figure out what capabilities are needed to accomplish the military task. Finally, you compare your existing capabilities against the functional standard to see if there is a match. If the capability is less, you have a "capability gap." If it is greater, you have an "overmatch."
This gap-analysis approach is the beginning of the JCIDS process. Gap analysis only examines the need for a capability. One must then conduct a capabilities-based solution analysis--again, scrupulously attempting to be agnostic with respect to potential solutions, to avoid pre-selecting a specific capability.
But a problem with this approach emerges even before you can say "capabilities-based analysis." The notion of military capability is difficult to translate from theory to practice. Such a term briefs well, but it is very difficult for military commanders to consider, for example, "force employment--ground" as some kind of generic, kinetic capability. What they want are the things they know: tank battalions, combined-arms task forces, long-range-reconnaissance-patrols, etc. (Having said this, let me be clear that I am not critical of the use of the word "capability" as a term to describe a range of related warfighting tools or assets--just the notion that one can analyze capability in the generic sense in any rigorous way.)
Capabilities-based theory tells us that capability should be fungible--that is, one should be able to have some way of providing equivalent capability using either materiel or non-materiel means. The problem is that to date, no one has been able to adequately quantify a capability in terms of "units of capability," such that we can compare the relative effectiveness of, say, an infantry battalion to an aerial bombardment in terms of providing equivalent force-employment capability.
That is why so-called "gap analyses" are nothing more than highly subjective, qualitative statements that sound like, "The joint force commander lacks the capability to do_____." There is nothing rigorous or analytical about this, so why beat around the bush? If the joint force commander wants more "x," just ask for more "x"! Let's not pretend that we have to be "solution agnostic" if there is a known solution that works now or is in development.
If the notion of kinetic (force employment) capabilities is problematic, the situation is even more confusing when discussing the relatively ambiguous notion of command and control (C2) capabilities. For the most part, these capabilities are associated with tools that assist the commander and his staff in the planning and execution of those plans through various communication networks and the maintenance of the continuous awareness of both friendly and enemy situations. The "things" providing these capabilities are usually software applications. Like anything else, the complete "capability" requires a trained operator and a physical infrastructure, but we have come to associate a "capability" with the "system" or computer program that provides it.
Unlike many other military capabilities, such as weapon systems or strategic lift assets, which are platform- and program-centric and follow a predictable operational life cycle, information technology (IT)-based capabilities, such as those in the C2 domain are based on technologies whose state of the art changes exponentially relative to time. Because there is no traditional engineering and manufacturing infrastructure required, IT-based tools can (or should) be rapidly developed, tested, and fielded. Unfortunately, while the joint requirements generation process has attempted to become more flexible and agile through JCIDS, the Defense Acquisition System (DAS) establishment treats the realization of IT capabilities in the same, ponderous, program-centric way it obtains other capabilities. This fact, combined with the failure of so-called "capabilities based" approaches to acquisition, suggests an alternative approach is needed; at least with respect to the C2 functional area.
We offer the following propositions to help summarize the current situation and begin to move toward the next generation of capability development and delivery (with particular reference to C2 capabilities):
* The theory of capability delivery based on the notion of fungibility of capabilities and "solution agnosticism" is unsupported by either academic investigation or practical utility.
The definition of "capability" in the literature suggests that capabilities are combinations of both "ways and means." Ways refers to the non-materiel components of capability such as doctrine, organization, training; means refers to the materiel component.
Attempts to translate the above concept of "capability" into a practical evaluative system to compare alternative capabilities have not been successful.
* So-called "portfolios of capability" are an unrealistic and unworkable fiction and should be abandoned.
Portfolio management, by definition, implies ownership of the portfolio elements. What is in one person's portfolio cannot also be in someone else's portfolio. An experiment in "capability portfolio management," which began in 2006, established "capability portfolios" in an attempt to adopt commercial industry best practices. However, in many cases, programs that are in one portfolio are also claimed by another. For example, Net-Centric Enterprise Services (NCES) is claimed by both the Net-Centric and the C2 portfolios.
Industry uses portfolio management to reduce risk and maximize return on investment. Since the unit of measure (money) is common to such portfolios, assessment of portfolio elements is a straightforward exercise. This is not the case with capability portfolios, in which one is trying to compare two or more capabilities absent any kind of capability metric.
* Attempts to create analytical tools that purport to produce rigorous capability analyses supportive of "portfolio decisions" are an exercise in futility and should be discontinued.
The previous two propositions lay out the case that, unless and until sufficient theoretical work is done to undergird the concept of capability based analysis, it is a waste of money and time to attempt to build capability-based analysis "tools."
Over the past several years, a great deal of time and money was spent developing three prototype tools that were advertised as being key to supporting C2 capability portfolio decisions. In one case, the tool was based on the DoD Architecture Framework (DoDAF), a labor-intensive process of displaying military concepts via operational and system "views." In another, the analytical centerpiece was a "mapping" of C2 systems to system functions; the goal being to create a "Rosetta Stone" to link military functions with tools. Lastly, an attempt was made to develop a complex visualization tool based on something called Joint Mission Threads (JMT). A JMT is a complex, detailed model designed to thoroughly describe a military mission from start to finish, to show how supporting C2 systems would be used to support such a mission.
A problem with all three of these tools is that their developers assumed that simply breaking up the military problem into more granular pieces would allow a clear alignment with functions that can be provided by C2 systems. However, simply discovering that a C2 system performs a function that supports a military task set provides no information about the degree to which that system performs the function--something that is key if one is going to make a portfolio decision (retaining one system and eliminating another).
A better approach would be to take the time and effort to build a value model that captures what is really important to DoD decision makers and stakeholders and apply such a model to the assessment of potential C2 solutions. This technique, referred to as value-focused thinking, or VFT, has been usefully applied in numerous portfolio-based decision problems throughout DoD.
* Perhaps more important than so-called capability analysis is setting the conditions and structures for rapid and agile delivery of needed weapon systems and other capabilities. Some changes could include:
--Reform of IT acquisition. The acquisition of software-based capabilities must be freed from the traditional DoD 5000 series model. Such IT acquisition reform would include new approaches to funding the development and sustainment of software-based capabilities using such resourcing schemes as e-commerce and software as a service.
--Emphasis on net-centricity. DoD policy must strengthen the requirement for common enterprise architectures based on software services and cloud computing and conformance to the Global Information Grid (GIG) 2.0 model.
--Centralization of standards, policies, and governance, and decentralization and diffusion of capability development in conformance with said standards. Rapid and agile development and delivery of IT capabilities is more likely in such an environment than mired in traditional, large "software development houses" or materiel developers.
Years ago, I, too, became excited at the prospect of developing truly analytically rigorous capabilities-based approaches to meeting warfighter needs. The operations research community devoted whole symposia to the discussion of capabilities-based approaches. But the holy grail of a complete theory of capabilities-based analytics was never attained. We may yet achieve a level of capability analysis that yields to a quantitatively rigorous approach that will withstand the scrutiny of gatekeeper organizations like the office of Cost Assessment and Program Evaluation at the Pentagon (OSD [CAPE]). But in the meantime, we should apply our collective intellectual potential toward the more pressing, practical need to create a robust and flexible capability delivery system.
Getting the parameters of this capability development system right is more important than maintaining capabilities-based ideological purity. This means admitting that the complex details of military tasks and functions and the systems that support them might be best viewed as a sort of "black box." The important things to know are the inputs, outputs, and design parameters for the processes inside the box. If we get these parameters right (the "knobs" or "dials" on our black box) then we will have designed a robust capability development system in which the complex relationships of task and function to system will likely self-organize optimally without our interference.
It will take vision and leadership at the highest levels within DoD to move us to this kind of model, but it can be done.
Michael F. Cochrane, Ph.D.
Cochrane is an operations research analyst and has worked for the past 6 years at the U.S. Joint Forces Command.
The author can contacted at firstname.lastname@example.org
|Printer friendly Cite/link Email Feedback|
|Author:||Cochrane, Michael F.|
|Publication:||Defense AT & L|
|Date:||Jul 1, 2011|
|Previous Article:||Making sense of the changing global supply landscape: new rules and reformulations.|
|Next Article:||Shaping the way ahead: Army biometrics WIPT kickoff.|