What does one mean when they say they want to ‘adopt’ or implement DevOps? What is a ‘DevOps Solution’? DevOps is not a product. It is not a process. It is a philosophy. A philosophy that includes principles and practices effecting People, Processes and Tools.
Adopting DevOps hence, is not just about adopting a product or a process. It is about undergoing Transformational Change.
Why DevOps?
Organizations want to create innovative applications and features. They create these applications or services to solve a business problem. Either for themselves (better CRM system) or for their customers/users (better Web Portal). Whether they are a startup with an innovative Mobile App; a large financial institution with their complex transactional systems; or a Military contractor building a ‘dirt-to-space’ real-time battlefield management system, they are all looking for a way to make what they build better.
Better can mean many things. For the startup, better may be the number of new features they can get out to their users, fast. Quality may not be their highest priority. For the financial institution, better may be minimizing downtime for their systems every time they push out a new capability. The number of new features they release may be lower on their list. For the military contractor better may be ensuring close to 100% reliability of their system. Innovative features may be trumped by quality and reliability for them.
So, the reason to adopt DevOps will vary considerably from organization to organization and even from team to team within the same organization. The team building the customer website may have very different priorities than the team deploying the new HR system. All reasons are good reasons, as long as it is not ‘it’s the buzzword the VP heard at the last conference’.
Let’s list some of the reasons an organization may adopt DevOps:
- Time to value
- Speed of deployment
- Reduce cost/time to deliver
- Reduce time/cost to test
- Increase test coverage
- Increase environment utilization
- Minimize deployment related downtime
- Minimize deployment time issues (you know, the weekend long deployment marathons)
- Minimize roll-backs of deployed Apps
- Increase the ability to reproduce and fix defects
- MInimize ‘mean-time-to-resolution’ (MTTR) of production issues
- Reduce defect cycle time
- Reduce challenges related to Dev and Ops collaboration
…and I could go on. In a nutshell, the reason(s) to adopt DevOps has to be a reason that provides value to the organization.
The goals for DevOps an organization has will determine which practices and principles of DevOps the organization needs to adopt. I have worked with an organization whose biggest challenge was the limit they had on their ability to test often and thoroughly. Their QA environments took too long to be ‘refreshed’ for every test cycle, extending their test cycles to unacceptable lengths. What they needed to do was virtualize their test environments with ‘production-like’ systems (more on that in the next post), which could be provisioned and populated with ‘fresh’ test data in minutes/hours, rather than the days it took them currently. For them, adopting Continuous Delivery to Test, by building a Delivery Pipeline that would allow them to automate the cycle from a developer kicking off a build to tests being run in a ‘freshly’ provisioned environment, would add tremendous value. This is where they should begin and limit their DevOps adoption too. Once they see value from this one capability, they can examine other areas of challenges for them that can be addressed thru DevOps.
It is not easy or cheap:
Adopting DevOps is not easy or for that matter cheap. Not in terms of cost of tools, people, etc, but in terms of the effort it takes. It would be a multi-month, or depending upon your existing maturity, even a multi-year project. The good news is that if done right, starting and progressing down the path can produce value pretty early. I repeat, if done right.
The main reason it is not easy is because of the transformational change your organization will need to undergo. The People part of the equation will take more effort than the Process or Tools.
So, assess your areas of improvement in your delivery cycle. If you do not have the skills in-house, hire a consultant/consulting organization to conduct such an assessment. The assessment would help determine which areas in the DevOps spectrum of capabilities would provide you the highest ROI. Which would address the key pain-points you have. Then create a roadmap for adoption. <start commercial break> We at IBM conduct such assessments all the time. Contact us…</end commercial break>.
More on Transformational Change for DevOps in Part II.
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
Understanding DevOps:
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 3: The Battle of Dev vs Ops
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
Adopting DevOps:
- Adopting DevOps – Part 1: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
DevOps books I have written:
Other DevOps Posts:
- DevOps 101 – Concepts and Basics (Slides from IBM Innovate 2013)
- What is Water-SCRUM-Fall?
- Leveraging DevOps in a water-SCRUM-fall world
- Monetate’s 12-step program for Continuous Delivery
- The State of DevOps (by PuppetLabs)
- DevOps for Mobile Apps – Slides from IBM Pulse 2013
- Chef for DevOps – An Introduction
Home: sdarchitect.blog 
I’m actually missing a number of critical KPI’s. If we assume DevOps is applying manufacturing principles to software, we can inspire ourselves from the manufacturing KPIs, and nothing is better than the Supply Chain Operational Reference (SCOR) model. So, let’s start with “Perfect order fulfillment”, the percentage of time the DevOps teams delivers all the functionality required by the business in the timeframe agreed upon with no defects. “Order fulfillment cycle time”, the time between the business request and the moment the application with the required functionality is available in production. And I could go on like that.
@Christian, interesting thinking. I would like to hear if you are able to apply some of these KPIs to DevOps and what results you get.
I would however point out that the analogy between DevOps Delivery pipeline and an Assembly line breaks down as one goes deeper… Assembly lines in a factory produce ‘widgets’ that are identical in each batch. The goal is to bring the variance down to zero. In application delivery however, each cycle produces new, mostly unique code. The variance cannot be zero. This impacts leveraging the KPIs from assembly lines for delivery pipelines significantly.