►
From YouTube: DevOps Intelligence: Scaling Governance, Compliance, and Security across an Enterpri... Jamie Plower
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
DevOps Intelligence: Scaling Governance, Compliance, and Security across an Enterprise of 15K Developers - Jamie Plower, Fidelity Investments
At Fidelity Investments, every application workload must meet a unique mix of security, regulatory, audit & governance requirements to protect millions of customers. Enabling a standard automated approach to securing the CI/CD pipeline & Devops toolchain, ensures that engineering teams adhere to policy while being continuously audit-ready & secure. Scaling DevSecOps across application teams, code bases & various workload architectures requires bigger-picture thinking, built in flexibility and a smart approach from the start. During this session, Jamie will share Fidelity's journey to support over 15,000 engineers around the globe with our modern delivery approach. Hear about our challenges & successes to enabling accelerated velocity and overcoming our scale, while providing integrated, real-time governance and operations capabilities across the application lifecycle
A
Welcome,
first
of
all,
thank
you
all
for
taking
the
time
to
join
the
talk
and
for
those
who
don't
know
me,
my
name
is
jamie
plower
and
I'm
a
director
of
architecture
from
fidelity
and
focused
on
in
the
devops
space,
within
our
application,
lifecycle,
management
and
product
area,
and
I'm
excited
today
to
talk
to
you
about
how
we
are
approaching
governance,
compliance
and
security
at
scale
at
fidelity.
And
so,
let's
kick
off
just
to
manage
your
disclaimer.
A
We're
kicking
off,
like,
I
think,
fidelity
just
for
those
who
aren't
aware
and
we're
a
large
financial
services
firm
and
we've
75
plus
years
of
rich
technology,
innovation
and
we're
not
new
to
our
digital
transformation
and
we're
highly
regulated
environments.
It's
of
key
importance
to
us
that
we
deliver
software
at
scale
but
with
security
is
a
key
proponent
of
that,
as
I
mentioned
before.
I
think
when
we
submitted
this
talk,
there's
15
000
developers
have
been
informed
since
I
think
we're
growing
to
16
close
to
17
000
at
this
stage.
A
So
it's
really
critical
in
this
industry
that
we
are
able
to
be
really
have
a
lot
of
confidence
about
how
we're
releasing
software
quickly,
but
managing
that
rich
resource
ecosystem
of
developers
and
again
within
this
space.
Fidelity
like
it's
like
any
other
company,
there's
a
large
competitive
environment
and
constantly
needing
to
innovate
and
ensure
that
we
are
always
innovating
and
bringing
the
best
practice
toward
our
delivery
processes
and,
as
they
say,
in
investing
and
previous
past
performance
is
no
guarantee
of
future
success.
A
So,
as
you
can
see
from
this,
we're
well
on
our
way
in
our
digital
transformation.
Cloud
native
technology
and
open
source
are
a
key
component
of
that.
But
what
we're
going
to
talk
about
as
we're
releasing
our
software,
how
we're
focusing
on
that
delivery,
so
pipeline
intelligence
and
how
we're
looking
at
our
compliance,
so
under
underpinning
our
overall
strategy
and
learning
from
the
past
is
is,
is
how
we're
focused
on
bringing
together
standardization
as
much
as
possible.
A
So
a
key
part
of
that
is,
is
inner
source
and
bringing
together
our
various
business
unit
groups
and
ensuring
that
we
can
bring
together
a
layered
approach
to
our
delivery
processes
and
and
one
area
how
we
have
achieved
that
is
fidelity
pipeline
library,
there's
nothing
new
about
it.
It's
just
bringing
together
the
wealth
of
professionals
in
this
space
and
ensuring
that
together,
we
are
learning
from
our
past
experiences
and
focusing
on
a
capability
model
that
we
can
all
deliver
together.
A
On
top
of
that,
it's
focused
on
then
workloads
that
we
can
stroke
from
that.
So
if
you
want
to
take
the
analogy
that
the
library
itself
is
like
the
lego
blocks,
the
instructions
themselves
are
the
individual
workflows
that
we
are
building
through
and
again
with
that.
We
can
guarantee
much
more
immutability
in
how
teams
taking
a
cognitive
load
about
having
them
to
construct
particular
workflows
and
focusing
forward
on
on
making
sure
that
they
are
constantly
up
to
date,
have
baked
in
policy
and
tying
that
need.
A
A
So
again,
feedback
from
our
overall
community
in
the
past
was
how
they
were
not
only
stifling
the
innovation
around
bringing
their
pipelines
together,
but
how
they're
constantly
staying
up
to
date
with
compliance
and
the
other
angle
that
we
have
to
think
about
is
our
compliance
and
audit
units
within
the
firm
can't
scale
to
every
single
team
to
the
needs
that
we
want.
It's
generally
a
painful
process.
A
Why
is
this
important
like
going
back
to
the
pipeline
sprawl
initiative?
I
mentioned
beforehand
there.
Without
this
teams
were
either
creating
pipelines
that
had
little
nuanced
needs,
we
weren't
getting
the
benefit
of
reuse.
We
had
limited
governance
opportunities
because,
with
that
sprawl,
we
couldn't
guarantee
that
we
were
having
that
appropriate
security
and
governance
controls
in
place
and,
naturally-
and
surprisingly,
a
lot
of
the
teams
were
bought
into
this
immediately
and
it
took
the
discussion
of
like
I'm
special
I'm
different.
A
Everyone
had
a
voice,
it
was
a
democratic
situation
and
what
we
built
out
was
this
rich
capability
model
very
very
quickly,
so
we
have
12
different
business
units
that
spread
across
this
was
very
distributed,
and
it
means
then,
that
everyone's
getting
the
single
benefit
of
it.
Another
area
to
focus
on
was
specific
capabilities
within
our
tool
chain
were
complex.
A
Some
of
the
native
deployments
were
quite
bespoke
between
the
teams,
so
we
could
leverage
existing
tooling
that
exists
and
help
build
that
capability
and
grow
it
as
its
own
little
project
itself,
so
it
further
developed
more
innovation
and
reuse
and
standards
across
the
firm
and
that's
the
key
tenant
that
we're
looking
at
here.
In
that
we're
going
to
introduce
some
sort
of
scale
of
compliance.
Some
standardization
is
really
really
important,
and
flexibility
is
key
to
this
as
well.
A
There
are
nuanced,
is
a
journey
so
making
sure
that
we
were
baking
it
in,
but
again
that
had
another
aspect
on
how
we
were
designing.
This
work
in
the
first
place
to
make
sure
that
there
was
no
breaking
changes.
It
was
more
reliable
and,
as
we'll
discuss
a
little
bit
a
little
bit
better
then
further
on
once
you
have
this
in
place,
how
you
can
actually
then
extract
data
insights
that
will
help
validate
evidence
around
attestation
going
forward
and
the
process
itself
was
really
key
in
that
we
had
frictionless
experience.
The
developer.
A
Experience
is
key
to
this,
ensuring
that
everyone,
whether
you're,
a
hardcore
programmer
or
a
systems,
engineer
or
even
light
touch
that
you
can
get
involved
and
how
we
designed
this-
that
the
changes
were
very
simple
to
understand
and
a
very
clear
way
to
remediate
if
a
defect
did
come
out
going
back
to
the
catalogs
that
build
on
this.
This
allowed
us
to
understand
our
application
workflows
in
much
more
detail.
A
There's
one
between
ci.
It's
pretty
well
understood
it's
not
a
mature
process
within
the
firm
but
cd
itself.
There's
a
lot
of
legacy
there
that
we
have
built
and,
as
people
are
migrating
their
application
toward
cloud,
we
want
to
have
a
much
richer
discussion,
design
these
workflows
with
flexibility
and
build
in
some
flexibility
that,
for
example,
specific
stages
could
be
introduced
around
testing,
for
example,
or
how
many
environments
they
want
provisioned
and
how
we
could
extract
that
away
into
how
we
were
building
this.
A
A
So
again,
just
taking
this
concept
at
a
higher
level.
Looking
a
little
bit
further
like
one
of
the
key
areas
that
we
understood
is
okay,
we've
got
a
strict
backbone
across
our
devops
value
chain,
but
if
we
focus
in
on
a
specific
capability
like
what
is
that,
and
how
can
we
actually
get
specific
data
points
from
this
so
looking
at
each
capability
because
it
performed
a
well-defined,
fast,
a
task,
the
other
area
was,
it
provides
specific
context
that
was
completely
unique
to
the
pipeline.
That
was
being
run.
A
So
we
decorated
these
individual
capabilities
with
an
eventing
mechanism
where
we
could
extract
all
the
input
information
related
to
that
var
itself.
The
execution
life
cycle
of
that
specific
tasks
that
it's
doing
so,
whether
it
be
a
unit
test
or
whether
it
be
a
scan
for
a
security
analysis.
Not
only
could
you
get
the
specific
contextual
data
or
metadata
related
to
that
individual
capability,
but
we
can
interrogate
those
systems
on
the
back
end
to
get
the
actual
individual
detailed
results
like.
A
Why
is
this
important
and
up
until
now,
a
lot
of
our
security
and
related
activities
have
either
been
trust
based
or
based
on
attestation,
which
is
really
an
opinion
and
it
required
additional
load
and
more
complexity
in
the
pipelines
for
either
egress
calls,
or
these
bespoke
workflows
that
I
mentioned
beforehand
just
to
handle
these
nuances
around
the
process
that
you
wanted
to
capture.
This
is
all
completely
hidden
away
from
the
user.
All
they
have
to
worry
about
is
the
core
function
that
their
pipelines
are.
A
Building
information
is
completely
extracted
in
a
non-blocking
performant
way,
and
we
capture
the
evidence
requirements
around
that
I'll
talk
a
little
bit
more.
How
we've
identified
the
sort
of
key
areas
of
compliance
that
we
want
to
do
the
other
area?
That's
beneficial
about
this
as
well
is
not
only
do
we
get
the
specific
information
related
to
the
actual
contextual
data.
We
don't
get
teams
hitting
our
individual
systems
in
a
sort
of
batch
mode.
It's
more
of
a
push
model.
That's
occurring.
A
So
we
can
actually
do
really
hard,
real-time
gates
within
our
specific
pipeline
stages
based
on
the
requirements.
So
that
was
the
the
challenge
that
we
were
initially
looking
at
and
again
with.
This
is
why
having
the
standardization
and
the
inner
source
model,
first
of
all
pulls
people
into
it.
We
can
agree
to
define
workflows,
and
then
we
have
a
rich
extraction
mechanism
that
we
can
all
work
on
to
help
with
this
compliance
items.
A
It's
not
just
the
pipelines
by
the
way
this
this
this
model
is
extremely
flexible.
So
as
new
tools
come
into
our
ti
mcicd
systems,
whether
it
be
for
source
control
management,
artifact
management,
we
can
leverage
that
rich
ecosystem
of
web
hooks,
for
example,
to
tie
specific
events
in,
for
example,
pull
request.
Information
from
source
control
management
systems.
A
Artifact
management
systems
itself
will
be
additional
scans.
That
might
happen
at
that
stage.
Other
web
hooks
that
we
can
enable
from
the
actual
catching
things
before
they
even
go
out
in
the
assets
being
built,
so
we're
not
again
trying
to
alleviate
that
further
down
the
value
chain
or
even
worse
out
in
production,
and
then
we
also
have
a
huge
focus
of
self
service
on
boarding
with
infidelity.
So
all
our
role
management
is
is
extracted
away.
A
So,
for
example,
as
we
get
toward
production,
ensuring
that
we
have
the
right
segregation
of
duties
around
logical
access,
a
lot
of
these
systems
in
the
past,
there
were
just
transient
actions
that
were
occurring,
so
we
can
actually
collect
specific
audit
requirements
of
how
a
user
there's
nothing
stopping
the
user.
Getting
access
to
a
group,
then
removing
that
access
temporarily
or
those
types
of
controls.
We
can
capture
all
that
lineage
through
these
other
source
systems.
A
If
a
new
tool
comes
on
board,
we
can
tie
in
this
mechanism
to
that
and
deprecate
existing
systems.
So
it's
very,
very
flexible
so
again.
Moving
on
this,
this
diagram
just
depicts
at
a
very,
very
high
level
how
this
process
works
again
across
the
sort
of
key
area.
So
we
could
have
one
multiple
pipeline
orchestrators
that
have
this
mechanism
to
either
produce
eventing.
The
library
I
mentioned
is
purely
its
responsibility
is
providing
specific
context
at
that
individual
function
level,
so
it
lives
there.
A
It's
managed
there
as
it
evolves
that
payload
can
or
that
contract
can
effectively
evolve
over
time.
Orchestrator
has
the
specific
mechanisms
to
literally
handle
the
eventing
out
to
our
data
stream.
The
tools
I
mentioned
there
they
come
and
go.
We
leverage
them
best
as
possible
so
that
we
again
are
capturing
things
at
that
point
of
view
and
again
have
that
ability
to
cut
a
wider
net
of
additional
governance
items
that
we
want
to
control,
and
you
can
see
here
the
fpl
domains
or
fidelity
pipeline
library
here
it
just
demonstrates
across
the
board.
A
All
these
events
are
just
getting
created
and
sent
into
the
value
stream
and
it's
very
simple
sort
of
lambda
style
architecture
where
we
can
capture
things
in
a
sort
of
more
patch
orientated
mode
or
we
can
and
separate
our
type
of
topology
around
sort
of
real-time
requirements.
So
those
things
that
are
needed,
we
can
process
in
your
real
time
and
produce
the
data
points
that
can
be
called
back
into
the
pipeline
itself.
A
So,
for
example,
if
you
wanted
a
gate
on
unit
test
coverage
or
have
a
toggle
around
that,
there's
nothing
stopping
us,
providing
that
back
and
as
I'll
talk
about
later
on.
If
you
look
at
the
overall
retro
ecosystem,
there's
a
huge
possibility
for
us
to
do
really
really
rich
compliance
and
sort
of
more
opa-based
model.
A
The
other
side
of
this
is
we
are
democratizing
this
data.
This
is
a
card
for
the
n
engineers
at
the
end
of
the
day,
and
we
want
to
make
sure
that
all
of
this
data
is
again
pushed
back
to
the
developer
community.
So
we
provide
not
only
apis
that
provide
evidence-related
items,
that
order
can
easily
see
and
just
streamline
that
process
completely
and
allow
them
manage
more
policy
related
items.
A
We
are
looking
to
focus
a
little
bit
on
how
we
can
provide
a
steel
threading
across
our
whole
sdlc
process,
because
the
pipeline
will
go
so
far,
but
we
do
have
other
assets
around
the
company
that
we
need
to
work
with.
So,
for
example,
our
itsm
models
provide
how
infidelity
we
map
our
our
product
lines
against
products
across
the
board.
Those
products
might
have
multiple
microservices.
A
A
We
can
start
to
build
from
the
git
shas
to
the
build
ids
right
way
to
the
artifact
shads
and
how
they
actually
tie
back
into
the
itsm
model
and
effectively
we're
building
the
steel
thread
lineage
across
our
whole
devops
tool
chain.
So
we
should
be
able
to
trace
back
anything.
That's
in
deployment
further
back
to
commit
because,
as
we
have
seen
in
the
past,
whether
it
be
certain
vulnerabilities,
it's
one
thing
having
good
control
over
your
assets
before
they
go
out.
A
But
when
assets
are
out
there,
how
do
you
understand
actually
how
they
were
remediated
back
in
first
place?
So
we
can
have
that
clear
ability
and
again
demonstrate
that
the
appropriate
controls
would
be
met
all
the
way
through
the
the
tool
chain
itself
and
this
this.
This
helps
in
various
different
ways
as
well.
But
the
main
point
is
to
streamline
the
whole
process,
make
it
completely
invisible
to
the
end
user
and
then
focus
on
specific
assets
that
we
have
available
to
us
that
are
pretty
generic
across
any
application
type
that
are
moving
along.
A
A
A
Free
you've
got
more
eyes
on
the
problem
and
it
allowed
a
huge
level
of
reliability
that
didn't
exist
in
the
past
and
the
community
then
swarms
over
any
maintenance
that
comes
about
it,
but
it
really
was
a
very,
very
fragmented
state
and
again
this
led
to
sort
of
multiple
audit
findings
that
led
to
a
huge
amount
of
back-end
processes
around
how
we
had
to
discover
this
and
it's
just
a
huge
pain
point
to
our
overall
productivity
and
again.
I
think
we
need
to
stop
like
delays
to
impact
to
how
teams
will
evolve.
A
Changes
to
their
teams
was
another
problem
with
this,
because
there
was
no
central
way
that
we
could
actually
attack
new
policy
or
version
how
we
move
that
role,
that
out,
we
were
introducing
potential
risk
and
that
is
just
not
acceptable
in
our
modern
way
of
delivering.
So
again,
we've
moved
more
toward
this
approach.
A
Where
using
the
standardization
I
mentioned
there
between
the
library
builds
and
anything
else
that
was
related
to
the
catalogs
we
can
innovate.
We
can
get
the
best
of
breed
as
new
tools
come
no
problem.
It's
just
introduced.
We
get
the
basic
benefit
from
that,
but
all
the
information
across
all
systems
is
siphoned
into
what
we
call
pipeline
intelligence
or
our
devops
intelligence
and
from
that
the
evidence
store
builds
up
across
what
you're
seeing
at
the
bottom.
A
So
what
we
agreed-
and
I
said
this-
is
the
current
incarnation
of
each
of
these-
you
could
dive
into
a
little
bit
further
and
have
some
sub
and
evidence
items
related
to
it.
But
we've
focused
on
source
control,
management
and
simple
things,
making
sure
that
you
have
the
number
of
approvers
around
the
pull
request
in
place,
ensuring
that
the
person
who
wrote
the
code
can,
for
example,
circumvent
that
process.
A
People
who
traditionally
had
more
administration
controls
across
the
tools
couldn't
tweak
them
in
a
specific
way.
So
we
have
that
standardization
in
one
place
we
have
the
appropriate
and
itsm
controls
and
naming
conventions
around
what
we're
doing
and
the
appropriate
scans
happen
at
source
control
so,
for
example,
that
we're
not
detecting
vulnerabilities
way
way
way
down
the
food
chain
when
it's
harder
to
to
to
solve
at
that
stage
and
again
treats
the
developer
to
sort
of
learn
and
improve
on
that
aspect
of
it
from
build.
It's
really
important.
A
We
have
different
categories
of
application
and
again
with
all
the
data
points
that
we've
collected,
we
can
introduce
additional
levels
of
rigor,
if
required,
to
ensure
that
there
are
met
and
there's
flexibility
in
these
standards
and
that
they
can
be
actually
adopted.
But
overall,
the
goal
is
to
change
the
whole
culture.
How
we
develop
software
that
it's
easier
to
get
these
data
points
less
thought
to
think
about
it,
but
making
sure
that
we're
at
a
required
standard
and
then
for
production.
It's
it's!
A
It's
hugely
in
the
scope
of
fidelity
that
we
have
there's
there's
a
lot
of
different
systems.
We
have
a
lot
of
different
applications.
So
how
do
we
ensure
that
people
don't
have
persistent
production
access?
For
example,
everything
is
abstracted
through
a
deployment
pipeline
in
there,
the
appropriate
segregation
of
rules,
certification
of
our
various
groups.
The
list
goes
on
all
of
these
policies.
A
We
can
bake
in
and
externalize
through
our
risk
and
audit
and
apply
based
on
the
data
points
that
we
collected
and
again
we
work
with
our
application
teams
to
ensure
and
under
engineering
managers
to
to
ensure
the
hair.
If
the
fingerprint
doesn't
exist
on
the
evidence
store,
it's
going
to
be
harder
for
you
to
get
to
production
effectively
and
there's
a
lot
more
again.
A
A
So,
in
summary,
it's
just
it's
pretty
simple.
It's
it's
collection
at
a
high
level.
It's
making
sure
that
we
are
working
as
one
company
and
not
in
silos,
bringing
everyone
together.
It's
it's
really
understanding
and
the
beauty
of
this
model
is
is
that
things
will
change,
and
this
can
cater
for
that
at
the
end
of
the
day.
A
There's
data
points
coming
in,
but
it's
really
the
signal
collection
and
then
I'll
be
honest
with
you,
the
sky's,
the
limit,
the
potential
beyond
all
the
compliance
and
security,
to
gain
insights
that
we
can
feed
back
to
development
teams,
security
teams
of
interest
in
this
data
metrics
and
analytics
beyond
that.
There's
there's
many
rich
use
cases
that
we
can
use,
but
it's
all
about
improving
developer
experience
having
the
standards
in
there
and
ensuring
that
we're
meeting
the
appropriate
audit
and
compliance
guidelines.
A
A
B
A
Yeah,
no,
it's
it's
a
great
question.
I
think,
like
from
from
our
point
of
view,
we
looked
at
this.
We
couldn't
see
anything
out
there,
even
within
the
orchestrator,
so
I
think
we're
working
with
some
of
the
vendors
around
contributing
back
some
of
this
work
that
we've
seen
specifically
specifically
around
that
eventing
mechanism
and
even
further
the
way
we've
built
fidelity
pipeline
library.
It's
it's
completely
agnostic
to
fidelity
at
the
end
of
the
day,
we're
working
with
tools
and
the
adapters
around
that.
A
So
it
is
something
that
we
are
looking
to
work
specifically
with
the
cd
cdf
nation
to
see
how
we
can
understand.
There
are
some
projects
that,
for
example,
we've
got
cd
events
now,
there's
cloud
events
out
there,
so
different
providers,
whether
you're
talking
to
native
services
like
whether
it
be
kinesis
sqs
or
whether
we
want
to
talk
to
kafka.
For
example.
I
think
there's
a
lot
of
ability
to
have
a
plugable
model
around
that.
C
I
have
a
pretty
loud
voice,
but
I
guess
it's
safe
to
go
with
the
mic
when
you
were
talking
about
the
c-suite
buy-in
and-
and
you
were
kind
of
deploying.
Obviously
you
guys
have-
I
don't
know
dozens,
if
not
hundreds
of
different
business
units
that
were
all
doing
this.
What
was
the
time
frame
process
like
and
how
much
of
it
was
you
know?
Maybe
this
was
a
crude
question:
education
versus
enforcement
yeah
and.
A
Really
really
really
good
question
like
anything.
This
is.
This
is
a
journey
we
do
have
like
you
mentioned
there.
If
you
look
in
the
past
a
lot
of
legacy
systems,
a
lot
of
sprawl,
even
multiple
instances
managed
by
different
business
units
as
traditionally
so
when
this
vision
was
looked
at,
it
was
very
much
focused
on
the
strategic
systems
and
then
obviously
a
cure.
A
clear
roadmap,
around
ecom
of
the
older
systems
was
there,
so
there
was
plenty
of
pre-warn
that
this
is
coming.
A
I
suppose,
and
it
again,
this
is
where
a
lot
of
the
early
adopters
were
very
keen
to
get
involved
in
the
project.
Everyone
sees
that
coming
through,
I
think
the
most
surprisingly
is
when
you
see
the
community
start
swarming
and
the
value
coming,
because
initially
there's
a
natural
resistance
around.
I
like
control
right,
but
when
you
actually
have
like
some
of
the
interesting
debates
that
you
have
around
specific,
even
capabilities,
you
can
meet
everyone's
expectations.
A
It's
really
more
of
an
engineering
design
question
and
it's
really
around
how
you
domain
that
scope
of
what
you're
talking
about.
I
think
that
was
really
key
to
the
model
and
then,
as
the
wider
like,
why
would
you
spend
time
just
building
the
same
thing
when
you
can
contribute
on
innovating?
On
that?
A
It's
about
coming
together,
having
more
richness
and
robustness
and
reliability
and
I'll
be
honest
with
you.
We
haven't
had
a
breaking
change
in
this
whole
project,
since
it
was
initiated
all
down
to
this
and
a
lot
of
the
problem
that
we
found
from
developers.
As
they
said,
people
were
essential
teams
that
were
throwing
this
over
the
wire,
and
then
it
was
left
with
the
developers
to
really
test
it.
A
And
then
this
was
another
problem
that
was
happening
so
we've
had
times
that
we've
had
over
opinionation
and
something
similar,
but
then
by
bringing
in
inner
source,
everyone
gets
involved.
So
everyone
can
discuss
it.
So
it's
a
win-win
for
everyone,
but
it's
it's
sort
of
we're
we're
getting
better
at
it,
but
I
think
this
project
has
been
a
real
eye-opener
to
how
the
value
can
be
realized
very
very
quickly.
So
I
think
that's
the
card
for
the
other
teams.
A
You
will
have
outliers,
there's
no
doubt
about
that,
but
over
time,
when
the
the
mob
sort
of
swarms
on
this
they
get
more
isolated
and
it's
harder
for
them
to
suppose
justify
that
and
then,
at
the
end
of
the
day.
Let's
be
honest,
you
don't
see
the
risk
and
then,
with
the
data
points
that
you
get
out
of
it.
That's
that's!
The
real
car,
like
there's
a
huge
huge
richness
in
that
data
that
we've
never
really
uncovered
before
this
initiative.
So
it's
all
about
transformation.
A
C
A
I
think
it
was
more
interesting
when
you
actually
got
down
to
why
I'm
different,
and
then
you
actually
talked
to
that
it
was
really
around.
They
were
trying
to
collect
similar.
I
think
there
is
the
actual,
at
the
end
of
the
day,
build
code,
deploy
code,
configure
code
test
code,
but
that
was
the
overall
pattern,
but
when
you
actually
got
into
it,
people
were
trying
to
I'm
different,
because
I
wanted
to
actually
have
this
special
process
that
around
something
that
I
needed.
You
know
it
wasn't
really
justified.
A
But
when
you
look
at
what
we've
just
described
there,
just
taking
that
cognitive
load
away
and
it's
at
the
end
of
the
day,
you've
got
the
fingerprints
you
don't,
but
it's
just
spread
beyond
minimal
compliance
or
governance,
but
across
the
full
value
chain.
So
I
yet
to
see
many
innovation
opportunities
that
we
can
gain
from
this
as
we
go
down
because
it's
beyond
just
the
remit
of
this
talk
like
it
goes
further.
D
What
was
your
experience
around
that?
I'm
assuming
fidelity
was
impacted
by
this
regulatory
requirements
and
how?
What
was
the?
How
did
you
roll
out
somebody's
standardized
checks
and
evidence
collections
and
what
was
the
reaction
from
the
developer
community
community?
Did
you
did
they
experience
any
reduction
in
agility
and
due
to
the
new
tower
case,
and
things
like.
A
Again,
a
great
question:
I
I
think
overall
and
it
ties
back
into
the
we
do
have
certain
standards
that
we
do
need
to
meet.
That
was
there
at
the
end
of
the
day,
the
rigor
and
of
audit,
and
regardless
of
what
goes
on
was,
was
a
pull
on
the
teams
any
single
way.
So
I
think
anything
we
can
do
to
improve.
That
was
better
than
what
we
have
right
now.
Right
and
again,
I
think
it's
just
when
you
look
at
the
scale
of
what
fidelity's
doing
like
some
of
these.
A
This
goes
back
to
the
specific
water
teams
themselves,
like
that
those
practices
were
occurring
and
again
they
don't
know
what
they
don't
know.
So
as
they
peel
back
the
onion,
it
was
going
a
bit
further
right.
So,
at
the
end
of
the
day,
everyone
wants
this.
Everyone
wants
to
go
faster,
it's
it's
just
targeting,
I
suppose
the
the
highly
criticality
compliant
applications
initially
and
then
bringing
in
that
culture
that
everyone
swarms
in
that,
because
just
because
they
have
that
doesn't
mean
they
should
not
adhere
to
it
right.
A
That
was
a
key
frustrator
for
teams
and
it
was
also
a
big
risk
that
when
you
had
like,
for
example,
log
for
j
scenario
or
some
of
the
other
vulnerabilities
that
come
out,
how
quickly
can
we
react
to
that?
So
the
problem
compounds,
but
look,
I
know
we're
off
at
time
at
the
moment.
Thank
you,
everyone
and
I'm
going
to
be
around
for
the
next
two
days,
so
more
than
happy
to
take
any
offline
discussions
than
anyone
wants.
So,
thank
you
very
much.