This article is more than 1 year old
Ready for DevOps? Time to brush up on The Office and practise 'culture'
Beyond the tools: DevOps and you
DevOps is the Holy Grail that could save your IT architecture – or so we’re being told.
Do DevOps properly, and the IT department can deliver software continuously and fix complaints more quickly. This makes line of business managers happier, which is lovely. It also gives you more time to listen to their requests for new widget cost-averaging functions which they will then demand you implement. This is less lovely.
You win some, you lose some.
Just don’t get too excited – not yet, anyway. DevOps isn’t a single product, or even a set of products. And if anyone offers you DevOps in a box, you should run away - fast.
Rather what’s emerging as DevOps is a combination of skillset and a mindset along with toolset. So, then, if you’re going to do DevOps effectively, you’re going to need a few things in place. But what are they?
John Willis and Damon Edwards, who co-host the long-running DevOps Café podcast, have coined the term CAMS that stands for: Culture, Automation, Measurement and Sharing.
That’s a really good starting point.
“Look at the cultural side,” Splunk chief technology advocate Andi Mann told The Reg. “Changing corporate culture is no small thing. Its adopting shared values, and systems thinking. It’s accepting the consequence of having smaller deliverables and iterating faster on them.”
DevOps requires a significant change to the way that teams develop, test and deploy software. That’s a problem for firms who are allergic to it. “This inertia is one of the biggest blockers to any sort of innovation,” according to research director for development, DevOps and IT operations at 451 Research Donnie Berkholz.
To start to succeed at DevOps, organisations first need a culture that embraces change - and that can only come with executive buy-in. “Especially when it comes to reorganising teams and groups into more DevOps-friendly models, executive support is an absolute necessity,” Berkholz said.
Moving towards a more DevOps-oriented culture will take significant upfront investment in time, money, training, and mean hiring people – the right people. All that spending will need buy-in and sign off.
This therefore means that managers will set expectations, and plan for small wins up front that will inspire people to stick with it for the long haul. Consequently, finding a small project to test the DevOps discipline out on is a must. Starting small lets you learn lessons and establish practices and begin to build that culture.
Ashish Kuthiala, senior director of marketing and strategy for DevOps at the newly created Hewlett-Packard Enterprise, told The Reg: “Teams seeking to adopt DevOps should embrace the willingness to fail and learn from failures to move forward,” continued Kuthiala.
If you have managers in place who rule through fear, humiliation and threats, it might be time to rethink your team before you start.
This cultural shift has to be pushed through all of the teams involved in DevOps, and that means motivating them. A lead advocate should be the lynchpins of process change. They will need to ensure that everyone sees something in DevOps for themselves, which in turn requires a solid understanding not only of peoples’ roles, but what they need to get the job done. And it also requires a culture that avoids blame.
So what of automation – that second key stage in DevOps? The idea that’s gaining currency here, espoused by cloud hosts such as Claranet, is to build consistent environments from templates or scripts. That implies the use of tools that support that automation process, which will typically be programmatically accessed, and therefore API-driven.
This means laying the ground for open source and cloud-based tools for tasks like configuration management and continuous integration, so assessing procurement and usage policies is an important part of the preparatory process.
Tools are all very well, but a legion of failed projects will confirm that simply winding them up and watching them go is not enough. There’s an element of refinement too. After all, you don’t want to automate inefficient processes.
One of the prerequisites for an effective development, testing and operations process is visibility into how existing processes work, and who’s involved in them. You need to understand what everyone wants, and how they want it.
“People across commercial and technical parts of the organisation need to come together to agree what the key challenges facing the organisation are,” said Kief Morris, EU practice lead for ThoughtWorks told The Reg. “Otherwise, different parts of the organisation will be pulling in different directions.”
Monitoring and measuring systems enables operations staff to pinpoint problem areas with applications so that they can be flagged quickly for developers. It’s also a good way to identify waste in the system, and it makes people supportable and accountable to each other. Before you can begin the measurement process, though, you have to know what you’re looking for.
Identify they key performance indicators that you’re going to track, said Splunk’s Mann. “Find that out and make it clear to everyone so that you can baseline your performance before you start and measure your improvement continuously,” he suggested.
Measurement is only useful if you act on the data and information it creates – that’s how the oh-so-talked-about culture of “continuous improvement” you might have heard about can begin to be achieved. And, that is where the sharing comes in. Some of the measurement will be data-driven, with solid metrics captured by the automated systems. Some of it will be less tangible, though, requiring qualitative feedback from users and managers.
On this basis, some would argue that DevOps is a never-ending process. Neil Thomas, Claranet product director, said: “Each improvement will give you back more time, which you can then use to improve other processes. Make sure everyone logs their feedback on the DevOps process, and act on them fast.”
This collaboration layer serves more than one purpose. It encourages feedback, but can also be used to help manage a shifting reporting structure. In a DevOps environment, developers, operations staff and users are unlikely to interact with each other in the familiar old ways, warned Morris.
“Organisations need to be willing and able to change the way that work is planned and delivered, possibly radically,” he said. “This will almost certainly involve changing the way teams are set up, favouring fully empowered, cross-functional teams over functional silos.”
DevOps isn’t for the faint of heart, then. Open your wallet, and carve out some serious time in your calendar. Go practise your non-violent communication skills, and rewatch those old episodes of The Office. You’re going to need solid preparation on various fronts, and working out what tools you’re going to use for configuration management and templating will probably be the least of your worries. ®