When you work in IT, it's not out of the ordinary to encounter words you've never heard of before. These new words typically emerge at large technology conferences, and then—courtesy of the attendees—slip into next morning's company meetings, weaving their way across the IT workforce in no time.
DevOps is one such term that's been doing the rounds since 2009, when the first ever DevOpsDays event was held in Ghent, Belgium. Nearly a decade later, it's a term that many people are still unsure of. In smaller companies, one could even argue that DevOps is on the brink of being likened to a buzzword. There's no worse fate for IT terminology, so let's set the record straight by deciphering DevOps.
Culture of collaboration
As the portmanteau of ‘Development' and ‘Operations' suggests, DevOps involves collaboration between traditionally siloed teams of software developers and IT operations by employing feedback loops and automation to reduce cycle time, boost delivery speeds, and build superior products. More of a culture or mindset than an IT framework or organisation structure, it's also often considered a part of agile software development, where both the Dev and Ops teams enjoy a greater buy-in to the process of building the product.
DevOps practitioners place greater value on people over products or processes; agility and flexibility over monolithic approaches; and user experience over system performance. To sum it up in one sentence, DevOps can be defined as a set of cultural values and practices followed by developers and operations that automates processes through continuous feedback loops for quality software delivery.
Everyone wins
The deadline for a mammoth project is looming, the backlog of work is piling up, and everything is spiralling out of control due to a misalignment between developers and operations on the scope. It's a familiar scene in many IT departments.
By creating an environment that nurtures real-time collaboration among cross-functional IT teams, DevOps can result in faster detection and resolution of errors, shorter development cycles, and more reliable security. This, in turn, can lead to tangible improvements to costs, profit margins, and customer satisfaction: a win-win situation for all parties. But these are all the happy byproducts of the true benefit: intellectual and emotional ownership by IT professionals of not only the finished product but also the entire experience.
This emphasis of DevOps on people encourages developers and IT managers totheir work in terms of customer satisfaction and real-world performance. “Why are people buying the blue shoes more often than the yellow ones?” or “Why do we see a spike in customer support calls on the 2nd week of the month?” are general questions you'd expect to hear from a VP of Sales. They're also asked by DevOps practitioners who share the common goal of creating products that resonate with what people want and need.
Democratic at its core
A DevOps team can't be assembled overnight. It requires careful planning and a gradual integration of developers and operations into a single unit. Business leaders first need to understand that DevOps is, at its core, a democratic structure. A system where DevOps practitioners work together to gather opinions, reach a consensus, and then chart a course. It's a type of work environment that can't be mandated from the top down—otherwise, it loses the very essence of DevOps.
The key is to start out with a pilot project that's comprised of a team of people who adhere to the DevOps' philosophy. By assembling a team that's already pro-DevOps, or simply a team that collaborates well with all its members, you're already setting yourself up for success.
Once the pilot has ended and it's clear to all that a culture of less blamestorming, shared responsibilities, frequent communication, and better collaboration leads to great results, then it's time to expand DevOps across the board. IT leaders can play an instrumental role in ensuring that the DevOps culture flourishes. Whether it's through workshops, daily rituals, or team-building exercises, it's up to these leaders to make these new ways of working the norm in the business.
Next year, it'll be a decade since DevOps entered the IT vocabulary. Between then and now, more and more teams have warmed up to the idea of DevOps, but confusion still exists with little clarity on how to translate it from theory to practice.
As tools get better and siloed teams understand they can do more in less time under a DevOps model, then there will come a point in time when DevOps will no longer need to be defined, because it will be just how we build stuff. If the IT landscape of today is any indication, then this exciting future is not far off.