►
From YouTube: Five Ways to Transform Your Organization - Trevor Quinn (Red Hat) OCG Buenos Aires 2018
Description
OpenShift Commons Gathering Buenos Aires August 2018
5 Ways to Transform Your Org - Trevor Quinn (Red Hat)
https://commons.openshift.org/gatherings/BuenosAires_2018.html
A
A
So
what
we're
really
talking
about
here
is
how
do
we
go
from
kind
of
isolated
container
experimentation
to
mass
adoption
of
containers
and
in
the
process?
How
do
we
transform
the
organization
to
be
able
to
take
advantage
of
this
technology
and
I?
Think
if
I
could
sum
up
all
of
the
lessons
that
we've
learned
over
the
past
few
years?
It's
that
technology
is
easy,
but
changing
an
organization
is
difficult,
and
so,
let's,
let's
see
how
we
can
tackle
that
challenge,
how
we
can
address
that
challenge.
A
I'm,
first
going
to
talk
to
you
a
little
bit
about
strategy
and
some
high-level
principles
for
how
we
modernize
application
delivery
and
then
I'm
going
to
talk
to
you
a
little
bit
about
the
lessons
and
tactics
involved
with
achieving
that
that
digital
transformation
that
so
many
organizations
are
attempting
to
achieve
now.
I
think
I've
been
asked
to
trim
the
presentation
a
little
bit
to
save
us
some
time,
so
I
will
probably
not
get
to
too
many
customer
stories,
but
the
good
news
is.
A
So,
starting
with
strategy
I
think
the
question
for
a
lot
of
customers
is
how
to
modernize
the
IT
organization
and
specifically
how
to
modernize
application
delivery,
and
certainly
containers
are
part
of
that
of
that
journey.
Really
we
we
kind
of
spread
it
across
five
different
activities
that
represent
greater
and
greater
levels
of
of
delivery.
A
Optimization,
beginning
with
building
a
cloud
capability
inside
the
organization
and
by
cloud
capability,
we
really
mean
the
classic
definition
of
cloud
in
terms
of
developer,
self-service
and
ephemeral,
instances
of
compute
that
can
be
easily
created
and
destroyed
as
needed
and
utility
driven
pricing,
or
at
least
internal
chargeback
of
resources
based
on
hours
of
usage
or
based
on
unit
units
of
consumption.
That
can
be
measured
and
tracked
at
a
large
scale
across
the
whole
organization.
But
that
cloud
capability,
regardless
of
whether
it
is
on
Prem
or
through
public
cloud
consumption,
is
really
just
the
beginning.
A
The
important
next
step
is
to
start
to
move
workloads
into
the
cloud
environment
and
start
to
set
up
the
automation
of
the
delivery
pipeline
to
be
able
to
show
applications
in
motion
from
development
all
the
way
through
to
production.
And
it's
really
not
until
you
start
seeing
that
movement
of
workload
that
you're
validating
that
your
organization
is
taking
advantage
of
this
of
this
cloud
technology
to
the
fullest
extent.
A
And
once
you
do
that,
we'd
like
to
see
organizational
impact
to
those
to
those
activities
so
giving
your
delivery
teams
end-to-end
responsibility
over
their
code,
so
that
you're
starting
to
break
down
DevOps
silos
or
break
down
DevOps
barriers
and
instead
of
a
development
team,
seeing
its
job
as
creating
a
software
release
that
they
then
hand
off
to
an
Operations,
Group
and
kind
of
step
away.
And
let
it
let
it
you
know-
be
managed
and
run
by
a
different
team.
Give
those
teams
responsibility
for
that
workload.
A
So
that's
what
we
mean
by
this
end-to-end
responsibility
and
then,
finally,
and
and
perhaps
at
a
most
challenging
level,
starting
to
think
about
the
restructuring
of
teams
to
be
able
to
promote
better
organizational
agility.
So
the
classic
example
is
Amazon
trying
to
keep
teams
no
larger
than
you
can
feed
with
with
two
pizzas
I
think,
and
so
you
know,
as
you
start
to
think
about
this
eight
nine
ten
person
team.
A
We
want
to
plan
just
enough
to
get
started
with
the
effort,
try
to
break
big
projects
up
into
smaller
chunks
and
work
incrementally
through
those
project
stages.
We
want
to
see
rapid
feedback
cycles
between
different
participants
in
the
in
the
system
and
critically.
We
want
to
make
sure
we're
automating
as
much
as
possible.
So
a
lot
of
times
that
customers,
we
tend
to
see
a
relatively
narrow
focus
on
automation,
just
around
build
process
or
continuous
integration.
A
A
Oftentimes.
We
see
particularly
mental
managers
struggling
to
figure
out
how
to
translate
new
technology
adoption
into
business
value
for
their
executive
team
and
oftentimes.
There's
insufficient
attention
devoted
to
metrics
that
really
matter.
So
these
are
things
like
deployments
per
day,
mean
time
to
release
things
that
reflect
a
growth
in
operational
maturity
in
in
replacement
of
those
kinds
of
measures.
I
think
people
at
times
fall
back
on
short
term
time
and
cost
metrics
that
don't
always
reward
system
level,
improvement
and
long
term
return
on
investment,
and,
as
a
result,
this
can
compound
problems
with
cultural
alignment.
A
If
there's
more
of
a
kind
of
blame
type
culture
where
mistakes
are
are
punished,
it
creates
a
reductionist
view
on
timelines
and
cost
and
I
think
inhibits
organizational
improvement
as
a
whole.
So
what
can
we
do
to
get
past
this?
These
problems,
one
tactic
I
think,
can
help
with
this
is
something
called
the
impact
mapping,
and
this
is
this-
is
a
tactic
that
the
Red
Hat
innovation,
open
innovation
labs,
which
is
a
time-boxed
residency
program
for
process
improvement
that
we
offer
to
our
customers.
A
This
is
one
of
the
tactics
that
the
labs
team
has
been
really
trying
to
promote
among
our
customer
audience.
What
it
allows
you
to
do
is
kind
of
visualize
scope
and
underlying
assumptions
in
a
collaborative
way
with
the
rest
of
the
stakeholders
and
and
technical
contributors
on
the
team
and
the
way
it
works.
Is
you
start
with
your
goal
on
the
far
left
of
this
diagram
and
that
goal
should
be
expressed
as
a
specific
metrics
driven
outcome
that
you're
looking
to
achieve
that?
A
Expresses
the
answer
to
the
question
of
why
we're
trying
to
do
this
big
picture
highest
level.
You
know
what
are
we
trying
to
achieve
with
this
project
with
this
new
feature
with
this
program
for
container
adoption,
and
only
once
you've
expressed
that
clear
goal?
Do
you
start
to
proceed
into
actors,
so
these
are
individuals
or
roles
that
can
contribute
to
achieving
that
goal,
and
so
you
list
all
of
your
important
actors
who
can
produce
the
desired
effects,
who
can
potentially
obstruct
or
inhibit
or
delay
the
fulfillment
of
that
goal?
A
Who
are
your
consumers
and
users
and
then
once
you've
defined
your
actors
start
to
think
about
impacts?
How
should
our
actors
behavior
change,
how
how
can
they
help
us
achieve
that
goal,
or
how
can
they
delay
us
list?
Those
and
then,
finally,
and
only
after
you've,
started
to
fill
out
more
of
the
rest
of
this
of
this
diagram?
Do
you
turn
to
scope
or
deliverables
or
actual
work
products
that
you
would
like
to
see
as
part
of
the
the
project
and
what
this
does
it?
A
The
second,
of
course,
and-
and
we
see
this
in
most
large
enterprises
over
time
due
to
the
need
for
functional
specialization
silos,
develop
in
those
organizations
that
were
stick
our
ability
to
communicate
with
people
who
are,
in
some
cases
very
directly
involved
in
our
day
to
day.
Work
and
we've
seen
this
as
a
particular
challenge
in
the
container
adoption
program
and
enterprise
wide
adoption
of
open
shift
where
in
the
early
stages
of
program
execution,
the
focus
is
very
much
on
operational
maturity
for
the
platform.
A
So
getting
the
platform
installed,
getting
an
understanding
of
what
high
availability
means.
Disaster
recovery,
backups,
storage,
integration,
network
integration,
but
the
actual
consumers
of
that
platform
are
left
as
an
afterthought
or
their
involvement
is
delayed
to
a
later
stage
of
the
the
overall
programs
delivery.
And
what
we
would
like
to
do
is
to
encourage
our
customers
to
resist
the
temptation
to
think
of
platform
operations
as
separate
from
platform
users.
In
fact,
most
of
the
time
platform
operations
can
only
be
meaningfully
defined
with
real
users
and
real
workloads.
A
There
are
choices
that
you
are
going
to
make
in
the
operational
definition
of
you
know
the
support
and
maintain
maintenance
of
the
platform
that
you
can
only
come
to
the
correct
decision
on
once.
You
better
understand
the
needs
of
your
developer
audience.
So
we
really
like
to
encourage
customers
to
involve
development
teams
early
and
start
to
push
out
if
possible,
production
releases
of
applications
even
before
the
platform
itself,
is
completely
finalized
and
kind
of
complete.
Those
production
releases
may
not
have
external
customers
hitting
them
or
or
consumers.
A
We
also
find
at
some
point
you'll
have
to
start
to
think
about
how
to
incentivize
adoption.
We
work
with
several
customers
who
have
made
the
mistake
early
on
to
think
that
the
platform
itself
will
just
sort
of
naturally
bring
a
developer
audience
to
it
because
of
some
of
the
kind
of
natural
advantages
with
container
based
deployment,
automation
and
auto
scaling
and
orchestration,
etc.
But
what
we
found
is
that
nothing
is
quite
so
compelled
as
the
status
quo
right.
A
What
we
call
the
big
bang
approach
to
to
IT
development,
where
you're
working
internally
behind
closed
doors
in
private
for
months
and
months
and
months
and
and
finally,
you
have
a
release
date,
six
months,
twelve
months
into
the
project
and
then-
and
only
then,
do
you
start
to
get
real
users
and
real
feedback
on
the
system
and
oftentimes?
What
you
find
is
the
feedback
tells
you
that
you
were
working
on
the
wrong
thing
all
along
and
you
kind
of
have
to
go
back
to
the
drawing
board.
A
To
start
over
the
more
you
can
get
that
feedback
early
in
the
project
and
the
more
you
can
involve
developers
early
in
the
project,
the
better
off
you'll
be
the
other
thing.
We
recommend
in
terms
of
organizational
alignment
to
support
that
objective
is
to
start
to
reorganize
in
the
following
manner.
So,
on
the
on
the
left
hand,
side
we
have
the
before
snapshot.
Many
organizations
have
a
constellation
of
application
development
teams
who
may
interact
with
an
application
server
team,
that's
responsible
for
server
operations.
These
might
be
WebSphere.
A
We
do
still
divide
up
platform-as-a-service
from
architecture,
but
that
platform
as
a
service
role
is
very
different
from
the
traditional
application
server
team.
It's
really
infrastructure,
as
expressed
at
an
application
platform
level
and
thinking
about
the
capabilities
that
you
can
create
in
the
platform
to
make
developers
lives
easier
and
better.
A
Third,
we
want
to
make
sure
that
organizations
are
prioritizing
the
right
applications
and
the
right
teams
as
part
of
this
effort,
so
I
think
it's
important
to
note
that
not
all
potential
users
are
equal
inside
of
an
enterprise
organization.
It's
really
worthwhile
to
find
the
workloads
and
teams
that
have
the
most
engagement
and
will
derive
the
most
benefit
from
transformed
IT
and
a
container
based
ploud.
So
how
can
we
go
about
doing
that?
A
We're
talking
about
things
like
mainframe
applications,
COBOL
and
Fortran
that
may
be
running
on
dedicated
Hardware
desktop
applications
that
were
maybe
written
against
Windows
desktop
api's
with
a
Windows
desktop
user
audience
in
mind.
Those
are
probably
not
good
candidates,
at
least
for
the
container
platform,
without
significant
redevelopment
and
rewriting,
and
then
you've
got
a
category
of
applications
in
the
form
of
commercial
off-the-shelf
or
cots
software
that
you
may
be
purchasing
from
a
vendor
that
doesn't
have
a
development
team
associated
with
it.
A
A
But
if
you're
thinking
about
phase
one
showing
success
with
the
platform,
what
you
really
want
to
focus
on
is
teams
and
projects
whose
source
code
you
own,
deploy
and
maintain
so
java.net
PHP
Python,
no
debt
cetera.
Those
are
the
ones
that
you
want
to
kind
of
jump
to
every
portfolio
within
that
audience
has
a
mix
of
application
types,
so
you've
got
applications
broken
up
by
functional
variation.
Ui
batch
API
services,
you've
got
applications
with
different
system
dependencies.
You've
got
different
technology
choices
within
each
of
those
applications.
Each
workload
is
going
to
have
varying
business
values.
A
Some
applications
are
frankly
going
to
be
contributing
more
to
your
bottom
line,
they're
going
to
be
contributing
more
in
terms
of
opportunities
for
innovation,
more
to
capture
a
larger
customer
audience
and
drive
revenue
to
the
organization.
So
you
really
want
to
focus
on
common
types
or
patterns
that
also
provide
the
most
business
value
to
the
organization
and
the
larger
the
addressable
portfolio.
You
can
cover
with
a
particular
archetype
or
pattern
the
better.
A
Do
you
start
to
look
at
analysis
and
prioritization
of
individual
applications
to
establish
level
of
effort
level
of
difficulty
level
of
prioritization
around
the
kind
of
technical
ideals
for
a
cloud
compatible
workload?
An
automated
code
build
process,
for
example
the
ability
to
externalize
configuration,
not
a
lot
of
reliance
on
kind
of
fixed
hard-coded
IP
addresses,
rel
compatibility,
log
management
that
is
already
set
up
to
function
effectively
in
an
open
shift
setting.
The
reason
for
this
is
not
because
applications
that
don't
have
these
characteristics
can't
eventually
be
on-boarded
to
the
platform.
A
It's
more
like
an
early
phase
adoption.
You
want
quick,
wins,
immediate
success,
and
you
want
to
generate
momentum
that
those
teams
can
then
such
that
those
teams
can
promote
the
platform
and
the
methodology
to
other
application
users
in
the
organization
and
start
to
see
your
number
of
projects.
A
number
of
pods,
a
number
of
user
counts,
start
to
increase
the
way
we
saw
with
with
the
proto
bond
customer
example
earlier
this
morning,
fourth
start
to
challenge
existing
processes
in
a
lot
of
cases.
A
A
What
we
found
is
that
the
ROI
on
automation
is
very
large,
but
not
all
organizations
see
it
and
those
that
have
a
short
term
project
focus
tend
not
to
capture
those
opportunities.
So,
tactically,
what
can
we
do
to
adjust
our
mindset?
One
thing
to
look
at
is
maybe
starting
to
do
a
five
whys
retrospective.
So
a
lot
of
organizations
are
starting
to
or
continuing
to
employ
things
like
end
of
sprint
retrospective,
to
assess
what
worked,
what
didn't,
work
and
and
begin
to
start.
A
You
know
planning
for
the
next
sprint
that
can
have
an
overlap
with
this
notion
of
a
blameless
post
mortem,
especially
when
you're
talking
through
things
like
outages
and
process
failures
in
that
retrospective
start
to
look
at
opportunities
for
systemic
improvement
by
graphically
diagramming,
not
just
the
immediate
project,
shortcoming
or
failure,
but
examine
the.
Why,
behind
what
happened
and
the?
Why
behind
that
and
the?
Why
behind
that
and
the?
Why
behind
that,
so
that
you
can
start
to
identify
larger
systemic
improvements
rather
than
just
sort
of
short-term
fixes.
A
That
may
not
do
anything
to
kind
of
enable
the
the
organization
over
the
long
term
and
then
finally-
and
this
is
I-
think
problematic
for
a
lot
of
organizations,
but
is
worth
noting.
We
we
tend
to
see,
especially
on
the
platform
infrastructure
side,
that
uniqueness
and
creativity
is,
is
not
always
well
rewarded.
So
it
tends
to
work
better
at
the
application
layer.
A
A
We've
got
a
great
group
of
customers
here
today.
Just
to
recap,
digital
transformation
is
cultural
transformation.
I
think
we
all
understand
that
the
problem
is
culture
is
something
that
is
difficult
to
just
change
directly.
Culture
is
more
like
a
byproduct
of
the
practices
that
your
organization
is
pursuing,
and
these
are
some
practices
that
can
help
you
focusing
on
your
business
or
mission
goal
breaking
the
silos.
Prioritizing
the
right
applications
challenging
your
existing
processes
and
avoiding
unnecessary
uniqueness,
especially
in
the
application
platform
or
infrastructure
layer.