►
From YouTube: Modern Organizational Architecture, Are Microservices a Model for Diversity? - Brian Dawson
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Modern Organizational Architecture, Are Microservices a Model for Diversity? - Brian Dawson, Ortelius, Ripple
Virtual Track
Speakers: Brian Dawson
DevOps and Continuous Delivery require thoughtful attention to the Trinity of People/Culture, Process/Practices, and Tools/Tech. Very often teams and organization lean into the hard science of Process/Practices or Tools/Tech while struggling with or even completely avoiding People/Culture. Yet as proven by many high performing teams, a healthy and effective approach People and Culture is key to your success. In this session we will use the concept of micro-services as an analogy for how we can frame and manage diversity as "micro-cultures" which can balance between flexibility, freedom and alignment on shared objectives. Similar to the promise of micro services as enabling resilient fault tolerant systems, we can achieve resilient fault tolerant software organizations.
A
Today,
I'm
gonna
talk
about
a
concept
that
I've
been
thinking
about,
hopefully
to
inspire
some
thought
and
some
ideas
that
you
can
take
and
put
to
work
within
your
teams
and
organizations.
The
talk
is
titled.
Modern
organizational
architecture
are
microservices
a
model
for
diversity,
I'm
brian
dawson,
I'm
joining
as
a
member
of
the
board
of
directors
for
ortillius,
which
is
what
really
prompted
marrying
this
concept
of
micro
services
to
my
career-long
focus
on
increasing
and
improving
diversity.
A
So
I'll
give
away
the
punchline
all
right.
My
summary
or
my
thesis
is
that
in
ci,
cd
and
devops,
as
an
engineering
or
generally
analytical
discipline,
our
teams
and
organizations
tend
to
lean
on
the
process
and
practices,
aspect
of
devops
or
the
tools
and
tech
aspects
of
devops
versus
people
and
culture,
and
even
as
we
know
that
studies
are
showing
that
an
effective
approach
to
people
and
culture
and
diversity
is
a
key
to
success.
A
And
if
we
can
do
that,
then
we
can
achieve
resilient
fault,
tolerant,
human-centric
software
organizations.
So
why
am
I
talking
about
this?
Why
does
all
of
this
matter?
Well,
I
think
we
agree
that
most
of
us
are
here
because
we're
within
organizations
and
teams-
or
we
personally
have
a
desire
to
release
more
and
to
release
faster
and
to
do
that
in
a
way
that
we're
delivering
high
quality
software
so
that
we're
building
more
stable
and
more
secure
software
and
we're
doing
it
in
a
way
that
we're
delivering
an
improved,
innovative
ux
for
more
users.
A
As
I've
said
for
years
and
many
have
said,
a
fundamental
way
of
describing
continuous
delivery
and
what
devops
cultures
seek
to
achieve.
Is
we
seek
to
achieve
to
to
deliver
higher
quality,
better
software
faster
by
aligning
around
a
shared
of
shared
objectives
and
outcomes
that
have
a
particular
focus
on
delivering
software
rapidly
reliably
and
repeatedly.
A
But
we
just
can't
simply
automate
our
way
there.
We
can't
common
platform
or
sre
our
way
there.
We
can't
govern
mandate
or
higher
way
there.
At
the
end
of
the
day,
there
is
always
going
to
be
that
fuzzy
qualitative
component
of
humans
in
software
development
and
delivery,
and
we
we
just
can't
escape
that.
I
often
like
to
say
that,
no
matter
what
software
you're
delivering
software
is
being
developed
by
humans
for
humans,
there
may
be
a
few
edge
cases
where
that
concept
could
be
challenged.
A
I
also
want
to
take
a
moment
to
define
diversity
right
because
you
you've
seen
diversity
and
in
the
talk
overview.
I've
already
mentioned
diversity,
which
is
an
underpinning
of
this.
But
when
I
say
diversity,
it's
important
that
we
don't
narrowly
cast
it
right.
Diversity
can
be
generally
summarized
involving
or
participating
with
people
from
a
range
of
different
social
and
ethnic
backgrounds
and
of
different
genders
and
social
sexual
orientations.
A
When
we
look
at
this
concept
of
a
team,
I
borrow
from
a
study
that
referred
to
team
and
diverse
teen
diversity
as
individual
differences
between
members
of
a
team,
and
this
isn't
just
on
traditional,
gender
or
or
ethnic
diversity,
but
it's
value
diversity,
right,
a
difference
in
beliefs,
goals
and
values,
information,
diversity.
What's
our
experience,
knowledge
background
social
diversity,
gender
and
age
and
ultimately,
cultural
backgrounds,
various
lifestyles,
experiences
and
interests
that
compose
a
variety
of
individuals
with
different
viewpoints
that
can
be
brought
to
bear.
A
A
We
can
validate
assumptions
to
ensure
that
we're
arriving
at
the
right
solution.
It's
been
recognized
as
an
essential
feature
of
teams
and
then
in
the
absence
of
diversity,
gender
diversity,
for
example.
In
this
case,
some
teams
were
found
to
focus
more
on
speed
than
they
were
on
identifying
new
things
or
doing
new
things
on
things
new
ways
when
it
comes
to
ethnic
diversity,
studies
show
that
they
lost
the
benefit
of
multiple
viewpoints,
availability
of
knowledge
and
constructive
conflict
that
brought
about
better
outcomes
and
a
key
one.
A
So,
okay,
we
all,
I
think,
likely
agree
on
what
devops
is
why
it's
important
diversity
is
important.
So
what
is
the
problem?
Well,
the
problem
is
that
the
percentage
of
women
software
engineers
participating
is
extremely
low
when
we
get
into
the
u.s
that
the
the
disparity
between
male
software
professionals
and
female
software
professionals
are
even
larger.
A
I
contend
that
there
is
a
problem
that
we
need
to
address
and
solve
in
this
area.
So
let's
talk
about
microservices
for
a
second
we'll
set
a
baseline
again.
What
are
microservices
well,
borrowing
from
a
respective
colleague
of
mine
and
and
founder
of
ortillius
tracy
reagan.
In
a
presentation
she
gave
I'll
call
out
a
couple
of
things
right
with
microservices.
A
This
slide
is
that
when
you
move
to
a
loosely
coupled
arctic
architecture
of
services
connected
through
established
apis,
agility
becomes
possible,
resiliency
becomes
possible
and
more
so,
let's
compare
a
microservices
architecture
to
sort
of
our
traditional
monolithic,
architectures
right,
monolithic,
architectures
are
not
loosely
coupled
they're
tightly.
Coupled
it
results
in
less
reusability.
A
We
can't
take
sort
of
one
domain
or
one
implementation
and
easily
repurpose
it
to
another
code
can
be
complex.
It
can
be
tough
to
understand,
understand
the
code
and
the
business
knowledge
contained
in
it.
It
makes
it
harder
to
respond
and
scale
when
there's
a
demand
for
scale
and
and
it
results
in
a
single
point
of
failure
because
of
a
failure
to
follow
the
single
point
of
responsibility
principle.
A
Now,
let's
compare
that
monolith
to
microservices
to
organizational
architectures
traditional
architectures,
look
like
a
pyramid
right
power
increases
as
you
go
up,
and
all
employees
and
team
members
follow
a
chain
of
command
oftentimes.
This
follows
a
functional
organizational
structure
where
groups
are
based
on
specific
roles
or
specialties,
and
you
isolate
around
that
commonality
right.
A
When
we
look
at
kind
of
the
more
modern
approach
that
we
see
at
at
a
number
of,
probably
our
companies
here
and
peer
companies-
and
we
see
sort
of
as
a
extension
of
the
agile
movement
is
we
we
don't
tend
to
have
a
hierarchical
top-down
structure.
It
looks
less
like
a
pyramid
and
looks
more
like
a
node
graph
where
people
come
together
and
work
on
specific
projects
pursuing
business
goals
and
how
they
can
impact
them.
Those
business
goals.
A
A
When
we
look
at
some
of
the
traditional
organizational
structures,
they
can
leave
room
for
isolation
and
clicks,
which
discourages
diversity
or
discourages
the
feeling
of
inclusion.
They
place
a
priority
on
on
on
the
few
at
the
top
right
and
and
their
culture,
their
habitus,
their
learned
on
perspective
from
their
social
views
and
norms,
and
then,
if
that
happens,
to
be
wrong.
A
That
presents
a
single
point
of
failure
if
your
objective
is
to
deliver
an
inclusive
environment
for
your
staff
or
an
inclusive
software
product
that
can
address
a
wider
market
and
and
and
and
that
risk
is
emphasized
or
or
increased
through
limited
perspective.
Now,
in
contrast,
if
we
look
at
micro
services,
organizations
which
I'll
say
largely
very
grossly
is
composed
of
small
cross-domain
teams
that
are
organized
around
functional
areas
have
a
structured
way
of
communicating
together
and
ultimately
align
to
drive
a
single
or
deliver
a
single
system.