Approved for Public Release; Distribution Unlimited. Case Number 15-2842
©2015-2018 The MITRE Corporation. ALL RIGHTS RESERVED
DevOps for Federal Acquisition
Rick Cagle
The MITRE Corporation
Bedford MA, USA
rcagle@mitre.org
Tim Rice
The MITRE Corporation
Bedford MA, USA
tbrice@mitre.org
Michael Kristan
The MITRE Corporation
Bedford MA, USA
mkristan@mitre.org
Abstract— Federal acquisitions are principally grounded in a
traditional system development model with divisions of labor
among development, independent test, and operations
organizations. These silos are reinforced by the structure of
current acquisition artifacts such as standard Contract Data
Requirements List (CDRL) items and Data Item Definitions
(DIDs).
By contrast, in a DevOps ecosystem, development, test, and
operations simply share responsibility for delivery of functioning
services or products. Just as the movement toward a more Agile
Development model within Federal acquisitions continues to
struggle with adapting CDRL and DID artifacts, we anticipate
programs seeking to inject DevOps approaches and proficiencies
will have analogous challenges.
DevOps will continue to mature as a systems concept, and the
government will be looking to adopt and adapt DevOps. This
paper explores initial concepts of how a Request for Proposal
(RFP) may be constructed to procure a system with DevOps
principles, and proposes corresponding tailoring of acquisition
artifacts.
Keywords—DevOps; Acquisition; CDRL, DID, RFP
I. INTRODUCTION
The process by which the government purchases products
and services is referred to as Federal Acquisition. To guide
evolving acquisition legislation, Congress applied
administrative structure in the form of the Federal Acquisition
Regulations (FAR), defining the procurement framework and
mechanisms, and including contract-specific terminology. In
many cases, individual agencies supplemented this core
language with additional FAR Supplements to manage their
unique regulatory requirements, which appear within the Code
of Federal Regulations (CFR) volumes of the respective
agencies.
Acquisitions have long followed a commonly referenced
model for systems development consisting of divisions of labor
among development, independent test, and operations
organizations corresponding to like phases from the acquisition
process. Conceptually, FAR guidance acknowledges phases that
address Pre-Systems Acquisition, Systems Acquisition, and
Sustainment. Such divisions of focus are reinforced by the
structure of current artifacts of the process.
For example, a standard Contract Data Requirements List
(CDRL) details items to be delivered as part of the acquisition.
These items typically support design, development, testing,
transition, and sustainment of the core contract deliverable, such
as the software system or component. The CDRL is the standard
artifact for identifying potential data requirements in a
solicitation, and deliverable data requirements in a contract. It
identifies products to be formally delivered by the supplier, and
provides a standardized method of clearly and unambiguously
delineating the minimum essential data needs.
Data requirements, format, delivery, and content can be
further specified in sufficient detail to clearly identify delivery
of the product of a sufficient quality to be accepted by the
government and thereby satisfy the salient term in the Statement
of Work (SOW). These Data Item Definitions (DIDs) may
inherit from a default template, which can be found in the
ASSIST Online Database [1], and is often further tailored to the
needs of the specific acquisition.
II. PROBLEM DEFINITION AND ITS IMPORTANCE
A. DevOps
By contrast, in a DevOps ecosystem, development, test, and
operations simply share responsibility for delivery of
functioning services or products. The general principle of
DevOps is based on the convergence of software development,
quality assurance, and IT operations communities. Boundaries
between phases are blurred in favor of stimulating collaborative
responsibilities for delivery of product. Common components in
a DevOps ecosystem include configuration management and
infrastructure-as-code, virtual or cloud infrastructure, rich
feedback loops, and process automation that drives continuous
integration, packaging, auditing, and monitoring [2] [3]. An
outcome of DevOps is a continuous delivery pipeline such that
code changes can be automatically built, tested, and deployed
into production using a well-defined, repeatable process [4].
