A frustration inherent to working within the defense
industry is the sense that we’re regularly required to design and implement
systems using ideas and technologies long since adopted and vetted by the commercial
sector. Defense information and communications
practitioners often envy their commercial counterparts’ ability to rapidly integrate
new concepts that drive down costs and timelines while improving the quality of
delivered products. Sometimes, however,
this pattern doesn’t hold true. An
emergent, and promising, methodology known as “DevOps” appears to be a
recombination of defense industry methodologies dating from the mid-1990s. What sets DevOps apart from earlier process instantiations
is the emergence of enabling software tools.
These tools not only significantly improve the likelihood of project
success, but also provide a means to automatically integrate certification and
accreditation (C&A) requirements, thus promising significant cost and time
savings to government and defense programs.
I often joke with my commercial sector colleagues that my
corporate title should be “Director of Impenetrable Acronyms, Morphemes and
Portmanteaus.” After all, I come fully
equipped with phrases like “BLUF, if we’re going to propose DOD-wide C5I OPSEC components
based on SOA for a RSTA Bat tothe SES level, our IA, CM and QA stories need to
be squared away. Everybody HOOAH?” A few glassy-eyed stares and I remember that
not everyone is a defense geek.
Recently, however, the tables were turned when I found myself on the
receiving end of the phrase “DevOps.” Despite
my initial (and fervent) hopes, DevOps has nothing to do with black
helicopters, covert or kinetic action and everything to do with providing a
means to increase cooperation and understanding between business and technology
practitioners in a manner that dramatically increases the productivity of both.
Enterprise DevOps is a development methodology that mates
operational requirements (i.e., What business purpose is the objective software
supposed to accomplish?), legislative, regulatory, policy and guidance
requirements (i.e., What constraints are there in the manner in which the business
purpose must be accomplished?) with traditional information technology development
concerns including design time and runtime resources, solution engineering and
coding.
The goal is a collaborative environment that is marked by:
- Membership comprising constituents from both the operational and development communities
- Freely flowing communication; and
- Iterative, incremental and continuous development, test and deployment.
The collaborative environment is expected to result in a
more rapid delivery of capability to the operational community with a concomitant
reduction in defects and errors.
That’s great. And to
my colleagues in the commercial sector, I say (with a smile!): What
took you so long?
In May 1995, Secretary of Defense William Perry directed
"a fundamental change in the way the Department acquires goods and services. The concepts of Integrated Process and
Product Development (IPPD) and Integrated Product Teams (IPTs) shall be applied
throughout the acquisition process to the maximum extent practicable." The tangible artifact resulting from this directive
was the DoD Guide to Integrated Productand Process Development (Version 1.0), dated February 5, 1996.
Among other things, the Guide specifies the implementation
of Integrated Product Teams (IPT). The
Guide describes an IPT as follows:
An Integrated Product Team (IPT) is a multidisciplinary group of people who are collectively responsible for delivering a defined product or process. The IPT is composed of people who plan, execute, and implement life-cycle decisions for the system being acquired. It includes empowered representatives (stakeholders) from all of the functional areas involved with the product—all who have a stake in the success of the program, such as design, manufacturing, test and evaluation (T&E), and logistics personnel, and, especially, the customer.
If that sounds a lot like the description of a DevOps team, comprising
members across the development and operational communities, it should. Comparable principles drive the two concepts: Fostering free and open communication, bridging
often parochial disciplinary silos and leveraging the synergies resulting from
collective awareness. The difference is
that while IPTs are generally the embodiment of human-centric organizational principles
and tenets, DevOps principles assume the integration of automated tools from
the beginning.
DevOps platforms incorporate techniques including self-service
configuration, automated provisioning, continuous build, continuous
integration, continuous delivery, automated release management, and incremental
testing. Like the IPT, DevOps responds to the interdependence of software
development and business operations. It then extends the IPT concept with
automation capabilities that aid with in rapid production, certification and
deployment of software products and services. Flickr, for example, developed
DevOps capability to support a business requirement of ten deployments per day.
The core of a DevOps platform is a standardized development
environment that automates, as much as possible, different operational and development
processes. In doing so, these toolkits
address and automate product delivery, quality testing, feature development and
maintenance releases. It should come as no surprise that core DevOps concepts
come from the Enterprise Systems Management and Agile software development
models.
DevOps platforms really come into their own with respect to
programmatic governance. The rulesets governing continuous test,
continuous build and continuous integration activities are (and must be!)
reflections of organizational policies.
With respect to government and military software programs, DevOps
platforms offer the promise of automating the C&A process within the context of development
activities. In a nutshell, each time a
module is checked in, it is not only tested against functional requirements,
but vetted against the organization’s overarching C&A requirements as
well. Modules failing either operational
or C&A vetting are simply not accepted, and the developer receives near
real time feedback. Corrections are made
at the time of coding, reducing or eliminating the need for expensive and time
consuming verification, regression and C&A testing activities and shortening
the time from development to operational deployment. Additionally, the platforms incorporate
strong man-in-the-loop processes, ensuring that no code is promoted from
development to test to deployment without positive control of authorized
persons.
Speaking at the 2013 International Engagement on Cyber at Georgetown
University on 10 April 2013, US Department of Defense (DoD) Chief InformationOfficer Teresa (Teri) Takai posed the question “Why isn’t information assurance
(IA) embedded in the acquisitions process?”
The answer could be that the acquisitions community has not yet fully
embraced DevOps tools and platforms. By certifying
that the platform meets C&A requirements before the coding and testing
cycles begin, IA becomes a fully embedded, inescapable and transparent part of
the process.
This embedded, and therefore less expensive and time
consuming IA/C&A process becomes critical as defense and government
organizations move ever more rapidly toward the implementation of large scale
mobile networks with accompanying smartphone, tablet and app ecosystems. The current DoD software C&A process can
take anywhere from six to eighteen months and may cost a program as much as a
million dollars. This level of effort makes
sense when thinking of large and/or monolithic multi-year, multimillion dollar software
projects that create applications comprising hundreds of thousands or millions
of lines of code.
When it comes to small mobile apps whose deployed size is
measured in terms of a few megabytes, whose development time may be a month or
less and whose value derives, at least in part from being available to meet an
immediate need, the associated financial and temporal burdens of the current IA
and C&A regimes become unduly onerous.
Fortunately, the burden can be significantly ameliorated by adopting a
regime in which the certification and accreditation of a program’s DevOps
platform is extended to software products issuing from that platform.
DevOps platforms are, happily, not wishful thinking of
vaporware. An example is the WSO2 AppFactory. The 100% open source App
Factory embodies both programmatic governance and application lifecycle
management capabilities including:
- Project and Team Management;
- Software Development Workflow;
- Governance and Compliance;
- Development Status Dashboarding;
- Code Development;
- Issue Tracking;
- Source Control;
- Continuous Build;
- Continuous Integration;
- Test Automation; and
- Continuous Deployment.
DevOps repackages the best of earlier defense and government
development methodologies and combines it with software platforms that allow
for distributed, governed development in a manner that embeds IA and C&A
processes. For the defense and government
sector, DevOps offers the promise of a reduction in the time required to field
new capabilities and lower program cost profiles. Importantly, DevOps platforms such as the
WSO2 App Factory are situated to be a key enabler for defense and government
mobile networks.
No comments:
Post a Comment