DevSecOps - A new Software Development Paradigm

Another concept in IT architecture is the paradigm called DevOps or DevSecOps. The reason why this concept gained a lot of attraction lately is because of the required agility companies are looking for in their software delivery. A Forrester study quoted that only 17% of IT teams can deliver fast enough that is aligned with business demand. So what is the problem? To understand that, we need to dive into how software development evolved over time.

Traditional Development Challenges

The problem is that most IT organizations are isolated and working in separate silos. First we had the traditional waterfall methodology that focused on analysis, design, build and test phases in software development. It was very structured approach that has very strict control points between each phase and therefore its name origin as you could only pass to the next step once the step before was properly approved. Typically a lot of documentation was published to facilitate the hand-over between the phases. 

But even though this methodology has been used for decades and still in use, it lacked flexibility and proper interaction between the business and development team. Once the analysis phase is completed and all business requirements have been gathered and analyzed, the project does not allow any major changes anymore to its design during the construction and build of the application. The budget, scope and timeline are typically fixed from the start. 

This could lead to misunderstandings between business and development and are only detected once the business can test the software in the final test phase... which is too late if any major changes are required due to misinterpretation. 

Agile Methodology

That is where Agile methodology came in the spotlight where the business could iterate not only during the design phase, but during the whole design and construction phase on its functionalities and requirements. The development team focuses on smaller functional blocks that can be developed, built and shown to the project for feedback and changed if required. 

As you can see in the diagram above, the agile methodology has a number of iterations (called sprints) to iterate with this business, while the waterfall methodology has only one analyze phase with its counterpart at the start of the project. There is one misconception that agile methodology is more effective in building code, i.e. that its productivity is higher. That is unfortunately not true. Waterfall and agile deliver the same productivity in building software (they are still the same programmers) and the only difference is that it iterates more often in smaller increments with the business during a longer time where is its value.

. 

These agile projects lower the walls between business and development and reduces the level of conflicts. Agile project have typically a fixed budget and timeline, but an open scope as the business definition is variable and changes during the project.        

DevSecOps

Now the conflict between business and development is mitigated, there is another wall, between development and operations. Operations requires to keep its focus on stability, robustness of its systems, availability, while the security  department requires any production IT safe against hackers. 

The problem is that projects develop and test their software within their own premises, but once they want to hand-over to production, they they encounter problems with operations and security department due to acceptance and knowledge on the other side of the wall. 

The fact is that IT organizations typically spend more time testing, deploying and releasing software than designing and building it. The testing that guarantees the operations and security department that the software is safe in production is only done at the end, resulting in delays in production changes and a high proportion of testing errors and production incidents. This could be due to communication, misunderstanding, but also as a result of human errors for instance in the manual release of software. 

That is where the paradigm of DevSecOps in place. DevSecOps stands for Development, Security and Operations and its goal is to involve the 3 teams as one collaborative environment already during the start of development. So, DevSecOps lowers the barrier between Development and Operations, while Agile methodology focuses on aligning the business with development.    

We implemented DevSecOps in companies and saw improvements of deploying changes from development in production within minutes. The same exact development change without this environment before could take up to 3 to 4 weeks. The justification is quickly made.   

Implementing DevSecOps requires a focus on selecting tooling to facilitate hand-over between development, its test environments and operations. But it also requires processes and an organization optimized to streamline the processes to develop, test and deploy its software.

The following diagram shows that there is a large number of different tools available, and it depends on the company environment to select the most adequate tooling to reach its objectives.