2. 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.
3. Survey Results: Whatâs Stopping Businesses Automating? 2
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
board.
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
channeling them.
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.
4. 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
automation projects?
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?
5. Survey Results: Whatâs Stopping Businesses Automating? 4
4
Why is the banking industry a natural
customer for deployment automation and
RapidDeploy?
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
weight.
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
whatever.