At an open architecture summit in November 2014, Katrina G. McFarland, assistant secretary of defense for acquisition said that 75 percent of all Defense Department acquisition strategies implement open systems architecture across all services and agencies. "This department is seriously engaged in trying to understand how to help our program managers and our department and our industry look at open architecture and its benefits," McFarland said, "and understand truly what our objectives are related to intellectual property and making sure that we're doing it based on the best interest of national security relative to a business case." Open systems architecture (OSA) integrates business and technical practices to create systems with interoperable and reusable components. OSA offers outstanding potential for creating resilient and adaptable systems and is therefore a priority for the DoD. The challenges with OSA, however, make it one of the most ambitious endeavors in software architecture today. A group of researchers at the SEI recently held an informal roundtable with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems, to discuss OSA-based approaches and how best to help the DoD achieve them. This blog post presents highlights of the discussion with Sharp on OSA approaches and how they can best be integrated in DoD system development.

This blog post, the first in a series presenting the perspectives of DoD stakeholders, presents highlights of our discussion with Sharp including

• criteria for a system to be considered open
• the role of OSA-based approaches in meeting key DoD acquisition objectives, such as economic efficiency, speed to fleet/field, and a sustained competitive supply chain ecosystem workforce
• examples where OSA-based approaches have been applied effectively in defense systems
• concerns by many that OSA-based approaches make systems more vulnerable to attack

The State of OSA Adoption

Before delving into our discussions, however, it is important to explore the state of OSA adoption in the DoD. To deliver enhanced, integrated warfighting capability at lower cost the DoD must move away from stove-piped solutions and embrace OSA-based technical reference frameworks, which are based on reusable hardware and software components and services including open interface specifications. When components strictly adhere to open interface specifications, a component may be replaced without having to modify its environment to accept the new component.

The DoD has made previous efforts in this direction, but in this recent era of sequestration and austerity, the DoD has renewed emphasis on more affordable acquisition choices that reduce the cycle time for initial acquisition and for technology refresh throughout the lifecycle. This new direction will help the DoD introduce new technologies more quickly and less expensively to the warfighter.

There have been several, recent notable efforts on OSA in the DoD, including:

• Boeing's Phantom Fusion mission processing product line meets stringent security requirements in an open manner through the use of widely used commercial standards and support for multiple DoD standards such as Open Mission Systems (OMS) and Future Airborne Capability Environment (FACE). Phantom Fusion has been through extensive flight tests and demonstrations including FLEX-13 and FLEX-15 exercises on the EA-18G, Talon HATE on the F-15, and FACE / Joint Common Architecture demonstrations for the Joint Multirole Rotorcraft program
• Lockheed recently reported the latest Aegis configuration for destroyers, called Baseline 9.C1, used commercial technologies and open architecture systems to merge ballistic missile defense and anti-air-warfare capabilities into an integrated system.
• Boeing recently completed a ground-based demonstration of an OMS enclave into the B-52 CONECT system, including software from the US Air Force, Boeing, and Lockheed Martin. This effort rapidly integrated the Lockheed Martin Sniper Pod into the 1950s-era B-52, distributing digital video/imagery to the existing CONECT displays, storing and retrieving previously collected video/imagery by clicking on a map, and fusing off-board tracks. This successful demonstration reinforces the benefits of open system standards benefits for rapidly integrating new capabilities onto legacy platforms.
• Lockheed's Skunk Works is planning more test flights of an open-mission system (OMS) that promises true plug-and-play functionality for airborne communications, electronic warfare and sensor systems, according to a recent article in AINOnline. The platform for the flights is the U-2 reconnaissance aircraft, which has already demonstrated machine-to-machine integration in two series of flights since November last year.

At the beginning of our discussions Sharp explained that openness is sometimes viewed as a goal in and of itself, but it is typically only a means to a greater end. End goals driving open systems often include:

• reducing cost by avoiding vendor lock-in and increasing competition
• accelerating development and integration by composing systems from reusable components more easily

In many cases, past efforts met the specific open systems requirements imposed on them but did not achieve the underlying programmatic goals. It is this gap that drives continued work in open systems approaches.

These objectives often vary for different stakeholders in different contexts, Sharp explained. The underlying existence of different objectives on different programs or even different stakeholders on a single program, are what drive the different perspectives and definitions of openness. Debates about openness offer insight into underlying objectives and how best to achieve them. As Sharp explained

My first recommendation would be to explicitly define the program objectives for pursuing an open system and make sure that information then guides and tailors the definition of open system criteria in each particular case. To the degree that those can be made common across the DoD as a whole or subsets thereof--should help with communication and focus activities and investments on meeting those objectives. I think inherently there are multiple objectives that the government, acquisition programs, and industry contractors are trying to serve via openness. It is conflicts between those underlying objectives that lead to meeting required "openness criteria" without achieving the intended programmatic goal(s).

In many respects, the technical core of openness is supporting composition, Sharp said, and the ability to more easily pull together components and build larger systems due to standardized pre-defined interfaces. OSA enables the leveraging of existing elements and technologies to integrate them into a system. When used at system boundaries, OSA-based technologies enhance interoperability between systems and facilitate networked systems of systems capabilities. In this case, these technologies support the continuing trend toward networked systems and systems of systems in both DoD and commercial systems.

The Importance of Standards-Based Open Systems

Sharp stressed the importance of standards-based open systems, such as the DoD's Open Systems Architecture (OSA), which is one form of an open systems approach:

Standards, as far as the interfaces, are really, really key. Having fully defined and published interfaces and not having IP restrictions on the interfaces is theoretically sufficient to develop a replacement for a component (a basic form of openness), but it's often programmatically insufficient. Development of competing components is motivated by larger marketplaces for those components. Standards can increase the size of those marketplaces.

When asked what types of governance were most effective in developing standards, Sharp mentioned both consensus-based and directed models. Open commercial standards are typically developed according to a group consensus process, Sharp explained, which increases buy-in from stakeholders. The tradeoff is that they often take a long time to develop and suffer from "design by committee" effects such as bloated feature sets and complexity. The presence of some more directive authority can help reduce these disadvantages if applied wisely. A hybrid model works well, where stakeholder consensus is the normal operating mode and only topics with prolonged disagreement are brought to an authority for direction.

I like consensus. I'm a consensus driver myself, but I also recognize that not everything can be done by consensus. So, I think there is a role for both forms of standards or portions of standards: ones that are more directive and prescriptive and ones that are more consensus-based. The important part is that the resulting standard meets the core technical and business objectives and achieves technical integrity.

When it comes to lower layers of OSA systems (such as the hardware and software infrastructure components related to networking, operating systems, storage, and middleware), Sharp explained, where the commercial industry really serves as the key driver, consensus-based standards are common:

The lower in the stack you get, the more it gets aligned with commercial practice, which is essential for us to align with and leverage wherever possible. Then we need to recognize what portions we [the defense systems community] need to tackle ourselves, and not be derelict in our responsibilities in those areas. Certainly, we have seen more and more progress in availability of relevant commercial standards as you go lower in the protocol stacks and in the layered architectures.

Sharp said that one of Boeing's best OSA standardization experiences is the USAF Open Mission Systems program which employs the hybrid consensus / directed governance model in a joint DOD - industry consortium:

What I mean by 'best' is best in terms of making progress relatively rapidly and converging on solutions, developing proofs of concept, prototypes and things like that to really flesh out the dark corners of standards and recommendations through a combination of demonstrations, tests, and other validation/verification-type activities. We have seen that to be a successful model.

OMS is a government-driven and government-funded standardization effort, Sharp added, which spurs industry involvement, both in the near term and the long term. The government-industry consortium strives toward group consensus wherever possible, but leverages customer leadership when consensus roadblocks occur.

Boeing has been working with open systems since the mid-1990s with the Bold Stroke initiative and many others. Bold Stroke developed a common mission computing architecture and a repository of software used on multiple aircraft programs. Bold Stroke included a number of early projects for the Open Systems Joint Task Force to demonstrate and establish open systems practices. A core tenet of Bold Stroke was leveraging commercial standards and practices, Sharp explained. It included efforts to define and maturate tailored commercial standards where necessary as they moved from the enterprise world to the real-time embedded world.

I certainly would point to that suite of programs as good exemplars of what can be done when you have the right combination of customer, academic, and industry participation and alignment of objectives.

Bold Stroke has been inducted in the Software Product Line "Hall of Fame".

Securing OSA Systems

OSA systems are touted because of their potential to lower program costs, increase access to COTS, and ease integration. OSA programs also enable interconnectivity, but this also makes them more vulnerable because greater connectivity also coincides with greater access for cyber intruders. This accessibility has prompted concerns that OSA systems are more vulnerable to attack.

When asked whether OSA issues can be mitigated through more effective security models or techniques, Sharp cautioned

If there is anything that we have seen in the past year, it's that secrets are not as strong as you might think, whether it's our security system numbers in the IRS database [or] the military system design on your development system. Hacking is happening. There is wide recognition that company development networks have been hacked into, infiltrated, and exfiltrated.

In some respects, the days are over [when] we could assure ourselves of secure systems by keeping the designs or implementations secret.

Sharp added, however, that standards-based approaches have the potential to be more secure because multiple viewers are more likely to find and identify vulnerabilities.

I think there is a potential opportunity for open systems to actually be more secure than secret systems. It is somewhat an old-fashioned notion to think that secrecy by itself will get us there. It's necessary but not sufficient. I personally don't see a strong conflict there. I think we have to be developing assuming our secrets have often been compromised. That assumption changes your perspective on things.

Wrapping Up and Looking Ahead

Open systems architectures were first introduced in the DoD in November 1994 when the Under Secretary of Defense for Acquisition, Technology, and Logistics directed that all DoD components and agencies "use open systems specifications and standards for acquisition of weapon systems and chartered the Open Systems Joint Task Force (OSJTF) as a jointly sponsored oversight body to oversee the implementation of the new policy."

Fast forward to 2015, and OSA approaches have made significant inroads:

• The DoD's Better Buying Power initiative advocates open system architecture (The latest instantiation includes Modular OSA as an emphasis area).
• The office of the Deputy Assistant Secretary of Defense, Systems Engineering has an OSA initiative
• The Defense Acquisition Guidebook dedicates an extensive section on OSA initiatives.

There still remain, however, opportunities for research and development to make OSA approaches more useful for the DoD, specifically the warfighter.

In discussing future R&D, Sharp stressed that "tremendous opportunities" continue for interface standards to facilitate system and subsystem integration such as

• sensor interfaces
• weapons interfaces
• networked platform interfaces, including those between vehicles (e.g., data-links) and between platforms and ground stations (e.g., command-and-control messages between control stations and unmanned air vehicles such as STANAG 4586)

In addition to subsystem integration standards, there continues to be a significant opportunity for better tool support for component integration and analysis. While there has been significant progress in researching OSA approaches and tools, transitioning that into the industry space continues to be a challenge.

Meeting warfighter needs goes beyond any single standard, quality, function, or business objective. As Sharp explained

How do we integrate all of these -ilities and functions together? Safety, security, performance and fault tolerance, fault management. How do we better integrate all of those things together and develop better techniques, tools, and standards that allow us to do that? I think that is a very hard nut to crack, but one that continues to motivate additional research and investment in those. That is really what matters to warfighters. It doesn't help them until the integrated product gets in their hands, it's safe and secure, and it meets their operational performance needs.

Additional Resources

To view the presentation, Open Systems - What's Old is New Again, please click here.

To view the SEI special report Development of an Intellectual Property Strategy: Research Notes to Support Department of Defense Programs, please click here.

To view the SEI technical report A Decision Framework for Selecting Licensing Rights for Noncommercial Computer Software in the DoD Environment, please click here.