To deliver enhanced, integrated warfighting capability at lower cost, the DoD must move away from stovepiped solutions and embrace open systems architecture (OSA) approaches that integrate business and technical practices to create systems with interoperable and reusable components. In November, the SEI launched a series of blog posts that highlight the perspectives of DoD stakeholders--including contractor and government employees--on OSA-based approaches and how they can best be integrated in DoD software (and hardware) development. The first post in this series highlighted our discussion with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems. This post highlights a discussion with Nickolas H. Guertin, in the Office of the Deputy Assistant Secretary of the Navy for Research, Development, Test, and Evaluation.

Guertin has a long history with open systems, both for U.S. Navy OSA initiatives and broader DoD initiatives. Based on his experiences over the past several decades, he discussed with the SEI how OSA offers developers the ability to create more resilient and adaptable systems. He noted that Under Secretary of Defense for Acquisition, Technology and Logistics Frank Kendall, in his Better Buying Power 3.0, highlights how the acquisition community can address that demand signal. Together, they have established that we are behind in technology innovation and need to use OSA as a method to bridge that divide. This new direction is helping the DoD introduce new technologies more quickly and less expensively to the warfighter. Throughout this post, we will present excerpts from our conversation (Editor's note: These excerpts have been edited to improve readability).

A Litmus Test for OSA Adoption

The discussion began with Guertin explaining his definition of open, as well as the litmus test he uses as the criteria for defining a system as open.

Guertin: We have made attempts at rigorous definitions of open systems architecture, but in a nutshell, what's most important is the ability for multiple actors--including companies and government organizations --to provide effective solutions that are integrated with low technical risk in a short amount of time and at a reasonable cost to the government. In my opinion, the best way to achieve these goals is to ensure the environment and the architectural platforms on which stakeholders want to provide solutions is well-defined, published, and knowable by many, including potential competitors.

Schmidt: Is the key here the notion of published open interfaces that others can program against without having to be part of the original design team or development team?

Guertin: Absolutely, although I am starting to wonder if the notion of open interface is too narrow. In particular, I now believe that openness is more complicated than that. For example, what does it take to integrate a new component into a system? Perhaps it is more than just interface specifications. Working with colleagues from across industry and government, I have come to recognize that successful integration requires specification of key quality attributes, such as timeliness, security, and reliability, as well as access to technical data and related information needed to reuse components in systems beyond their original context. Ultimately, what we need is the ability to have multiple competitive alternatives that can evolve and interoperate dependably across the lifecycle of complex systems and systems-of-systems.

The Business Value of OSA Approaches

While there is a technical dimension to OSA that includes a set of application programming interfaces, standards, components, and frameworks, it is also important to recognize the business value they provide to the government. Our discussion next touched upon key benefits the DoD can realize from OSA approaches with respect to acquisition objectives and business models.

Guertin: We frequently start out with less-than-complete awareness of how a product is ultimately going to behave when we start doing the design. The desired behavior is often discovered as the design process unfolds. Sometimes you end up needing a new piece, or something that you started out with just didn't work out well. Without an open architecture (i.e., without the ability to bring in alternative components during the development or sustainment phases), you have to find a way to brute force through the pieces you have to get to what you need, which is time consuming, risky, and expensive.

Program managers often apply open systems architectures during product development to achieve various benefits, such as reducing program risk and controlling lifecycle costs. These benefits also hold when programs go to their next phases, such as testing and production, where it often turns out that the solution needed at the beginning has changed over time. Now, the warfighter, who would have ended up using the initial solution, wants a different feature set. Likewise, the initial system implementation may not pan out (e.g., due to problems with scalability or security concerns). At this point, it may be necessary to devise a different way to instantiate the product. By establishing open systems architectures, these natural evolutions in business and technical needs can be accommodated more effectively and efficiently during product development, production, and throughout the lifecycle.

OSA's Impact on the Overall Supply Chain

Guertin next examined the effect of OSA on the work force and the overall supply chain--not just integrators and contractors, but also on the ability to integrate and assume or assimilate commercial off-the-shelf technologies.

Guertin: At the product development level, OSA approaches can be liberating, but get more complicated up the management chain, where you start getting into the cultural dimensions. I have counselled program office staffs who are burdened by a past pattern of acquisition that goes something like this:, "I start with needing a solution to a big problem; I then map that into a single specification; then go on to forge a path to that capability by writing a monolithic contract that gets awarded to a single source. I have performed a competition because I have completed the whole thing at once. Haven't I done my job?"

I contend that packaging our business into very large contracting vehicles makes it hard to break free of established relationships because it's necessary to recompete the whole program as one big package. Often, however, it isn't risk prudent to recompete an entire program since the incumbent is well entrenched, deeply aware of exactly what is going on, knows how the product works, and understands how to interact with a program manager and the fleet customer.

Instead, we should package our business into smaller units so there's a chance to recompete and replace these units more nimbly and cost effectively in the future. At present, that type of approach represents a gigantic culture shift for the defense acquisition community. The conventional model has been rewarded by defining requirements for a system up front, putting those requirements into a contract, bidding it out, and letting the winner take all. Unfortunately, this conventional model is bad business in terms of managing our value proposition to both the tax payer and the warfighter.

When you examine the industrial development community you'll see it contains a few very large integrators, not many medium-sized businesses, and many small businesses (which are very much tied into the large businesses). When the government wants to compete or recompete a program, the smaller, more nimble (and often less expensive) contractors are sometimes put in a difficult business situation where they must compete for work they may be already doing under a subcontract or be well enough aware about it that they may have a business relationship with the organization that we are trying to move the work away from. The dynamics become harder for the community at large to embrace.

Therefore, although OSA is the right thing to do--and we will gut our way through some of it--it is not an easy thing to go off and accomplish. In particular, we have cultural dimension problems on the government buying side and we have business relationship friction on the industry side.

The Evolution of OSA Over Time

Open systems approaches 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 to "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 contemporary OSA approaches have made significant inroads, including

• 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 and challenges for research and development to make OSA approaches more useful for the DoD, specifically the warfighter. One challenge to OSA adoption is the conservative nature of the acquisition community in adopting approaches that have not been extensively proved. Guertin cited examples of DoD projects that have successfully applied OSA approaches, beginning with the Acoustics-Rapid COTS Insertion program in the 1990s.

Another early initiative is Team Submarine, which brought "diverse submarine-related commands and activities into a single submarine-centric organization." Team Submarine was started to eliminate the stove-piped structures and processes that hindered submarine research, development, and acquisition communities.

Guertin: The acoustic rapid COTS insertion program was able to establish an integration fabric that could bring together multiple components from different vendors. The level of individual vendors is a microcosm of the problem we were talking about earlier, where each vendor has their own environment, but they are able to integrate them together pretty well. They have been doing that for a while now and it's a flagship example of a successful program that's applied OSA principles and methods.

The folks at PEO for C4I systems have also been successful with the Common Afloat Network & Enterprise Services (otherwise known as CANES) program. CANES has established a development stack that was published and widely available so suppliers could bring in products from multiple vendors and integrate them into an environment that could be populated on multiple ships. It is not the be-all, end-all solution, but it is another progression in our evolution toward a more effective OSA-based environments.

Most recently I have been working with the Future Airborne Capability Environment (FACE) consortium, which consists of 80-plus companies. FACE is an OSA-based specification that standardizes several layers of a platform for avionics computing and communications. It utilizes a well-published, rigorously defined set of technical reference frameworks that is being adopted by various U.S. Navy and Army acquisition programs. FACE is the latest step in a long progression of starting from coupling together products built in a federated construct to establishing systematically architected technical environments that multiple commercial and government stakeholders can act in cooperation and collaboration together. These examples span a period of 20-plus years and illustrate that on a trajectory and are getting better at defining and adopting OSA practices and methods over time.

Openness and the Future of DoD Systems

In looking forward to the next decade and whether OSA-based approaches will help or hinder the rollout of capabilities needed by the warfighters, Guertin said that his recent discussions with program managers and other acquisition professionals has underscored the necessity of having an integrator who can pull together different pieces of the system.

Guertin: A single integrator isn't necessarily the only party that should compose the full solution. In the future, I expect programs will have a set of activities associated with integration and they may benefit from contracting with multiple parties to compose together the components and subsystems that comprise that system. They could do this contracting in creative ways.

We must be strategic in performing competitions, especially in the area of product integration. One of my favorite methods for establishing beneficial motivation for integration activities is the "award term" contract. This type of vehicle rewards performers by tacking another year of performance onto their contract, but only if they perform with great excellence. The goal is to renew the relationship if the desired behavior is maintained, in this case, supporting the government's needs for an open system that demonstrates seamless incorporation of components from other vendors. However, it's essential to encourage the production of multiple competitive alternatives, so program managers have the flexibility to change components when better solutions are availability.

One of the most powerful books that I have read in the area of market transformation was called The Box by Mark Levinson. It chronicled the activities of a fellow who, in the early fifties, decided that he wasn't in the trucking business; he was in the "moving stuff" business. He went from moving stuff in trucks to moving trucks on ships transportable modules, (i.e., without having to take everything out of the truck and put it into the hold of the ship).

What happened is that whole cities that had been built around the close coupling of transportation and manufacturing were impacted because transportation was now modularized. Many people from many different parts of the world could now participate in product development. Not completely by itself, but the container ship concept changed how and where products get built in the global market.

I see open systems architecture as The Box, (i.e., the framework on which we can acquire our systems in smaller components and be able to deliver them to multiple integration agents without having to always go to a big system integrator in order to get there). I think if we do this right, it could have a substantial impact on the way that the government contracts for its systems and how that eventually impacts the defense marketplace.

In examining other key drivers for future improvement, Guertin said all stakeholders involved in fielding technologies to the warfighter need to focus on the business processes of the acquisition framework.

Guertin: Programs need to start looking at each other as opportunities for technical leverage instead of being avoided as business risk. When we talk to our program managers about utilizing capabilities from other programs, they are often hesitant because they perceive risk and loss of independence. Admittedly, at times in the past this risk has been realized. In the face of increased threats and stagnant budgets, however, there's a growing need to reduce the number of times we develop duplicative components and use that same intellectual capacity, that same performance capacity, to build new and innovative things more rapidly.

Secretary Kendall when he briefed out the third iteration of the Better Buying Power initiative looked at potential adversaries and saw they were often turning tighter corners than we are. The national strategic objective is to develop excellent warfighting systems more rapidly and more cost-effectively. To accomplish that objective we must start counting on each other, leveraging and reusing from others, and moving on to use more innovative products and solutions, regardless of where they might come from.

Our discussion concluded with an examination of the gaps that should be addressed to motivate further research and development on OSA approaches beyond training program managers in our existing knowledge through Defense Acquisition University.

Guertin: In the office I work in now, we are heavily engaged in prototyping and experimentation. One thing we're trying to accomplish in the way we develop these prototypes is to take these products out of the science and technology environment and make sure that they align with open systems architectures as they mature through the prototyping process. Later, during the experimentation process, if we decide these are valuable products for the warfighter, then we have a proven prototype that has demonstrated not only the capability but the principles of OA. Using what we learned during the prototyping and experimentation phase, we can initiate a robust competition at the component level with a more robust technical awareness of what the solution needs to do. The use of open system architectures enables the next team to pick up the ball and run with it without having to completely relearn a whole new set of rules.

This series of blog posts will continue to highlight the perspectives of stakeholders who are vested in leveraging OSA approaches to help the warfighter. We welcome your feedback on this series as well as suggestions for future OSA-related discussion topics in the comments section below.

Additional Resources

View the presentation Open Systems--What's Old is New Again.

View the SEI special report Development of an Intellectual Property Strategy: Research Notes to Support Department of Defense Programs.

View the SEI technical report A Decision Framework for Selecting Licensing Rights for Noncommercial Computer Software in the DoD Environment.