Adopting DevOps – Part I: Begin with the Why

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.

Understanding DevOps:

Adopting DevOps:

Other DevOps Posts:

About these ads

, ,

  1. Chef for DevOps – an Introduction | Sanjeev Sharma
  2. Understanding DevOps Series!! | the BPM freak !!
  3. Adopting DevOps – Part II: The Need for Organizational Change | Sanjeev Sharma
  4. The State of DevOps (by PuppetLabs) | Sanjeev Sharma
  5. Understanding DevOps – Part 5: Infrastructure as Code | Sanjeev Sharma
  6. Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring | Sanjeev Sharma
  7. So, what is ‘Water-SCRUM-fall’? | Sanjeev Sharma
  8. Understanding DevOps – Part 1: Defining DevOps | Sanjeev Sharma
  9. Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery | Sanjeev Sharma
  10. Understanding DevOps – Part 3: Dev vs. Ops | Sanjeev Sharma
  11. Monetate’s 12 step program for continuous deployment | Sanjeev Sharma
  12. Adopting DevOps – Part III: Aligning the Dev and Ops Teams | Sanjeev Sharma
  13. Slides: IBM Innovate 2013 Session – Continuous Integration for System z | Sanjeev Sharma
  14. Slides: IBM Innovate 2013 Session – DevOps for Mobile Apps | Sanjeev Sharma
  15. Slides: IBM Innovate 2013 Session – DevOps 101 | Sanjeev Sharma
  16. Slides: Mobile to Mainframe – the Challenges of Enterprise DevOps Adoption | Sanjeev Sharma
  17. My ‘meetup’ with Gene Kim | Sanjeev Sharma
  18. Updated DevOps 101 Deck | Sanjeev Sharma
  19. Understanding DevOps – Part 6: Continuous Deployment | Sanjeev Sharma
  20. Adopting DevOps – Part IV: Adopting Continuous Deployment | Sanjeev Sharma

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: