Open Systems Architecture (OSA)
The open systems initiative at the Department of Defense began in November 29, 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. The OSJTF charter was extended several times during the last 10 years with its mission, functions, and responsibilities transferred to the System and Software Engineering Directorate – now the Office of the Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)).
The DoD preferred approach for implementation of open systems, previosuly called Modular Open Systems Approach (MOSA), is now called Open Systems Architecture (OSA). OSA is both a business and technical strategy for developing a new system or modernizing an existing one. Through OSA application, acquisition and engineering communities are enabled to design for affordable change, employ evolutionary acquisition and spiral development, and develop an integrated roadmap for system design and development. Basing design strategies on widely supported open standards increases the chance that future changes to the system be integrated in a cost effective manner.
Open systems employ modular design, use widely supported and consensus based standards for their key interfaces, and have been subjected to successful validation and verification tests to ensure the openness of their key interfaces. Open systems characteristics and principles may be dealt with as:
(1) design requirements (e.g., mandated open standards and protocols);
(2) derived requirements (e.g., need for open interfaces to enable interoperability);
(3) design constraints (e.g., need to adhere to open interface specifications as system components are designed);
(4) architectural attributes (e.g., need for an adaptable, upgradeable and reconfigurable system architecture);
(5) design considerations (e.g., taking into considerations modular and open systems design benefits and concerns); and
(6) business strategies to gain access to competitive sources of supply and effectively manage technological obsolescence.
Enclosure 1, section E1.1.27. Systems Engineering of the DoDD 5000.01 (The Defense Acquisition System) highlights consideration of MOSA by all programs: Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular, open-systems approach shall be employed, where feasible. DoDI 5000.02 (Operation of the Defense Acquisition System) further discusses MOSA in Enclosure 12 (Systems Engineering), Section 8: Program managers shall employ MOSA to design for affordable change, enable evolutionary acquisition, and rapidly field affordable systems that are interoperable in the joint battle space.
Within Chapter 2 of the DAG, Section 18.104.22.168.3. Business Case Analysis (BCA) with Engineering Tradeoff Analysis highlights the need stating, "Business case development for open systems architecture and data rights is a process of analyzing alternative acquisition decisions to be undertaken for a given system to derive quantifiable costs as well as benefits for these alternative decisions. The business case should provide evidence that justifies an investment decision for the purposes of implementing (or not implementing) an open systems architecture or acquiring (or not acquiring) data rights for the program being examined." Chapter 2 also states the the Acquisition Strategy should summarize the make-or-buy approach to establish and maintain access to competitive suppliers for critical areas at system, subsystem, and component level (e.g., requiring an open-systems-architecture or a make-or-buy plan). List critical items and their sources. DoD Acquisition Guidebook Chapter 4 states that "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." Sections 22.214.171.124 Open Systems Architecture and 5.3.1. Architecture Considerations provide additional information. Program manager are expected to plan for OSA implementation and include a summary of such planning as part of the SEP, the overall Acquisition Strategy, and to the extent feasible, the Technology Development Strategy. The summary of the OSA planning should describe:
(1) how OSA fits into a program's overall acquisition process and strategies for acquisition, technology development, and T&E;
(2) what steps a program will take to analyze, develop, and implement a system or a system-of-systems architecture based on OSA principles; and
(3) how such program intends to monitor and assess its OSA implementation progress and ensure system openness.
Program managers can use the Program Manager's Guide and the MOSA Program Assessment and Review Tool (PART), which is an automated analytical tool that relies on objective data and evidence-based judgments, to monitor, assess, and evaluate MOSA implementation by their program or the Navy-sponsored Open Architecture Assessment Tool (OAAT), Version 3.0.
For more information on open systems implementation please see DAU Continuous Learning Modules CLE 013 Modular Open Systems Approach to DoD Acquisition and CLE 012 DoD Open Systems Architecture (OSA), and the Naval Open Architecture and DoD Open Systems Architecture website.
In December 2011, the USD(AT&L) directed the newly established DoD Open Systems Architecture Data Rights Team to publish an interim draft of the Department of Defense (DoD) Open System Architecture Contract Guidebook for Program Managers to the Defense Acquisition Guidebook. The principles described in the draft guidebook can be tailored to apply to the acquisition of any system or service. The draft is intended to augment, rather than replace, existing contractual source materials such as the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS). Users should consult the most recent versions of the FAR and DFARS, in addition to the draft Guidebook, when developing acquisition materials.