English | EN 
As consultants working on DevOps transformations, we often get approached by people who ask me for a DevOps framework or solution that they can take back and implement in their organizations. Personally, I sometimes feel at a loss on how to answer such questions, as different organizations typically have different toolchains and it would not make sense to change those toolchains just to fit your framework. Instead, one needs to bridge these toolchains, make them talk to each other and implement feedback mechanisms. Thus, every organization requires a solution that is tailored to meet their specific needs and there is no ‘one-size-fits all’ framework when it comes to DevOps.
Unfortunately, such misplaced expectations are all too common and reflect a widespread understanding of what DevOps is and what it isn’t. Such unrealistic expectations often lead to unsatisfactory client engagements, where, even with experienced consultants, a good plan, and the appropriate toolchains, it becomes difficult to implement DevOps in the client’s organization. To avoid such situations, it is best to be clear about what DevOps is and the results it can produce before embarking on any transformation journey.
So, here are some broad guidelines on what DevOps is, and what it isn’t:
a) DevOps means being ‘production ready’
Earlier, software development used to take 3, 4 or even 5 years before entering the launch phase. Today, however, organizations have become so agile, that the moment a requirement pops up, people expect it to be implemented and made available. Companies like Facebook have multiple upgrades and deployments happening every day. Such speed and agility are a direct result of successful agile and DevOps in operation. So, if you believe in the adage that ‘the proof of the pudding is in the eating’, then the ability to be ‘production ready’ and to roll our changes and upgrades quickly is one of the key characteristics of DevOps.
Keep in mind, that what we call ‘agility’ can vary a lot across organizations. Companies like Facebook and Google can roll out upgrades every couple of hours, since they are entirely web-based. Achieving such speed can be difficult for companies which have a lot of legacy systems or embedded software.
b) Agile is the foundation for DevOps
Moving quickly and effectively to DevOps, is tougher for organizations which are strongly tied to waterfall approaches. This is because organizations which are already used to working with agile are used to working in multi-disciplinary teams and deploying smaller chunks of work at one time. More importantly, they also have the kind of organizational structure, workflow and processes which make a move to DevOps easier.
c) DevOps is all about people, culture and mindset
One of the most common misconceptions about DevOps is that automating one’s processes and putting the right tools in place is what it is all about. This is only half the truth, for tools and automation are necessary but not sufficient conditions for DevOps to work. In any transformation towards DevOps, approximately 75% of the efforts should be focused on people, whereas process and tools constitute to only 15% and 10% respectively.
Above all else, DevOps requires a culture of collaboration across teams, effective and efficient feedback mechanisms to reduce latencies and multi-disciplinary skill sets within project teams. This ‘soft’ and ‘difficult to define’ element of culture is critical. This is because DevOps, in order to succeed requires a holistic and collaborative mindset among all stakeholders involved. The days of working in a separate development, testing and infrastructure teams are over. Not only do software professionals need to develop multi-disciplinary skill sets, they also need to collectively own all problems and challenges that come up. The days of working in silos are over.
This also means that the way products used to get audited has changed. Whereas earlier such quality checks were carried out by dedicated QA teams, quality today is the responsibility of the integrated project team and is an objective to which everyone must contribute. This means that product teams need to be trusted on their deliverables, everyone needs to take responsibility and the ones developing also need to do the QA and compliance checks themselves. Creating this culture of openness, cross-skilling and stepping out of comfort zones to achieve shared team goals is THE critical requirement for DevOps and it is this area which most organizations find difficult to pull off.
d) DevOps requires continuous integration
As already pointed out above, DevOps requires effective and efficient feedback mechanisms to reduce wastage in the lifecycle. Under waterfall, developers would code and check it in, following which someone else would test the code and log in defects. These long feedback loops also led to situations where the developer had forgotten about the code they had developed by the time they received the list of defects. DevOps cannot work like this and requires immediate feedback.
This is where continuous integration (CI) comes in. Today, the moment an SDET develops code and checks it in, certain tests are automatically triggered. With frameworks like user acceptance testing, developers also build directly to user requirements, so as to completely remove certain feedback loops.
In sum, the move to DevOps is a difficult one to pull of and is more than just a question of automating processes and buying expensive tools. The biggest stumbling block for most organizations is in underestimating the cultural and mindset change required to make DevOps work. One can buy automation tools, acquire AWS toolchains or IBM stack, but ultimately, the ones who will drive it are the people. This is where organizations would do well to focus on, in their DevOps transformation efforts.
