Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Introduction
One of the challenges of introducing DevOps in the setting of a traditional (i.e. siloed, waterfall etc) Enterprise is where to begin.
It’s certainly something I wrestled with alongside the CTO for quite some time.
It’s not possible to impart years of experience of moving a large company to a DevOps ways of thinking but I hope to give the main 3 pillars of how I’ve approach it previously.
Note…none of it mentions technology and tools! DevOps is primarily a cultural idea and therefore affects people above anything else.
Step 1 – bring in the Rock Star
If you are moving to DevOps in your organisation, then bringing together different people from different silos and then expecting them (under their own steam) to magically cooperate and agree on everything is a little unrealistic.
If you are dealing with historical teams and employees – which I suspect most of you are – then breaking down silos is likely to be a significant challenge.
Aligning incentives makes things a lot easier. If both your devs and ops guys are paid a bonus depending on how much “change” they do in a year is a simple way of getting them to agree on whether they should automate releases for example. That’s a little too simplistic but hopefully you get what I mean.
This may well come at the cost of something else though. The first thing that springs to mind in the last example is quality.
Let’s put everything straight into live! We get paid for it!
Ok so that isn’t going to work.
Sometimes, at least to begin with, you need to bring people together and ultimately empower someone to make decisions when one can’t be reached through consensus. I’ve seen a real danger in DevOps of death by committee. The more silos you bring together then potentially the greater the possibility of them not making a decision.
You may have heard about this idea of DevOps rockstars. Guys (and gals) that get DevOps inside and out. People that understand all sides of the coin (development, DBA, infrastructure etc).
They try and influence through education and persuasion and point people in the right direction. They help the silos reach the right decisions themselves rather than a top-down “do what I say”.
All said and done sometimes this open inclusiveness doesn’t always work and someone needs to just stand up and be counted.
So what’s my point?
If you are trying to move towards DevOps then hire a rockstar (I doubt Rod Stewart is suitable btw). Someone that has done it before. Someone with a very mature sense of what DevOps is and preferably someone that has done most of the jobs he/she is trying to influence.
Moreover, hire someone who’s first instinct is to try and bring people around to their way of thinking. And lastly, someone who isn’t ultimately afraid to put their privates on the line and make a goddam decision.
Step 2 – look at your people structure
The traditional definition of DevOps is to break down the silos between Development and Operations so that they accomplish shared goals.
However, I’m a keen advocate that DevOps isn’t just Dev and Ops (see http://enterprisedevops.blogspot.co.uk/2014/07/devbiztestreleasethingyops.html).
It’s about all the functions that come together to achieve meaningful change.
The devs, the ops guys, the business and techies should all have shared goals and incentives. Where possible they should be sat around the same desk. The team should rise and fall collectively (there is no “us and them”). The team should manage change from cradle to grave (requirements, build, test, deploy, support).
I think we should rename Devops to “DevBizTestReleaseThingyOps”. Catchy.
To that end, DevOps is as much to do with “people” than it is about new tools and processes.
With that in mind, potentially you are talking about some fairly radical changes across a wide number of people of various skills, experience and personality types. I guess it really depends on what your organisation is structured like, the skills of your team and many other factors. For my company (a large UK insurance company) however, it’s meant some fundamental changes.
We started by aligning change functions (devs, testers, BA’s etc) to individual business units (rather than monolithic shared group services).
That fundamental change has been sponsored on the back of some early and small wins by implementing things like Continuous Integration and labeling it “DevOps”. Ok so it’s not DevOps but if using that term starts to get visibility and movement within your organisation then I don’t think that’s a bad thing. I always believed we needed a banner for the modernization of the department to fly behind. If that banner reads “DevOps” then so be it.
That early small success was really vital to us.
When we started out we had a lot of push back and negativity….
- Why are you telling me how to do my job?
- You are using the wrong tools
- I don’t see the benefit
- I know more about this than you do
- What you are trying to do is easy
- We don’t have the right people
- This is a hipster idea for the likes of Facebook
- There are regulatory reasons this won’t work
Basically everything under the sun.
That’s stressful when you are trying to do the right thing and move the incumbent forward.
I don’t think we helped ourselves too much to begin with. There was too much of my team trying to pick up and change other team’s technologies and processes. Not enough leading the other team to water and helping them implement something themselves. Lesson learnt.
Step 3 – create a team to help others
I mentioned earlier that DevOps is cultural idea and not a job title. Definitely not. Unimaginable.
So how is it I run a “DevOps” team? Surely that’s a collective of “DevOps engineers”?!
My team “Platform Services” supports the idea of the change platform at my company. The change platform consists of tools such as Jenkins, Puppet, uDeploy, Teamcity, TFS and a few others.
Someone ultimately needs to “own” the tools making sure they are maintained, creating best practices and establishing a roadmap for the future.
My team goes beyond this and helps different change functions adapt to the change platform and are evangelists for things like DevOps and Continuous Delivery.
With DevOps being concerned with breaking down silos its contradictory to have a team that bottleneck of knowledge and skills. To this end, Platform Services is the silo-buster – we help others pick up the tools & processes and implement them.
For example, we don’t do deployments ourselves but we do sell the benefits to other teams and help them to adopt the tools and processes.
I think this is a good model and helps spread the success of DevOps around the IT function.
It helps that consultancy from my guys is effectively free to other parts of the IT team (thanks to an enlightened CIO & CTO).
I hope you found some of that useful. Feel free to check out my blog on my move to DevOps: http://enterprisedevops.blogspot.co.uk/
Good luck and get in contact if you have any questions or comments.
