How to start a deployment automation project 1
First you’ve got to identify your problem – and a need.
There doesn’t have to be a disaster that brings the problem. It can be a
number of things. Facts certainly can be a catalyst; Why has this all
failed? We don’t have control of our CM?
It also can be things like the cost of your existing resource. As your
project grows, say, to encompass more and more fixes, more and more
features, more and more customers, the infrastructure grows and
scales and the code base grows.
You get so many more people, and it becomes unmanageable, so
there becomes a point, a tipping point where you just can’t go on like it.
You have to change. That’s when people start looking for tools that are
going to make their life easy throughout the whole ALM piece.
In terms of the people involved, is it technical architect led, or is this
actually at a level higher, the CIO saying actually, there’s a problem
we’ve got to address?
It can come from different layers. It doesn’t typically come from
grassroots, but I guess technical architects would be more likely doing
it on their project or their program.
Really, you need a CIO buy-in to say we need to automate everything.
If you do it from a technical architect point of view; you might well end
up automating one part of your organization. If it’s from a CIO point of
view, then there’ll be lots of technical architects working together to
automate the whole thing at once.
Is it too big of a project to actually go
through all the environments?
I think it’s too big a project to say, “We are tomorrow going to move
across our organization and automate everything.” I think for the CIO to
say we’re going to identify where we’ve got the biggest problem, or
maybe even a project that doesn’t have the biggest problem but is a
new project, we’re going to implement these practices across that
project, so there is no human interaction all the way through the
deployment process. We have a smooth process from development to
production, which is going to sit outside of our existing processes and
procedures. We’re going to experiment properly and test with
something entirely new, and let’s see how it goes.
You’ve got to put the will in to make it work.
Survey Results: What’s Stopping Businesses Automating? 2
Who in your team would you choose to lead
at that point?
Interesting question. Who I would choose would firstly depend on what
we are talking about – manage it or implement it?
You’ve got to put together a team. If you’ve got a new project, you have
to put together a team of people who embrace change. From the
project management point of view I suppose that would have to be
somebody who’s been proven in this area before, or maybe elsewhere,
or who is willing to change.
From the implementation team, I would say, and having been in this
position myself, the person that’s the hero, fixes everything, the go to
person, would either be your biggest asset or your biggest detractor.
Because they’ll either protect their position and not let anybody do
anything, in which case you’re kind of back to square one, or they’ll
drive it forward and be absolutely key to implementing it.
What they’re effectively going to do is implement all the stuff that they
do themselves to keep the show on the road. If you can get them to
automate themselves out of a job on that particular project, that’s the
key person or people. That has to make sense?
That might be difficult because they might be prima donnas and difficult
people to work with, but they are the ones that you need to get on
I guess what you can sell to them is if it works on this project, we’re
going to implement this everywhere, so you’ve got a job for life, which
would appeal to them I suspect. These people have been good for the
organisation; they’ve solved problems, but also helped cause problems.
In the recent DevOps survey one question "What was stopping you
from doing deployment automation" was answered with ‘The problem is
a cowboy hero culture.’ It’s taking the cowboy hero and actually
When will we see ROI?
It’s a big investment in time and money to kick deployment automation
off and sometimes the payback comes further down the line.
However, you should see ROI on that first project, because that first
project will deliver faster and be easier to manage, and all the lessons
learned will able to be moved onto the other projects. Of course the
other projects will be more retrofitting, because your pilot’s potentially a
green field probably.
How to start a deployment automation project 3
Maybe you can’t do it on a green field project, it’s best if you pick a new
project. If it’s a large enough company, there are plenty of those, but if
not then it’ll be some project that’s failing and needs to be sorted out
ASAP, and maybe do it on that.
The trouble with that is you start having failures when you start doing
your deployments and you get a bad name.
Is there any such thing as a green field
project anymore for an organization?
Doesn’t everything integrate?
Well it all integrates, but you have new projects that kick off all the time.
I mean I remember at one bank, we worked on lots of upgrade projects
from old projects, but also 20 totally brand new new projects a year.
Can you give examples of what some of
those projects might be in a bank?
The biggest one that I ever worked on was the total rewrite of Internet
banking, which was really going from C++ to Java. It was a brand new
project. There are lots. I can think of others like SOX-compliant projects
when SOX-compliance came in. There were new projects that kicked
off. Where it hit the IT teams from the WebSphere point of view was we
were implementing solutions for SOX. Solutions that enforce SOX
compliance for example, or Basel II. Any of those types of things.
How are these green field deployment
Well effectively, they are. You can do them in one of two ways. You can
put them into your usual sausage factory and go right, that’s another
project that goes in, gets assigned a project manager, it goes through
this process, all the ITIL stuff, it does all of that.
Or in the case that we’ve spoken about, you can say we’re going to
take this completely outside that and start again. We’re going to have a
team that consists of developers and operators, and pull people from
dev and ops and put it on some new infrastructure or new kit and build
it out in the cloud. I mean, how far do you want to go?
Survey Results: What’s Stopping Businesses Automating? 4
Why is the banking industry a natural
customer for deployment automation and
Because the banks have been going for a long time. They were the first
people to implement because banks generally have implemented large,
complex IT systems for many decades. They’re now creaking under the
Unfortunately for the banks, because they were the first to implement
large IT systems, they’re now the ones that are falling behind the
newcomers to the industry because their IT systems are so sclerotic.
So if you started again, you would have a
totally different architecture, wouldn’t you?
That’s why the banks need to change. I think they’re recognizing it now.
They can’t carry on with these archaic systems that nobody knows how
they work. They need to migrate off them.
Is automation a way of creating that?
I mean, because they look at the likes of Facebook. Big banks, they’re
not going to be a Facebook, but they look at those people and they
think, ‘Well, if we could just do 25% of what they do, then we would be
in a much better place.’
It’s like in the banks you can’t do anything at the moment. In a way
they’re so frightened about deploying anything to production that
they’ve put in huge amounts of process, and this is where ITIL is
responsible to that extent. They’re terrified of deploying to production.
They’ve put huge amounts of process in place to basically stop you
from deploying to production because they’re terrified of it.
What’s that do? That means they’re basically stopping you from
deploying new changes that are potentially market differentiators or