►
From YouTube: Manage your toolchain before it manages you
Description
Forrester's Chris Condo details a findings of a survey on DevOps toolchains, and explains how a single application can cut delivery times and help teams be more efficient.
Get in touch with Sales: http://bit.ly/2IygR7z
A
A
Usually
it
wasn't
for
a
sales
pitch,
it
wasn't
for
someone
to
do
a
demo.
I
can
usually
find
those
pretty
easily,
and
lord
knows,
if
I
talk
to
a
sales
rep,
I
can
get
the
pitch.
I
came
to
these
events
because
I
wanted
to
meet
my
peers
because
I
wanted
to
listen
and
learn
from
them
about
what
they
were
doing
and
I
don't
know
what
motivated
you
to
come,
but
I
hope
it
is
these
op
objectives,
because
that's
what
we've
tried
to
put
together
for
a
program
of
sorts
to
talk
about
now.
A
Does
anybody
have
other
objectives
here
tonight?
If
you're
looking,
you
know
for
jobs,
I
do
have
a
web
page
up
of.
We
are
hiring
I'll,
be
glad
to
go
through
the
open
positions.
We've
got
a
number
of
them
that
are
open,
so
we
could
talk
about
that.
We
are
growing
rapidly,
so
hopefully
from
an
agenda
perspective.
This
meets
your
needs.
If
not,
let
me
know,
because
we
can
tailor
this
on
the
fly
and
make
it
and
make
it,
make
it
flexible
to
meet
your
needs
and
feel
free
to
grab
a
seat.
A
Welcome
a
lot
of
times
when
I
talk
to
people
about
the
trends
and
the
things
they're
experiencing,
they
end
up
talking
about
digital
transformation.
This
is
a
cliche
topic
and
it's
one
that
a
lot
of
enterprises
and
organizations
are
wrestling
with,
and
it's
one
that
when
I've
looked
at
the
data
and
I've
talked
to
people,
I
come
away
with
some
some
things
that
are
sometimes
disconcerting,
especially
when
as
many
people
are
doing
it
and
when
you
look
at
it,
digital
transformation
is
not
something
that's
just
happening
here.
It's
not
something.
A
That's
just
happening
with
a
few
unicorn
companies.
It's
happening
in
enterprises
everywhere
from
old,
old-style
insurance
companies
to
the
government
with
three-letter
agencies
that
we
can't
talk
about
it's
happening
in
countries
around
the
world
and
when
we
look
at
this,
the
world
economic
forum
produced
and
they
worked
with
accenture,
they
produced
a
really
awesome,
got
links
to
it
here.
If
you
want
to
pull
it
up,
but
they
pulled
up
and
they
produced
this
long
detailed
study
of
what
does
it
mean
when
people
say
digital
transformation
and
it's
ultimately
it's
about
changing
the
business.
A
A
I
mean,
I
think,
about
how
radically
different
it
is.
When
I
come
here
and
I
get
in
a
car
driven
by
someone,
I
don't
know
that
a
little
app
on
my
phone
somehow
is
enabled
how
many
years
ago
was
that
a
foreign
idea.
It
wasn't
very
long
that
it
was
you'd
automatically
get
a
get
a
cab
or
rent
a
car.
Today
I
get
into
a
car
shared
by
a
friend
of
mine
who
I've
just
met
moments
ago
because
of
this
really
cool
mobile
app.
A
A
Airbnb
doesn't
own
any
land
or
any
real
estate,
but
they
account
for
millions
of
nightly
states.
Amazing
transformation.
It's
a
huge
thing,
that's
happening,
and
it's
hard
though
it's
not
the
e.
It's
not
an
easy
thing
for
hilton
or
for
american
express
or
for
goldman
sachs
or
for
any
traditional
companies
to
go
through
this
transformation.
A
He
made
the
comparison
that
people
don't
buy
cars
anymore,
it's
not
about
buying
cars.
It's
more
about
the
phone
phones,
iterate
faster.
The
car
is
a
feature
for
the
phone.
Think
about
that.
How
many
times
have
you
thought
about?
Will
the
my
phone
be
compatible
with
the
car,
I'm
shopping
for
it's
a
radical
change,
and
it's
one
that
10
years
ago,
I
don't
think
any
of
us
would
have
thought
that
was
true
mark.
You
know
he
he
saw
that
where
it
was
coming.
A
A
Idc
did
this
study
about
a
year
ago
about
where
people
were
at
and
I
did
the
math.
My
addition
to
this
was
the
math
45
percent
of
organizations
haven't
started
if
this
is
as
big
a
deal
as
we
all
talk
about
it
as
common
as
everybody
talks
about.
Why
is
it
that
45
have
not
even
started
to
figure
this
out
and
the
reason-
and
I
think
the
reason
is
really
clear-
there
are
lots
of
challenges.
A
There
are
lots
of
challenges
from
the
different
teams,
the
processes,
the
tools
they're
using
the
silos
in
the
organization,
the
different
goals
and
objectives
and
then
think
about
it.
Most
of
these
organizations
have
goals
or
objectives
like
we
have
to.
I
mean
how
many
of
you
are
in
an
organization
where
the
goal
is
to
go
faster,
how
about
more
efficient,
maybe
more
secure,
lower
risk,
probably
all
three
right.
A
A
You
know
I
yeah
you
maybe
want
me
to
speed
up
the,
but
the
reality
is.
These
challenges
are
out
there
and
last
year,
or
earlier
this
year
we
started
talking
to
chris
about
looking
at
some
of
the
challenges
that
impact
people
and
impact
organizations
with
accelerating
software
delivery
so
that
they
can
meet
the
needs
of
the
market,
and
so
with
that,
I
want
to
turn
it
over
to
chris
and
I'll
double
click,
the
slides
to
powerpoint.
So
you
can
share
what
you've
learned
and
what
you've
discovered.
B
All
right
thanks
very
much
yeah,
so
thank
you
very
much,
john
thanks
get
blab
for
having
me
here
today.
So
let
me
see
where
this
goes
right
into
I'll.
Just
give
you
a
yeah
manage
your
tool
chain
before
it
manages
you
so
I'm
chris
condo,
I'm
from
forester
research
from
the
east
coast.
We
work
out
of
the
cambridge
office
there
right
next
to
alewife.
B
If
anyone's
familiar
with
that,
I
came
to
be
an
analyst
about
three
years
ago
previously
I
had
worked
at
companies
like
microsoft
and
then
a
long
long
time
ago,
a
company
called
digital
equipment
corporation,
but
at
microsoft,
as
we
really
started,
learning
about
this
whole
idea
of
automation,
product
focus
the
idea
that
being
focused
on
the
customer
being
focused
on
delivering.
You
know
an
experience
that
is
delightful
to
your
user
is
very
important
when
we
were
when
I
was
developing
for
them
from
99
to
2014.
B
We
were
in
their
new
england,
research
and
development
office
in
cambridge
right
next
to
mit,
and
we
were
in
out
sort
of
an
offshoot
of
their
office,
365
team,
and
so
that's
what
you
know
back.
Then
we
had
to
write
all
our
own
devops
tools,
because
microsoft
had
a
no
open
source
policy
and
we
we
did
our
own
automation.
We
had
to
write
our
own
deployment.
B
Scripts
azure
didn't
have
any
at
the
time,
and
so
it
was
really
kind
of
like
a
bootstrap
effort
fast
forward
to
today,
and
you
see
that
there's
just
the
plethora
of
tools
available,
but
you
know
not
everybody's
using
them,
so
let's
just
jump
right
into
it.
So
the
agenda
is,
you
know,
teamwork
and
tools
are
paramount
to
accelerating
software
delivery.
B
The
interesting
thing
that
kind
of
got
me
down
this
path
is
when
I,
my
very
first
research
project
was
actually
part
of
my
interview
process
at
foresters.
So
when
you
want
to
become
an
analyst
forester,
they
actually
make
you
write
a
research
paper
and
then
they
actually
make
you
deliberate
in
front
of
a
bunch
of
analysts
and
so
throughout
this
whole
process,
which
took
several
months
my
wife
kept
saying
they're
trying
to
steal
your
ideas.
B
I
did
this
whole
report
on
devops
transformation
in
the
cloud
and
then
I
interviewed
a
lot
of
teams
and,
like
you
know,
we
spend
like
10
of
our
resources
just
managing
our
tool
chain.
We
spend
this
much
time
spending
our
you
know
managing
our
on-premise
tool
chain.
If
somebody
could
offer
something,
you
know
a
cloud-hosted
tool
or
or
a
solution
that
can
alleviate
that
pain
from
us
we'd
be
willing
to
go
for
it.
B
So
kind
of
got
me
down
this
whole
agenda,
so
a
little
bit
more
about
forester
work
with
businesses
and
technology
leaders
to
develop
customer
service
strategies
that
drive
growth,
so
the
whole
customer
obsession
focus
on
the
customer.
It's
been
something
that
forest
has
been
behind
for
quite
a
long
time.
B
So,
let's,
let's
talk
about
it
right,
so
teamwork
and
tools
are
paramount
to
accelerating
software
delivery.
You
know
this
is
sort
of
like
the
the
metaphor
for
the
modern
devops
team.
Everyone's
got
a
different
role,
but
everyone
has
to
work
together
and
they
have
to
work
fast
right.
You
only
have
so
much
time
to
get
it
right.
You
don't
have
so
much
time
to
keep
the
release
moving
along
and
there's
a
lot
of
pressure
on
these
teams
right.
So
we
you
know
john
just
talked
about
the
digital
transformation.
B
He
referenced
ted
schadler's
report
ted's
a
you
know,
vice
president
principal
insult
analyst
at
at
forrester,
and
he
wrote
this
report
the
sorry
state
of
digital
transformation,
where
he
talked
about
the
fact
that
all
these
companies
are
under
so
much
pressure
and
some
of
them
actually
think
they're
done
and
he's
like.
That's
the
most
ridiculous
thing
is
that
people
think
they're
done
with
digital
transformation.
The
idea
is
once
you've
embraced
it.
You
realize
it's
just
not
going
to
end
it's
just
going
to
keep
going
on
along
with
that.
B
Forester
has
a
lot
of
other
research
that
backs
up
the
idea
that
customer
experience
is
a
real
driver
for
revenue,
a
real
driver
for
keeping
your
business
up
and
running
and
a
real
driver
for
winners
and
losers
in
this
market,
and
so,
when
you
put
those
two
things
together,
it
gets
back
to
that
market
and
reason
quote
right.
The
idea
that
cycle
time
compression
is
really
putting
a
lot
of
pressure
on
our
feature
teams.
B
So
we
took
a
look
at
some
research
and
we
said
you
know
what
is
the
current
release
frequency
and
we
said
all
right
well
in
2000,
this
is
actually
from
two.
We
actually
have
newer
data
from
2019.
It
shows
the
same
number,
but
for
the
last
five
years
previous,
this
is
pretty
much
the
graph
for
release
cycles
for
the
people
that
we
interview.
So
we
sent
out
a
survey
to
about
it's
it's
a
little
bit
more
than
this.
B
The
vast
majority
of
the
area
under
the
curve
is
between
a
month
and
a
year,
so
not
really
agile
right.
If
you
have
a
bug,
fix
you're,
not
getting
out
the
door
anytime
soon.
If
you
have
to
get
something
in
front
of
a
customer,
you
want
to
try
it
out
it
ain't
happening
anytime
soon,
and
so
by
and
large,
the
majority
of
customers
that
we
deal
with
are
struggling
with
this
digital
transformation
effort.
B
Now
you
can
go
look
at
like
other
research
from
like
dora,
or
even
you
know
the
state
of
supply
chain
they
all
have,
but
I
would
say,
sort
of
like
interviewing
or
surveying
companies,
maybe
at
a
broader
sense,
maybe
there's
more
more
smaller,
more
cloud
native
companies
that
are
able
to
kind
of
push
these
numbers.
You
know
closer
to
these.
You
know
more
more
daily
release
or
more
weekly
release,
but
by
and
large
the
people
that
we're
interviewing
are
are
stuck
and
they're
and
they're
looking
for
help.
B
Here's
another
thing
right,
so
this
sort
of
calls
out
the
2018-2019
data,
where
it's
showing
some
improvement.
Finally,
in
the
customer
base
that
we
have
so
apparently
our
subscriptions
are
are
doing
something
for
these
people
they're.
Finally,
getting
unstuck,
but
they're
still
not
doing
quite
well
they're
they're
still
kind
of
still
over
here
and
then,
if
you,
if
a
lot
of
teams,
you
know
say
they're
more
agile,
but
the
reality
is
that
you
know
it
went
from.
B
You
know
we
think
we're
kind
of
agile,
too
yeah
we're
pretty
agile
over
here.
You
know
most
of
them
are
saying
that
they're
they're
using
agile,
but
a
lot
of
companies
still
are
stuck
in
this
sort
of
like
fake
agile
world,
where,
even
though
they
want
to
do
agile,
even
though
they've
got
all
these
scrum
teams
and
they've
got
all
these
meetings
set
up.
B
It's
really
just
a
big
waterfall
project
chopped
up
into
10
10,
easy
projects
right
and
the
requirements,
never
change
the
backlog,
never
changes,
it
only
grows,
it
never
actually
shrinks,
and
so
the
whole
idea
of
you
know
iterate,
learn
and
then
readjust
just
doesn't
happen
on
these
teams.
What
usually
happens?
Is
they
start
with
their
first
release?
B
What's
going
on
and
what's
important,
here's
another
interesting
one,
I'm
not
sure
if
I
even
believe
this
data
to
be
quite
honest,
because
it
shows
continuous
integration
that
only
31
percent
of
the
folks
that
we
surveyed
you
know
3294
developers
claim
to
be
using
continuous
integration.
I
just
I
it's
what
the
data
is,
and
maybe
it's
the
way
that
the
question
is
is
is
asked,
but
it
just
seems
absolutely
ludicrous
to
me
right,
and
so
you
know
when
you
look
at
this
data.
B
It
just
shows
that
there's
a
complete
lack
of
modern
techniques
or
modern
tools
and
technologies
being
used,
and
maybe
that
is
the
state
of
things
right
when
you
actually
start
looking
at
the
data.
Maybe
the
reality
is
that
not
everyone's
actually
using
continuous
integration
on
a
daily
basis?
Maybe
they're
doing
you
know
a
batch
build
job
at
night
or
maybe
they're
doing
you
know,
maybe
they're
not
doing
it
at
all,
and
you
know
you
have
to
feel
bad
for
people
in
that
situation.
B
So
teams
tell
forester
too
many
tools
create
friction
right.
So
this
is
one
of
the
problems
that
they
have
right.
71
percent
agree
that
governance
and
invisibility
of
software
delivery
are
major
challenges
right.
So
one
of
the
problems
that
folks
talk
about
is
that
like?
Well,
you
know
we
work
in
a
regulated
industry
in
almost
every
step
of
the
development
process.
We
have
to
do
an
audit
or
we
have
to
do
a
manual
check.
We
have
to
do
a
manual
review.
B
B
Many
estimate
managing
tool
chains
consumes
10
of
their
development.
That's
what
I
I
said
at
the
very
beginning
that
I
first
learned
about
this
whole
problem.
Where
teams
are
complaining
that,
like
hey,
I
I
feel
like
you
know,
I
got
100
developers
and
10
of
them
are
always
managing
the
tool
chain.
I'd
gladly,
you
know
buy
something.
I
gladly
you
know
rent
something
in
the
cloud
if
it
meant.
I
didn't
have
to
do
that.
Yes,.
B
This
this
particular
case
was
10
of
the
development
team
and
developers
right,
so
they
these
these
are
like.
They
don't
have
a
separate
team,
managing
their
tools,
they're,
actually
managing
it
themselves.
Does
that
answer
your
question?
Okay
and
then
67
agree
that
handoffs
between
different
teams
using
different
tools,
slows
down
delivery
right.
B
So
this
is
another
problem
right
where
a
lot
of
a
lot
of
different
teams
have
their
own
roll,
your
own
tool
chain
or
each
team,
has
a
different
tool
chain:
they've
all
incorporated
open
source
tools,
they've
all
built
their
own
different,
bespoke
tool
chains,
and-
and
now
you
know,
you're
trying
to
you-
know,
transfer
work
from
one
place
to
another,
and
it's
not
going
very
well
nope
hit
the
wrong
button.
So
this
is
the
respondus
demographics
100
in
an
I.t
role,
respondent
level.
B
B
You
know
by
and
large
western
europe
u.s
and
I
guess
that
counts
as
u.s
as
well,
but
I
wonder
how
much
devops
is
going
on
up
there.
Maybe
a
lot
who
knows:
job
function,
I.t
and
infrastructure
operations
by
and
large,
you
know
for
most
traditional
companies.
These
are
the
people
that
own
the
tools
and
operate
the
tools.
Those
teams
are
trying
to
become
more
agile.
You
know
application
development
and
then
it
kind
of
goes
down
the
road
from
there
and
then
the
company
size
by
and
large,
you
know
51
percent
5
000
to
19.
B
B
I
don't
know
why
that
was
in
there
all
right,
so
teams
have
too
many
tool
chains
and
too
many
tools
to
manage.
So
this
is
one
of
the
interesting
things
that
came
out
of
the
survey
data
right
so
to
the
best
of
your
knowledge,
how
many
different
software
delivery
tool
chains?
Does
your
software
organization
maintain?
B
So
you
know
the
the
biggest
number
was
two
tool
chains,
but
the
second
biggest
number
was
three
to
five
tool
chains.
So
you
know
one
tool
chain.
Maybe
that's
too
unreasonable
because,
like
you
know,
if
you're
dealing
with
multiple
technology
stacks,
like
maybe
your
team's
big
enough-
that
you
have
a
java
stack,
you
have
a
microsoft
stack,
maybe
like
a
mobile
like
maybe
android,
and
you
might
want
android
and
you
might
want
native.
You
know
ios
right,
so
you
might
want
all
those
things
you
know.
B
Maybe
you
need
three
or
four
different
tool
chains
to
manage
it,
but
that
just
puts
a
lot
of
burden
on
these
teams,
and
then
you
get
up
here
and
some
of
these
other
folks,
where
you
know
21
tool,
chains,
11
to
20
6,
10
tool,
chains
right.
This
is
just
like
ridiculous
right,
so
those
are
obviously
from
the
larger
companies,
but
this
means
that
the
person
who
answered
said
they're
managing
this
many
tool
chains.
B
So
it
doesn't
mean
that,
like
just
because
a
company
has
20
000
employees
doesn't
mean
that
and
there
could
possibly
support
you
know.
20
different
tool
chains
doesn't
mean
they're
dispersed
all
over
the
place.
It
could
mean
that
this
this
team
is
actually
stuck
managing
them
for
for
teams
that
are
local
to
where
they
are
and
then
to
the
best
of
your
knowledge.
How
many
different
tools
comprise
your
current
software
delivery
tool
chain?
B
You
know
the
majority
is
one
to
five,
so
you
know
a
pretty
decent
backbone,
probably
some
ci
cd,
an
agile
planning
tool,
maybe
a
release
tool,
maybe
a
static
analysis
tool.
Six
to
ten
tools,
though,
is
thirty
percent.
So
now
you're
getting
a
little
bit
more
complexity
right.
We
didn't
I'm
not
sure
if
we
actually
dug
in
on
the
complexity,
maybe
it's
in
the
next
slide
and
then
11
to
15
16
to
20..
B
So
if
you
take
this
box
right
here
and
you
and
you
multiply
that
out
right-
that's
hundreds
of
different
tools
that
are
being
managed
by
the
same
team.
That
means
hundreds
of
different
licenses,
hundreds
of
different
updates,
hundreds
of
different
interconnections.
It's
it's
really
quite
a
mess,
and
it's
quite
a
burden
right.
So
how
do
teams?
How
do
teams
end
up
with
so
many
tools
the
drivers
to
expand
a
number
of
tools
within
tool
chain,
organic
growth
and
maturity
of
the
cicd
automation
market
right?
So
they
they?
B
They
started
with
a
basic
tool
chain
and
like
hey,
this
looks
good.
Let's
add
that
on,
and
that
looks
good.
Let's
add
on,
and
then
you
know.
Of
course,
we
need
some
static
code
analysis.
Of
course
we
need
sonar
cube.
Of
course
we
need
all
these
things,
but
then
that
particular
tool
chain
lives
in
one
team.
B
Greater
awareness
of
test
automation,
security
scanning
cloud
native
technology
such
as
docker
right,
so
people
see
these
goodies
and
they
want
to
add
them.
Why
not
right
new
is
good.
More
is
better
drivers
for
the
expansion
for
the
number
of
tool
chains,
test,
autonomo
team
autonomy
and
selecting
their
own
tool
chain.
So
this
idea
that,
like
you
know,
teams
should
be
able
to
select
the
tools
that
are
best
fit
for
their
team.
It's
a
nice
concept,
but
what
ends
up
happening?
B
So
we
talked
about
that
right,
mobile
apps
versus
web
server
and
then
these
enterprise
silos-
that's
probably
probably
the
evilest
one
right
where
you've
got
these
different
business
decisions
or
maybe
you've
got
different
divisions
within
the
same
same
business
unit,
and
you
know
one
particular
set
of
developers
and
and
managers
and
designers
worries
about
one
aspect
of
your
application.
You
know
maybe
you're
an
insurance
company
and
they
worry
about.
B
You
know
how
they're
acquiring
new
customers,
whereas
the
other
one
worries
about
how
we
actually
processing
you
know,
claims
how
we
doing
all
the
forms
and
they're
in
like
just
completely
separate
worlds,
even
though
those
two
things
are
supposed
to
work
together.
Somehow,
so
that's
how
teams
kind
of
end
up
with
so
many
tools
and
so
many
num
and
different
tools
in
the
in
so
many
different
tool
chains,
tool,
chain
responsibility
gets
spread
out
which
teams
are
ultimately
responsible
for
maintaining
your
tool
chain.
That's
the
question
we
asked
and
what
this
is
with
a
burden.
B
40
is
on
the
development
team.
So
when
I
talked
about
you
know
10
people,
you
know
that
was
an
anecdotal
number.
You
know
I
I
listen
to
clients,
I
interview
people,
they
tell
me
you
know,
I
don't
know
it's
roughly
10.
I
don't
have
a
survey
that
exactly
says
that.
But
then
this
actually
come
came
back
in
this
survey.
It
was
really,
I
guess
it
was
kind
of
rewarding.
B
I
feel
like
sometimes
I'm
a
little
bit
like
colombo,
where
I
just
sort
of
stumble
around
and
listen
to
people
and
come
to
a
conclusion
that
sometimes
doesn't
seem
like
it
has
any
basis,
but
it
turns
out.
I
was
right,
so
development
teams
are
really
overburdened
with
these
tools.
Why
do
you
think
that
is,
though?
B
Well
typically,
it's
a
developer
who
understands
how
to
automate
things.
A
lot
of
companies
have
test
teams,
but
they
don't,
but
those
testers
don't
necessarily
understand
automation
right
so
who
they
might
have
an
I.t
team
who
understands
how
to
script?
Who
understands
how
to
you
know,
do
some
automation,
but
not
in
a
development
sense
right,
not
necessarily.
Traditionally,
not
every
traditional
ino
person
understands
how
to
code
and
and
instantiate
infrastructure
and
use
you
know,
java
or
yaml
or
other
types
of
languages
that
can
instantiate
understand
how
to
compile
and
build
code.
B
So
developer
team
development
teams,
a
lot
of
the
burden
falls
on
them,
mainly
because
they
want
to
go
faster,
they're,
the
ones
that
are
pushing
the
rest
of
the
team
to
go
faster.
So
they
take
on
this
burden
saying
well,
we've
got
to
do
this.
This
is
how
we're
going
to
manage
it:
release,
teams
and
devops
teams.
That's
a
growing
sort
of
like
faction
within
teams
where
they
say
well.
This
particular
skill
set
is
kind
of
unique
it's
different
from
just
software
development.
It
combines
software
development
and
infrastructure.
B
There
are
people
that
just
sort
of
naturally
gravitate
towards
that
on
both
those
teams-
let's
put
them
together
and
maybe
maybe
that'll-
be
a
good
way
to
be
a
self-service
devops
team
that
can
create
self-service
tool
chains
that
can
create
managing
and
help
manage
that
burden
for
our
development
team.
Take
it
off
the
development
team
kind
of
take
it
off
the
operations
team
and
put
it
on
this
middle
tier
team.
B
Well,
that
works
pretty
well,
but
those
folks
are
still
if
they're,
managing
20
tool
tool
chains
and
each
of
those
tool
chains
has
five
tools.
You
know
that's
five
times:
twenty,
that's
a
hundred
right!
That's
a
lot
of
stuff
to
manage
still
even
for
a
team,
that's
dedicated
to
that!
Not
bad!
Considering
I
have
jet
lag
and
you
know,
and
then
it
goes
down
to
software
tools
and
operations
team.
So
you
know
by
and
large
70
is
on
these
teams
right
here.
So
that's
a
lot.
B
It's
a
lot
of
burden
and
it's
what
it.
What
it
really
is,
is
sort
of
like
the
cost
and
burden
of
managing
these
tools
means
that
these
folks,
who
are
working
on
this,
aren't
creating
business
value.
They
aren't
helping.
You
know
with
the
customer
experience
they're,
not
helping
design
the
next
architecture
they're,
not
developing.
Necessarily.
You
know
the
next
feature
set
they're
worried
about
just
the
plumbing
and
the
fixtures
that
keep
the
whole
business
running.
B
You
know
we're
in
this
to
win
it
and
we're
up
against
amazon,
we're
up
against
walmart
and
we're
the
little
guy.
You
know,
even
though
there's
a
thousand
developers
here,
even
though
we
know
we
make
billions
of
dollars,
we're
the
really
really
tiny
online
retailer
compared
to
these
other
guys.
So
you
know
they
consider
these
things
just
the
way
they
have
to
operate.
It's
it's
a
differentiator.
B
The
ability
to
release
and
own
their
own
tool
chain
and
develop
fast
is
something
that
they
realize
is
what's
going
to
make
them
a
differentiator.
So
that's
why
a
lot
of
these
teams
take
these
burdens
on
integrating
those
tools?
Becomes
a
labor-intensive
challenge
right.
So
what's
the
biggest
problem,
our
tool
chain
is
integrated
with
a
combination
of
plugins
and
scripts
right.
B
So
forty
percent
of
the
folks
who
have
one
or
two
chill
chains
tell
you
that
and
three
plus
tool
chains
say
that
so
you
know
if
you're,
if
you're,
installing
plugins
onto
your
your
ci
server,
and
then
that
becomes
a
unique
installation.
Now
that
becomes
a
different
server
than
the
other
server
has
different
plug-ins.
They
all
become
snowflakes,
they
all
become
independent
points
of
failure.
Independent
points
of
management
into
points
of
independent
points
of
pain
in
the
ass.
Our
tool
chain
is
integrated
via
well
defined
apis.
Well,
that
would
be
nice
right.
B
So
18
have
one
a
tool
chain,
two
tool
chains
and
three
plus
tool
chains
is
30,
so
that's
good
right,
so,
well-defined
apis
that
helps
you
loosely
coupled
architectures,
but
still
a
bit
of
work
to
maintain
when
you
need
to
update
those
apis.
Our
tool
chain
is
integrated
manually
by
a
hard-coded
custom
integration
between
tools.
So
these
folks
have
a
rather
you
know,
tenuous
relationship
with
their
tool
chain,
23
and
17
percent,
and
then
we
have
an
out
of
the
box
software
delivery
tool
chain
that
is
integrated
end
to
end.
These
are
the
get
lab.
B
Customers
apparently,
and
then
our
tool
chain
is
not
integrated,
so
oops
that
happens
right
or
or
or
they're
using
another
brand
that
we're
not
going
to
talk
about
anyways.
So
then,
there's
also
this
skill
gap
right.
So
these
are
the
other
problems
that
that
come
up
right,
so
skill
gap
emerges
teams
struggle
to
maintain
the
vast
number
of
different
tools
and
their
integrations
right,
so
insufficient
skills,
expertise
and
resources
to
integrate
discrete
tilt
screen
tools
right
46.
B
So
what
does
that
mean
right?
So
it
kind
of
goes
back
to
the
whole
thing.
The
reason
why
developers
are
in
charge
of
the
tool
chain,
it's
because
they're
the
folks
that
typically
understand
how
to
integrate
tools
together,
they're
typically
the
people
who
understand
apis
who
understand
how
these
things
all
have
to
plug
together
and
they
understand
how
they're
how
they
want
their
software
built.
B
So
when
there's
an
insufficient
skill,
set
or
or
body
of
resources
to
pull
from
you
end
up
pulling
from
your
development
team,
insufficient
skills,
expertise
or
resources
to
maintain
the
tools,
so
that's
another
big
problem.
So
it's
one
thing
to
build
the
tool
chain:
it's
nothing
to
maintain
the
tool
chain,
and
then
you
know
the
behavior
change
needed
to
maximize
these
tools,
lack
of
executive
leadership
and
n
a
we
don't
face
any
challenges
in
this
area
at
all,
we're
just
happy
having
a
great
time.
B
So
that's
seven
percent,
so
seven
percent
of
all
the
respondents
say
they're
just
happy,
and
so
you
know
by
and
large
people
are
dealing
with
resource
issues.
They're
dealing
with
skill
set
issues,
they're
dealing
with
the
fact
that
it's
just
hard
to
maintain
all
these
tools,
so
it
professionals
struggle
to
maintain
secure
tool
chains.
Here's
another
one.
It's
kind
of
interesting
thing
that
came
out
of
it
which
of
the
following
process
challenges.
Does
your
team
currently
face
with
its
tool
chain
and
difficulty?
Ensuring
security
across
the
tool
chain
was
45.
B
You
know
credential,
then
you,
you
know
when,
when
it's
just
amongst
us
friendly
developers,
no
big
deal
right,
but
then,
once
you
start
expanding
this
this
tool
chain
and
more
and
more
actors
start
being
part
of
it.
Then
you
realize
hey,
guess
what
we've
got
race.
Basically,
there's
a
there's,
a
back
end
network
of
all
these
development
tool
chains
that
all
have
hard-coded
credentials
that
anybody
has
access
to
and
could
access
other
assets
within
the
company.
B
Every
one
of
them
has
different
ways
of
managing
our
back
different
ways
of
managing
sso
different
ways
of
how
they
communicate
with
the
next
tool
up
and
the
next
tool
down,
and
that's
when
the
concern
really
started
hitting
home
that
this
is
a
really
big
problem
right.
It's
been
sort
of
like
a
something
that's
been
sort
of
swept
under
the
rug
for
a
long
time,
but
but
but
not
anymore,
right.
Lack
of
visibility
is
the
other
one
right.
B
So
once
you've
automated
a
lot
of
these
things,
you
know
it
sort
of
goes
into
a
black
box
and
comes
out
the
other
side,
but
you're
like
all
right.
Well,
you
know,
do
I
know
how
fast
we're
actually
working
now
do
I
you
know
where's
all
that
data
is
it
is
it
is
it
something
I
can
look
at?
Is
it
something
I
can
comb
through?
Is
there
any
way?
I
can
understand
what
our
our
cycle
time
is.
B
You
know
what's
going
on
how
the
artifacts
are
being
passed
along,
you
know,
what's
the
handoff
look
like
who's
doing
what
and
you
know
some
ability
to
get
an
audit,
because
you
know
we're
a
bank
or
we're
an
insurance
company
or
we're
in
the
government,
and
we
need
to
understand
who
worked
on
what,
when,
when
did
that
work
item
get
picked
up?
How
long
did
it
take
for
the
work
time
to
get
processed
things
like
that
that
we
talked
about
at
forrester,
called
value
stream
management?
B
Well,
the
whole
idea
of
like
lean
software
development,
we
try
to
really
understand
the
full
process
from
end
to
end
and
get
visibility
into
that
process.
So
those
are
two
things
that
that
really
came
out
of
this
survey.
They're,
really
quite
interesting
that
I'm
not
sure
that
we
expected.
I
think
we
just
expected
it
to
be
a
maintenance
nightmare,
and
that
was
the
end
of
it,
but
this
is
another
problem.
B
Poor
usability
across
the
tool
chain
is
the
third
one
right:
the
idea
that
these
tools
are
just
difficult
and
they're
kind
of
bearish
to
work
with
they.
You
know
one
one
tool
might
be
really
elegant,
maybe
maybe
you're
using
a
really
great
agile
planning
tool
like
jira
and
and
you
think,
it's
great,
but
then
you
go
on
to
your
ci
tool
and,
like
everything,
just
falls
apart
right
and
so
the
idea
that
you
get
you
know
poor
visibility,
poor
usability
across
the
tool
chain.
You
know
I
look
at
that
as
spottiness
right.
B
Some
tools
are
good.
Some
tools
are
bad
and
then
back
to
these
other
things
right,
insufficient
skills,
insufficient
resources,
difficulty
implementing,
chargeback
models,
you
know,
and
then
you
know
we
don't
face
any
challenges:
four
percent:
what's
that
chargeback,
pretty
sure
that
is
just
yeah?
Actually
I
think
it's
a
financial
idea,
the
idea
that
you
want
to
actually
figure
out
how
to
how
to
pay
for
this
particular
thing.
B
Like
so
you're
you've
asked
an
it
team
to
support
you,
and
now
they
want
money
from
your
development
team
for
doing
some
work
for
you
and
it's
like.
Well,
how
do
you
manage
all
that?
How
do
you
work
between
cost
center,
the
cause
center?
And
so
what
can
happen?
Sometimes,
is
you
say:
well,
you
know
on
the
development
team.
I
need
you
to
fix
this
and
like
well
we're
not
going
to
do
it
unless
you
know
you
fund
us,
I'm
like
we're
not
going
to
fund
you
so
we'll
have
a
developer.
B
That's
what
I
believe
it
means.
That's
my
interpretation
anyways,
yes,
okay,
the
audience
agrees.
I.T
professionals
see
benefits
from
an
out-of-the-box
tool
chain
so
so
which
of
the
following
benefits.
Do
you
anticipate
realizing
or
have
you
realized
from
a
new
out
of
the
box
tool,
chain
management
system,
and
so
this
one
so
when
we
thought
it
was
going
to
be
like?
Oh,
we
thought
we
would.
We
were
going
to
see.
Well,
it's
a
lot
easier
to
maintain
my
tools
now,
but
risen
to
the
top
is
improved
quality,
improve
quality
of
their
products.
Why?
B
Maybe
it's
because
they're
able
to
focus
on
developing
their
products
now
versus
developing
their
tool
chain
right?
Maybe
it's
because
the
tool
chain
now
kind
of
works
for
them,
rather
than
them
working
for
the
tool
chain
and
they're
actually
able
to
think
about
you
know
and
get
visibility
into
it
and
understand.
B
What's
going
on
inside
all
the
different
software
developing
processes
improve
security,
improve
developer
productivity,
so
these
three
right
here
are
all
the
sort
of
like
sore
points
that
people
had
earlier
got
solved
by
this
idea
of
you
know
this
is
what
you
can
get
from
a
complete
connected
and
integrated
tool
chain.
That's
pretty
stunning!
It's
sort
of
like
a
nice
reflection
on
on
the
pain
that
we
saw
earlier.
We
also
saw
increased
revenue,
increase
compliance,
improve
time
to
value,
and
then
you
know
all
the
way
down
lower
cost.
B
This
is
something
that
you
know
actually
going
to
go
back
to
the
my
my
day
of
going
to
the
the
wayfair
devops
meetup.
They
actually
hosted
it
in
their
in
their
building
and
they
they
gave
out
devops
t-shirts
and
free
sandwiches.
It
was
really
great
one
of
the
best
moments
of
my
life.
I
guess
anyways
they
they.
They
talked
about
the
fact
that
you
know
they
host
on
amazon,
google
and
azure
simultaneously
and
to
them.
B
Multi-Cloud
was
extremely
important
because,
first
of
all,
they
compete
with
amazon,
but
they
host
on
amazon.
So
they
have
this
kind
of
weird
relationship
with
them
and
then
what
they
don't
want
to
do
is
be
beholden
to
one
particular
cloud
vendor
or
have
to
suffer
an
outage
and
not
be
able
to
have
a
backup
plan.
So
they
have
a
dynamic
system
where
they
go.
You
know
multi-cloud.
That
was
really
the
first
time
I
heard
about
someone
really
truly
buying
in
on
multi-cloud,
since
that
time,
forrester
has
done
a
lot
of
research.
B
Not
just
you
know
this
particular
survey
analysts
like
lauren
nelson.
They
all
talk
about
the
fact
that
customers
are
asking
for
multi-cloud
solutions.
They
don't
want
to
be
locked
into
one
particular
vendor.
They
want
the
ability
to
shift
workloads
or
do
workload
appropriate
things
for
each
cloud.
Each
cloud
has
different
strengths
and
weaknesses,
or
they
want
to
be
able
to
shift
storage
back
and
forth
when
they
want
it.
B
Well,
they
want
to
have
some
things
on
premise:
some
things
in
the
cloud,
so
the
whole
idea
that
they
don't
want
to
be
locked
in
they
don't
they
want
to
have
the
ability
to
move
things
around
and
so
we're
seeing
that
come
through
in
this
particular
survey
as
well,
the
ability
to
deploy
any
target
environment
or
cloud
25.
That
was
the
the
biggest
number
the
next
one
is
simplified
maintenance.
So,
even
though
people
want
simplified
maintenance,
you
know
they
want.
You
know
to
make
the
tool
chain
easier.
B
A
big
business
driver
is
the
ability
to
be
multi-cloud,
and
that
was
another
kind
of
surprise.
Out
of
the
whole
out
of
this
whole
survey,
which
was
you
know
a
pleasant
surprise,
and
you
know
77
agree
that
organizations
is
moving
to
the
cloud
and
want
to
avoid
cloud
blocking
our
future
is
multi-cloud.
So
that's
it's
really
quite
quite
interesting
and
and
kind
of
bucks.
The
trend
of
what
some
cloud
vendors
will
tell
you.
B
So
why
is
multi-cloud
important?
You
know
avoid
getting
locked
in.
I
guess
I
guess
I
already
talked
about
it:
deploy
and
host
your
applications
or
components.
You
know
to
any
of
the
providers
that
best
match
your
functional
needs.
I
mean,
maybe
you
don't
want
to
host
on
one
of
the
big
public
clouds.
Maybe
you
want
to
host
on
oracle
right,
and
so
you
know
you
should
have
the
choice
and
then
you
know
public
cloud
outages
are
rare,
but
they
happen.
You
know
s3
outage
there
was
an
azure
devops
outage.
B
You
know
so
you
know.
Do
you
want
to
be
reliant
on
one
particular
vendor?
You
know
if
you're
in
the
government
or
you're
you
know
in
a
financial
technology
services
you
know
are
you're
trading,
you
know
thousands
of
transactions
a
minute
and
you're
going
to
invest
in
a
cloud
vendor.
Are
you
going
to
put
all
your
eggs
in
one
basket
or
are
you
going
to
have
a
plan
b
and
a
plan
c
right?
You
just
can't
afford
to
be
down
when
being
down
means,
maybe
millions
or
billions
of
dollars.
B
You
know
of
lost
revenue
so
and
there's
also
the
whole
idea
of
like
governance,
where
many
firms
have
to
have
multiple
sources
of
of
for
their
vendors.
So
there's
a
lot
of
different
reasons.
Why
multi-cloud
is?
I
think
going
to
become
a
more
important
aspect
for
larger
enterprises
for
smaller
companies.
I
think
it's
not
a
big
deal
right.
It's
like
hey
we're.
You
know
100
people
we're
a
startup
or
we're
beyond
startup
and
we're
getting
bigger.
You
know,
maybe
that's
not
such
a
big
deal
right.
B
So
what
can
teams
do
reduce
the
diversity
of
tool
chains
within
the
enterprise?
Duplicated
functionality
is
wasteful
right.
So
if
you
have
multiple
tools,
all
doing
the
same
thing
and
they're
all
working
on
the
same
stack,
why
bother
right?
Is
it
just
because
it's
some
particular
person's
pet
pet
project,
or
is
it
actually
doing
any
value
right?
So
the
whole
idea
is
measure
the
value
you
know
does
it
does
it
support
open
standards?
Is
it
does
the
tool
change,
simplify
security
and
risk
compliance?
B
Does
the
tool
chain
allow
you
to
deploy
where
it's
most
advantageous?
Will
the
tool
chain
be
easier
to
maintain
right?
So
you
look
at
these
factors,
and
you
saw
you
try
to
think
about.
You
know
it's
great,
that
I'm
giving
my
developers
choice,
but
you
know
we're
all
working
for
a
business
to
make
money,
and
sometimes
that
means
a
little
bit
of
standardization.
B
Sometimes
that
means
a
little
bit
of
you
know,
trying
to
bring
things
to
sort
of
like
an
even
keel,
so
that
different
developers
can
jump
from
different
teams,
and
you
could
have
mobility.
You
could
have
the
ability
to
you
know
you.
Can
you
can
get
all
the
tools
you
want,
but
you
can
just
do
them
in
kind
of
a
standard
way.
B
So
in
summary,
software
delivery
automation
is
a
business
differentiator.
You
know
all
the
companies
that
are
going
through
digital
transformation
that
are
suddenly
realizing
that,
oh
guess
what
you
know
we
are.
Actually
our
product
is
going
to
be
a
software
platform
which
we
deliver
our
services
on.
It's
not
that
you
know
the
software
is
just
there
to
be
part
of
the
claims
management
process,
or
it's
not
just
there.
You
know
to
be
our
website
for
the
banking.
It
actually
is
our
product
now
and
we
just
happen
to
sell
financial
services
on
it.
B
We
happen
to
sell
banking
on
it,
or
the
government
happens
to
do
your
taxes
on
it.
Government
I
mean
custom
best
of
breed
tool.
Chains
provide
differentiation,
but
they
come
at
a
cost
and
that
cost
gets
multiplied
when
there
are
multiple
tool
chains
right.
So
not
every
team
wants
to
take
on
that
cost.
Not
every
team
can
afford
to
take
on
that
cost
and
if
you
have
a
choice
and
you
don't
need
to
take
on
the
cost,
why
would
you
want
to
and
then
choosing
a
modern
single
tool
chain
solution
can
be
beneficial.
B
It's
less
maintenance!
You
look
for
ones
that
have
open
standards
that
enable
extensibility,
so
that
you,
you
know
you
want
one
of
the
biggest
reasons
why
tool
chains
of
the
past
like
if
you
look
at
you,
know,
ibm's
rational.
You
know
the
original
microsoft
tfs
clearcase.
They
were
all
closed
systems
right.
If
you
wanted
to
add
a
scanning
tool,
if
you
wanted
to
do
something,
you
had
to
kind
of
do
it
on
your
own.
You
want
something:
that's
got
apis
that
allows
loosely
coupled
architectures.
B
It
allows
you
to
plug
in
tools
as
you
need
to,
so
you
can
sort
of
have
this
backbone
of
a
tool
chain
and
then
hang
the
other
pieces
off
of
it.
So
you
don't
have
to
worry
about
managing
all
of
it.
Simpler
security
model,
less
time
spent
on
automation,
more
more
time,
spent
delivering
value
and
then
freedom
to
host
and
deploy
where
you
need
right.
So
that's,
that's
the
really.
A
B
A
C
C
B
D
B
A
E
Did
you
dig
into
that
to
find
out
if
the
reason
that
there
was
a
shorter
time
to
ramp
was
because
they
were
surrounded
by
people
that
already
knew
the
tool
chain
or
because
it
was
an
industry
standard
chain,
so
they
could
go?
Look
on
the
they
could
go
google?
How
to
do
things
versus
custom
tools
where
you
like?
Did
you
get
any
sense
as
to
why
using
a
single
tool
chain
like
this,
actually
led
to
a
faster
ramp
time
versus
whatever
people
were
doing
before.
B
B
That's
like
the
tip
of
the
iceberg
and
then
underneath
it
there's
all
these
business
rules,
and
so
then
they
go
to
another
team.
And
it's
like,
oh
well,
your
business
rules
are
a
lot
different
than
the
business
rules
I
used
to
use
and
you
know
we
didn't
do
it
this
way.
We
didn't,
you
know,
use
that
particular
scanning
tool.
B
I
don't
necessarily
think
that
one
tool
is
less
sophisticated
or
more
complicated
than
the
other,
although
some
tools
certainly
can
be.
I
just
think
it's
that
those
teams
then
sort
of
further
embellish
them
with
rules
and
scripts
and
other
types
of
code.
I
I
suppose
you
know
you
could
have
one
tool
that
becomes
really
complex
as
well
with
all
you
know,
manner
of
business
rules
built
into
it.
B
But
if
it's
in
one
tool,
I
feel
like
at
least
as
a
common
interface
to
find
out
where
those
rules
are,
and
you
know
how
to
discover
them
and
know
how
to
understand
them
and
that
there's
a
common
knowledge
base
across
the
team
or
the
organization
that
can
help
you
with
shared
knowledge
when
it's
all
different
individual
tools.
It's
sort
of
like
figure
it
out
for
yourself.
B
B
Are
you
talking
about
the
tool
itself's
ability
to
scale
yeah?
That's
a
question
that
in
this
particular
case,
you
know
for
git
lab
I'll.
Let
john
talk
about
that,
but
what
I've
typically
typically
seen
is
that
people
are
having
scaling
trouble
because
they
have
too
many
different
types
of
tools.
So
maybe
you
know
it's
one
thing
to
say:
is
it
one
single
tool?
That's
one
instance,
or
is
it
the
same
tool
just
used
in
multiple
places
right?
So
those
are
two
different
kinds
of
things.
B
I
guess
two
different
ways
to
scale
that
I
guess
it.
That's
a
that's
a
question.
Don't
I
don't
actually
know
the
direct
answer
for,
but
my
feeling.
So
if
you
look
at
folks
that
are
moving
to
like
cloud
hosted
systems,
the
main
reason
they're
doing
it
is
because
they're
just
sick
of
managing
a
bunch
of
snowflake
servers
and
that's
why
they're
moving
to
the
cloud
they're
sick
of
having
to
ask
for
someone
to
create
a
server
for
them
or
you
know,
stand
up
a
tool
chain,
so
they're
they're
they're
moving
to
the
cloud.
B
If
you
look
at
people
that
have
teams
that
manage
on-premise
installations,
they're
looking
for
one
tool
so
that
their
team
can
master
it
and
know
how
to
self
create
self
provisioning
systems
that
can
scale
that
they
can
actually
manage.
So
there's
two
different
things
going
on
there:
teams
that
are
okay
and
willing
to
invest
in
having
an
on-premise
team
to
manage
their
tool
chain.
B
B
The
other
thing
is
that
so
that
was
an
assumption
that
got
approved
the
thing
that
surprised
me
was
that
the
people
that
talked
about
multi-cloud
and
security
as
really
big
driving
factors
that
that
those
are
the
benefits
that
they
want
to
get
from.
You
know
a
common
tool
chain.
I
think
that's
really
interesting
and
telling
that
security
is
becoming
a
really
big
problem
for
a
lot
of
companies,
they're
really
starting
to
focus
on
it,
and
they
understand
that.
It's
not
just
you
know
outside
the
firewall.