OPED: Navy Shifts SeaPower Strategy

Navy Expert: "We are going to need concept development that looks at the adversary and discerns new ways of neutralizing it, rather than concepts that look at our platforms and discerns new ways of employing them."

Bryan McGrath is a former Navy Captain who Commanded an AEGIS Destroyer. 

--He is a retired destroyer captain, a defense consultant, and is the Assistant Director of Hudson Institute's Center for American Seapower---

Much of this essay comes from McGrath's Feb. 15 Presentation to the American Society of Naval Engineers:

***********

Chief of Naval Operations Adm. John Richardson has a new idea about how he wants to build the budget and is pushing the Navy to get onboard. He is rightfully concerned about the competition with rising naval powers. He is rightfully concerned that the pace of the competition is quickening.  His approach isn’t  getting a whole lot of press, and to many it sounds like a whole lot of inside baseball, but to my mind, it is incredibly important stuff.

Richardson is reshuffling the deck—and his dealer is the VCNO (Vice Chief of Naval Operations), who is enforcing discipline in the new process. Instead of the resource sponsors being responsible for putting together that portion of the POM (Navy Program Objective Memorandum Budget Process)  that corresponds to their “Platforms”—CNO has decreed that POM’s will be built around how the Navy will fight AS A SYSTEM within the various warfighting domains.

For instance—the Director of Surface Warfare Programs—RADM Ron Boxall—is no longer just responsible to the CNO for putting together a program that deals with US Navy cruisers, destroyers and frigates. Boxall is now charged with leading a domain-based view of how all platforms—submarines, ships, aircraft, space and electronic warfare systems-- that deal with how we confront ADVERSARY ships.

That is, he oversees an entire architecture, the Surface Domain, and he must bring to his boss (N9, Deputy CNO for Warfare Systems) a coherent, architecturally-based view of how ALL the capabilities fielded by ALL the resource sponsors relate in this domain. The undersea, air, and Cyber/Space/EW domains are similarly honchoed by a two-star integrator.

The theory here is that at some point in the process, this domain-driven approach will then allocate functionality within the domain back to the traditional platform sponsors in a way that is derived from a coherent warfighting architecture, and so their program proposals will spring NOT from whatever community interest they’d like to scratch, but from an efficient and effective view of what is required for dominance within that domain.

Why is this important? It is important because as we all know, goodness follows money. And if we begin to think about allocating resources from a domain architecture perspective rather than from a platform perspective, the REQUIREMENTS generation process will ultimately have to ALSO be altered to reflect an architectural—rather than a platform—view.

If we are going to begin to budget from a domain architecture perspective, we are going to need to begin THINKING about warfighting from that perspective. We are going to need concept development that looks at the adversary and discerns new ways of neutralizing it, rather than concepts that look at our platforms and discerns new ways of employing them.

And if we begin to develop domain-centered concepts, those concepts are going to have to be backed up by coherent, multi-platform systems architectures, architectures that allocate functionality to achieve warfighting desires. After all—what OPNAV (Naval Operations) is doing right now is necessary, but it is NOT sufficient—because even though they are building a budget using a domain approach, they HAVE NOTHING TO CHECK IT AGAINST—that is, these domain systems architectures simply…don’t….exist.

And they don’t exist for one very important reason. Up to now, there hasn’t been a general need for them. To be brutally honest, the Navy simply doesn’t have an organization charged with or staffed for doing this kind of work.

For the full value and goodness of the CNO’s ABSOLUTELY spot-on approach to work, the Navy will have to up its domain-oriented systems engineering game, and I have a feeling that people in this room will be critical to that effort.

So now—let’s leap ahead to twenty years from now and dream out loud for a bit. Let’s assume that the Navy—way back in 2017—stood up a systems engineering organization that held the whip-hand when it came to architectural compliance in acquisition matters, and for twenty years, Navy acquisition has steadily moved away from the stove pipes of platform capability into the light of domain driven capability allocation.

We’ll still have ships then, right?

We’ll still need to build ships then, right?

So then, what would such an approach VALUE from surface ships? More importantly, if we are going to move in this direction, what should our shipbuilding, naval engineering, and naval architect communities be thinking about TODAY?

Well then. This gets to the heart of the matter.

It seems to me that in such a domain architecturally-driven view of the world, surface ships will be most valued for flexibility, reconfigurability, interoperability, and capacity. And I think if we’re honest with each other, we’d conclude that this is NOT what we prize in the way we currently build ships.

Don’t get me wrong. We build great ships. The AEGIS Destroyer I commanded was the envy of the world. But it was conceived of and built as a “point solution” to a set of requirements that produced a variety of warfighting capabilities. Insufficient thought was given to how it might evolve, and how that evolution could be enabled.

My friend and mentor retired RADM Nevin Carr has a pithy way of describing what the surface force should move toward. He talks about “big trucks”, “medium trucks”, and “small trucks”. I’ll build on this simplicity here for a bit, and what I say will be no surprise to most of you who have already been thinking along these lines—but perhaps not from the architecturally-driven perspective that I suggest.

Surface ships of the future must be built in order to be able to pace the threat. When a new ARLEIGH BURKE destroyer is commissioned, it immediately begins to decline relative to the threat, which is always upgrading. Ten years or so down the road, at great expense and at a cost of significant operational availability, at least ten year’s worth of technology and capability upgrades are stuffed into the ship. It then rejoins the fleet—again at a high state of readiness—and begins the cycle of decline relative to the threat once again. Perhaps one more time in its remaining service life, it will get another massive modernization period in which it is taken out of service for a year and $150M is poured into it.

What if we could build a ship—build all of our ships—in a way in which regular maintenance periods could be used to accomplish major capability upgrades? These more frequent and less intrusive upgrades would accomplish two things. They would ensure that the ship remains in front of the threats it is imagined against, and because the capability upgrades will have arisen from a domain architecture – and a disciplined systems engineering process – the prospects for interoperability with the rest of the architecture are improved.

I’m talking mainly about functionality driven by open architecture schemes---in which the Navy controls the interface and industry creates the applications to meet architecturally driven requirements. Because a coherent systems engineering organization will have been involved from the beginning, where an application for a particular function has already been created—it, or portions of it—can be integrated into the computing platform of the ship. This commonality, this reuse, also contributes to architectural interoperability.

But why stop with software? We took a stab at modularity in the LCS (Littoral Combat Ship) class, and while it was a well-intentioned stab, it appears that we may have gotten it wrong. Mission area modularity—to me—makes much less sense than component level modularity. I’ve come to refer to this as “the commoditization of capability”, and how we get there is somewhat like how we get to software architectures. The government—i.e. the Navy—defines the real estate and the support functions—in other words, it defines the physical interfaces. Space, weight, power, and cooling are provided, and industry is asked, “what can you do with this space”? This is why RADM Carr talks about “trucks”. The ship is a truck that carries around commodities, and those commodities are capabilities—capabilities that can be switched out pierside while the enabling software is upgraded over encrypted networks.

You know better than I that this approach is not the way we do things now, and you also know better than I that the government almost certainly wouldn’t get it right if it tried to impose such a system on industry.

So why not work together?

Why not bring together the various stakeholders in this process and begin the work of creating the future?

Why not get the fleet, the requirements community, the acquisition community, and industry together and hash this stuff out?

Why not say to industry—“here is where we want to go—can you help us get there?”

I believe we can. I know it is worth doing. And I am certain that it will take inspired leadership across a number of years to accomplish.

It will certainly not be easy.

But if it were easy—the Navy wouldn’t be doing it.

Visit Warrior


Warrior Top Stories