[G u e s t P o s t] The term “DevOps” has been floating around the IT industry since 2009, yet a very select number of people seem to actually understand what it means. Companies make efforts to create DevOps teams, appoint DevOps managers, and even seek outside consulting, but the main point that is missing is that there is no one person, or small group of people within a company that can “do” DevOps. It is a culture that needs to be accepted and practiced by the company as a whole. Only then can it effectively contribute to the ultimate goal of customer satisfaction.
Change in Culture
John Willis and Damon Edwards, two internationally recognized experts on the culture, came up with an acronym that describes the process of incorporating the culture into an organization. C.A.M.S. (Collaboration, Automation, Measurement and Sharing), if done correctly, incorporates all people within an organization, their manual processes, and the business value, measuring everything in a variety of stages and ways.
While this notion of DevOps culture seems ideal for business development, it seems to be a bit more difficult to execute in reality. In order for a company to work as a whole entity and not separate parts, that may or may not be operating in a way that benefit or even consider others, communication is key. Sales and marketing, developers, software and production, even the cleaning crew, all need to be on the same page and working towards a mutual goal. Keep the business up and running, and make the necessary changes to ensure customer satisfaction.
So, how, exactly does an organization incorporate DevOps culture into their everyday routine?
First of all, the right mechanisms need to be in place to measure the efficiency of every department, in order to provide feedback on their level of operation. The right facilities also have to be set up, allowing all employees to share ideas and communicate freely and easily.
In order to improve a system, it must be looked at as a whole. A company is not just software development or marketing. If the company is not viewed as a whole entity, the system cannot be improved. Refining one department does not consider how other departments are affected, which consequently, could create problems within the system. Once employees within the company understand how a bug in the system is not simply a development issue, but also a sales and marketing issue, they will comprehend the importance of embracing DevOps culture into their everyday routine.
The notion of Continuous Delivery goes hand in hand with DevOps culture. It focuses on placing the release of a product/application/feature/service in the hands of the business and not in the hands of IT. In the olden days, software developers would write a code that would be presented to the customer the same time as the product/feature/service. This process was very risky in terms of customer satisfaction. If the customer was not happy with the new feature, it would take the sales team time to understand that, then send the information along to development to create a new code and start the process all over again, taking days if not longer to implement the changes. Fortunately, now-a-days, companies make changes like these around 60 times per day. However, they use a slightly different method of implementation. With the use of a completely automated pipeline, changes made to a feature or service can be made and deployed multiple times a day, yet never released to customers. This process,not to be confused with Continuous Delivery, is known as Continuous Deployment. These releases are not made every day and are actually not usually even unveiled to all of a company’s customers. A small percentage may be exposed to the change, enabling the company to measure how the change affected customer satisfaction. This process is further accelerated by the existence of a DevOps culture in an organization. By working together and employing the right modes of communication within a company, innovation and deployment delivery become speedy processes at a very low cost; customers can more easily benefit from countless upgrades, making their quality of life and levels of satisfaction that much greater.
While traditional IT folks may not be ecstatic about the DevOps and Continuous Delivery revolutions, companies around the globe have been reaping their benefits: Removing the ceremonial headache from the deployment and delivery processes, automating tools and processes to instill a framework that provides space for improvements with less busy work, allowing for more creativity, giving everyone the ability to deploy as often as desired (new hires, included)… All of these advantages enable companies to release value to their customers on a continuous basis, receiving immediate feedback, in order to evaluate if and how the company is working to its highest potential.
The keys to successful DevOps culture and Continuous Delivery are automation and feedback. Once everything is automated, it is that much easier to tweak small parts here and there since the rest of the system continues to run automatically. The framework is in place, it simply needs to be refined. Feedback, then, allows organizations to learn from changes, what works and what does not.
When looking back at John Willis and Damon Edwards’ notion of C.A.M.S., we can see that both DevOps and Continuous Delivery contribute to each aspect of the acronym. Continuous Delivery demands short feedback groups, otherwise it would be traditional development, and everything is measured mathematically and can be seen visually, in graphs. Everyone has the opportunity to pitch an idea to improve the system as a whole, and everyone is aware of other departments’ statuses and tasks. In order to improve our systems, we need to first embrace how they behave on the whole.
Note: Great thanks to my colleague, Ziv Rechnitser (email@example.com) who supported me creating this article.
About the Author
Evgeny Zislis is a founder of DevOps Israel who consult DevOps adoption in technology companies. He has been involved in IT operations for more than 10 years in companies such as IBM, RSA, ECI and others. When he is not solving techie problems in a console, he can be found playing computer games or visiting the movie theatre watching the latest Sci-Fi or superhero flick. He can be contacted via his company webpage or e-mail at firstname.lastname@example.org.