►
Description
IBM has long been on a mission to open doors for enterprises to usher in new innovation, foster interoperability and now more than ever engage developers. Their open engagement spans from the early years of Linux to today’s era where IBMers engage to establish openly governed communities such as OpenStack, Cloud Foundry and Node.js. Peter Klenk explains how open architectures and open communities lead to faster innovation.
Peter Klenk is a product manager, at a company of which you may have heard, called IBM. He's passionate about cloud computing, software development, and continuous delivery.
About Satellite:
GitHub Satellite 2016 was a celebration of the latest and greatest in development. Watch the recordings to learn how engineers, founders, activists, and beyond tackle the latest and most difficult challenges in software.
For more, join us in San Francisco on September 13th-15th for GitHub Universe, three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
Ibm
is
delivering
so
I
think
we
all
know
it's
a
very
disruptive
world.
You
know
I
a
joke
that
you
know.
Uber
is
now
a
verb
and
it's
a
verb
with
two
meanings:
I
ubered
over
here
this
morning,
but
when
we
talk
to
see
iOS
and
even
CEOs
of
enterprises,
they're
worried
about
being
ubered,
you
know
with
a
very
different
meaning.
A
You
know
a
competitor
out
of
nowhere
using
software
using
the
cloud
using
mobility
using
analytics
using
cognitive
computing
using
Internet
of
Things,
using
some
of
these
technologies
that
are
at
their
disposal
now
to
enter
a
market
completely
unseen.
You
know
it's
a
stealth
attack.
It's
not
like,
there's
a
massive
ramp
up
of
infrastructure
to
be
able
to
deliver
these
disruptive
applications.
A
A
It's
the
developers
who
are
going
to
create
those
new
applications
that
are
going
to
figure
out
innovative
ways
of
leveraging
those
services
and
so
leading
a
digital
transformation,
and
the
enterprise
is
really
about
empowering
the
developer
and
I
think
there
are
a
couple
ways
to
look
at
that.
You
know
one
is
the
kind
of
culture
you
establish
in
the
organization.
A
Another
is
the
kind
of
communities
you
create
in
your
organization,
but
also
the
kind
of
communities
you
participate
in
outside
your
organization
and
that's
where
open
source
and
proprietary
development
you
know
start
to
blend.
A
lot
is
when
you
get
into
the
community
aspect
of
things
and
then
third
is
code.
What
are
we
building?
What
does
that
code?
Look
like
what
are
we
choosing
for
our
platforms
that
our
infrastructure
and
how
are
we
connecting
it?
A
Ibm
has
a
history
with
disruption
by
the
way
you
know,
I,
think
many
of
you
probably
think
of
us
as
the
mainframe
company
in
the
mainframe
generation,
I
think
people
thought
of
us
is
the
typewriter
company.
So
you
know,
even
though
you
know
IBM
might
not
be
perceived
as
the
leading
cloud
native
forefront
of
change
in
the
fact.
Is
we've
been
able
to
do
this
over
many
generations
of
Technology.
A
All
right,
so
here's
where
we
were
so
how
do
we
create
a
culture
in
the
enterprise
for
innovation,
for
the
developers
and
I
think
you
know
in
the
enterprise
they're,
always
a
lot
of
excuses
and
I'm
going
to
say
their
excuses,
because
this
is
not
optional.
If
you're
going
to
be
competitive
in
the
market,
you
need
to
deliver
faster.
You
need
to
leverage
new
technologies.
A
The
processes
that
are
set
up
aren't
catered
to
this.
The
organizational
structures
that
are
set
up
our
cater
to
this
typical
enterprises
are
very
hierarchical.
Functions
are
divided
very
much
by
silo.
There's
the
ops
team.
There's
the
dev
team,
there's
the
QA
team,
there's
the
business
analyst
team.
That
does
something
that
occasionally
tells
development
what
they
need
to
do,
but
not
on
a
continuous
basis.
And
you
know
this
is
counter
to
how
you're
going
to
move
quickly
and
experiment.
A
A
lot
of
industries
are
highly
regulated
healthcare,
financial
services,
and
so
that
imposes
a
burden
and
process
on
verification
on
separation
of
duties
that
you
know
it's
kind
of
neglected.
When
you
read
the
literature
of
what
the
folks
at
Etsy
or
the
folks
that
Netflix
are
doing
with
cloud
and
DevOps,
but
it
doesn't
mean
you
can't
address
those
needs
in
a
fast-moving
environment,
it
just
means
it
takes
some
care.
A
The
kind
of
architectures
and
systems
that
we've
built
traditionally
aren't
amenable
to
fast
delivery
and
disruption.
They're,
often
large
monolithic
applications
running
on
specialized
dedicated
hardware.
You
know,
if
you
look
at
some
of
the
you
know
cloud
native
practices
for
zero
downtime
deployment.
How
do
you
pull
that
off?
Well,
yeah,
apps,
up
and
running
you
bring
up
the
new
version.
You
gradually
shift
traffic
over
to
it,
that's
great,
but
it
assumes
you
have
an
architecture
we
can
have
multiple
instances
and
that
the
application
logic
is
separate
from
the
data
tier.
A
A
We
had
very
discreet
lines
of
business
and
we've
been
deliberately
trying
to
execute
a
change
over
the
last
several
years,
we've
reorganized
into
smaller
squads
and
following
the
Spotify
nomenclature
around
squads-
and
you
know
we
talked
about
to
pizza
teams,
now
kind
of
unheard
of
in
the
old
IBM,
where
organizations
you
know
were
measured
in
hundreds
of
people.
That
means
they're,
obviously
building
some
more
granular
stuff.
So
a
micro
service
architecture
almost
emerges
from
this
cultural
pattern,
because
six
to
twelve
people
can't
build
a
million
lines
of
code
in
a
couple
months.
A
So
that's
a
nice
benefit.
We've
broken
the
silos
down
and
combined.
You
know
QA
and
ops
responsibilities
into
the
dev
team
and
it's
eye-opening
for
developers
the
first
time
they
have
to
write
an
automated
test
for
web
UI
and
they
only
can
rely
on
XPath
because
they
didn't
think
to
put
in
unique
IDs
for
various
UI
elements,
something
the
QA
team
has
been
arguing
about
and
arguing
for
for
a
decade
but
never
half.
A
Now
that
the
developers
understand
and
feel
the
pain
it's
happening,
I
opening
when
developers
get
an
alert
through
pagerduty
that
a
runtime
service
in
production
is
down,
and
so
you
know
just
that
organizational
dimension
is
forced
the
huge
amount
of
change
into
the
way
people
act
and
behave
and
think
about
what's
important
when
the
writing
code
and
the
realities.
It's
not
just
the
code.
They're
writing,
but
it's
thinking
ahead
to
what
it's
coming.
A
You
know
move
to
more
of
a
con
bone
process
and
continuous
delivery
a
decade
ago,
maybe
a
little
more,
you
know,
IBM
was
doing
an
agile
transformation
and
we
saw
this
in
a
lot
of
enterprises.
Agile
was
the
big
thing
and
I
could
argue
it
either
way
it
succeeded
in
that
our
development
teams
started
doing
continuous
integration.
They
started
doing
daily
stand-ups
and
increasing
communication
within
their
team,
so
that
was
all
great
but
didn't
actually
solve
the
problem,
because
that's
not
where
the
bottleneck
was
right.
A
The
bottleneck
was
how
do
you
get
that
code
out
of
the
development
team
how'd?
He
get
a
test
that
and
get
it
into
production
and
that
continuous
delivery
mindset
wasn't
there
when
we
embarked
on
agile
a
decade
ago
and
when
a
lot
of
others
didn't
so
I
think
that's
a
real
difference
in
mindset
in
this
transformation
and
one
that's
actually
getting
the
results
we
want,
which
is
faster
code
into
market,
to
innovate,
to
at
least
experiment
and
see
what
it's
going
to
be
successful
for
our
applications.
A
We
started
embracing
tools,
like
slack,
I'm
sure,
a
lot
of
people
here,
you
know
use
similar
tools
for
real-time
collaboration
and
again
all
the
stakeholders
are
listening
on
the
same
channels
and
we've
integrated
it
with
our
systems.
So
operations,
issues,
test
issues,
build
issues
all
are
automatically
getting
fed
into
that
channel.
So
there's
a
tremendous
increase
in
real-time
awareness
of
what's
going
on
with
the
project.
A
So
how
do
we
go
about
that
transformation?
The
executives
sponsored
it
early
on
and
established
a
center
of
competency
within
IBM,
and
they
didn't
build
this
by
bringing
in
outside
experts.
They
didn't
build
this
by
bringing
in
necessarily
people
who
have
done
other
things.
You
know
that
were
interesting.
A
We
sat
with
some
core
tools:
github
Enterprise,
being
one
of
them
and
probably
being
the
first
one
we
standardized
on
as
the
platform
for
coding
and
by
having
one
github
Enterprise
repository
across
the
organization.
We
had
the
ability
to
share
code
more
widely.
Now
it's
taken
I'll,
say
about
a
year
for
teams
to
see
the
power
in
that
I'd
say
you
look
a
year
ago,
you
look
six
months
ago.
A
So
we've
got
a
much
more
polyglot
world
now
and
so
now
you
know
things
that
they
used
to
be
and
I
may
be
calm
and
blessed
code,
for
you
know:
well
no
one's
written
that
code
in
Python
yet
or
in
or
four
node
yet
so
that
you
know
now,
there's
a
way
to
find
it.
Someone
probably
has
written
that
it's
somewhere
in
IBM,
and
you
know
we
can
go
to
ghe
and
look
for
it.
A
So
teams
have
seen
results
in
developers
are
seeing
less
process
overhead
and
more
focus
on
doing
what
they
want
to
do,
which
is
coding,
which
is
great
deployments,
because
we
now
this
automated
pipeline
that
includes
test
that
includes
production,
deploy
you
know,
time
to
deploy.
New
changes
is
going
down
for
one
of
our
infrastructure
teams.
You
know
from
ours,
which
was
typical
old
school
manual,
release,
weekend
kind
of
events
into
the
six
minutes,
I'm
sorry
26
hours
and
then
two
minutes.
You
know
now
that
everything
is
automated.
A
The
Watson
team
is
an
interesting
example:
people
familiar
with
IBM
Watson
and
the
cognitive
platform
you
a
lot
of
hands.
The
Jeopardy
game
show
was
brilliant
as
far
as
MIT
building
awareness.
That
was
almost
two
years
ago,
and
so
you
know
the
day
after
jeopardy.
The
team
was
formed
to
say,
okay,
take
the
school
technology,
we're
going
to
start
building
products
we
want
to
monetize
and
because
Watson
was
driven
out
of
research.
That
was
not
something
they
worried
about
before,
because
Watson
was
delivered
at
a
research
memory,
footprint,
compute
requirements.
A
Architectural
flexibility
and
how
you're
going
to
evolve
that
code
base
globalization
and
internationalization
a
whole
bunch
of
things
work
thought
about.
So
this
new
team
inherited
the
set
of
problems
with
this
code
base
with
a
lot
of
potential,
and
so
from
day
one.
You
know
they
wanted
to
model
what
deleting
cloud
teams
were
doing
so
they
really
started
with
the
goal
of
very
quick
delivery
cycles,
delivering
all
the
services
through
the
cloud
through
the
IBM
bluemix
platform,
and
you
know
just
picked
away
at
this
code
base
and
extracted
and
refactored
and
hardened.
A
So
this
is
reproducible
in
other
enterprises.
I
guess
I,
don't
know
the
audience.
How
many
people
here
are
small
company
big
company?
This
curious,
any
big
company
people
will
say
over
a
thousand
people,
a
few
all
gravitate
to
the
back
and
the
near
the
door,
probably
because
get
paged
any
second.
But
this
senator
competency
learned
a
lot.
A
You
know
about
how
to
do
this
and
because
they
were
trying
to
replicate
across
IBM,
they
wrote
it
down
and
what
we've
done
is
shared
that
on
the
web,
and
if
you
go
to
this
link,
you
can
register
today
for
free
as
an
attendee.
You
can
also
register
tomorrow
for
free
as
a
person
we're
not
charging
for
this
at
all.
You
don't
actually
have
to
register
to
get
access
and
we've
broken
down
what
we
learned
in
26
practice
areas.
A
You
can
see
around
the
outside
of
the
the
wheel
here,
a
wheel
of
hexagons
all
centered
around
a
cold
as
a
seventh
category
and
I'm
going
to
just
breeze
through.
You
know
some
examples
of
this
real
quickly,
but
you
know
please
do
check
this
out
on
the
web.
If
so,
I
mentioned
some
of
the
cultural
things
I
mentioned,
you
know
d,
siloing
teams
and
fostering
full
sense
of
ownership,
my
bench
an
executive
sponsorship.
I
don't
think
I
mentioned
collaborative
spaces,
but
IBM
is
a
very
distributed
company
people
all
over
the
world.
A
We've
leveraged
that
and
had
very
distributed
teams.
I
know,
certainly
in
the
open
source
community.
You
know,
teams
are
entirely
distributed
and
are
very
effective
at
collaborating,
but
when
I
go
to
work
every
day
at
an
IBM
lab
that
is
nominally
home
to
3000
developers
and
I
can't
find
a
group
of
more
than
two
people
working
on
the
same
project.
It's
the
distributed
things
gotten
out
of
hand.
A
You
know,
there's
an
opportunity
for
real-time
collaboration
that
we're
missing
so
we've
actually
reorganized
teams
and
swapped
people
around
over
the
last
year
year
and
a
half
to
try
to
get
more
Geographic
cohesion
amongst
various
squads,
and
then
we've
moved
them
into
more
collaborative
workspaces.
We've
broken
down
cube
walls
and
office
walls
and
we've,
you
know,
had
more
of
the
kind
of
office
space
you'd
see
at
github,
for
example,
I've
seen
their
headquarters
and
a
lot
of
open
space
from
spontaneous
collaboration.
A
The
think
practice
area,
I
think,
is
really
important
and
it's
not
about
code
and
it's
not
about
technology,
but
at
the
end
of
the
day
in
the
enterprise.
The
reason
for
this
change
is,
you
want
to
innovate
and
you
want
to
disrupt
your
industry
before
some
upstart
competitor
does,
and
so
that
has
to
start
with
the
business.
So
you
know
before
you
embark
on
some
project.
A
You
need
to
understand
what
you're
trying
to
do
it's
great
to
say:
well,
build
something
and
throw
it
out
there
see
what
happens,
but
how
are
you
going
to
see
what
happens
so
from
the
very
beginning?
You
know
establishing.
What's
your
hypothesis,
what's
your
minimum
viable
product,
that's
going
to
test
the
hypothesis.
How
are
you
going
to
measure
those
results
and
learn
from
that
sounds
obvious.
A
big
change
actually
for
the
way
some
teams
worked.
A
Design.
Thinking
is
the
other
thing.
Ibm
is
embraced
in
a
big
way.
Everything
we
build
has
a
user
in
mind
might
be
a
consumer,
it
might
be
someone
in
your
enterprise,
it
might
be
a
consumer,
a
programmer
who's
using
an
API
you
produce,
but
everything
has
a
user.
Everything
has
a
user
experience,
they're
not
uniformly
good,
and
so
the
way
we
implement
design
thinking
is
up
front.
A
We
spend
a
lot
of
time
identifying
who
the
user
is
and
establishing
a
persona
to
represent
them,
and
then
we
create
what
we
call
an
empathy
map
that
describes
what
that
user
is
thinking.
What
are
they
doing?
You
know
they're
clicking
this
button,
they're
thinking
this
is
too
many
buttons.
You
know
what
are
they
feeling?
This
is
a
dumb
app
you
know
and
look
for
ways
to
change
how
they're
feeling
about
what
they're
doing
in
my
stepping
back
and
changing
what
they're
doing
so
we
do
a
lot
of
this
user
design.
A
Code
I
mentioned
some
of
this.
A
lot
of
agile-
you
know
comes
through
here,
but
you
know
doing
it
for
real
this
time,
certainly
bringing
in
things
like
quality
and
test-driven
development
and
doing
it
for
real
this
time
in
delivery.
I
think
understanding
that
you
know
some
sense.
The
pipeline
and
being
able
to
push
builds
through
the
pipeline
are
more
important
than
what
you
actually
do
on
the
way
to
production.
I
saw
this
pattern
many
times
in
clients,
as
well
as
an
IBM,
where
application
have
pick
a
big
number.
A
Two
thousand
tests,
two
thousand
functional
tests-
it's
great,
it's
not
great.
It's
meaningless,
it's
meaningless
because
there's
only
one
guy
who
can
get
them
to
work,
and
it's
only
on
one
machine,
and
you
know
his
laptop
is
busted
today,
so
in
having
a
place
where
they
can
run.
Repeatably,
that's
visible
to
the
whole
team,
where
errors
are
visible
to
the
whole
team.
I'd
say
it's
more
important.
A
A
You
know
in
the
cloud
in
production,
some
chaos,
testing
and
so
on.
End
of
the
cycle
is
learned.
You
know
what
did
what
have
we
gathered
from
running
the
system
in
production
that
can
feed
back
into
our
process
and
either
verify
our
hypothesis
or
cause
us
to
change
it?
So
instrumentation
is
way
up
both
on
where
the
users
are
spending
time,
as
well
as
traditional
kind
of
who's
coming
to
the
applications
and
so
on.
So
that
was
you
know
the
methodology
and
the
culture
aspect
of
this.
A
The
stat
that
jumps
out
I
think
most
to
me,
is
that
less
than
three
percent
of
companies
don't
use
open
source
at
all.
This
is
ubiquitous.
Open
source
is
now
part
of
everyone's
platform,
different
degrees,
different
choices,
but
it's
ubiquitous
and
more
and
more
companies
not
only
are
rolling
out
projects
based
on
open
source,
but
are
looking
to
more
actively
participate
in
the
next
one
to
three
years.
So
I
think
that's
exciting
and
I
think
you
know
github
as
a
platform
for
doing
that.
A
You
know
it's
been
really
helpful
and
the
successes
of
projects
like
the
web
and
Linux-
and
you
know
big
things-
has
really
opened
eyes
to
the
power
of
open
source,
but
they're
kind
of
this
free
software
and
there's
successful,
open
source
and
they're,
not
the
same
thing.
I
mean
I,
think
we've
all
seen
code
bases
out
there
that
don't
really
have
a
governance
structure
that
aren't
really
licensed
in
a
way.
That's
agreeable
for
enterprises
to
pick
up.
A
A
A
Gpl
is
a
noble
experiment
and
I.
Think
the
nature
of
GPL
was
driven
by
the
desire
to
keep
increased
participation
and
openness
by
sharing
everything
back,
it's
a
great
desire,
but
it's
backfired
and
it's
backfired,
because
a
lot
of
enterprise
is
trying
to
build
on
open
source
and
leveraging.
It
can't
accept
those
terms
and
their
extensions.
So
something
like
the
apache
license
in
fact,
Spurs
more
contributions
and
more
participation
because
of
the
fact
you
can
control
what
you
keep
private
and
what
you're
going
to
contribute
back
and
it
frees
you
up
to
do
more.
A
You
having
clear
governance
structures
as
the
other
one
I'll
mention
it's
great
to
have
the
code
transparent.
You
also
want
to
know
how
decision-making
is
happening
if
you're
going
to
bet
a
product
or
a
platform
or
an
application
on
it.
You
need
some
reassurance
that
again
one
vendor
or
one
individual
isn't
controlling
the
world.
There
are
some
examples
of
technologies.
We've
seen
from
very
prominent
companies,
doing
a
lot
of
things,
an
open
source,
but
things
that
you
know
never
reach
this
level
of
maturity.
A
Where
there's
an
open
governance
structure
with
the
diversity
go
system
with
the
number
of
key
players,
you
want
high
participation,
but
you
don't
want
it
centralized
so
think
of
something
like
Facebook,
parse
kind
of
cool
they're
going
to
open
source
it
great
people
like
that
and
Facebook
pulled
the
plug
and
I.
Think
it's
going
away.
I,
don't
think!
There's
any
legs
to
it
left,
so
the
community
is
really
important.
A
A
Let's
just
talk
about
some
of
the
projects
we're
contributing
to
now,
so
we
actually
have
an
open-source
group.
We
have
several
of
these
in
IBM
and
a
lot
of
it
right
now
is
centered
around
cloud
computing,
although
also
run
data
and
analytics
and
Internet
of
Things-
and
you
know
we're
bringing
serious
resources
to
bear
to.
You
know
make
a
number
of
foundational
technology
successful,
so
OpenStack
the
largest
open
source
infrastructure
as
a
service
platform.
A
Huge
number
of
contributors-
I,
don't
know
offhand
the
IBM
number,
but
you
know
it's
it's
hundreds,
but
there
are,
you
know
thousands
working
on
this
project,
high
level
of
activity
and
we'll
talk
about
why
I
think
this
is
important
in
a
minute,
so
that
was
the
infrastructure
layer
in
this
multi-language
multi
runtime
world
kind
of
a
pain
to
set
up
all
that
language
runtime
stuff.
So
cloud
foundry
emerged
as
platform
as
a
service
with
variety
of
language.
A
Runtimes
IBM
has
been
contributing
to
this,
for
I
want
to
say
over
two
years,
but
from
the
core
and
in
some
of
the
language
run
times.
As
you
know,
a
way
to
provide
the
platform
of
choice
to
each
development
team,
where
they
can
pick
the
right
platform
for
their
application,
IBM
is
working
on
node,
so
nodes
an
example
where
the
technology
was
great,
but
the
infrastructure
and
the
governance
model
wasn't
quite
there.
A
Yet
and
a
while
ago
we
saw
this
Fork
of
the
node
code
base
into
nodejs
and
I
ojs,
and
you
know
that's
a
path
of
destruction
for
an
open
source
platform,
sometimes
because
you
lose
critical
mass.
So
one
of
the
things
I've
been
working
on
was
ringing
that
code
base
back
together
and
establishing
a
foundation
that
can
independently
govern
the
node
community,
similar
in
data
couchdb,
the
IBM
acquired
Cloudant,
which
was
one
of
the
main
contributors,
the
couch
and
we're
still
contributing
their
spark.
A
The
list
goes
on
this
morning.
Chris
mentioned
Swift
in
the
keynote
and
IBM
is
involved
in
that
one
too.
We've
partnered
with
apple
and
a
number
of
things,
and
one
of
them
has
been
the
initiative
to
bring
Swift
to
the
server.
So
a
key
part
of
that's
just
pretty
straightforward.
You
know
port
it
to
Linux
whatever,
but
part
of
that
was
the
recognition
that
okay,
we
got
a
server
language
now,
but
where's
the
web
framework.
That's
great.
A
We
had
all
the
mobile
AP
is
for
the
iOS
apps,
but
if
you
wanna
use
it
for
something
else,
you
really
need
a
web
presence,
so
IBM
established
keturah,
which
is
a
web
framework
built
in
Swift
for
swift
architectural
patterns,
largely
based
on
express
j/s,
but
I
got
that
community
bootstrapped
IBM
also
hosts
with
sandbox.
So
if
you
want
to
play
with
Swift
this
way
to
do
that
online,
you
have
an
online
editor.
It
runs
immediately
and
in
a
fun
way
to
get
started.
A
So
why
does
that
matter
to
IBM
I
you
know,
could
rattle
off
more
and
more
projects
and
gee?
That's
great!
Aren't
we
wonderful,
but
why
does
it
matter
because
you
think
IBM
would
want
to
compete
on?
You
know.
Our
cloud
is
better
than
your
cloud
and
if
our
cloud
is
built
on
some
of
the
same
open
sources,
your
cloud
isn't
that
a
disadvantage,
and
the
answer
is
no.
Our
cloud
is
better
than
a
lot
of
clouds
and
the
reason
it's
better
is
it's
because
it's
built
on
some
of
these
open-source
platforms.
A
So
if
you
look
at
IBM,
bluemix
bluemix
offers
virtual
machines
managed
by
OpenStack
offers
containers
compatible
with
docker
and
with
an
enterprise
trusted
registry
as
well
as
other
doctor
registries.
It
offers
cloud
foundry
runtimes
if
you
want
a
really
low
cost
way
of
getting
your
node
or
Java
or
Ruby,
or
go,
or
whatever
application
up
and
running
with
things
like
auto
scaling
and
dynamic
memory
management
in
a
cloud.
Foundry
is
your
answer.
So
we've
got
all
these
runtime
platforms
and
because
these
are
open
platforms,
we
were
also
able
to
deliver
them
in
a
variety
anyways.
A
So
we
have
a
public
multi-tenant
cloud
as
everyone
would
expect
when
we
say
cloud,
but
we
can
also
host
that
same
stack
either.
In
a
dedicated
single-tenant
environment
in
our
data
center,
or
we
can
host
it
in
your
data
center
and
I
think
the
openness
of
this
as
part
of
it
gives
us
the
flexibility
to
do
some
of
those
things.
So
we
got
infrastructure,
we've
got
run
times,
we've
got
flexible
delivery
models
and
the
other
thing
we
have
in
the
upper
right
is
a
Service,
Catalog
and
I
mentioned
earlier.
A
This
is
the
is
becoming
v
way.
Ibm
offers
new
capabilities
to
market
so
instead
of
the
big
model,
if
the
konprann
map,
seeing
things
like
Watson
deliver,
very
small,
very
contained,
discreet
services,
published
AP
is
pay-as-you-go,
you
know
or
subscription
through
the
bluemix
catalogue,
and
it's
not
just
IBM.
There
is
large
number
of
third-party
services
available
there
as
well,
so
I
need
to
wrap
pretty
quickly,
but
I
just
wanted
to
comment
about
that.
Devops
bar
on
the
top
of
the
slide.
A
When
we
talk
to
enterprises
about
how
to
be
successful
with
cloud
and
digital
transformation
and
all
these
themes
in
a
part
of
it
is
the
learning-
and
you
know
what
are
the
best
practices
and
that's
in
the
method,
part
of
its
the
platform
and
that's
what
we've
brought
together
here,
building
on
open
source,
but
then
part
of
its
on
the
tools.
I
think
tools
aren't
everything,
but
tools
are
important
and.
A
Just
to
practice
some
of
what
we've
peaked
preached
here
and
we
have
a
hypothesis
we
want
to
test,
and
the
hypothesis
is.
This
is
beyond
hypothesis.
We
know
teams
want
best-of-breed
tools
and
that
not
every
team
is
going
to
want
the
same
thing,
but
we
also
know
when
you
try
to
repeat
that
across
the
enterprise
just
buying
the
team,
the
tools
licensing
them
provisioning,
your
users,
integrating
them
together.
A
Getting
the
right
plugins
in
the
right
places,
is
cumbersome
and
then
trying
to
figure
out
they're
all
trying
to
tell
you
is
difficult
as
well,
so
we
establish
three
personas.
The
developer
just
wants.
Where
are
my
tools?
I
just
joined
a
new
squad
this
week.
Where
is
our
github
repo?
Where
do
we
keep
issues?
Where's
our
play
on
what
our
latest
test
results
just
find
the
stuff?
A
The
team
lead
wants
to
be
able
to
add
tools,
as
the
team
grows,
as
the
team's
needs
change,
but
isn't
a
full-time
tool.
Smith
we
used
to
have
those
in
some
enterprises
they're
gone
now,
so
it
needs
an
easy
way
to
do
that
and
then
Caroline
who's
sponsoring
the
executive
executive.
Sponsoring
the
transformation
wants
to
be
able
to
pick
those
practices
and
tool
chains
that
are
working
and
stamp
them
out
across
multiple
teams
so
coming
to
bluemix,
and
this
is
something
you
can
go
check
out
now.
A
Is
this
idea
of
tool
chains
as
first
class
objects
that
let
you
establish
for
a
team?
Here's
the
set
of
tools
we're
using
this
will
automate
some
of
the
integration,
it'll
automate,
the
provisioning
of
users
and
it's
a
platform
which
you
can
build
and
we
are
building
analytics
to
try
to
derive
meaning
from
all
these
tools,
for
the
enterprise
transformation
aspect
makes
these
tool
chains
template
eyes
so
that
you
can
stamp
them
out
again
and
again
for
teams
with
similar
needs.
A
Part
of
the
toolchain
initiative
was
partnering
with
github,
so
in
February
we
announced
that
IBM
is
going
to
offer
github
enterprise,
so
single-tenant
private
solution
for
enterprises
that
I
want
that,
but
posted
and
managed
by
IBM
in
the
IBM
cloud,
for
teams
that
don't
want
to
run
their
own
infrastructure
and
become
github
admins.
So
this
is
the
first
example
where
we're
trying
to
bring
those
best
debride
tools
into
the
IBM
cloud
platform
as
a
first-class
part
of
the
platform
and
make
them
available
to
our
enterprise
clients.
A
So
for
innovation,
you
need
the
method
and
check
out
the
garage
method,
engage
in
communities
and
there
are
a
number
of
cloud
foundational
communities
we
think
are
very
critical
to
enabling
innovation
that
we're
working
with
and
then
a
platform
that
brings
it
all
together
and
that's
IBM
bluemix.
So
you
can
check
these
things
out.
If
you
want
to
read
look
at
the
method,
if
you
want
to
code,
look
at
bluemix
you'll
find
the
Swift
sandbox
there
and
I
almost
got
us
back
on
time.
Thanks
very
much.
You.