Over the last couple of years, larger enterprises started to see the value in devops, helping to shift the movement into popular business discourse. If every company's now a software company, as Microsoft's Satya Nadella famously claimed, then being able to fail fast and push releases out in hours not weeks is critical. But what are some practical steps that can be taken?
First, suggests Accenture's MD for devops Martin Croker, it's worth defining what devops is likely to mean for your organisation. It's a broad term, he says, generally meaning a collection of behaviours and tools – encouraging collaboration between departments, automating processes, and so forth.
"But when we talk about an organisation being friendly to devops, we're probably more likely to be talking around the processes of automated build and delivery," Croker says.
"The processes of branching strategy for configuration management, and really that drive of trying to get the development and operations teams harmonised around delivering their business outcome, and trying to drive continuous experimentation."
In real terms, Croker says this translates to a huge focus on cycle time – how quickly a business can go from having an idea to making an idea live.
"There's a very IT component to that, about how quickly the development team is able to produce and add it to the code base," he says.
"But also, how quickly the operations team is able to accept it, operationalise it, and get it to the point it adds business value."
With this in mind, it's worth any organisation remembering that there are roadblocks to the practical aspects of implementation.
"I like to think of it that there is a set of things an organisation can do to inhibit devops," Croker says.
"That could be a governance process that allocates funding on an annual basis – poor flexibility is not going to help an agile delivery.
"Enterprise companies are finding they have their legacy structures, infrastructure, teams and processes, so getting to devops is slightly harder," says HPE's senior director of strategy for devops, Ashish Kuthiala.
"There might be pockets of team that are doing devops successfully or across a couple of teams, but to scale this for an enterprise is an interesting challenge."
Kuthiala says there are a few things that he and HPE have seen work well.
"You need to have a mindset of working together, and understand we're going to have some setbacks as we're going on – there's no prescribed formula to get from point A to point B in devops in X number of days," Kuthiala explains.
"We have huge teams that figured out, collectively, the common goal for us between the teams – and the kinds of metrics we want to keep improving over time.
"Let's figure out what works and what doesn't work for our organisation in these loose boundaries – as long as we are making progress towards continuous improvement, and those metrics look good, and we're trying to deliver better results to the business, it starts to work."
Get the buy-in
It's also critically important, Kuthiala says, to make sure executive management and leadership are supporting your efforts – they need to be clear on the concepts of failing fast and experimentation.
John Ediger, IT Strategist at Hewlett Packard Enterprise says the company brought in a culture of continuous improvement that also got the management team involved in the concepts and benefits of devops. They focused on that, and every month each team would pick a small set of goals towards devops, and when they made that progress, they'd review their work, make adjustments, and set a goal for the next month.
"It all has to be based on what we're trying to do in each group, on a set of organisational metrics and goals we're trying to achieve, so it's not just devops for devops' sake," Ediger says.
"That cultural shift is the hardest part. We were absolutely finding it's 80 percent practice and culture and 20 percent tools. So we started small and figured out how we can scale this, and then do the continuous improvement process. There's three core things we're driving to, and that's collaboration, codification and automation."
According to Mandi Walls, consulting director for EMEA at automation specialists Chef, there are a few steps organisations can take to address that cultural challenge.
"Open brown-bag sessions – casual meetings over lunch – anything that helps share the kinds of work people are doing," Walls says. "Open stand-up sessions, where anybody can join the team stand-up and learn about what each other is doing during the week. Regular reviews, and demos of things that they're doing.
"Even for operations folk, who are like: ‘here's the dashboard we built, here's how the monitoring works', those are the things that help put a face and a voice to the work that they're doing. So they're beginning to get an understanding of what the teams actually do, and to try to reach a more human conversation that there's actually people involved in those teams."
By persisting in bringing different teams together in pressure-light, low-stress situations, the hope is that people interact with each other in ways they might not be used to – think constructive conversations between teams rather than bureaucratic ticket-filing processes.
"You'll have a more a more personal relationship, rather than silos represented by formal requests and all these things that are necessary when you don't have a lot of interpersonal communication," Walls says.
"The breakdown of that becomes much more person-to-person and conversational."
From a technical standpoint, Walls says the "baseline, 101-level of getting started" is bringing in system automation and the use of source code control mechanisms like Github, where software components can be shared internally.
"It's where you have this explicit documentation in those components, for everything that's going on in the systems and all the source code is saved and available," Walls says.
"All the system configurations, similarly, are also saved and available – so you have a starting place where everything is shared and apparent to all of the stakeholders.
"As you become more proficient with those over time, most of the teams we work with end up with their goal being some kind of continuous deployment, continuous delivery situation – where they're making small changes on a continuous basis and it runs through some kind of automated pipeline. That's whether it's our product, or Jenkins, or Go, or one of the others. To do all of the automated testing, provisioning and integration components, and then it just pushes out to production."
Walls says this does take a certain level of technical competency to get the ball rolling. But provided that talent exists, is it perhaps worth bringing in outside consultants to put management and execs at ease?
"The term devops is a door opener at the moment, and is being used as such," says Accenture's Martin Croker.
"There are pitfalls and things to watch. Devops is a change in which an organisation behaves, so an external organisation can act as a catalyst to help you get there and bring a new perspective – they can bring the tools and the tricks – but the really important thing is that they are leaving those behind, and leaving you substantially better than when they arrived."
Croker says that there are certain steps to take to ensure that the approach remains in place. "We make sure the teams understand what they are doing, we work through different ways of working, we speak about blame-free ‘postmortems' and how we use them, and we support them for a period of time."
If all goes right, Croker's team is no longer there because it doesn't need to be.
Specifically for having management on side, HPE's Ashish Kuthiala says that even simple things like getting the VPs and directors from different teams together can be easier with a neutral third party to broker the conversation.
"I was in a customer meeting in which the VP of ops and the VP of apps had come together for the first time, to discuss how to optimise their end-to-end software delivery life cycle in the context of devops," Kuthiala says.
"The first question I asked both of them was: what drives your objectives? And the VP of apps said, well I get paid to incentivise rapid innovation in the marketplace, more frequent software releases.
"The VP of ops smiled at me and said: ‘My job is keeping the system stable. It can go down. The more changes you make, the more unstable my system can be, and I'm always scared you're going to break something!' They were completely opposite metrics. Being in the same room can move that on to talking about how to get to a common goal. It's a big cultural thing, and that dialogue was not facilitated internally. They were at loggerheads."
And HPE's John Ediger stresses the importance of ‘rapid feedback loops' – the ability to immediately gain feedback on a new release and fix an issue, not just in development and operations but across many different areas of a business.
"The feedback loop concept is fundamental whether you're in planning, or doing any kind of marketing or business venture," Ediger says.
"If you tipped your mindset to: ‘let's not create a long lead time' but instead shrink that down just like you do with a devops continuous delivery pipeline. Try to roll that out in small batches, get the immediate feedback. You can apply that pattern and principle to most business areas, and I think that's fundamental."
Kuthiala equates devops to physical manufacturing, where the concept has its roots. It's a useful metaphor for introducing agile or continuous development processes into a workplace.
"Think about the car, where a team works on one thing and hands it over to the next person. At the end a car comes out. Doors are assembled, an engine is put in – software delivery lifecycles are really not very different.
"If putting the engine in takes six hours, it doesn't matter how fast the chain before or after that goes, that's your bottleneck. In software, you can identify those bottlenecks in the same way. Where are the biggest bottlenecks, where you wait for testing for three months? If that's your biggest bottleneck, let's go solve that first, and then look at the next biggest bottleneck."