The Secret To DOD's Next- Gen Tactical Networks: Open Architecture And Standards

By Sherin S. Kamal

Absent an open architecture and standards applied to multivendor systems, the military is forced to resort to gateways, translators, and adapters to create something resembling interoperability.

Often, articles that discuss open systems architectures (OSAs) and open standards interfaces (OSIs) come across as dry, preachy, and boring. Many of us can’t relate to how OSA and OSI can actually improve our business, not just our technical design. The rules and protocols involved with these subjects cause design engineers to conclude that they only present additional burdens to projects already under schedule and budget pressures.

Additionally, their reputation is not helped by being misunderstood or misapplied. OSA and OSI should not be blindly applied everywhere. As with other technical concepts, we must understand them well enough to know where they help most. This is especially true for DoD acquisition programs of record (PoRs) that deal with modernizing the services’ tactical networks.

This article examines the practical aspects of both architectures and standards, which actually assist PoRs to be successful and mitigate a program’s risk. Further, the article will prove a fact that seems counterintuitive: Innovation and agility are more impactful in open standard designs.

Why is this more important than ever before? Three reasons:

• Because the military has articulated advanced and complex mission capabilities necessary to maintain the force dominance critical to the U.S.’ National Defense Strategy.¹
• Because the DoD is in the midst of reforming its acquisition policies and processes and hasn’t quite decided how to get there from here.^2-4
• Because time is not on our side. External geopolitical forces make it imperative that the military modernize quickly.

In short, the defense community (government and industry) needs to adopt advanced complex technologies to deliver new equally complex operational capabilities ... yesterday.

This article speaks to the engineer, designer, and solutions architect in practical terms, but it also speaks to the program manager, contract officer, and business developer. How can their work mitigate the above challenges? Where in their design and development work do OSA and OSI fit, helping their products and business case? DoD cannot achieve the mission capabilities it says it needs, or do so in the timeframe it needs, unless these standards are wielded across its modernization initiatives.

Why Standards?

The value of open architectural standards, like SCA and others, should not be assessed in a vacuum. A standard should be adopted and enforced only if it supports the endgame, not some abstract academic objective.

So what is the endgame? Daily, it seems, military and DoD leaders speak at conferences and industry forums where they present futuristic OV-1 graphics and describe complex, nearscience- fiction devices and smart weapon systems. They’ve backed up that talk by articulating specific capabilities they need from their tactical networks to realize this vision:

• Simple and intuitive: single-mission command suite installed, operated, and maintained by soldiers — not contractor field specialists
• Available, reliable, and resilient, with the ability to operate in all operational environments against any scale of enemy
• Expeditionary and mobile, providing voice, data, and video to units on the move
• A standards-based, protected, and dynamic network environment that is upgradeable over time
• Enabling the warfighter to observe, orient, decide, and act (OODA) faster than the enemy in the conduct of joint, allied, and cross-domain operations.
• Usable as a weapon system itself
• Enabling of leaders to lead and fight their formations from anywhere they choose

Here, technologies will enable unmanned devices to augment soldiers’ capabilities. Machines will talk to soldiers and to other machines (M2M) — absent soldiers’ input. Cyber threats will demand reaction times in microseconds — again, absent soldiers’ input. Electronic Protection will involve not just surviving EW attacks but also anticipating and thwarting them, sometimes weeks or months in advance and thousands of miles away from the “combat zone” or AOR.

Here, technologies like cognition, AI, data anlytics, and a myriad of other complex technologies interplay with unprecedented precision. This is not your daddy’s battlefield!

Even to begin realizing such a contested, congested, complex tactical environment, system/solution architects try to break down these requirements. Here, too, the military has been very clear about its needs: resiliency, survivability, scalability, modularity, interoperability, security, and sustainability.

If every person involved in the military Defense Acquisition System (DAS — “The management process by which the Department of Defense provides effective, affordable, and timely systems to the user”) and its Defense Business Systems (DBS — “the information technology systems that run the Department of Defense’s business functions such as finance, logistics, contracting and human resources”) understood why these capabilities are needed, this article wouldn’t be necessary. But, consider all of the possible interpretations of military and Pentagon leaders’ endless stream of pronouncements regarding the urgencies for these operational requirements: geopolitical imperative, near-peer adversaries, risk of overmatch, cyber onslaught, critical infrastructure, never-fightalone- again, etc.

To summarize: the military’s next-gen tactical networks need complex capabilities fielded immediately. It must adopt complicated (often not-yet-matured) technologies, involving numerous devices manufactured by various vendors, made available to our allied forces, as well. These capabilities need to scale across differing fighting formations and platforms. Finally, these systems must not only survive adversarial efforts to degrade them or turn them against us but also inflict tremendous damage on the adversary’s own tactical C5ISR systems.

Modular Software, Architecture, And Interfaces

It is safe to assume that software will dominate how these complex-yet-agile, modular-yet-scalable network capabilities are delivered; today’s battlefield is nothing like what is yet to come but already involves tens of millions of lines of software code. We also know that the likelihood of software having bugs is proportional to its size/complexity and inversely proportional to how well it is tested. How bugs will affect the tactical capability’s performance, reliability, and resilience often is unknown before a system is fielded.

Given the complexity and rigor needed to deliver these capabilities, sourced from multiple vendors, rules are necessary to avoid a mishmash of products and an alphabet soup of solutions that don’t work well together. Contrary to popular belief, rules of open architectures and standards interfaces enable and encourage innovation, not stifle it. Custom innovation protects vendors’ proprietary designs and cements vendor lock-up. Unique designs prevent their application on a wide scale and undermine interoperability.

Any specific military capability can be deconstructed to consist of features, functions, and technologies that fit and work together (e.g., a dismounted soldier network is composed of antennas, amplifiers, batteries, various software, etc.). The software involved can be composed of many modules — each with a specialized function, but together they deliver a capability (e.g., sensor software, video surveillance software, and voice communications software may combine to alert a soldier or squad of the need for close air support or medical evacuation).

The difference between capabilities delivered through custom vendor designs versus those based on open systems architectures and open interfaces is depicted in Fig. 1. On the left, the various “modules” that make up the capability are shaped and fitted in one specific way. They are custom-made to work together, and only the developing vendor knows how the pieces of the puzzle fit as well as owns the proprietary way in which they fit.

Figure 1.

Above, the same capability is organized into “modules,” or functions. Here each function follows some rules that provide a superior solution if we want (i) the individual functions to be developed by different parties yet remain interoperable; (ii) to replace some of these functions in the future with BETTER solutions (technology insertion, or tech-refresh); (iii) to implement all, or a subset, of these functions in a different configuration (or, if software, on networking devices of different shapes and sizes).

So, the open architectures and interfaces present smarter, more powerful, solutions when there is a bigger picture in mind than one PoR, acquisition, or development. That bigger picture lies in the military’s own list of demands for its capabilities: agility, resiliency, survivability, scalability, modularity, interoperability, security, and sustainability. Conversely, if developing a one-off, custom capability that will be deployed for specific applications, you don’t need to mess with open architectures and interfaces.

Architecture And Interface

Network architectures tell a designer how to define the various functions of their design into indivdual, self-contained modules, not which functions to use. It’s the ordered structure into which all the above shapes (functions) fit. Standard Interfaces are rules that apply to how these individual modules speak to each other across their borders or interfaces (exchange information they each need and coordinate their work). This allows modules to be replaceable, as long as the interfaces are maintained and the rules followed (Fig. 2). Equally important is that such setups allow individual modules to be replaced, be it by an expert on the system itself or innovators with specialized expertise in one specific function, but not others.

Figure 2.

This disciplined modularity is how new technologies can easily be inserted into tactical networks; how different configurations of modules easily deliver different but compatible capa- bilities. It is not easy to design software or hardware to open architectures and standards interfaces. Too often, vendors prefer to meet the contractual requirements through custom, non-repeatable designs, poor documentation, and minimal testing. They practice these bad habits to save time and money by cutting corners. They sacrifice the big picture battlefield need to “just get to the finish line and deliver something.”

MIL-STDs Are Overcome By Events (OBE) For Software

A strong statement, but MIL-STDs can’t get us where we need to go fast enough or without unwarranted risk. They subject DoD to what I call vendor kerfuffles! If we give specifications and blueprints (MIL-STDs or STANAGs) to multiple vendors, from which to design/implement military requirements, each vendor interprets them differently, producing solutions of different “flavors.” Software developed by many vendors from the same recipe is heavily influenced by which design tools, development environments, and test tools are used. No two implementations are the same, and, in tactical networking software that is rapidly exceeding millions of lines of code, these variations are not trivial.

This poses risk, compounded by two factors: (i) vendors’ implementation innovation spin, which deliberately or inadvertently creates vendor-lock; and (ii) the absence of a central DoD authority to insist that acquisition contracts require vendors to provide detailed evidence of how well they tested their version versus all competitors’. It bears mentioning here that Joint Interoperability Test Command (JITC) tests interoperability of a solution against its contractual IERs — not against other vendors’ implementations (unless vendors donate their devices and pay JITC to test).

Figure 3. This table shows how open architectures and standard interfaces enable the attributes demanded by DoD leaders as foundations for its modernization.

Risk can be adequately managed, but to date it hasn’t been. Sufficiently rigorous testing and verification to ensure all vendors’ efforts deliver the full capabilities promised is mistakenly viewed by Pms as too costly and too lengthy — especially in tactical software.

Designing software capabilities to MIL-STDs — and not open standards — has given a false sense that multi-vendor development from specifications is fast and cheap. GAO audit reports show that 40 percent of military software lifecycle management costs are incurred after fielding (as bugs and patches reveal gaps from insufficient testing).⁵

DoD’s Joint Tactical Networking Center (JTNC) assesses military networking software for its degree of interoperability, security, and reusability by vendors other than the original developer. JTNC’s assessment of military waveform software over the past four years supports the GAO’s findings: Custom development of software and rapid fielding hide the true costs (and total cost of ownership, or TCO) in follow-on maintenance and software in-service support (SwISS) contracts.

Absent an open architecture and standards applied to multivendor systems, the military is forced to resort to gateways, translators, and adapters in an attempt to stitch these disparate deliveries into something resembling interoperability. The resultant after-the-fact architecture suffers the additional cost of the gateways, the complexity of fielding and operating the cobbled solution, and the increased risk of failure and cyber breach from the translators scattered throughout the network.

Moral of the story: Look at the rate at which global militaries are identifying new devices (manned and unmanned) and advanced capabilities. Consider the complexity with which artiificial intelligence, cognitive devices, and data analytics allows adversaries to attack and degrade our networks and to sabotage our intelligence, surveillance, and reconnaissance (ISR). Then, consider what must be done to thwart those threats and mount a counter-offensive. With millions of lines of software communicating faster than any human reaction time, delays of a few milliseconds could be unacceptable. Now ask, is it ideal to have multiple vendors deliver these devices by individually following blueprint MIL-STDs?

Is It Really Speed vs. Quality?

Open systems architectures and standards interfaces fall victim to how their impact is measured. At the indivdual PoR level, PMOs and vendors largely shun compliance with open architectures. They are right to do so, if the architectures are not specified in the requirements and the PM has not been allocated sufficient resources and time to fulfill them. But this does not serve the Services-atlarge or the DoD and is a consequence of incomplete requirements definition before they even get to the PM.

Adopting open architectures and standards will never be easier, faster, or cheaper than at a one-off PoR scale. Their effectiveness lies in being used to deliver capabilities on a wide scale, quickly and safely. Smart design is hard, and PMOs behind schedule and over budget jettison anything that is not an explicit requirement in the contract; we can’t blame them. PMOs saddled with constrained budgets at the outset avoid even asking for such things in their contract. Poor contractual requirements focus on the narrow and immediate needs of a specific case or CONOPS, ignoring the enterprise needs that military leadership keeps saying it needs for its modernization.

Unsurprisingly, the results have been cheap, fast, and quick solutions — which end up being costly to undo and fix later.⁵Every Service has pointed to its legacy graveyard of quick-fix solutions as the number one financial impediment to its modernization. Moving forward, they cannot afford to stockpile more one-off custom solutions.

“If you want to go fast, go alone. If you want to go far, go together,” states a popular proverb. The misunderstanding of this proverb is that going together and far also means going slow. Instead, think of it as investing a little bit more care up front in articulating capabilities, identifying their underlying requirements (all of them), and guiding the contractual terms by which industry submits proposals for its innovative solutions. This investment ensures the fielded solutions are on a solid foundation that allows the military to realize what it keeps asking for: security, survivability, resiliency, scalability, modularity, interoperability, sustainability, and agility. Done right, they can have their cake and eat it, too.

References

1. National Defense Strategy 2018. http://nssarchive.us/national-defense-strategy-2018/
2. Achieving Effective Acquisition of Information Technology in the Department of Defense. National Research Council. ISBN 978-0-309-38391-2 | DOI 10.17226/12823.
3. The Unfitness of Traditional Military Thinking in Cyber. Jan Kallberg and Thomas S. Cook. Army Cyber Institute, West Point United States Military Academy, West Point, NY 10996, USA.
4. Army Tactical Network Modernization Strategy Assessment. Director, Cost Assessment and Program Evaluation and Director, Operational Test and Evaluation Report. April 2018.
5. Army Contracting: Leadership Lacks Information Needed to Evaluate and Improve Operations. June 7. GAO-17-457.

---

Dr. Kamal is president and CEO of DataPath Inc., a provider of wireless and satellite products and solutions to DoD and the U.S. Government. Previously, he was chief scientist/engineering and director of technical services at SAIC, a defense contractor. His background is in advanced networking solutions for tactical military environments. Recently, he has turned his attention to working with the Pentagon and Programs of Record on modernization and reforming the defense acquisition environment. His book in this area will be published later this year.