According to the web site Simplicable.com,

“'Think global, act local', is a common principle that is applied to organizations, business, education and governance. It asks that employees, students and citizens consider the global impact of their actions.”

As a group, virtually all who are reading this blog (thank you) are all of the above - employees, students and citizens. It’s logical to assume the words global and local are relative terms – especially within an engineering context.

A friend of mine holds a PhD in Astrophysics from Caltech. Like a lot of super smart guys, he now excels in an area that couldn’t be farther afield from his education – although, Astrophysics speaks to a very large “field”. As the CTO of his current company, he has architected a very nice, one-touch disaster recovery system for data you just don’t want to lose. Marc likes to refer to the hardware behind the magic as, “the necessary evil”… In effect, he’s echoing the sentiments of Harvard Economist, Theodore Levitt, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole”.

The Necessary Evil

Hardware required to execute combat systems applications doesn’t necessarily add value to the platform. While it’s a critical piece of any platform, it’s deployed with a fixed set of components (sometimes in redundant configurations) yielding limited capacity and capabilities.  These systems require on-going maintenance, administration, and technology refresh when limits are in reach – as a result of obsolescence, end-of-life, or inherent ineffectiveness. This is what we mean by being “necessary”, but “evil”… platform IT equipment has traditionally driven up costs, while ultimately limiting combat effectiveness and even availability of the platform, itself.

With regard to a single closed system, a universally accessible resource might be considered global I/O (Input/Output) and that owned by a single server, local I/O. As purveyors of components for mission critical military and aerospace systems, Mercury Systems operates with a core underlying principle that we are an important and integral part of our customers’ global context, be it a RADAR, a naval surface combatant, an ISR aircraft, or a land mobile platform. However, our goal is not to simply execute our “local” piece of the overall system, but to deliver in ways that enhance the whole.

What does any of this have to do with a naval surface combatant?

A surface combatant, e.g., Aegis Guided Missile Destroyer, might be described succinctly as providing Integrated Air and Missile Defense (IAMD) for a battle group, or even a piece of our global habitat. Nowhere in that short description does it mention a floating data center. On the other hand, it’s obvious to even the most casual observer that an exemplary IAMD platform features superior sensors, a comprehensive command & decision framework, and highly effective kinetic and/or electro-magnetic response systems.

In no case do Navy commanders pine for fewer, less capable missiles, smaller and less capable sensors, and fewer lines of code in their command & decision systems. Rather, if the current mission could be performed on (25) $1,500 laptop computers, they’d surely find use for the space, weight, power and cooling dividends. It cannot be overlooked that our Navy’s near-peer competitors have access to the same IT gear, but (hopefully) NOT the same sensor & weapons designs.

U.S.S. Shoup on patrol. The Aegis destroyer DDG 86 is a key component of the U.S. Navy’s strategy of distributed lethality. Fleet air-defense relevance directly derives from contemporaneous maintenance of technological and training competence

In a report out of NAVSEA SEAO5TD, Dr. Norbert Doerry identified the ship’s combat systems’ “effect on actual ship service life” as a “strong driver” and that the Navy “can’t cost-effectively update”. From the outside looking in, that seems just as evil as if a ship’s company were sent home early, and the ship turned into an artificial reef… Oh, wait…

The Deficit of Modular Adaptable Technology

In October, 2012, Dr. Doerry went on to make the following statements:

• Modular adaptable ship technologies enable ships to affordably remain operationally relevant over their service life
• Modular adaptable ship technologies are not yet an institutional part of our design and modernization processes

Fast-forward to 2018. We’re still talking about “modular adaptable ship technologies” and getting our arms around the Federal deficit…

So, what about the necessary evil, and how can its contribution to early ship retirement be mitigated? Wait, did I just refer to our flagship products as “evil”? Hang with me on this… this is where the “think global, while acting local” comes into play.

When it comes to deploying naval combat systems and playing billiards, thinking ahead to the next shot is imperative if one isn’t to be eliminated prematurely. Technology deployment, without regard to the inevitable follow-on technology-refresh, or technology-insertion phase is a recipe for buying more future shipboard industrial work and thus, less fleet-wide IAMD capability.

Both Naval and commercial hyper-scale system engineers grapple with many of the same issues. Simply stated: how to efficiently deploy and manage requisite IT capacity now and in the future. In the past, purpose-built, big iron Mil-Spec machines (e.g., AN/UYQ-43) did the job. A sea-change in the early 90’s led to a COTS revolution and its hoped-for “dividends”. Phase (1) saw the wide-spread adoption of quasi-commercial hardware in the form of VMEbus single board computers and related IO devices. Phase (2) is playing out with bladed and/or modular servers and 1-, 2-, and 3-U rack servers.

It doesn’t take a logistics whiz to look across the physical computing landscape of an Aegis Destroyer and see a “global problem” of unconstrained growth in IT hardware & software combinations with their corresponding permutations. As a result, phase three will increasingly embrace the adoption of commercial data center strategies, including: virtualization, convergence & hyper-convergence, and ultimately the notion of “open composable everything”.

Next Generation Efficiency and Scalability

Today, hyper-scalers (i.e., Google, Netflix, Amazon, Facebook, et al) are leading the way in rapidly deploying, provisioning, and realizing a continuous growing revenue stream – a revenue stream that shows few signs of slowing down. Not only is Facebook, for example, achieving historic levels of global customer interaction, but they are also doing so by adhering to globally-responsible environmental stewardship principles for renewable energy usage.

While much of what Facebook does (and, I don’t advocate for their service) is done to increase profitability, it undeniably provides an invaluable service for some, and they are leading the way in next generation efficiencies and scale.  In our estimation, the Department of Defense and defense contractors can and should adopt a more global approach to shipboard systems as they are specified and delivered.

“Decomposition into smaller pieces is a fundamental approach to mastering complexity. The trick is to decompose a system in such a way that the globally important decisions can be made at the abstract level, and the pieces can be implemented separately with confidence that they will collectively achieve the intended result.”  - Jim Hornung

In my experience, a key difference between commercial hyper-scaler or cloud operators and DoD weapons systems is: the former is fluid and dynamically scalable, and the latter a capacity and capability fixed to a calculated worst-case load. A commercial data center is resilient, while weapons systems are redundant. While virtualization of servers, storage and networks is all the rage, it’s tough to imagine a system, certified for weapons release, operating at the will of a commercial load-balancing hypervisor. Currently, data center architectures are in transition from converged to hyper-converged infrastructures. DoD systems are transitioning from discrete servers and appliances to converged racks.

The time is right to begin planning for a more global approach to shipboard systems. Rather than a plethora of system permutations, we propose a small set of open composable modules that can be combined into an almost unlimited number of mission critical systems.  In essence (n) modules for (n!) systems.

For more on this topic, download the whitepaper “Managing life cycle network interoperability challenges on Navy platforms”.