Sunday, April 14, 2013

DevOps and the Future of Defense and Government Software Development Programs

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