Is DevOps or DevSecOps Dead?

Is DevOps or DevSecOps as we know it dead? While the objective of DevSecOps is noble, challenges existing in practice have stymied the model from reaching its full potential due to barriers related to development and operations having different perspectives and objectives. Developers commonly violate the first rule of marketing by becoming infatuated with the “beauty” of their code and expend insufficient effort or care in ensuring that Operations can deliver architectures that work to holistically solve business needs or that security and compliance elements are sufficiently addressed. DevSecOps must evolve beyond its current incarnation to ensure business requirements are efficiently delivered throughout the software development life cycle (SDLC) with a minimum of risk, and that the needs of all critical constituents are being properly addressed. IT executives must adopt a new approach, as part of the evolution of DevSecOps, which has all parties actively involved in all phases of the process and restructures the leadership position so that there is a smooth handoff as code goes through the development and production phases.

Organizations have worked in silos for decades. DevOps was developed as a set of practices that is designed to automate and integrate the processes between software Development and other IT teams, so they can build, test, and release software faster and more reliably using an agile development process. Thus, DevOps was intended to be a shift in delivering functionality to end users by getting all the players involved throughout the cycle. Security was always intended to be included in the DevOps approach but not everyone understood that. Hence, the renaming of DevOps to DevSecOps by many. Nonetheless, regardless of naming conventions, DevOps as initially implemented is not gaining sufficient traction and many organizations are struggling to move the methodology forward from pilot mode to standard operating procedure.

The way most firms implemented DevSecOps was to have Development lead the effort with Operations and Security (and Compliance) playing a minor role until code moved towards production. This passivity and checkbox approach meant that the SecOps piece was not playing the active role it needed to and the methodology objectives were not being met.

The Rally Car Analogy

To address this challenge, we propose that DevSecOps teams operate using the rally car model. Under this methodology Development still sits in the driver’s seat. But it is the navigators (Compliance, Security and Operations) who call out the best paths forward, road hazards, degrees of approach, and a variety of other factors that the driver must accept as directives in order to succeed. The driver relies on these instructions religiously to complete each stage, as the implicit understanding and agreement is that failure to do so will result in elimination or the car ending up in a ditch. Thus, it is SecOps that sets guardrails around which Development must adhere if it expects to have its code put into production.

Another benefit from the Rally Car approach is that each of the team members learns something about the others’ views and tools. Developers learn about the needs of Operations and the requirements of Compliance and Security while the latter groups gain an understanding of Developers and their tools.

It is equally important that these groups be incentivized to learn something about each other’s roles, requirements and goals, and have shared use cases. There cannot be a goal for Development, a goal for Operations, and a goal for Security/Compliance – there must be shared goals.

The teams must optimize for global goals with both a horizontal and vertical component. There still will be vertical teams along with networking, security, QA, and operations, which create the horizontal/vertical matrix. These teams then provide cross pollination of ideas and requirements.

The Bottom Line

DevOps is dead; long live the new “rally car” DevSecOps model. Like any postulated theory, the DevOps model needed tweaking. Moreover, this new model gives the SecOps team members an opportunity to evaluate and develop what additional wrappers they would like to provide to surround the application so that it better satisfies their operational needs.

The DevOps model has evolved over the last decade and improved significantly. Additionally, business and IT executives must provide the leadership required throughout the process in support of each of the DevSecOps teams as they actively lead their part of the effort. This will enable enterprises to be more flexible and responsive to customer, corporate and regulatory needs. Business and IT executives need to re-evaluate their current development methods and determine what of the new methodology is adoptable within their organizations and how it can get quickly piloted and rolled out.

Related content:
Four Steps to Leverage Technology and Fuel Business Growth
Technology Driven Trends for 2021: Writing the Future
Keeping Up with Jargon and Technology for Small Business
Cal Braunstein
Cal Braunstein
Mr. Braunstein serves as Chairman/CEO and Executive Director of Research at the Robert Frances Group (RFG). In addition to his corporate role, he helps his clients wrestle with a range of business, management, regulatory, and technology issues.  He has deep and broad experience in business strategy management, business process management, enterprise systems architecture, financing, mission-critical systems, project and portfolio management, procurement, risk management, sustainability, and vendor management. Cal also chaired a Business Operational Risk Council whose membership consisted of a number of top global financial institutions. Website

[optin-monster slug=”vuslebyocndjsreaoncm”]