DevOps (a play on “Development” and “Operations) is an enterprise software development concept meant to join Development and IT operations with improved communication and collaboration between these two business units.
To the outside looking in, “IT” generally encompasses all areas related to technology, be it programmers, the guy who fixes your printer, or the guy who maintains your current systems. To the non-technical types, there is a myth that “being good with computers” means you can do any field of computing expertise.
In the medical field, if you have a vitreoretinal illness that requires a specialized surgery, you’re going to contact an ophthalmologist–not an orthopedic doctor. While the latter will likely do better than say, myself, you want someone who has studied that particular field of medicine and does it all day.
DevOps is a system that helps merge these different IT fields together, specifically focused on making sure the people who will maintain and use the application are involved in the process from start to finish. DevOps then goes a step further, with a focus on bringing an entire organization together to ship better software, more frequently.
Under a DevOps model, development and operations are no longer operating in echo-chambers and siloed. These two teams are merged together to allow engineers and different layers of expertise to work together during the entire application lifecycle, instead of just their core expertise.
The Three Ways: Principles of DevOps
DevOps is based on “Three Ways” of which all observed patterns and behaviors are structured. Unlike a more rigid system like Scrum, DevOps is much more philosophical:
From The DevOps Handbook:
The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.
The First Way is based on Agile/Lean production and focuses on moving bite sizes of the final product into production sooner rather than later while bringing all key players into the development cycle (from developers to project managers, and finally–the customer).
The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and recovery.
The Third Way enables the creation of a generative, high-trust culture that supports dynamic, disciplined, and scientific approach to experimentation and risk-tasking, facilitating the creation of organizational learning, both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace.
The Second Way & Third Way are focused on creating safer systems of work where problems can be discovered and fixed without having to go through a committee.
Similar to the leader-leader method developed by Captain Marquet. Captain Marquet was a Navy captain, responsible for developing a unique method of leadership after he gave an impossible order to his men one day.
His method developed around the philosophy of never giving another order, rather, giving an intent. So, instead of (moving back to web development) a project manager saying “create a shopping cart with products for this new website” it’s “the intent here is to create a shopping cart that women in the late 40s, affluent, can use to purchase specialized spices for their kitchen.”
Of course, this doesn’t mean that everything is left to the discretion of the developer and lower-on-the-totem-pole people, the rules of the system (i.e., the generated PDFs from this application have to look exactly like our other branded materials, or, the conversion tracking on a website needs to be functioning 100% of the time) still apply.
What is removed is the ego of the project manager, company owner, client, and other factors that have a habit of delaying projects and causing confusion. This allows for all to have a core focus on the rules of the system.
How Does DevOps Work in an Organization?
Software and the Internet have helped transform this world, and software no longer merely supports a business; it is now a fundamental aspect of every business.
“…which tended to be a set of principles from which one can derive all of the observed DevOps patterns. The first is all about accelerating flow as you go from left to right, [Development] to [Operations], in the value stream. The second is the flow of feedback, how do you create effective feedback from Ops back to Dev so that when something goes wrong, you can either prevent it or detect it more quickly. The third is about creating a culture of continual learning and experimentation using the notions of high trust culture.”
In the age of digital business, the DevOps founders realized that sites with massive traffic like Google, Amazon, and Twitter, are all known for being able to do deployments (moving new features or bug fixes into production) many times a day (or even many times an hour). In order to deploy new ideas this quickly, you’re going to need a system that doesn’t break what’s already working, can be undone easily, and relies on open and honest communication with others within the organization.
As Amazon puts it:
“In a similar way that physical goods companies transformed how they design, build, and deliver products using industrial automation throughout the 20th century, companies in today’s world must transform how they build and deliver software.”
Working in a DevOps environment helps place the focus on constantly shipping products, features, and changes to the customers. It means that you can establish an environment where you can create feedback as quickly, cheaply, and rampantly as possible.
DevOps & Your Organization, a Few Troubles
Initially, especially for a simpler website build or smaller piece of business software, an organization may be turned off to paying for an environment of continuous deployments. A lot of companies like the idea of treating a software project like an architectural project or remodel: there is a beginning, a middle, and end–with a fixed cost and time line.
With DevOps, you’re constantly working on improving your software or product, and focused on shipping new changes and features in a rapid environment. This means that you either have staff members or an ongoing contract with a company to ensure that software is constantly being worked on, improved, and released.
Next, if DevOps is the main philosophy of an organization or project, c-suite executives, customers, and project managers begin to get spoiled and think that this means everything will be much faster to build and implement. This is rarely the case, complicated tasks will still take longer than “an afternoon” to complete.
If you’re going to completely change your application to move from the web to a desktop or iOS style application, DevOps will not get it done by the end of the day. Rather, it means that the philosophy of DevOps will be used to ensure that when you launch the application, you don’t spend the next 3 months putting out fires for angry customers and losing business.
The next issue we see a lot in implementing DevOps: dealing with egos. The human ego has a nasty way of creeping into processes and philosophies like this and losing sight of the core focus.
It is generally agreed that DevOps is about efficiently providing the customer with the best possible product. It’s not about providing the company CEO with a new website “look” two weeks after the last website was deployed because she found a new website she likes, and this is now the top priority.
It also doesn’t allow for inter-department wars, where programmers are furious because designers keep making “asinine changes” without seeing the full project picture or designer are furious that developers came back with a two week lead time on what they felt was a “simple fix.”
DevOps is all about breaking down isolation chambers, which can be extremely difficult for some organizations.
It’s Not Everything
Much like some of the other systems we’ve talked about, DevOps has attracted a lot of Zealots that exclaim this system can do everything and the kitchen sink. While DevOps is good at creating a collaborative and agile corporate culture, it is specific to how operations and development tie together to work in harmony. It should focus only on the delivery and project management of software, without trying to fit into areas it does not belong (like the overall company structure, human resources, or other similar items).