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          Complexity is managed via interfaces
Interfaces
         Evolvability is managed via interfaces

         Components are decoupled using interfaces

Disciplined          Systems don’t just happen to be affordable
Systems
Engineering
Process          A disciplined process is required to address affordability over the life cycle
of the project

         Process must balance affordability with performance

Well-defined          Key interfaces are based on widely used, consensus-based commercial
Open Interfaces
standards maintained by recognized standards organizations
Rely on          Acquirer provides performance specs, leaving decisions about how to the
Performance
Specifications developer

         Developer is responsible for selecting the most appropriate standards

Commercial          Commercial investment in innovative technology keeps a viable technology
Leverage
base

         Commercially developed and maintained interface standards are used in

place of government standards where possible
Seek to Improve          Projects have an affordability plan
Affordability

         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
 
Promote use of an open systems
approach during acquisition
 
Define an approach to elicit
open systems requirements
 
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.
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.
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 Open Systems Approach, by definition, involves making
that facilitate an open systemsdecisions about COTS; COTS products have varying life
approach 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 Open Systems Approach is an essential activity for Ensuring
affordability and Interoperability because the use of standards-based
interoperability 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:
[Anderson, Anderson, M. H. and Rebentisch, E., (1998). “Commercial
1998] Practices - Dilemma or Opportunity?” Program Manager 27(2),pp.
16-21, 1998

http://www.dau.mil/pubs/pm/pmpdf98/andersma.pdf
[ARO DoN Acquisition One Source website: Acquisition Topics
Website] -Systems Planning, Research, Development and Engineering
(SPRDE)

http://www.ar.navy.mil/navyaos/acquisition_topics/systems_
planning_
research_development_and_engineering_sprde_/specificati
ons_and_standards
[Bradley, Bradley, Ryan and Wimberly, Gary, “Acquisition Reform of
1996] Existing Contracts: The Secretary of Defense Single Process
Initiative”, Crosstalk, 1996

http://www.stsc.hill.af.mil/crosstalk/1996/09/Acquisit.asp
[CMU/SEI- “Capability Maturity Model Integration (CMMI), Version 1.1 – Continuous
2002-TR- Representation”, Software Engineering Institute, CMU/SEI-2002-TR-011,
March 2002
011]
http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr001.pdf

 
[CMU/SEI- “Capability Maturity Model Integration (CMMI), Version 1.1 – Staged
2002-TR- Representation”, Software Engineering Institute, CMU/SEI-2002-TR-012,
March 2002
012]
http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr002.pdf

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

http://www.acq.osd.mil/dpap/Docs/020405.Regulation.pdf

 
[DSP, 2001] “Frequently Asked Questions”, Version 1.3.1, DSP Web Site, Defense
Standardization Program Office, 2001

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

 
[GOVNEWS “Joint Technical Architecture Standards and Related Publications”,
LTR, 2003a] Government Newsletter, Issue 2, Vol. 2, 2003

http://global.ihs.com/news/gov1_4.html
[GOVNEWS “New JTA Referenced Standards Collection Compliance
LTR, 2003b] Made Easier”, Government Newsletter, Issue 2, Vol. 2, 2003

http://global.ihs.com/news/gov1_3.html

 
[Hanratty, Hanratty, Col. J. Michael; Lightsey, Robert H.; Larson, Arvid G.,
1999] “Open Systems and the Systems Engineering Process”,
Acquisition Quarterly Review, 1999

http://www.acq.osd.mil/osjtf/library/library_sep.html
[Hanratty, Hanratty, Col. J. Michael; Ph.D., Dixon; Dr. James H., Banning;
2000] Charles K., “Product Line Approach to Weapon Systems
Acquisition”, Crosstalk, Nov. 2000

http://www.stsc.hill.af.mil/crosstalk/2000/11/hanratty.html
IEEE, 1995] “DoD Military Standards Initiative-- Implications for SDOs?”,
IEEE Standards Bearer, April 1995, Vol. 9, No. 2
http://standards.ieee.org/reading/ieee/SB/Apr95/dod.html
[INTERIM, “Interim Defense Acquisition Guidebook”, 30 October 2002
2002]
(Replaces DoD 5000.2-R, canceled 30 October 2002)

 
[Kowalski, Kowalski, Norman W., “Key engineering Management Practices
1995] to Achieving an Open System in a DoD Environment”, 1995

http://www.acq.osd.mil/osjtf/html/library_kowalski.html
[Logan, “OSCAR IPT/Bold Stroke, Open Systems Lessons Learned”,
2000] Prepared by the OSCAR IPT for Glenn T. Logan - Lt Col USAF,
Open Systems Joint Task Force, 2/26/2000

http://www.acq.osd.mil/osjtf/pdf/oslllogan_reva.pdf
[OSJTF, “An Open Systems Approach to Weapon System Acquisition”,
2001] Working Draft Version 1.0, Open Systems Guide, OSJTF, 2001

http://www.acq.osd.mil/osjtf/pdf/PMG.pdf
[OSJTF, Overview - Open Systems Approach
2003]
http://www.acq.osd.mil/osjtf/mspowerpoint/how01.ppt
[Perry, Perry, Dr. William J., “Specifications and Standards – A New Way
1994] of Doing Business”, Memorandum from Secretary of Defense,
1994

http://www.dsp.dla.mil/policy/perry.html
 [Roark, Roark, Chuck, and Kiczuk, Bill, “Open Systems – A Process for
1996] Achieving Affordability”, May 1996

http://www.acq.osd.mil/osjtf/html/roark.html
[SCW, “Report of the Software Collaborators’ Workshop”, Sponsored by
1999] the DUSD (Science and Technology), October 1999
 [Turner, Turner, R.G., “Implementation of Best Practices in U.S.
2002] Department of Defense Software-Intensive System Acquisitions”,
Ph.D. Dissertation, George Washington University, 31 January
2002

 
 

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

Affordability Affordability of Software-Intensive Systems aims to provide the best

value among available solution alternatives within life cycle budget and
schedule constraints through reliance on software acquisition,
management, and development practices/processes to maximize both
functional and quality properties for a technology.

-    AFRL Affordability IPT

Airlie Council Refers to a group of experts convened by the Navy’s Software Program
Manager’s Network (SPMN) in 1995 who established/identified nine best
practices.  These practices have been augmented with other practices since
1995, and in current literature are referenced as the original Airlie best
practices.
Best Practice A documented practice aimed at lowering an identified risk in a system
acquisition and is required or recommended by a bona fide DoD, industry,
or academic source.

Methodologies and tools that consistently yield productivity and quality

results when implemented in a minimum of 10 organizations and 50
software projects, and is asserted by those who use it to have been
beneficial in all or most of the projects.
Closed Interfaces Privately controlled system/subsystem boundary descriptions that are not
disclosed to the public or are unique to a single supplier.
Commercial The techniques, methods, customs, processes, rules, guides, and standards
Practices normally used by business but either applied differently or not used by the
Federal Government (Defense Systems Management College, 1998).
COTS Commercial-Off-The-Shelf
De Facto A standard that is widely accepted and used, but lacks formal approval by
Standard a recognized standards organization (FED-STD-1037C).
F3I Form, Fit & Function, Interface (F3I): As defined in Document EIA
Standard IS-649-Draft-1997.  Form:  The shape, size, dimensions, and
other physical measurable parameters that uniquely characterize a
product.  For software, form denotes the language and media.  Fit:  The
ability of a product to interface or interconnect with an integral part of
another product.  Function:  The actions that a product is designed to
perform.  Interface:  The performance, functional, and physical attributes
required to exist at a common boundary.
Federal These cover materials, products or services used by more than two federal
Specifications agencies.  They are issued by the General Services Administration (GSA)
and must be used by all federal agencies.  Federal specifications can be
obtained at http://apps.fss.gsa.gov/pub/fedspecs/ or from your local
Procurement Technical Assistance Center (PTAC).
IEWCS Intelligence Electronic Warfare Common Sensor
Interface The functional and physical characteristics required to exist at a common
boundary or connection between systems or items (DoD 4120.214-M).
Interface A standard that specifies the physical, functional, and operational
Standard relationships between various elements (hardware and software), to permit
interchangeability, interconnection, compatibility and/or communications.
Interoperability The ability of systems, units, or forces to provide data, information,
materiel, and services to (and accept the same from) other systems, units,
or forces, and to use the data, information, materiel, and services so
exchanged to enable them to operate effectively together (DoD 5000.1).
IPPD Integrated Product & Process Development
IPT Integrated Product Team
Key Interface An interface for which the preferred implementation uses an open
standard to design the system for affordable change and enhance
commonality and reuse of components.
MAIS Major Automated Information Systems
MDAPS Major Defense Acquisition Programs
Military These cover items or services that are intrinsically military in character, or
Specifications commercial items modified to meet special requirements of the military. 
ASSIST-Quick Search provides direct access to nearly 100,000 full text DoD
Specifications and Standards available in the DoD master repository - ASSIST! 
ASSIST-Quick Search does not require an account and password and makes
documents available to the public free of charge. 
http://assist.daps.dla.mil/quicksearch/

They are also distributed in hard copy form by Naval Publications and
Forms Center (NPFC), located in Philadelphia, PA (PHONE (215) 697-
3321).  NPFC stocks and issues Department of Defense printed and digital
matter without charge to federal agencies and the general public. 
Documents distributed by NPFC include military specifications and
standards, federal specifications and standards, Qualified Product Lists
(QPLs), Military Handbooks, and Departmental Documents.  Here again,
many PTACs offer military specifications and standards as a part of their
services to their clients.
Model A simplification of reality that provides a complete description of a
system.
Modular Design Characterized by the following:

         Functionally partitioned into discrete scalable, reusable modules

consisting of isolated, self-contained functional elements

         Rigorous use of disciplined definition of modular interfaces, to

include object oriented descriptions of module functionality

         Designed for ease of change to achieve technology transparency and,

to the extent possible, makes use of commonly used industry standards
for key interfaces
NDI Non-Developmental Item
NGS Non-Government Standards
Open An architecture that employs open standards for key interfaces within a
Architecture system.
Open Source A method and philosophy for software licensing and distribution designed
to encourage use and improvement of software written by volunteers by
ensuring that anyone can copy the source code and modify it freely.  Free
means free of distribution restrictions, not necessarily free of charge. See
the Open Source Initiative for further details.

 http://www.opensource.org/docs/definition_plain.php

The public release of source code by a commercial organization for others

to use or enhance as they see fit.
Open Standards Standards that are widely used, consensus-based, and published and
maintained by recognized industry standards organizations.
Open Systems Computer systems that provide either interoperability, portability, or
freedom from proprietary standards, depending on your perspective.  For
years, the term was applied loosely to the many flavors of Unix.
Open Systems An integrated business and technical strategy that employs a modular
Approach (OSA) design and, where appropriate, defines key interfaces using widely
supported, consensus-based standards that are published and maintained
by a recognized industry standards organization.
OSCAR Open Systems Core Avionics Replacement Program
OSJTF Open Systems Joint Task Force
PBBE Performance-Based Business Environment
Performance A performance specification states requirements in terms of the required
Specification 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.
PM Program Manager
Proprietary A standard that is exclusively owned by an individual or organization, the
Standard use of which generally would require a license and/or fee.
PTAC Procurement Technical Assistance Center
 QFD Quality Function Deployment
SCW Software Collaborators Workshop
SDOs Standards Developing Organizations
SLOC Source Lines Of Code
SPMN Software Program Managers Network
Standard A document that establishes engineering and technical requirements for
products, processes, procedures, practices, and methods that have been
decreed by authority or adopted by consensus (EIA-632, Annex A).
Systems The interdisciplinary approach governing the total technical and
Engineering (SE) managerial effort required to transform a set of customer needs,
expectations, and constraints into a product solution, and support that
solution throughout the product’s life.
TDP Technical Data Package
TOC Total Ownership Costs

 
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]