How to cope after your CIO Googles DevOps

Baby steps and a bottle of whiskey

So your CIO thinks that cloud, BYOD and big data are all passé and now has declared The Next Big Thing in the IT department will be DevOps — and hey, even worse, he or she used the Google and has seen that Big Vendor X and Big Vendor Y offer 'DevOps-ready products' so all that it's going to take is picking up a bunch of overpriced automation tools.

Step one: Medicate yourself with some combination of paracetamol, scotch and Valium. But what do you do next? According to Gartner analyst Cameron Haight — who, for the record, did not suggest the all-important step #1 — experimenting with a DevOps-style approach does not need to involve a big bang-type initiative.

Start off with projects that are not super complex and have a high degree of uncertainty associated with them — because chances are, you're going to encounter failures along the way, the analyst told the Gartner IT Infrastructure Operations and Data Center Summit in Sydney.

When it comes to low uncertainty, low complexity projects and low uncertainty, high complexity projects, it's worth looking at more traditional methodologies, according to the analyst.

DevOps is about bridging the divide between development teams and IT operations teams. "It aligns operations and development together, because right now in many organisations you have development metrics and you have operations metrics and those are working at cross purposes," Haight said.

Patrick Debois interview: DevOps and definitions

As Agile approaches to development become popular and as enterprises explore techniques such as continuous deployment, there can be a tension between the teams producing rapidly changing software products and the teams mandated with ensuring stability for production systems.

"In that sense what I see in a lot of organisations today is you have development teams paid for change and you have operations teams paid to minimise the impact of change," Haight said.

The first step doesn't have to be a giant leap for humanity: It can begin with just co-locating IT and operations teams. "If the teams are co-located, communicating is going to be a lot easier, especially when you’re introducing new concepts, new processes," the analyst said.

"You don’t want the time lag; you don't want the separation of people to add confusion to the environment."

"I had one client tell me that just the practice of moving their operations team to the same floor as the development team — magic happened," Haight said.

"Why? What he told me was really kind of funny. If you’re going to run into someone on the kitchen on the floor you’re not going to send them a really bad flame mail... They actually interspersed their teams together. So it wasn’t just ops on this side of the floor and dev on this side. They actually intermixed their desks.

"And what they found out is — one of the ops guys said 'You know I walk around the cube to my developer colleague and I see that picture on his desk and gosh — he had human children! He wasn’t the devil incarnate! Wow — he wasn’t this bad guy that I thought he was!'

"So merely the act of moving people together created organisational dynamics that were truly amazing for this one client."

To some organisations DevOps may just equate to technical solutions such as automation or release management, and DevOps discussions often turn into discussions about tools, Haight said. But fundamentally, it's about cultural change within an organisation.

"At the end of the day... DevOps is ultimately about what? It’s about changing culture. It’s not implementing cool tools; it’s not about implementing just enough process per se. It’s about changing our culture."

And that means within an organisation there needs to be understanding, desire and ability to change, the analyst said.

DevOps initiatives need to have linked KPIs, but they need to be the right ones. For example, one way to overcome the contradictory interests of dev and ops teams is shifting an emphasis away from time between failures as a metric to how rapidly service can be restored.

Senior management buy-in is also important, Haight said. "Do they have you back?" the analyst said. "Why is this important? Because you are going to fail. Fail miserably to start off.

"We’re introducing a whole new set of processes, and if the CIO isn’t on board and doesn’t accept the fact that we’re going to be stumbling a little bit when we first start off, it won’t be a happy time for anybody."

Fundamentally there's no cookbook for DevOps, Haight said, and what it means to your organisation is going to vary. "DevOps is a compass," the analyst said.

"It's not a roadmap. And how you do it in your organisation will differ, organisation to organisation."

At least one thing is certain: Chances are, you're going to need a stiff drink at some point.

Read more: Some Aussie businesses using DevOps to improve customer engagement and reduce IT spend: report

Tags GartnerIT OperationsdevelopersDevopsagileagile software

More about AgileGartnerGooglegosh

3 Comments

Tamarack Bugaroo

1

I feel like I joined a discussion at the half way point. What a confusing article. What exactly is dev ops?

t.michaud

2

Dev Ops is the idea of combining the roles of OPS (operations support) and development (software running).

Traditionally these roles are separate. The same person who writes code can't push the same code to production.

But there are those claim there is value in allowing the same people (or at least some people) full access to production.

chris haddad

3

Hi Tamarack, DevOps = Principles + Best Practices + Tooling. see this blog post
http://blog.cobia.net/cobiacomm/2014/03/06/devops-equals-devops-principles-plus-devops-practices/

Comments are now closed

Amazon vs. Google vs. Windows Azure: Cloud computing speed showdown

READ THIS ARTICLE
DO NOT SHOW THIS BOX AGAIN [ x ]