Depending on the perspective of who you are speaking with, DevOps can mean several things. Is it a culture, a movement, an approach or a philosophy? It helps to root a discussion of DevOps in a solid definition.
What is DevOps?
“DevOps is a set of practices that emphasize the collaboration and communication of both software developers and information technology professionals inside an organization while automating the process of software delivery and infrastructure change. It aims to establish a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.”
-- Wikipedia
At Summa we have a bit broader definition:
DevOps is a logical extension of Agile. DevOps practices emerge if we continue to manage our work beyond the goal of “potentially shippable code at the end of each iteration, extending it to our code always being in a deployable state.”
Instead of IT operations doing manual work that comes from work tickets, DevOps enables developer productivity through build and test automation (and architectures to support it), APIs and self-serviced platforms that create environments, test and deploy code, monitor and display production telemetry, and so forth.
By doing this, IT operations staff becomes more like development. They are engaged in product development, where the product is the platform that developers use to safely, quickly, and securely test, deploy, and run their IT services in production.
While many of the DevOps patterns require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation. As Christopher Little, a technology executive and one of the earliest chroniclers of DevOps, wrote in The DevOps Handbook, “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”
Aside from a starting point of a grounded definition, I’ve found that comparing DevOps to the plumbing in a house makes the subject more approachable and consumable. This analogy is especially useful in understanding the role of DevOps in the enterprise.
How does DevOps resemble plumbing?
When living in a home that is over sixty years old, you experience a few plumbing problems over time. If you are like me, when you purchase a house, you bought someone else's problems.
Most enterprises have a software delivery infrastructure that has many of the same things in common with my home's plumbing.
- The system predates most of the people who use it (or remember why it was built the way it was)
- Individual components have been broken, fixed, or upgraded reactively as problems arose
- Has a multitude of types and styles of pipes, such aserracotta, iron, copper, PVC, PEX,Cobol, C, C++, Java, HTML, Javascript
- The system has grown well beyond its original design capacity and is over-taxed
- Many different plumbers/IT professionals and owners have worked on it over the years
- When it is working nobody pays any attention to it, but if it breaks, it is always a real emergency
- Even more complexities arise from remodeling and or mergers, often resulting in multiple locations with vastly different systems
For over ten years, I continued to ignore obvious signs I was having plumbing problems until I found mold and wet dry wall in my finished basement. I discovered that I had to demolish my entire finished basement due to a couple of small leaks that had gone unnoticed for many years.
At this same time,, I was consulting with many large companies in Pittsburgh, PA. The same warning signs that I had ignored at home in my plumbing are apparent with software delivery value streams of many of my clients.
- Demand is higher than ever
- Software leaving the system is slowing
- The supply of requirements ready for development is not adequate
- Technical debt has been accumulating
- Mergers and acquisitions have left a hodgepodge of technologies
I am sure you can look around your company and make several similar comparisons yourself. All the warning signs are there, but what can be done to avoid catastrophic failure?
New construction
If this were a new home build, we could engineer a modern plumbing system with a supply manifold, new fixtures, flexible PEX piping , and new waste lines with adequate diameter and venting for future growth--laying in pristine lines as the home is built.
Unfortunately, in most enterprises, much like my home, starting with a clean slate is not an option. We have to live in our home as we resolved these issues, and this is how I tackled it.
Incremental transition
I first had new main waste lines and PEX manifolds installed without connecting any of the existing plumbing to the new system.
I remodeled each room that used plumbing and connected each room to the new system. I proceeded to remove as much of the old plumbing as I could. Once all of the fixtures in the house were using the new system, I removed the unused plumbing that remained. This enabled me to limit my risk and only affect one fixture at a time during the remodeling process. This allowed me to refinish my basement rooms with much greater confidence, now that there were far fewer points of failure.
There were a few challenges along the way and many opportunities to learn from my mistakes. Luckily, by limiting my exposure to risk and keeping my work focused on small---but right-sized---deliverables, I was able to persevere.
One example was when I found that my initial manifold did not supply enough flow for the large soaking tub in the first bathroom that I remodeled. This would have been a nearly unrecoverable mistake. It would have been extremely costly if I had not discovered it early and had been working on small deliverables.
This is why I feel it is important to test systems with an adequately-sized effort to find issues throughout the early stages Choosing a very small project can leave these problems unidentified until it is too late to “course correct.”
Remodeling your software delivery value stream: 6 steps
In an enterprise, we can handle an upgrade of the software delivery value stream with modern DevOps principles in much the same way. Here are 6 steps to keep in mind:
- Start with a modern---both hardware and software---DevOps delivery infrastructure.
- Choose a consulting partner to help develop your Agile culture and train your management, operations, developers, InfoSec, and QA staff who will develop your pilot program.
- Do not strangle the new value stream with your existing process. Allow the proper checks and balances to be developed organically and have all participants focused on avoiding bottlenecks or choke points. The goal is streamlined delivery of small low-risk units of work to production.
- Deliver a medium-size application (large enough to tax the process) using Lean Management, Scaled Agile teams, CI, CD, and flesh-out the new DevOps process.
- Once you release the application to production and are achieving five or more releases a day, you can roll in additional personnel and projects. Use existing staff to train teams on the new processes and coach them according to the revamped culture. Multi-day releases prove that you have worked the bugs out and the culture is taking root.
- Finally, once you have deprecated all of your legacy waterfall projects, dismantle the remaining infrastructure. Pat yourself on the back. You have made the shift to a modern DevOps software delivery value stream!
It is imperative that both management and all subordinate groups who participated in the pilot program are fully empowered to make decisions and prepared for failure. The cultural shift is a huge change from the bureaucracy and delay associated with quarterly releases and waterfall methodologies of the past, and will require some trial-and-error.
There are several other benefits that are realized from the newly implemented value stream:
- Development, Operations, and Information Security become aligned and companies can begin to reward teams on quality and quantity of delivered value to the customer.
- Releases can be directly attributed to small teams and the individual rewards can be smaller, but more frequent. Frequent successful releases highlight the success of the new culture.
- Customer satisfaction grows as the enterprise becomes more responsive to the ever-changing technical environment.
- More modular, less tightly coupled software and services are created. As the deliverables shrink, so should the complexity of the code and the need for regression testing.
Band-Aid repairs don’t work
I should have read the signs and re-plumbed sooner.
I would have saved a fortune on “Band-Aid” repairs and could have saved the cost of doing an entire remodel of my finished basement. In an enterprise, it is even more important, as all businesses depend on IT and software at ever-increasing rates. The inability to reduce lead times dramatically could spell doom in today's hyper-competitive markets.
If you see the warning signs, act and make the cultural shift to support DevOps before your software delivery value stream fails catastrophically.
