Some days it feels like everyone is talking about Devops. If you read industry blogs, follow groups such as Back2ITSM on Facebook, or talk to people in our industry, someone will start to mention DevOps fairly quickly. That’s fine if you work in an organisation that does software development, but surely it doesn’t matter to you if you don’t. Or does it?
A year or so ago, I was talking with Rob England about Devops and I couldn’t see how it would affect the types of organisations that I generally consult to; small, “traditional” IT shops with off the shelf software being used, with no development. We had a great discussion about it as part of an ITSM Crowd recording.
So, if, like me, you have your heart in Operations, what does DevOps mean, why should you care and can it help you?
What does it mean?
According to DevOps.com:
“The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Well, that’s a fairly dense definition, yet still pretty vague. I think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.”
DevOps, at it’s core is all about bringing together Dev & Ops and the wider business and ensuring that the cadence of development delivery can be matched and managed at the same pace by Operations. DevOps also encourages the use of the goals of CALMS; Culture, Automation, Lean, Measurement and Sharing.
Very (and I mean very) simply, they mean:
Culture; The culture of collaboration is one of the key ones and guides the bringing together of Dev& Ops and the wider business. It’s not about them and us, but about us all working together to get things done better, quicker and cheaper. It doesn’t happen overnight though.
Automation; Wherever possible, automate tasks. Automate testing, deployment, integration, incident resolution, everything that can be.
Lean; Reduce waste. If it doesn’t need to be done, don’t do it. Move quickly and continuously learn and improve. If you try something and it fails, never mind, try something else quickly. You are allowed to fail in DevOps.
Measurement; Measure what you need to to ensure that you know that you are improving.
Sharing; Share responsibility & knowledge between Dev & Ops. It’s what it’s all about.
Why should you care? Well, the world is changing. While there are still many organisations out there who “only” do traditional IT and use the ITIL framework as the loose guide to handling calls and changes, we need to acknowledge that there are different and often better ways to do the job. So you need to be aware of what is happening and be open to changing the way you work. Do you want to be that person who says “We’ve always done it that way!” or “ That’s not how we do it here”?
Can DevOps help you? Yes. It can make you work together and remove some, if not all silos in IT. It can also help you work closer with the wider business so that everyone understands the drivers and priorities for the work that IT does. It can help you to trust each other more and move away from the blame culture that still persists in some organisations. It can allow you understand that it’s ok to try something and fail. It can make you think about automating stuff through scripts or pre-approved changes. It can encourage sharing.
There is a lot of good stuff in DevOps which can and should be adopted by those with no Dev.
So how do you start the thinking?
There is also the Phoenix Project business simulation workshop which is based on the book by Gene Kim et al and takes you through the usual issues experienced by IT and guides you through applying DevOps principles.
Get in touch and see how we can help.