As a navalist, think-tanker, and defense consultant, I get to spend a lot of time among very intelligent people thinking about the future of naval operations. Over the course of my work this past summer, I’ve come to focus on what I believe to be a serious problem for a Navy faced with increasingly difficult great-power contenders.
The problem is that the way the Navy fights is inefficiently and ineffectively supported by the way the Navy thinks about fighting, and the way the Navy thinks about fighting is inadequately supported by how it acquires the platforms, sensors, weapons and networks that enable it.
Put another way, the Navy employs increasingly interdependent networks of platforms and capabilities across a broad expanse of geography and physical domains (undersea, surface, air, space, cyber, electronic warfare). The nodes of this system, linked together, create a warfighting system that harnesses the power and effectiveness of the interdependent nodes.
However, the Navy is not effectively organized to:
* Think conceptually across the warfighting physical domains;
* Devise coherent, cross-domain architectures that describe such concepts at the systems level, and;
* Acquire the systems, platforms, and capabilities required to populate such architectures.
Instead, the Navy fights as a kluged system derived and acquired through platform specific acquisition and requirements generation organizations.
To his credit, the Navy’s Fleet Forces commander, Adm. Phil Davidson understands this grand problem about as well as anyone. His recent presentation at the Center for Strategic and International Studies is required viewing for anyone who wants to understand what this piece is about. Davidson quite rightly focuses on the “power of the fleet” in his talk, and the fleet is the “system” under review here. I will dive more deeply into the organizational and bureaucratic issues that will bedevil Davidson as he tries to move forward with his fleet-centric approach.1
Thinking Across War-fighting Domains
Of the three issues I raise, thinking across the war-fighting domains is probably the least among them.
As Davidson stresses, the operational level of war for the Navy is the province of the fleet. The fleet operates across multiple warfighting domains—undersea, surface, air (and space), cyber and electronic warfare. Within each of these domains are organizations charged with conceptual development within that domain.
Often attached to an Echelon 3 “Type Commander,” those organizations tend toward the “Center of Excellence” model, in which an assigned organization gathers subject matter experts to consider doctrine, tactics, and concepts and then issues guidance to the organizations participating in that domain. Additionally, these organizations feed back into their associated domain-oriented OPNAV resource sponsors those capabilities necessary to enable the concepts they champion.
To the extent that there is cross-domain conceptual thinking within the Navy, it largely occurs within the Navy Warfare Development Command, an organization that works for Davidson. It is located in Norfolk, Va., and the domain-level centers of excellence are spread throughout the country (to include multiple sites within each domain). In an age of giant data pipes and instantaneous communication, it is tempting to think that distributed concept development is not only possible, but the preferred approach. After years of being in rooms week-in and week-out with subject matter experts from across the warfighting domains, my conclusion is that there is no substitute for physical proximity when it comes to thinking about warfighting in a cross-domain sense. Physical proximity is however, only one of the problems in fostering integrated, cross-domain concept development.
The second problem—partially aided and abetted by physical distance—is the continuing influence of the various “tribes” within the Navy: aviation, submarines, surface warfare are the most well-known among them, but the rise of the “cyber” tribe, the “networks” tribe, and the “electronic warfare” tribe must be acknowledged. Those groups do in fact cooperate and collaborate in conceptual development to some extent, and the fact that our Navy remains the world’s most powerful is a testament to their accomplishment. But true cross-domain, integrated warfighting conceptual development tends to be more or an organic, bottom-up process—wherein one of the tribes seizes on an idea and then begins to evangelize to the others—than a top-down, collaborative effort that considers the various contributions of the tribes in support of an overarching architecture designed to achieve fleet operational imperatives. Which brings us to our second problem.
Cross-Domain Architectural Development
Let’s do a thought experiment. Let’s assume that the problem of conceptual development across the warfighting domains was not a problem, or that it has been solved largely by the enlightened suggestions made at the end of this piece. Were such a world to exist, incredibly well-thought out concepts would be put on the table that maximize the efficiency and effectiveness of the various warfighting communities and enablers against the most pressing operational imperatives. What then? What would the Navy do with such a product? As currently configured, the Navy would break the concept up into constituent parts and the various tribes would head off and create platform-specific operational and systems architectures designed to derive requirements and capabilities to a degree sufficient to hand over to the acquisition community, whose job it would then be to design, buy, and build the constituent parts.
Stated differently, if a perfect operating concept were devised by a perfect organization staffed and empowered to do so, it would be handed over to platform dominated requirements and systems engineering organizations that would proceed with independent efforts that would promote inefficiency.
Well thought-out, cross-domain operating concepts must be supported by coherent cross-domain operational and systems architectures created by organizations staffed and empowered to look across tribal boundaries in order to most effectively allocate functionality and capability.
Such an organization does not exist in the Department of the Navy. Instead, a gaggle of systems commands (NAVSEA, NAVAIR, etc.), program executive officers (PEO’s), warfighting labs, and requirements organizations attack their piece of the puzzle for future kluging back into an integrated whole.
But let’s assume that this wasn’t the case. Let’s assume that an efficient and effective mechanism for both operational concept and system architecture development existed across the various war-fighting domains. How would the Navy acquire such a system or components of this system?
Cross-Domain Acquisition
Disciplined operations concept and systems architectural development processes must be accompanied by an equally disciplined acquisition process. If perfection were handed to the current tribal resource sponsor and acquisition organizations, it would necessarily compete with a wide range of other priorities, to include tribal favorites and priorities. Considerable damage could be done to progress in acquiring the capability (or better, the system of systems) if the resource sponsors were not fully invested in its realization and viewed it as simply another bogey drill to accommodate or pot of money to raid.
The current requirements and acquisition system is optimized to provide systems and platforms that contribute to “fighting as a system”, but not inclined to define requirements and acquire capability that is “derived from the system.” Because the fleet is a grand system of systems, the Navy must organize and align itself to think, architect, and buy capability differently. The fleet and its future must drive where the tribes go. This levies great responsibility on the fleet(s), and argues for a level of centralized authority that currently does not exist.
Recommendations
The following two recommendations are unlikely to be well-received on Capitol Hill, where the reduction of headquarters staffs is in vogue as a sign of congressional activity. Both of these recommendations require an increase in the size of the bureaucracy, some of which could be obtained by centralization. However, getting the Navy ready for great power completion is unlikely to be achieved by re-allocating and centralizing its already too-small-to-be-effective support bureaucracy.
+Fleet Forces Command Authority:+ The Fleet Forces Command must be staffed and resourced sufficiently to perform two main functions—force provider and concept developer. These are independent functions but both would derive their authority from that of the commander. For the purposes of this article, the scope, role and authority of the Navy Warfare Development Command would dramatically increase, to the point where it exercised direct command authority over the tribal Centers of Excellence and any other concept development effort that the tribes undertake that spans two or more war-fighting domains. It would be staffed with tribal experts whose mission would be cross-domain conceptual thinking, and who would be responsible for not only fostering such thinking, but also for monitoring the portfolios of the tribal centers of excellence for their compliance with cross-domain concepts. This commander would report to the CNO to ensure that the concepts created are aligned with national and maritime strategy.
+Navy Systems Engineering Command:+ The Navy should create a four-star position not unlike that of the Chief of Naval Reactors, in which the incumbent would serve an extended term (eight years). This organization would be responsible for the creation and maintenance of systems, and system-of-systems architectures applicable to the requirements of cross-domain concepts. This commander would report to the CNO to ensure prioritization of efforts to achieve national and maritime strategy imperatives, and would also report to the assistant secretary of the Navy (Research, Development, and Acquisition) as the service acquisition executive. Navy acquisition organizations would be required to comply with the requirements generated by coherent cross-domain architectures, and the Navy Systems Engineering Commander would have the authority to direct such compliance.
It is recognized that “system of systems” concepts, architectures, and acquisition is a difficult undertaking. One must only look back a few years to the Army’s ill-fated “Future Combat Systems” initiative to gain understanding of how complex an undertaking this is. And now that I have poked the camel’s nose into the tent, some would suggest that joint warfighting would benefit from such an approach to deriving and allocating functionality—and they would not be completely wrong.
That said, degree of difficulty and fear of joint creep should not keep the Navy from making organizational changes designed to align its concept development and acquisition systems more closely with the way it fights. Capable adversaries are stirring. It is time to think differently.