Yes – DevSecOps Can be Done, and Done Well

Weeds picture

Rob Wedertz – VP DoD Programs

DevSecOps Diagram

Inarguably, the pace of change in the technology environment outpaces the program and acquisition oversight within the Department of Defense.  I don’t believe this is a controversial statement.  C-SPAN is riddled with testimony of senior ranking DOD officials asserting the same.  The National Defense Authorization Act (NDAA) is littered with language encouraging the Department to accelerate the adoption of rapid acquisition methodologies.  Nowhere is the delta between advanced technology capabilities and the Department’s ability to procure these capabilities more prevalent than in Software (i.e. Artificial Intelligence, Machine Learning, and Discrete Event Simulation).  And even more specifically, it is the incorporation of the development methodologies, for example DevSecOps, that often befuddles program managers, contracting officers, and even leadership, as this methodology is counter to acquisition guidelines and requirements oversight.

In an effort to close the delta, the Department has established bodies (e.g. DoD Enterprise DevSecOps Community of Practice – a Joint effort among DoD CIO, OUSD (A&S), and DISA; the Defense Innovation Board, the Joint Artificial Intelligence Center, and others) to “sanctify” best practices and is actively campaigning to align acquisition and procurement with best in breed enabling technologies and development methodologies.  Because we have been charged with designing, developing, and implementing the Joint Staff’s Global Force Management Decision Support Platform (ORION), we are actively “leaning out over our skis” to demonstrate that DevSecOps can and should be done.

As a software development company tasked to deliver leading edge technology-enabled decision support platforms to the Joint Staff, there is little more deflating than telling our platform leads that they cannot implement the best in breed capabilities (i.e. open-source software, enablers, architectures, etc.) because the product is evolving so quickly that we cannot introduce it into the Risk Management Framework accreditation sphere.

Fortunately for us, we were introduced to Defense Innovative Unit (DIU) (then with an “experimental” on the tail) early in the ORION development process. They were encouraged by our startup mentality developed in support of our commercial products and they encouraged our government oversight to think about things like; Minimally Viable Products (MVPs), continuous User Engagement, and leveraging modern technology and platforms.  During their assessment of the ORION Joint Platform (at the time known as the Joint Force Capabilities Catalog (JFCC) / Global Laydown Server (GLS)) DIU acknowledged that we were already accomplishing the things they suggested.  They passed as much to the Chairman of the Joint Chiefs of Staff and his support staff.  Achieving this level of maturity didn’t happen overnight.

We lived the painfully slow migration from “waterfall” acquisition and associated development practices to Agile, and are on the leading edge of DevSecOps.  In fact, as DoD CIO, OUSD (A&S), and DISA work through “sanctifying” the DoD Enterprise DevSecOps maturity model (via a Community of Practice), and the Defense Innovation Board awaits the response to their Software Acquisition and Practices (SWAP) study published in April of this year, we’re already demonstrating that the DevSecOps model works, can be implemented at no additional cost to the government, and perhaps most importantly, is scalable.  Case in point – when we began the ORION project, we were squarely in the “rapid prototyping” phase of development as the overarching requirements were being developed, and oversight was being codified.  The early days required rapid deliveries and constant engagements with users, all while adhering to information assurance requirements and cyber security.  (Note – we were (and are) deploying code to the SIPRNet, a production environment, every 2 weeks – functionality that is Beta, IOC, and FOC simultaneously.)  Achieving and sustaining this level of S/W development maturity is difficult and often requires a champion.

Advocacy is paramount.  It is not enough to be an innovative company with technical “chops”.  You MUST have a program sponsor that endorses the DevSecOps methodology and removes legacy critical barriers that prevent innovation at the speed required.  (It does not hurt that our advocacy was a shared understanding and endorsement from the sitting CJCS and the leadership of DIU.  That we were doing it was the result of technical leadership and guidance provided by our Joint Staff J35S Program Manager; that we are continuing to do it is the result of the senior leaders of the DOD acknowledging that is the way it SHOULD be done.  Early in the project, the J35 Deputy Director of Regional Operations, briefed the entirety of the Joint Staff (J-DIRs, Director, and Chairman) and the Deputy Secretary of Defense.  Paraphrasing his remarks, [sic] “these guys are pushing the envelope on s/w development.  They sprint, they fail, they recover, they deliver, they iterate – we win.”

Perhaps the lynchpin in achieving technical maturity in an oftentimes legacy environment is the simple acknowledgement that requirements WILL change.  When we started ORION, Globally Integrated Operations and Dynamic Force Employment were not yet established in policy.  Had we developed and delivered an application that was a reflection of solely the original requirements specifications, both the program and our platform would now be obsolete.  Fortunately we’ve been allowed to iterate throughout the software development lifecycle.  Continuous user feedback and rapid development cycles have facilitated relevance and viability that have ultimately enabled the Joint Staff to make Better Decisions, Faster.

Aligning the DevSecOps methodology with Scaled Agile Framework has additionally ensured that ProModel is permeating best practices not only across our DOD vertical but also in our COTS and Healthcare spaces as well.  Our collective roadmap is articulated in the Defense Innovation Board’s Software Acquisition and Practices (SWAP) study graphic below.  Our objective is to live in the “Do’s” and demonstrate that we can and should avoid the “Don’ts.  ORION is validation that it can be done.

2 thoughts on “Yes – DevSecOps Can be Done, and Done Well

    • Thank you Jai,

      Technology first – policy second. That’s the solution. As long as security requirements are met and costs are controlled, there is no down side.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s