Want to Break Down Barriers to DevSecOps? Stop Splitting Requirements.

CJ Capizzi - Principal Technical Director

By CJ Capizzi, Principal Technical Director

In the era of DevSecOps, there is global recognition of the inherent value of coupling development (Dev), security (Sec) and operations (Ops) into a single mindset. It is curious why many agencies that are moving towards continuous delivery and a culture of DevSecOps continue to perpetuate the splitting of Development, Modernization, and Enhancement (DME) and Operations & Maintenance (O&M) support requirements across contracts. This separation of duties between DME and O&M contracts was much easier to rationalize in a historically waterfall process where production releases were less frequent and involved formal stage-gate governance reviews (e.g. Production Readiness Review) prior to deploying into production. In the moving toward smaller, more frequent releases such as those used in DevSecOps processes, there are numerous inefficiencies and risks in continuing to operate under this bisected DME/O&M delivery model over adopting a model where a single vendor is responsible for end-to-end development and operations.

So why must agencies consider this paradigm shift to a single delivery vendor? By adopting a culture of DevSecOps and aligning support to this unified delivery model, agencies can more easily realize a number of benefits.

  1. Reduced Overhead – The effort to manage and oversee separate DME and O&M contracts brings with it the overhead costs and duplicate administrative activities and management structures. By consolidating DME and O&M contracts, agencies are able to reduce the administrative burden on procurement and contract management activities as well as administrate support on the Contracting Officer Representatives (COR) and other program staff. A single vendor presents opportunities to drive down costs through reduced contractor Program Management Office (PMO) structures, tooling, and the need for additional cross-contract coordination meetings.
  2. Improved System Design – In organizations where DME and O&M are split, most systems are designed-for-function over designed-for-support, often times introducing downstream complexity for managing systems in production. Teams that are responsible for both developing new functionality and enhancements as well as maintaining the system in production design better systems. This is in part to the teams having additional knowledgeable and understanding of how the current system operates in production and designing for optimal supportability since they will be ultimately responsible for the changes deployed to production.
  3. Reduced Lead Time to Change – In organizations where DME and O&M are split, there is some level of pre-production coordination to review the changes included in the release candidate as well as any technical and support document teams that own the end-to-end life cycle can more rapidly deliver changes to production enabling improved business agility for the agency to respond to evolving needs. Since there is not a production “handoff” in a single vendor model, this reduces the burden and time of having to train O&M staff on changes, reducing software deployment and support risks
  4. Increased Focus and Accountability – Separate lists of priorities between DME and O&M often cause confusion and conflicts when planning and coordinating efforts across teams with different priorities. Teams that own end-to-end system life cycles are able to manage from a single backlog versus separate development backlog and an O&M backlog which requires separate priorities for separate teams. Operating from a single backlog means having a single list of program priorities all teams can plan and execute against. A single vendor support DME and O&M also improves accountability for meeting Service Level Agreements and implementing improvements as there is a responsible single entity.
  5. Continuous Improvement – One foundational practice of DevSecOps is observability. Observability centers around understanding how the system performs and is being used in production to drive product and process improvements. In many environments where DME and O&M Teams are separate there are both cultural and technical barriers to having visibility into operational data. True DevSecOps teams have fewer barriers to bridging the hypothesized value created through development with the actual value delivered in production.


As DME or O&M contract periods of performance are drawing to an end, agencies should consider doing the following:

  • Evaluate the consolidation of DME and O&M support under a single vendor to achieve some or all of the aforementioned benefits
  • As most contract periods of performance are not neatly aligned , look ahead and take time to collaborate with the Contracting Officer to develop an optimal acquisition plan and transition strategy in moving to a single vendor model
  • Exploit the levers that are available such as the end of contract or option periods to realign or consolidate support, collaborate with other agencies to learn how they are adapting contracting strategies to better adopt a DevSecOps model
  • Leverage RFIs to gather insights and recommendations from industry partners on how to better structure contracts to support DevSecOps and facilitate a continuous delivery of value to your mission

While the move to a single vendor model is not groundbreaking, it is still a critical step that many agencies must take to improve responsiveness to mission needs and in alignment with industry leading delivery practices and technologies.