4.3.18.15. Open Systems Architecture

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.3.18.15. Open Systems Architecture

4.3.18.15. Open Systems Architecture

Open Systems Architecture (OSA) benefits Program Managers by using established and working frameworks that are already crafted with component reuse in mind, such that many common services and applications can be quickly instantiated with small effort from program to program. Adding features to address evolving threats to an already tested, fielded, and working component is far less risky than a “ground up” new development start. OSA is identified as a key tenet of Better Buying Power, under Promoting Effective Competition, because it enhances system interoperability and the ability to integrate new capabilities without redesign of entire systems or large portions of the enterprise. It is also addressed in DoDI 5000.02.

An open architecture is defined as a technical architecture that adopts open standards supporting a modular, loosely coupled, and highly cohesive system structure that includes the publishing of key interfaces within the system and relevant design disclosure. The key enabler for open architecture is the adoption of an open business model that requires doing business in a transparent way that leverages the collaborative innovation of numerous participants across the enterprise, permitting shared risk, maximized reuse of assets, and reduced total ownership costs. The combination of open architecture and an open business model permits the acquisition of OSA that yield modular, interoperable systems allowing components to be added, modified, replaced, removed, and/or supported by different vendors throughout the life cycle in order to afford opportunities for enhanced competition and innovation.

OSA benefits warfighters by:

• Reducing operator learning curves by using systems that have similar functions and are operated in similar ways thereby reducing costs
• Increasing interchangeability
• Reducing support and sustainment costs

The engineering trade analyses conducted prior to MS B help determine which system elements of program architecture can be adapted to OSA in order to reduce program cost and development time lines. Correct application of OSA principles and practices results in modular architecture components having well-defined functions and open standards-based interfaces. Threat analyses, functional criticality analyses, technology opportunities, and evolved capability assessments are examples of assessments against the functional architecture to determine what components should be OSA-enabled. When these architecture components require upgrade, replacement is competitive, faster, and cheaper because the OSA-enabled components are modular. Because system functional architecture maps from the higher-level enterprise architecture, engineering trade analyses and assessments supporting OSA should be completed and OSA-enabled architecture components specified, before contracts are let for technology development of those architecture components. Successful implementation of OSA approaches requires the synchronized acquisition of data rights for OS and interfacing architecture elements. These data rights are initially structured to support acquisition of modular open system designs but also should address life-cycle support.

Acquisition programs adopting OSA benefit from:

• Reduced acquisition and sustainment cost without sacrificing capability
• Reduced reliance on single-source vendors (“Vendor Lock”)
• Shortened program acquisition time line
• Enhanced rapid and agile development
• Accelerated transition from science and technology into acquisition due to modular insertion
• Increased ability to retrofit/upgrade system elements for new/evolving capability
• Enhanced incremental approach to capabilities
• Increased competition and innovation
• Enhanced ability to create security structures within a design to reduce security risk

DoDI 5000.02 identifies the use of OSA as a key systems engineering (SE) approach in Enclosure 12, paragraph 8. The USD(AT&L) memorandum, “Better Buying Power 2.0: Continuing the Pursuit for Greater Efficiency and Productivity in Defense Spending," November 13, 2012, raises the relevance of OSA along with acquisition of data rights for appropriate architecture elements. The overarching business case for DoD is increasing the level of competition by enabling small business. Programs should develop a business model documenting the strategy for use of OSA and associated data rights. The OSA-DR Charter signed by USD(AT&L) on February 15, 2012, requires programs to issue business case guidance to aid programs in developing their business models.

The DoD Open Systems Architecture Contract Guidebook for Program Managers contains guidance regarding contract language programs should use to acquire data rights in support of a program’s OSA strategy. Additional information and supporting details amplifying each aspect of OSA is available on the DASD(SE) website.

The Program Manager should:

• Establish supportive requirements; business practices; and technology development, acquisition, test and evaluation, and product support strategies for effective development of open systems
• Ensure their data deliverables support their Technical Data Rights Strategy (see Acquisition Strategy template) and secure the necessary data rights to support and sustain the system
• Map Open Systems strategy and functional architecture to SOW requirements, Data Item Descriptions (DIDs), and CDRLs consistently across the enterprise
• Ensure compliance
• Consider including OSA as one of the evaluation criteria for contract proposals
• Determine the appropriateness of an OSA approach by considering software constraints, security requirements and procedures, availability and cost of data rights, life-cycle affordability, and reliability of open standards, as well as other relevant factors such as environmental constraints (e.g., temperature, humidity, and environment, safety, and occupational health (ESOH))

The Systems Engineer should:

• Employ an overall plan for and OSA approach that supports program functional architecture and that uses prescribed USD(AT&L) business case analyses
• Ensure the program functional architecture is structured to accommodate OSA where feasible, due to the high potential for reduced risk and cost
• Assess performance
• Balance current implementation of OSA with performance and evolving technology at the physical level; OSA establishes a technical baseline that may support modular architecture, but formally constrains the interfaces between modules, where interfaces close to current performance limits may quickly become obsolete
• Technically evaluate the appropriateness of an OSA approach by considering software constraints, security requirements and procedures, availability and cost of data rights, life-cycle affordability, and reliability of open standards, as well as other relevant factors such as environmental constraints (e.g., temperature, humidity, and ESOH)

Modular open system designs, developed from the system architecture, should be analyzed at each design review because there is a link between OSA and the level and type of technical data, computer software, and data rights the Government needs for life-cycle support. In many cases weapon systems using OSA system elements can have increased opportunities for competitive sourcing during the life-cycle sustainment, and a correspondingly less need for detailed design data and associated data rights. This benefit enables an incremental approach to capability adaptation in OSA-enabled systems and is a benefit of the modularity originally specified into the functional architecture.

Figure 4.3.18.15.F1 depicts an example architectural approach for mapping and assessing which component interfaces can be open, how associated risk is ascertained, and visualizing the impact to interfaces with other system elements. The figure presents a top-level system view of the OSA characteristics of system architecture components. Not all interfaces need to be open at any one level of the design, only those that are required to meet anticipated incremental capability updates or changes in threat or technology insertion. A system view such as this one includes a record of the data rights that are required to enable the planned OSA design. This is to initially ensure and, for the life-cycle sustainment, maintain the strong link between the OSA design and the acquired data rights that enable it. The levels of data rights that need to be required for each OSA-enabled architecture component are determined in order to assert the requisite contract requirements to obtain them. The data rights strategy ensures that enterprise-level data rights flow to system architecture components and that they support the system architecture. Levels of data rights are described in DAG Chapter 2 Program Strategies and in Appendix 9 of the OSA Contract Guidebook.

Figure 4.3.18.15.F1. Sample OS and Data Rights Analysis

Successfully implementing an OSA strategy results in identification of required technical data and software deliverables that are necessary to field and maintain weapon systems and their logistics support. The Technology Development Strategy and Acquisition Strategy should be updated throughout the system’s life cycle to reflect changes in the OSA approach resulting from technology and software evolutionary developments. The Systems Engineering Plan (SEP) also is updated to reflect the OSA-related updates and modifications employed throughout the system and its system elements.

Specific OSA-related data deliverables that should be required to include:

• Software Development Plans (DI-IPSC-81427A)
• Software Development Status Reports (DI-MCCR-80459)
• Software Development Summary Reports (DI-MCCR-80902)
• Software Design Descriptions (DI-IPSC-81435A)

In addition, the Program Manager should maintain an open systems management plan. The plan describes the offeror’s approach to:

• OSA, modularity, and open design
• Inter-component dependencies
• Design information documentation
• Technology insertion
• Life-cycle sustainability
• Interface design and management
• Treatment of proprietary or vendor-unique elements
• Reuse of preexisting items including all commercial-off-the-shelf/non-developmental Item (COTS/NDI) components, their functionality and proposed function in the system
• Copies of license agreements related to the use of COTS/NDI components for Government approval

The open system management plan also should include a statement explaining why each COTS/NDI was selected for use.

Program products typically used in making decisions regarding OSA include:

• System Requirements
• Technology Development Strategy (TDS) or Acquisition Strategy (AS)
• Program Protection Plan (PPP)
• Analysis of Alternatives (AoA)
• Enterprise Architecture

OSA approaches and requirements should be addressed at design reviews, e.g., System Readiness Review (SRR), Preliminary Design Review (PDR), and Critical Design Review (CDR).

See DoD ASSIST homepage for more data item deliverables that may be appropriate for each specific program and DoD 5010.12-M for data deliverables.

Top of page