SOFTWARE ACQUISITION GOLD PRACTICE

COMMERCIAL SPECIFICATIONS/OPEN STANDARDS

FOCUS AREA:   REQUIREMENTS – Systems Engineering

Definition and Summary:  Taking an open systems approach (using commercial specs and standards) to systems development.  Military specs and standards are replaced by performance specifications; the burden of selecting the specifications and standards lies with the developer, not the acquirer.

 

The Open Systems Approach represents a paradigm shift in system development focus to a design methodology that addresses affordability as well as performance.  Implementation requires different skills and a different technical knowledge base than traditional design.  It requires adherence to a systems engineering process that addresses affordability and performance goals at the architecture level.  Performance goals relating to the functional capability of the subject system are equally important, but are not addressed in detail here because they are already the focus of development and have been for years.  The Open Systems Approach is about continuing to provide required functional capabilities, but making them affordable.

 

Successful implementation of the practice of using a Commercial Specifications and Standards/Open Systems Approach can result in:

 

• Improving the affordability of systems over their life cycle

• Greater adaptability to evolving requirements and threats
• Mitigating the risk associated with technology obsolescence
• Reducing development cycle time
• Achieving higher levels of performance

 

DESCRIPTION OF THE PRACTICE:

 

SUMMARY DESCRIPTION

The Open Systems Approach, as represented by this Commercial Specifications/Open Standards practice, represents a paradigm shift in system development focus to a design methodology that addresses affordability as well as performance.  Implementation requires different skills and a different technical knowledge base than traditional design.  It requires adherence to a systems engineering process that addresses affordability and performance goals at the architecture level.  The figure below identifies the essential activities of Open Systems Approach as it relates to affordability.  Performance goals relating to the functional capability of the subject system are equally important, but are not addressed in detail here because they are already the focus of development and have been for years.  The Open Systems Approach is about continuing to provide required functional capabilities, but making them affordable.

The Open Systems Process for Achieving Affordability

 

Some key open systems principles are:

1.       Build an architecture using a disciplined systems engineering process

2.       Identify and define interfaces early in the development cycle, but delay implementation as long as practical

3.       Define criteria for interface choices: at a minimum measure openness, maturity, and applicability

4.       Consider system evolution (and how it might impact an interface decision)

5.       Identify firewall interfaces to isolate the impact that changes in one component have on another, and to enable seamless evolution

6.       Consider how the interfaces will enable reuse, potentially reducing development and production costs

7.       Define domain specific catalogs of preferred standards

8.       Manage interfaces to reduce the risks involved in using COTS

9.       Define the open system architecture-first – insert COTS where appropriate.  (COTS does not equal OPEN; non-open COTS leads to vendor dependencies)

10.   Employ a “commercial check” of COTS prior to finalizing implementation decisions

11.   Perform market analysis to assess the future support for a candidate interface standard

12.   Build strategic supplier relationships to ensure support for maintenance and integration of COTS

13.   Ensure product compliance to standards for both COTS and custom products.  Tie tests for compliance to the selection process.  Ensure product certification.

14.   Use innovative approaches during upfront engineering to ensure that systems will meet performance and environmental requirements using commercial components and products

 

DETAILED DESCRIPTION

Due to the scope and breadth of this practice, it makes sense to describe it from the long accepted framework of questions as follows:

Why?  Why would this practice be implemented?  What are the key motivating factors?  What problems does this practice try to solve?

What?  What exactly is the practice?  What are its key elements?  What are its guiding principles?

Who?  Who needs to be involved?  Who are the stakeholders and what are their respective responsibilities?

Where?  At what levels within and/or across organizations/programs does this practice make sense?  Where are the boundaries, or what criteria would serve as a basis for defining its boundaries?

When?  When should this practice be implemented relative to the life cycle of a project or program?

How?  How does the practice get implemented?  How do you make it happen?  What are the essential activities?  What are some of the lessons learned?

Why?

Why would this practice be implemented?  What are the key motivating factors?  What problems does this practice try to solve?

There are a multitude of reasons for implementing this practice as indicated in the many references from the Interim Defense Acquisition Guidebook cited above (see C5.2.3.5.5.2).  In essence, the Open Systems Approach (OSA) is viewed as the key to integrating the initiatives that impact affordability with those that impact performance in order to achieve/sustain the appropriate balance of those broad goals (See Figure 1). Open Systems Approach addresses a rapidly changing technical environment characterized by a need to address: §         Complex systems §         Faster delivery of increasing capability §         Evolving requirements and capabilities §         Maintaining a technology base for the system life cycle §         Increasing demand for interoperability

 

What?

What exactly is the open systems approach?  What are the essential elements of the practice?  What are its guiding principles?

Let’s examine the key phrases from the Open Systems Approach definition provided by the Open Systems Joint Task Force:

 …integrated business AND technical strategy …  a strategy for building software-intensive systems that addresses both business and technical goals (issues of affordability and performance) from an integrated perspective in order to achieve a balance that will ensure needs of the warfighter are met while sustaining/improving affordability.

… employs a modular design …  Modular design is the key to achieving flexibility, enabling technology insertion and evolvability, and ultimately having a positive impact on affordability over the life cycle of the system.  Modular design, in this context, also implies “independence”.

Figure 2(a) illustrates the structure of a typical system under the traditional design approach of the ‘80s and early ‘90s, in which the modules were tightly coupled with the subsystems they supported.  The connectivity of modules to subsystems, and subsystems to systems, was generally customized and, therefore, unique to each system.  This structure offered some degree of modularity in that a subsystem (or module) could be added or removed without having to redesign the entire system – provided it originated from the same development environment (language).  Some benefits were also derived from reusing “common” modules (functions) typically provided with the development language library in multiple systems/subsystems.  However, each new system had to be built from “scratch” (even though ideas were reused) and required significant resources for its sustainment over the life cycle.  As new technology emerges, the cost of sustaining these “legacy” systems goes up, making them less affordable as time passes.

With modular design implied by Open Systems Approach (see Figure 2(b)) individual components, which are the building blocks of systems, are independent entities that “plug & play” together, and can be updated or replaced as needed quickly, without requiring a redesign of the entire system.  Components need not originate from the same development environment, but must conform to the required interface standard.  Modularity, with implied interface standards, is typically addressed at the architecture level in order to focus on the most important problems of communication, connectivity, and evolving requirements early in the life cycle.  Addressing modularity through architecture typically ensures that a system will be scalable, evolvable, and flexible, and, therefore, longer lasting at less cost.

… defines key interfaces …  As illustrated in Figure 2(b), interfaces (based on standards) are the focus of the Open Systems Approach.  All systems have structures that allow their subsystems and components to work together to provide the required functionality, but use of standards-based interfaces (versus proprietary or custom designed elements) permit greater interchangeability, interconnection, compatibility and/or communications within a system, as well as across systems, and facilitate technology insertion over the system life cycle.  Well-defined “open interfaces” are critical to the success of the Open Systems Approach.  The components and sub-systems are independent entities that can be applied to various systems within a domain without re-design.

Which interfaces are the most important?  Identifying the “critical” or key interfaces within a system is essentially making an educated guess about which components and subsystems might/should be leveraged for other capabilities in the future.  Part of the decision involves assessing the long term value derived from including an open interface.  This is sometimes very difficult because there is no immediate value to the current project – but an interface may be necessary to ensure the interoperability of future systems in the domain.

… using widely supported, consensus-based standards …  that are published and maintained by a recognized industrial standards organization.  How do we determine what interface standards to use?  Historically the government has developed and maintained its own set of standards to specify the physical, functional, and operational relationships between various elements.  Extensive government resources were required to support the initiative and developers incurred additional costs of complying with both the government standards and the more viable commercial standards.  These factors combined to drive up the cost of sustaining systems across their life cycle.  Under Open Systems Approach, and primarily driven by affordability issues, as well as the need to sustain a commercial technology base to support the demand for increased capability, the government, through acquisition policy, is shifting the responsibility for selecting (and maintaining) standards to the developer community.  In doing this, it expects to reap the benefits of innovative commercial technology, including a stable technology base, at a reduced cost.  Open interfaces are defined as those specifications and standards that are (1) widely used, (2) consensus-based, and (3) published and maintained by a recognized industrial standards organization.  The degree of “openness” that a system has is characterized by the extent to which it uses standards that are mature, widely accepted, and allows for future technology insertion.  The process/activities for selecting the right standards are critical to achieving an open system solution, and that focus represents a significant change in how systems are developed.

Who?

Who needs to be involved in this practice and what are their respective responsibilities?

Open Systems Approach works best with on-going interaction among the following stakeholders operating under the structure of an Integrated Process and Product Development (IPPD) team.  Interaction/participation from recognized standards organizations might enhance the solution space as well.

§         Program Manager – establishes the necessary communication with other PMs in the domain in order to assess interoperability issues, and opportunities for reuse

§         Domain Experts – provide the operational expertise to help drive requirements definition (including performance requirements)

§         System & SW Architects – help define an architecture solution that addresses the desired degree of openness in meeting the desired performance objectives of the system.  Note: Architects represent highly skilled technical roles with significant design experience.  Project Managers typically do not have the required expertise to fulfill this role.

§         Developer Team – follows a disciplined engineering process that includes participating in specifying requirements, as well as developing the system.  Development includes a well-defined marketing research process that results in knowledge of innovative technology and emerging commercial standards and specifications that may be candidates for the system architecture.

Where?

At what levels within and/or across organizations/programs does this practice make sense?  Where are the boundaries, or what criteria would serve as a basis for defining its boundaries?

To achieve affordability results, open systems issues must be addressed at the architecture level of a domain, or among groups of program managers, or within an Integrated Product Team (IPT) at the program office level or higher.  To begin at the project level and establish an “open systems architecture” in isolation makes no sense.  The value of decision-making regarding interface standards is based on the notion of reuse, compatibility, or interoperability among several systems/programs within a domain.  Although significant knowledge of interface standards is required to implement an open systems approach, it is not a “bottom-up” strategy, because it is not possible to address the affordability issues from that level.  A bottom-up approach typically would weight the scale in favor of performance over affordability.

When?

When should this practice be implemented relative to the life cycle of a project or program?

Open Systems Approach is, by definition, focused on architecture.  Therefore, most of the activities associated with this approach should occur early in the life cycle, during architecting, or during inception and elaboration.  It makes no sense to build a system based on whatever strategy is dominant in the developer organization and then, after-the-fact, try to re-engineer it to be an “open system”.

However, if you are in the middle of a phased development that is not using Open Systems Approach, is it possible to alter the approach in favor of Open Systems Approach?  In some cases, yes!  For example, if you have completed requirements definition and are ready to start design, or to solicit for a developer, it may be possible to re-visit requirements by adding some performance requirements relating to the use of interface standards, and a modular design approach, that would set the stage for open systems development.  The closer you are to actual code development or production, the more difficult it will be to migrate to Open Systems Approach.

The task of migrating legacy systems to open systems is complex. The feasibility of re-engineering a legacy system versus building a new system must be studied.  Keep in mind the key motivators of affordability, as well as performance.

How?

How does the practice get implemented?  How do you make it happen?  What are the essential activities?  What are some of the lessons learned?

Open systems concepts are founded on a set of principles that are used in the development and application of an open systems architecture that, in turn, is defined by open systems interface standards.

Some key open systems principles are:

1.       Build an architecture using a disciplined systems engineering process

2.       Identify and define interfaces early in the development cycle, but delay implementation as long as practical

3.       Define criteria for interface choices: at a minimum measure openness, maturity, and applicability

4.       Consider system evolution (and how it might impact an interface decision)

5.       Identify firewall interfaces to isolate the impact that changes in one component have on another, and to enable seamless evolution

6.       Consider how the interfaces will enable reuse, potentially reducing development and production costs

7.       Define domain specific catalogs of preferred standards

8.       Manage interfaces to reduce the risks involved in using COTS

9.       Define the open system architecture-first – insert COTS where appropriate.  (COTS does not equal OPEN; non-open COTS leads to vendor dependencies)

10.   Employ a “commercial check” of COTS prior to finalizing implementation decisions

11.   Perform market analysis to assess the future support for a candidate interface standard

12.   Build strategic supplier relationships to ensure support for maintenance and integration of COTS

13.   Ensure product compliance to standards for both COTS and custom products.  Tie tests for compliance to the selection process.  Ensure product certification.

14.   Use innovative approaches during upfront engineering to ensure that systems will meet performance and environmental requirements using commercial components and products

 

                   Figure 3:  The Open Systems Process for Achieving Affordability


The Open Systems Approach represents a paradigm shift in system development focus to a design methodology that addresses affordability as well as performance.  Implementation requires different skills and a different technical knowledge base than traditional design.  It requires adherence to a systems engineering process that addresses affordability and performance goals at the architecture level.  Figure 3 identifies the essential activities of Open Systems Approach as it relates to affordability.  Performance goals relating to the functional capability of the subject system are equally important, but are not addressed in detail here because they are already the focus of development and have been for years.  The Open Systems Approach is about continuing to provide required functional capabilities, but making them affordable.

 

CHARACTERISTICS OF IMPLEMENTATION:

 

SUMMARY CHARACTERISTICS

 

NO DATA CURRENTLY AVAILABLE

 

ANTICIPATED BENEFITS OF IMPLEMENTATION:

 

Successful implementation of the practice of using Commercial Specifications and Standards/Open Systems Approach can result in:

 

• Improving the affordability of systems over their life cycle by:

o         Allowing programs to leverage commercially funded or developed technology

o         Achieving economies that were previously unrealizable

o         Taking advantage of increased competition

o         Providing a lower cost path for insertion of new technologies in existing platforms

• Greater adaptability to evolving requirements and threats
• Mitigating the risk associated with technology obsolescence

o         Systems supported by a wide range of readily available products

• Reducing development cycle time

o         Faster upgrade of legacy systems with less complexity and cost

o         Development of subsystems and components that are testable

o         Enable application of a “Product Line Approach” to acquisition of weapons systems

·         [Encompasses the assembly line idea, where basic platforms or frameworks are fitted with subsystems or components to form a larger system to deliver a specified capability.  The subsystems and components are designed to specified levels of openness and feature modularity and interchangeable parts.  Some subsystems or components may be common to a variety of weapon platforms and identically interface with each platform.]

• Achieving higher levels of performance

o         Contributes to ensuring interoperability among systems without major modification of existing components

 

DETAILED CHARACTERISTICS

 

Key Characteristics of the Commercial Specifications and Standards/Open Systems Gold Practice

Characteristic	Comments
Focus on Interfaces	§         Complexity is managed via interfaces §         Evolvability is managed via interfaces §         Components are decoupled using interfaces
Disciplined Systems Engineering Process	§         Systems don’t just happen to be affordable §         A disciplined process is required to address affordability over the life cycle of the project §         Process must balance affordability with performance
Well-defined Open Interfaces	§         Key interfaces are based on widely used, consensus-based commercial standards maintained by recognized standards organizations
Rely on Performance Specifications	§         Acquirer provides performance specs, leaving decisions about how to the developer §         Developer is responsible for selecting the most appropriate standards
Commercial Leverage	§         Commercial investment in innovative technology keeps a viable technology base §         Commercially developed and maintained interface standards are used in place of government standards where possible
Seek to Improve Affordability	§         Projects have an affordability plan §         Evidenced by trade-off analysis relating to performance vs. affordability

 

RELATIONSHIPS TO OTHER PRACTICES:

 

The Figure below represents a high-level process architecture for the subject practice, depicting relationships among this practice and the nature of the influences on the practice (describing how other practices might relate to this practice).  These relationship statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices.  A brief description of these influences is included in the table below.

 

Process Architecture for the "Commercial Specifications & Standards/Open Systems" Gold Practice

 

 

Summary of Relationship Factors

INPUTS TO THE PRACTICE
Develop a strategy to support use of an open systems approach	The Planning for Technology Insertion practice parallels the Open Systems Approach with respect to addressing affordability issues.  Open Systems Approach encompasses planning for TI and is, therefore, impacted by the quality of the TI plan.   Integrated Product and Process Development (IPPD) brings together the key stakeholders, ensuring that domain experts, as well as system architects, participate in identifying key open interface candidates and interoperability requirements within a domain that help to determine which components and interfaces are most important.  Developing and Maintaining a Life Cycle Business Case is part of the Open Systems Approach because it addresses the affordability side of the balance scale which, in turn, influences decisions about the design of the system and the degree of “openness” it should have.  Requiring Structured Development Methods is more likely to result in a sound disciplined engineering process being applied to requirements elicitation and to the identification and selection of interfaces.
Promote use of an open systems approach during acquisition	Performance-Based Specifications identify required results and free the developer to make the best decisions about how to achieve those results.  Performance specifications must address all significant performance attributes such as interoperability.  Using Past Performance as part of the criteria for Best Value Awards provides a way to secure knowledgeable, experienced developers who can actually build open systems, and reduces the risk of acquisition failure.
Define an approach to elicit open systems requirements	All three of the practices mentioned below accept the Open Systems Approach tenet of balancing affordability with performance.  Negotiating Trade-Offs is a realistic approach to preserving the necessary balance.  Achieving Agreement on Interfaces is part of the Architecture-First Approach that improves affordability by addressing interfaces at the architecture level where necessary changes can be made with the least impact on cost, and the greatest positive impact on performance.
Identify management activities that facilitate an open systems approach	Open Systems Approach, by definition, involves making decisions about COTS; COTS products have varying life cycles that differ from the cycle of the product under development.  Therefore, there is risk associated with using COTS (and the corresponding technology insertion practices).  Assessing the Risk of Reuse (implied by use of COTS), and Formally Managing Those Risks, is a significant factor of the Open Systems Approach.  The rationale for Open Systems Approach is premised on the recognition that the operational environment of a system undergoes change, and with that comes changes to requirements over the life cycle. Accepting requirements volatility and Managing the Requirements process is essential to achieving the affordability gains purported for the Open Systems Approach.
OUTPUTS FROM THE PRACTICE
Leverage technology to support affordability and interoperability	Open Systems Approach is an essential activity for Ensuring Interoperability because the use of standards-based interfaces provides the structure that enables component reuse across multiple programs and resolves issues with data interchange.  Since Open Systems Approach is based on widely used consensus-based commercial interface standards, it facilitates Leveraging COTS/NDI to achieve affordability gains through innovative COTS integration and Technology Insertion Initiatives.

RESOURCES:        

 

§        Websites

o         Defense Standardization Program Office Web Site – provides access to government and military standards and specifications, and their status.  It also provides guidance on writing performance specifications.

http://www.dsp.dla.mil/

o         Open Systems Joint Task Force Web Site – contains documents describing the open systems approach and guidance for its implementation, as well as active pilot programs and demonstration projects

http://www.acq.osd.mil/osjtf/

§        Tools and Methods

State-of-the-art methods and tools that may be useful in implementing and improving the effectiveness of implementing Open Systems Approach include:

 

• Quality Function Deployment.  Quality Function Deployment (QFD) is one technique for evaluating trade-off scenarios.  It is predicated on gaining an understanding of what the end user really needs and expects.  The QFD methodology allows for tracking/tracing trade-offs through various levels of the project hierarchy, from requirements analysis, through the software development process, to operational and maintenance support.
• Systems Thinking Techniques – as defined by Peter Senge in his book titled The Fifth Discipline.  Systems Thinking approaches the solution space on the premise that the whole is not only greater than the sum of its parts, it is also fundamentally different than the sum of its parts.  This is in contrast to the more traditional linear functional decomposition method.  It is applied to problems that are assumed to be complex (multivariate, with multiple linkages and feedback loops), adaptive (able to respond to an environment of constant change without either stagnating or dissolving) and non-linear.

 

Open Systems – Joint Task Force Web Site/ Tools and Guides/ - provides several documents addressing specific aspects of implementing an open systems approach. 

http://www.acq.osd.mil/osjtf/implement/implement_tools.html

 

Turbo SpecRight  - an online tool to assist those who develop, or review, performance specifications ... co-sponsored by the Defense Standardization Program Office and the Navy Acquisition Reform Office.  http://www.ar.navy.mil/navyaos/content/view/full/223

 

JTA Referenced Standards Collection  - an electronic compilation of all versions of the JTA document and quick-link to full text of most of the standards it specifies.  http://global.ihs.com/news/gov1_4.html

 

ASSIST ON-LINE - a robust, comprehensive web site providing access to current information associated with military and federal specifications and standards in the management of the Defense Standardization Program (DSP).  It is the official source of DoD specifications and standards.  It can also be used to find out about standards that have been canceled.  http://assist.daps.dla.mil/online/start/

 

§        Experts/Contact Points

Norman W. Kowalski, a Computer Scientist at the Naval Undersea Warfare Center (NUWC) Division Newport, Newport, Rhode Island.  [See Kowalski bio]

Phone: 401-832-1298

Email: kowalskinw@csd.npt.nuwc.navy.mil

 

Experts from the Open Systems Joint Task Force Operations

Lt. Col Glen Logan, OSD-ATL

Phone: (703) 602-0851

Email: Glen.Logan@osd.mil

Duane Hardy, OSD-ATL

Phone: (703) 602-0851

Email: Dwayne.Hardy@osd.mil

Dr. Cyrus Azani, OSD-ATL

Phone: (703) 602-0851

Email: cyrus.azani@osd.mil

 

Open Systems Joint Task Force Web Site – identifies active pilot programs and demonstration projects, and has a library of downloadable documents describing various implementations of the Open Systems Approach.

http://www.acq.osd.mil/osjtf/

 

§        Training Opportunities:

o         OSJTF Training:  Tutorials, courses, and related DAU courses are listed.

http://www.acq.osd.mil/osjtf/how_to_do_os/training/index.html

 

Specific relevant courses include:

·         Open Systems Engineering:  A downloadable PowerPoint presentation

http://www.acq.osd.mil/osjtf/mspowerpoint/apmc_en_mgmt_feb_2000.ppt

• The Open Systems Approach And Acquisition Management:  A downloadable PowerPoint presentation

 http://www.acq.osd.mil/osjtf/mspowerpoint/apmc_prmgmt_mar_2000.ppt

• Open Systems for Executives:  An overview of open systems principles and major weapon system procurements (in downloadable PowerPoint units)

http://www.acq.osd.mil/osjtf/how_to_do_os/training/osexec/index.html

• Open Systems Acquisition of Weapons Systems:  A 3-day workshop designed to give participants practical skills for using Open Systems concepts in defense weapon systems programs

http://institute.brtrc.com/open.htm

Slides relating to the content for this course are available at the following URL:  http://www.acq.osd.mil/osjtf/html/course.htm

 

o         DSPO Training:  SD-17 Making Standardization Decisions – A course designed to help engineers, logisticians, and other technical and acquisition personnel decide when — and when not — to standardize items and systems.  Call the Document Automation & Printing Service at (215) 697-2179 and ask for a free copy of the SD-17 CD or download a copy from the SD-17 page. <http://www.dsp.dla.mil/ipt/af/msd.htm>

 

o         American National Standards Institute (ANSI) Portal to On-Line Learning:   A basic orientation to standards for students, faculty, new employees or new committee members, and for non-standard professionals such as engineers, technologists, government and corporate management staff.  Go to www.standardslearn.org for more information.

 

o         Defense Acquisition University (DAU) Standardization Training Courses

 

These courses do not address Open Systems Approach principles in general but they do address specific activities/skills that are used in an Open Systems Approach implementation.

·         PQM 103, "Defense Specification Management" http://www.dau.mil/catalog/Chapter%203.pdf

·         PQM 104, "Specification Selection and Application" http://www.dau.mil/catalog/Chapter%203.pdf

·         PQM 202, "Commercial and Non-developmental Item Acquisition" http://www.dau.mil/catalog/Chapter%203.pdf

·         PQM 203, "Preparation of Commercial Item Descriptions" http://www.dau.mil/catalog/Chapter%203.pdf

·         PQM 212, "Market Research" http://www.dau.mil/catalog/Chapter%203.pdf

 

§        Bibliography:

 

 

APPENDICES

DEFINITIONS:

 

The practice of taking an open systems approach (premised on using commercial specifications and standards) to systems development and sustainment.  Military specs and standards are replaced by performance specifications where possible and the burden of selecting the appropriate specifications and standards (to meet the performance specification) lies with the developer, rather than with the acquirer.

Related Definitions:

[Author’s Note:  The Open Systems Approach is NOT THE SAME as the Open Source Initiative (OSI), although an Open Systems Approach may use open source material in its solution.  See Glossary].

An Open Systems Approach (OSA) defines key systems interfaces by widely used, consensus-based interface standards to leverage commercial products and practices in order to field superior war fighting capability more quickly and affordably.  An Open Systems Approach mitigates technology obsolescence risk over the service life of the weapons systems by achieving multiple sources of supply and technology insertion.  [Software Collaborators Workshop (SCW), 1999]

An Open Systems Approach is an integrated business and technical strategy that employs a modular design and, where appropriate, defines key interfaces using widely supported, consensus-based standards that are published and maintained by a recognized industrial standards organization.  [Open Systems Joint Task Force (OSJTF), 2001]

A performance specification states requirements in terms of the required results with criteria for verifying compliance, but without stating the methods for achieving the required results.  A performance specification defines the functional requirements for the item, the environment in which it must operate, and interface and interchangeability characteristics.  [NAVY Acquisition Reform Office (ARO) Website]

SOURCES (Origins of the Practice):

 

NONE INDICATED

RECOMMENDING SOURCES:

 

§         William J. Perry, “Specifications and Standards – a New Way of Doing Business”, Memorandum to Defense Secretaries, 29 June 1994

“I have repeatedly stated that moving to greater use of performance and commercial specifications and standards is one of the most important actions that DoD must take to ensure we are able to meet our military, economic, and policy objectives in the future.” [Perry, 1994]

 

§         DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs”, 5 April 2002 [CANCELLED 30 October 2002]

§         Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

C2.6.6.1.2  Acquisition strategies shall incorporate a performance-based business environment (PBBE) to enable Government customers and contractor suppliers to jointly capitalize on commercial process efficiencies to improve acquisition and sustainment processes.

C2.6.6.3  Applying Best Practices.  “In tailoring an acquisition strategy, the Program Manager (PM) shall address management constraints imposed on the contractor(s).  PMs shall avoid imposing Government-unique restrictions that significantly increase industry compliance costs or unnecessarily deter qualified contractors, including non-traditional defense firms, from proposing.  Examples of practices that support the implementation of these policies include …; performance-based specifications …; an open systems approach that emphasizes commercially supported practices, products, performance specifications, and performance-based standards; replacement of Government-unique management and manufacturing systems with common, facility-wide systems; technology insertion for continuous affordability improvement throughout the product life cycle …; Government-Industry partnerships, consistent with contract documents;”

C2.7.1  Open Systems.  “PMs shall apply the open systems approach as an integrated business and technical strategy upon defining user needs.  PMs shall assess the feasibility of using widely supported commercial interface standards in developing systems.  The open systems approach shall be an integral part of the overall acquisition strategy to enable rapid acquisition with demonstrated technology, evolutionary and conventional development, interoperability, life cycle supportability, and incremental system upgradeability without major redesign during initial procurement and re-procurement of systems, subsystems, components, spares, and services, and during post-production support.  It shall enable continued access to cutting edge technologies and products and prevent being locked in to proprietary technology.  PMs shall document their approach for using open systems and include a summary of their approach as part of their overall acquisition strategy.”

C2.8.3.1  Product Support Management Planning.  At a minimum, product support management planning shall address how the program will accomplish the following objectives:  C2.8.3.1.8  Improve product affordability, system reliability, maintainability, and supportability via continuous, dedicated investment in technology refreshment through adoption of performance specifications, commercial standards, non-developmental items  (NDI), and Commercial-Off-The-Shelf (COTS) items where feasible, in both the initial acquisition design phase and in all subsequent modification and re-procurement actions.

C2.9.1.4.2.2  The commercial marketplace widely accepts and supports open interface standards, set by recognized standards organizations.  These standards support interoperability, portability, scalability, and technology insertion.  When selecting commercial or non-developmental items, the PM shall prefer open interface standards and commercial item descriptions.  If acquiring products with closed interfaces, the PM shall conduct a business case analysis to justify acceptance of the associated economic impacts on Total Ownership Costs (TOC) and risks to technology insertion and maturation over the service life of the system.

C5.2.3.5.5.1  Open Systems Design.  “PMs shall use a modular, standards-based architecture in the design of systems.  They shall identify key interfaces and define the system level (system-of-systems, system, subsystem, or component) at and above which these interfaces use various types of standards.  Preference shall be given to the use of open interface standards first, then to de facto interface standards, and finally to Government and proprietary interface standards.  PMs shall report on their progress using open standards for key interfaces at both Milestones B and C.”

C5.2.3.5.5.2  PMs shall use an open systems approach to achieve the following objectives:

§         To adapt to evolving requirements and threats

§         To accelerate transition from science and technology into acquisition and deployment

§         To enhance modularity and facilitate systems integration

§         To leverage commercial investment in new technologies and products

§         To reduce the development cycle time and total life cycle cost

§         To ensure the system is fully interoperable with all systems with which it must interface, without major modification of existing components

§         To achieve commonality and reuse of components among systems

§         To provide users the ability to quickly and affordably interconnect and assemble existing platforms, systems, subsystems, and components, as needed

§         To maintain continued access to cutting edge technologies and products from multiple suppliers during initial procurement, re-procurement, and post-production support

§         To mitigate the risks associated with technology obsolescence, being locked into proprietary technology, and reliance on a single source of supply over the life of a system

§         To conduct business case analyses to justify decisions to enhance life cycle supportability and continuously improve product affordability through technology insertion during initial procurement, re-procurement, and post-production support

§         To facilitate modular contracting

 

C5.3.2  Performance Specifications.  The Department shall use performance specifications (i.e., DoD performance specifications, commercial item descriptions, and performance-based non-government standards) when purchasing new systems, major modifications, upgrades to current systems, and commercial and non-developmental items for programs in all acquisition categories.  The Department shall emphasize conversion to performance specifications for re-procurements of existing systems at the subsystems level, and for components, spares, and services, where supported by a business case analysis, for programs in all acquisition categories.

 

GLOSSARY

 

 

CASE STUDIES FROM THE LITERATURE:

 

Product Line Approach to Weapon Systems

 

This article, written by Col. J. Michael Hanratty, Ph.D., Open Systems Joint Task Force, appeared in the November 2000 issue of Crosstalk.  He describes the product line approach and its reliance on commercial standards.  Product lines are defined as groups of products sharing a common, managed set of features that satisfy specific needs of a selected market.  They take advantage of commonality, and incorporate the open systems strategy.  The article does an excellent job of explaining the open system strategy and goes on to cite several examples of how this strategy has been successfully implemented to result in major reduction in Total Ownership Cost over time.  He cites the Army’s Project Manager Signals Warfare program that combined six outdated programs into a single program, the Intelligence and Electronic Warfare Common Sensor (IEWCS), in which common modules could be deployed from four different platforms, resulting in a life cycle cost savings of $845 million.

-    [Hanratty, 2000]

Commercial Practices: Dilemma or Opportunity?

This study collected data from 23 of 37 Defense Acquisition programs solicited for information relating to the use of commercial practices and results attributable to that use.  The study revealed that 8 commercial practices were prevalent, including use of performance specifications, commercial specifications & standards, and COTS/NDI use.  The most frequently used (most prevalent) practices were “Commercial Specs & Stds”, and “Performance Specifications”.  Their use resulted in direct program savings totaling almost $4 billion (an overall average savings of 4.3 % per program).  The most significant results related to use of COTS/NDI (55.9% overall schedule reductions, 21.6% cost reductions).  The study also noted improvements to quality of workmanship and product performance.

-    [Anderson, 1998]

OSCAR IPT/Bold Stroke: Open Systems Lessons Learned

Bold Stroke is an initiative in the Boeing Corporation to extend advantages of the Open Systems Core Avionics Replacement (OSCAR) program to a fleet of aircraft.  The OSCAR program objective is to modernize the AV-8B (Harrier) aircraft to make it more operationally viable through the year 2023.

The program focused on specifying functional/performance requirements versus “How To”, and using COTS where appropriate.  It found that, in reality, it is extremely difficult to prevent engineers from diving down into too much detail.  They realized they needed to get a better handle on high-level performance requirements.  They determined that it was not feasible to achieve precise requirements traceability.  They achieved a significant software development affordability improvement (defined in terms of labor hours/source lines of code (SLOC)) attributable to reuse, COTS tools, change containment, desktop testing, and use of high order language.

- [Logan, 2000]