In my earlier video titled DevOps 101, I introduced DevOps and the basic idea of a new cultural wave.

Today, we look at a metaphor called as the wall of confusion which drives home the point of the reason for DevOps’ existence. I will further explain how DevOps aids in solving the problem.

The image represents the wall of confusion image. On one end of the wall, we have the development team that consists of developers and testers. That’s the left side of the wall. On the right side, we have the operations teams.

In non-DevOps organizations, development and operation teams sit in different silos which is nothing but a wall in between the two parties – similar to what you see in the image.

The development team is put in place to develop new features to products. The operations team exists to ensure that the environments are maintained and are stable. In other words, the operations teams want to maintain status quo.

The development team’s objectives of developing new features involves changes to the existing environment. So it necessarily means that changes are pushed into an environment. So in effect, a potentially stable environment can get destabilized due to the changes that have been put in – which is in direct contradiction with the objectives of the operations teams.

So this contradiction where the development teams are needed to push changes and operations teams needing to keep the environment stable is represented as confusion in the wall of confusion metaphor.

If you have ever been in a change advisory board (CAB) meeting, you will often hear the operations team pushing back on the changes by questioning the change, checking up on various test cases and tests that have been performed. In other words, they try to put spanner into the works. I am not saying that they are wrong to do so. Think from their perspective. If the testing is incomplete or not done satisfactorily, there is a chance that it could result as a failed change implementation or worse as incidents in the production environment. This would undermine the stability of the system.

DevOps to the Rescue

Now let’s see how DevOps provides a solution to this quagmire.

In DevOps, teams are not situated in silos – at least the development and operations teams that support a product. So, both the development and operations teams are part of the same team. They do not have different objectives. The entire team has a single set of objectives that apply to all roles in the team.

The operations personnel in the team are aware of the various changes that are getting developed, the various tests that have been done and the outcome of each of these tests first hand. So any questions that they may have had will be asked and addressed during the development and testing stages itself. And not during a CAB meeting. They questions that are asked make the product stable, and address the issues in lower environments rather than in production.

And for the operations teams, since they are part of the entire setup from genesis, there will be no such thing called as transition to support. The operations teams will be ready to start supporting from day one without a formal handover.

This is a classic example of a win-win situation where the DevOps methodology not only breaks down the wall, but makes the entire process of development and support look easy and seamless.