By: Rahul Punjabi, Lead DevOps Engineer, DevOps Practice

“How long would it take your organization to deploy a change that involves just one single line of code?”

“Do you do this on a repeatable, reliable basis?”

The answers to the above questions, which were originally asked by Mary & Tom Poppendieck, who wrote a book on Lean Software Development, can reveal a lot about the true pace and quality that an IT organization has, in delivering software to the market, and the effort it would need to put in to fulfil increasing demands of the customers.

The waterfall model of delivering software would seem highly outdated, but it would be incorrect to assume that it has become extinct. In the waterfall scheme of things, a whole lot of efforts would be spent in delivering changes to production only to realize its futility because the requirements have long changed, or do not have much value now. Agile Development provided some much-needed improvements over waterfall, with multiple stakeholders getting involved early in the lifecycle of products. However, every iteration of 2-3 week sprints would bring about a “potential increment,” or so was the promise.

The reality of course was that changes were made rapidly to the product in sprints, but not enough emphasis was placed on the testing (compromising the quality of the product), nor on the release mechanisms and operations. There were clear bottlenecks in the delivery pipeline with different teams operating in ‘Silos’, having manual handovers, incompatible goals and a different Definition of Done.

The result being only marginally better than waterfall, the value of the product was diminished, and the customers were dissatisfied still. DevOps addresses these ‘Last mile delivery’ challenges that the Agile movement could not, by breaking down silos in favour of fully synchronized teams having a shared Definition of Done.

It defines a set of practices to continuously deliver increased business value to the customers, by enabling E2E automation through well-established workflows and integrated tools. In that sense, DevOps is PPT – the synergy between People Collaboration, Process Automation and Tool Integration. Beyond this simplification, it is safe to assume that people have different opinions on DevOps, ultimately leading to a lack of definition. However, certain key practices have always been associated with DevOps.

DevOps exploded onto the scene when companies like Netflix, Facebook and Amazon amongst others, claimed to be doing thousands of production deployments a day, something that was unfathomable at the time, attributing their success to the DevOps movement. Netflix created its very own Simian Army: A bunch of tools that would wreak havoc on their systems with the purpose of testing the resilience & fault tolerance, and then automating the fail-over mechanisms to stabilize the system. Certainly, such tales of breakneck deployments caught everyone’s attention, and soon companies started attempting to replicate their practices, start-ups being the primary takers of this movement.

Adopting DevOps practices in Enterprise IT companies however, was a different story altogether. Unlike the examples mentioned, Enterprise IT has several challenges in DevOps adoption:

• Segmented global organization structures in alignment with business processes
• Multiple products on different platforms having diverse technological requirements
• Dedicated teams operating in silos
• Sizable proportion of legacy, as well as stable system of records/ERPs

Trying to mirror the practices followed by pioneers in such a complex scenario, would certainly be counter-intuitive and disruptive to how Enterprise IT functioned, bringing in tremendous risk. It is also worth noting that DevOps may not be suited to the system of records and stable systems – a sizable proportion of projects within Enterprise IT. Firstly, such systems would not be expected to change rapidly and secondly, they would have their own dedicated tools and processes into which standard DevOps practices and tools may not apply directly. Systems of differentiation and innovation on the other hand, are prime candidates for DevOps adoption.

How can Enterprise IT adopt DevOps?

For Enterprises, adopting DevOps should be a journey; and not a one-shot solution. Incremental and measured improvements in collaboration, integration and automation can lead to shorter release cycles, lean processes and superior productivity – all contributing towards a cultural shift in the day-to-day functioning. By having cross-functional teams aligned to business products, complex hierarchies can get simplified into several “start-up like” self-sufficient teams. Over time, cross-skilling can take place to reduce the number of different roles required to design, plan, build, test, run and monitor a product or an application. With an increase in DevOps maturity, the focus continuously shifts from “keeping up” to a more holistic culture of “Continuous Innovation”.

In summary, I would like to share my take on DevOps and my answer to the omnipresent question: What is DevOps?

“DevOps is the seamless flow of value, from idea to release, which is driven by a culture of collaboration and automation of application life-cycle through lean processes and integrated tool chains.”