To print a PDF copy of this article, click here.
One of the significant challenges faced by program managers (PMs) is determining what formal data deliverables need to be included in solicitations. Historically, the lack of sufficient technical data and software and the lack of the rights to use them have limited PMs’ ability to implement acquisition and sustainment strategies that are competitive throughout a program’s life cycle.
Recent acquisition reform efforts have addressed this problem by emphasizing the importance of both managing intellectual property (IP) and adopting an open, modular approach to program design. For example:
Better Buying Power 2.0 (April 2013) identified “enforcing open system architectures and managing technical data rights” as important strategies for promoting effective competition in Department of Defense (DoD) acquisitions.
Interim DoD Instruction (DoDI) 5000.02, “Operation of the Defense Acquisition System” (November 2013) added provisions requiring PMs to:
- Establish and maintain an IP strategy to identify and manage the full spectrum of IP and related issues throughout a program’s life cycle
- Apply open systems approaches in product designs, where feasible and cost effective
The long-run success of these acquisition reforms requires (among other things) a common understanding of the ways in which initial decisions on program architecture, data deliverables and data rights licenses affect the potential for competitive procurement and sustainment in the future. In this article, the authors explore a significant linkage in this interdependence: the connections between program architecture, data rights and sustainment strategies. We first outline Open Systems Architecture (OSA) as a general policy goal, and then illustrate its implications in the context of both consumer choices and DoD acquisitions.
Open Systems Architecture as a Policy Goal
The general objective of OSA is to enable a PM to rely on “one or more qualified third parties to add, modify, replace, remove, and/or provide support for a component of a system” throughout a program’s life cycle (DoD Open Systems Architecture Contract Guidebook for Program Managers, p. viii). Reaching this goal depends upon the engineering approach adopted, as well as the business strategies selected for sustainment and procurement. From an engineering perspective, OSA requires a system that is modular in design, “where functionality is partitioned into discrete, cohesive, and self-contained units with well-defined interfaces that permit substitution of such units with similar components or products from alternate sources with minimum impact on existing units” (OSA Contract Guidebook, pp. 137–138). A fully open architecture has interfaces that are public, published and nonproprietary. From a business perspective, OSA requires data (and data rights) strategies that support competition throughout a program’s life cycle, enabling the PM not only to control the cost of the initial system, but also to integrate technological innovations as they become available. In short, OSA is a policy designed to help the government to avoid “vendor lock” (i.e., where only one vendor can respond to the government’s needs).
OSA requires a system that is modular in design, “where functionality is partitioned into discrete, cohesive, and self-contained units with well-defined interfaces that permit substitution of such units with similar components or products from alternate sources with minimum impact on existing units.
Alternator Failure in the Family Automobile
A complete description of OSA requirements and implications is beyond this article’s scope. However, a familiar scenario—the choice of maintenance options for a typical family car—helps identify the types of questions that must be answered when pursuing an OSA strategy.
Furthermore, analyzing the linkages between program design, data rights and market forces in this simple context illustrates the types of issues that PMs need to consider as they refine their acquisitions and sustainment strategies for the next generation of DoD weapons systems.
Our analysis starts with a description of a vehicle as a system with a specific architecture. Figure 1 is a partial Work Breakdown Structure (WBS) for a typical military vehicle, identifying the components of the major systems and illustrating the hierarchy among them. We assume that a family car would have a similar component structure.
Figure 1. Component Structure of a Typical Military Vehicle
Experienced car owners know that flickering dashboard lights, dim headlights and a “Check Engine” light are symptoms of a failing alternator—component 184.108.40.206.6 in Figure 1. In principle, a car owner who notices such indicators can either buy a brand new car or choose among three basic maintenance strategies:
- Option 1: Take the car back to the dealer for repair.
- Option 2: Buy a new alternator (or get one at a junkyard) and install it (or have a third party install it).
- Option 3: Remove the alternator, rebuild it, test it and reinstall it (or have a third party do so).
The relative merits of these options depend on many factors, including:
- The owner’s general knowledge of car repairs
- Competing claims on the owner’s time and budget
- The owner’s access to information about the specific alternator and its interface with the specific make and model of car in question
- The owner’s access to the tools necessary to perform the repairs
- The availability on the open market of replacement alternators, replacement alternator parts and a detailed repair manual
Many of these factors—like market conditions or the owner’s familiarity with car repairs—are determined by factors that have nothing to do with the terms of the original contract negotiated between the current owner and the car dealership. However, the availability of the information needed to follow a given maintenance strategy may well have been determined on the day the car was purchased. For an automobile, access to essential information—and permission to use it—will depend not only on the reporting mechanisms built into the car’s dashboard but also on the terms of the original sales agreement for the vehicle.
Consider the scope of information required for each of the car maintenance options mentioned above.
Option 1: If the owner relies on the dealer for repairs, he or she needs little more than an operator’s manual that explains how to interpret warning lights and gauges. Since such manuals are standard equipment—with a cost built into the sale price of the vehicle—the owner generally will have ready access to the information needed to pursue this strategy at no additional charge.
If no further maintenance information is available—or if the car’s warranty requires that all maintenance be done by authorized dealers—the manufacturer is treating the vehicle essentially as a closed system.
Option 2: If the owner wishes to buy a new alternator and install it (or have a third party install it), then more information is needed, including complete specifications for a replacement alternator and instructions on how to remove, replace and test a new one. More formally, the information required by the public for this maintenance strategy includes:
- All data listed for Option 1
- Full “form, fit and function” data for the existing alternator, such as
- Mechanical interface (mounting, volume)
- Electrical interface
- Power interface (pulley size, shape)
- Performance specifications, including
- Power output (voltage, amperage, allowable ranges)
- Acceptable range of revolutions per minute
- Thermal environment/heat dissipation
- Repair instructions
- Remove and replace directions
- Test directions
- Description of tools/test equipment required
If the manufacturer provides this information to the public at little or no cost, the manufacturer can be said to follow an OSA approach to the design of the electrical system (i.e., component 220.127.116.11)—at least insofar as the alternator is concerned. This approach enables the owner (or a third party) to use publicly available data to identify and install a suitable replacement component but does not necessarily provide the information required to disassemble the alternator itself and perform repairs.
Option 3: A possible third approach is for either the owner or a third party to remove and repair or rebuild the alternator. This maintenance strategy would involve troubleshooting the alternator to determine what is faulty, disassembling it, replacing the defective part(s), reassembling, testing and reinstalling it in the vehicle. For this strategy to work, the technician would need to be able to buy appropriate parts from either the vehicle manufacturer or a parts supplier and have access to more extensive information, including:
All information required for Options 1 and 2
“Form, fit and function” (FFF) data (including performance specifications) for the internal parts of the alternator, such as
- Electrical parts such as diodes, boards, brushes and connectors
- Mechanical parts such as bearings, rotors and stators
- Alternator repair procedure details
- Problem diagnosis
- Disassembly/reassembly directions
- Test directions
- Description of tools/test equipment required
In other words, the technician would need detailed information about the internal workings of the alternator in order to make the needed repairs. If the manufacturer provides this information to the public at little or no cost, the manufacturer can be said to follow an OSA approach to the design of the alternator itself (i.e., component 18.104.22.168.6).
Table 1 provides a comparison of the information and parts requirements for the basic options discussed thus far. The question of how to repair a faulty alternator is only one of many that buyers must consider when deciding how they plan to maintain and repair their purchase. In each case, the set of options available to buyers (and their respective costs and benefits) will depend, in part, on the extent to which manufacturers have adopted an OSA approach to vehicle design and sales practices.
Table 1. Information and Parts Requirements for Car Maintenance Strategies
Lessons for DoD Program Offices
Within DoD, a program’s life cycle sustainment strategy identifies the maintenance option(s) chosen both for the system as a whole and for its separate subsystems. Although the details differ, the choice of a sustainment strategy for a DoD program follows the same basic logic as the choice of maintenance strategy for the family car. In both cases, success depends on possession of and licenses for essential technical data and/or software. For DoD programs, the availability of this information will depend upon the specific technical data and software actually delivered, the terms of contracts negotiated between a given program office and its various suppliers, and the general legal framework provided by the United States Code and the Code of Federal Regulations (C.F.R.). For a more complete description of the rights to which the federal government is entitled to, see Section 22.214.171.124.5 of the Defense Acquisition Guidebook (https://dag.dau.mil).
Although the details differ, the choice of a sustainment strategy for a DoD program follows the same basic logic as the choice of maintenance strategy for the family car.
The task of choosing a maintenance strategy for a military vehicle can be used to illustrate the common elements of the two planning problems. As with the privately owned automobile, there are three basic options to consider for a specific component such as an alternator:
Option 1: Have the original equipment manufacturer (OEM) provide all maintenance (for major systems, this option is seldom chosen).
Option 2: Treat the vehicle’s alternator as a “Line Replaceable Unit” (LRU), a “black box” component of the electrical system and plan for maintenance, replacement and upgrades at this level.
Option 3: Treat the vehicle’s alternator as a repairable component and plan for access to the spare parts, tools and data needed for removal, repair, installation and testing.
Once again, these three options imply different data and data rights requirements.
Option 1: Even if the OEM provides all maintenance (including repairs and upgrades) over the vehicle’s life cycle, military users will need basic information about vehicle operations and maintenance requirements. Under the Defense Federal Acquisition Regulation Supplement (DFARS), required operation, maintenance, installation, and training (OMIT) data are
delivered with unlimited rights. The government can also specify the standards (military or commercial) that certain systems and/or subsystems must meet.
Option 2: Removal and replacement of LRUs (such as an alternator) can be performed by the OEM, government workforce or third-party contractors:
If system development followed OSA design principles down to an LRU level of detail:
- The government would require FFF data for each LRU as well as FFF data concerning the interface between each LRU and the rest of the vehicle. Under standard DFARS contract clauses, these data would be delivered with unlimited rights. This information is normally incorporated into interface control documents (ICDs) developed by the vehicle designer, whether the design was paid for by the government or by the contractor.
- As in Option 1, the government would have unlimited rights to OMIT data delivered with the vehicle.
To enable this approach, the government must define the LRUs for the vehicle in the request for proposal (RFP) and require delivery of FFF data (ICDs) for each LRU.
Usefulness of this strategy also will depend on existence of competing LRU suppliers and qualified support contractors.
Unless additional data are delivered, government personnel and support contractors (other than the OEM) do not have sufficient information to repair the LRUs.
Option 3: The life-cycle sustainment and acquisition strategies provide for the repair or upgrade of the individual LRUs, plus the maintenance options discussed in Options 1 and 2.
This would be required of an architecture that is open down to the individual part level.
The government must require delivery of technical data for each part that could be repaired or replaced.
If the government paid for the development of the vehicle, the government would be entitled to unlimited rights for all data delivered under the contract. If the contractor developed, at its expense, some or all of the vehicle, it has the option of asserting limited rights for the data associated with the portion it developed outside the government contract or of asserting restricted rights for software developed exclusively at private expense. The contractor must clearly segregate the data pertaining to the exclusively privately funded development from that associated with the government-funded effort.
In addition, the system’s acquisition strategy may include the plans to upgrade the system in the future to provide additional capabilities and address new requirements. The ability to incorporate new or improved technology is frequently part of the acquisition strategy. Using our alternator example, if industry developed new, low-friction bearings for the alternator (thereby reducing fuel consumption), how would the PM desire to take advantage of this new technology? The choice—buy new alternators or buy new bearings and rebuild the existing alternators with government assets—will determine what technical data are required to be delivered to enable the desired upgrade approach.
The PM may elect to treat some components as consumables, as nongovernment repaired LRUs, or components that will not be upgraded or modified, while other components of the system are considered “repairable” or able to be modified by the government or support contractors. Once this determination is made by the PM and the PM’s integrated product team members, the technical data and software delivery requirements can be determined. It is not sufficient to simply require the delivery of a general Technical Data Package (TDP), as this does not necessarily contain the technical data and software that will be required for the sustainment strategy chosen. (MIL-STD [Military Standard] 31000A provides a definition of the contents of a TDP.)
To implement an open systems architecture, the PM—together with the systems engineer(s)—must incorporate several different (and sometimes competing) requirements in the analysis of alternative systems architectures:
- Life-cycle sustainment strategy
- Acquisition strategy (including plans for upgrading and adding capabilities)
- Existing military and commercial standards
- The level at which the government wants to implement an OSA (may be different for different components of the system)
Additional information and guidance can be found in the OSA Contract Guidebook, available at the Defense Acquisition University/Acquisition Community Connection website (https://acc.dau.mil/osaguidebook).