►
From YouTube: Enabling a Pipeline Catalog at Scale - Aoife Fitzmaurice & Jamie Plower, Fidelity Investments
Description
Enabling a Pipeline Catalog at Scale - Aoife Fitzmaurice & Jamie Plower, Fidelity Investments
Speakers: Jamie Plower, Aoife Fitzmaurice
At Fidelity to support the drive Pipeline As Code at scale a key ingredient to enabling this is the establishment of a Pipeline Catalog created and managed by Fidelity's community of Developers. This talk will walk through what is involved in enabling a culture that will support this in the longer term.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Inside
so
just
housekeeping,
you
know
something
that
we
have
to
kind
of
you
know
put
in
front
of
everybody
in
front
of
all
of
these
presentations,
but
our
disclaimer
is
the
presentation
that
is
a
case
study
of
fidelity
investments
experience.
This
is
not
an
endorsement
or
a
recommendation
of
any
particular
vendor
product
or
service.
B
A
A
A
A
A
A
So
we
talk
about
various
different
business
units
within
fidelity
and
these
are
have
their
own
independent
product
lines
and
products,
their
own
independent
budgets
concerns
development
teams
etc
that
you
would
actually
deal
with
and
then
where
jamie
and
I
kind
of
sit,
is
in
centralized
I.t
services.
So
we
offset
against
all
of
these
business
units.
A
We
provide
them
a
set
of
services,
a
set
of
platforms
in
order
for
them
to
be
able
to
do
their
innovation,
it
can
be
a
difficult
experience
to
deal
with
so
many
voices
that
are
a
very
independent
thoughts,
but
definitely
kind
of
leveraging.
You
know
partnership
principles
in
order
to
be
able
to
kind
of
toe
that
line
in
order
to
be
able
to
set
to
provide
the
greatest
set
of
services
to
the
most
amount
of
people.
A
Then,
specifically
around
what
we
kind
of
do
within
this
wheel
here,
on
the
the
right
hand,
side.
These
are
the
kind
of
areas
that
we
really
focus
in
on
in
terms
of
the
platforms
and
the
capabilities
that
we
do
provide
and
within
that
space,
our
mandate
is
to
provide
a
next
generation
software
delivery
platform
for
the
firm
so
provide
these
services
to
all
of
the
business
units
that
do
exist
within
fidelity
and
to
do
it
in
such
a
way
that
it
is
backed
and
baked
in
in
terms
of
security,
governance
and
compliance.
A
We
want
to
look
at
stability
and
resiliency
for
all
of
these
tools
and
platforms
that
are
there,
but
then,
as
we
kind
of
talked
about
before,
we
have
challenges
within
that
space,
with
so
many
voices
with
so
many
kind
of
people,
so
many
different
requirements
that
are
out
there.
It
can
be
challenging
in
order
to
be
able
to
meet
that
need
and
not
necessarily
fall
into
the
trap
of
looking
at
a
single
voice
in
a
single
requirement.
B
Obviously,
what
we're
talking
about
here
today
is
scaling.
Our
pipeline
catalogue
strategy
is
is,
is
building
a
sort
of
shared
library
of
pipeline
components
and
leveraging
that
talent
across
the
organization
that
we
can
inner
source
this
project
and
define
is
probably
a
better
word
of
weld
paved
paths
that
we
can
deliver
for
various
workload
patterns.
B
So
this
slide,
I
suppose,
is-
is
not
highlighting
everything,
but
it
does
indicate
some
of
the
sort
of
capability
domains
that
we
focus
on,
whether
it
be
the
artifact
or
asset
construction,
how
it's
published
the
various
controls
that
we
want
to
put
into
there.
As,
if
mentioned,
we're
highly
regulated
environment,
we've
got
different
workload
scopes,
so
some
might
be
non-critical.
Some
might
be
a
require,
an
rto
within
half
an
hour.
So
we
have
a
whole
lot
of
different.
B
I
suppose
constraints
that
we
need
to
leverage,
and
traditionally
these
were
left
to
the
individual
teams
to
develop
in
their
own
in
their
own
isolation.
So
one
of
the
key
goals
that
we're
trying
to
achieve
is
not
to
offer
that
scale
is
how
do
we
bring
together
the
best
learnings
and
the
feedback
from
the
business
units
and
providing
us
a
centralized
fidelity
pipeline
library?
That
teams
can
leverage
with
confidence
to
to
help
accelerate
their
workloads.
B
It's
it's
not
all
bad
news.
I
think
what
I
want
to
highlight
here
is
is
that
we
do
a
lot
of
challenges
in
in
the
pipeline
journey,
but
like
feedback
that
we've
had
that
teams
do
enjoy
along
this
journey
is
by
providing
the
catalog
level
approach
like
a
lot
of
our
workload
patterns
are
pretty
consistent,
so
teams
do
enjoy
having
the
ability,
especially
smaller
teams,
that
may
not
afford
a
large,
devops
or
or
ops
team
to
help
support
their
their
their
needs.
B
That
ability
to
help
provide
opinionation
that
they
can
follow
a
lot
of
the
time
policy
changes.
It
evolves.
New
services
come
online,
so
keeping
up
to
date
and
and
having
simple
integrations.
For
example,
common
common
m
integrations
around
secrets:
management
common
integrations
around
our
observability
and
telemetry
best
to
breed
patterns,
around
testing,
for
example,
or
or
workload.
Orchestration,
and
anything
that
we
can
avail
there
is
is,
is
highly
regarded
by
teams,
but
at
the
same
time,
if
teams
want
to
have
the
flexibility
to
go
themselves
that
they're,
they
can't
do
that.
B
I
think
that's
one
of
the
repeated
learnings
that
we
we
do
provide
some
somewhat
flexible
options
for
the
teams,
because,
as
if
mentioned
there
like,
there's
no
one
way
we're
going
to
have
a
silver
bullet
for
everyone.
So
it's
it's
having
that
right
balance
so
to
have
teams
have
the
options
go
forward
as
a
big
learning
and
that
ties
into
the
repeatable
patterns
and
the
standards
enforcement
I
mentioned
there.
B
Another
key
learning
as
well
is
that,
as
we've
gone
along
our
our
journey,
we
we
used
to
have
many
many
platforms
within
this
space,
whether
it
would
be
across
many
csps
and
big
africa
has
gone
on
in
recent
time
to
move
behind
single
platforms
with
with
key
integration,
tooling,
that
these
these
teams
provide.
So
the
experts
provide
the
best
guidance
to
that
and
then
the
pipeline
authors
can
just
integrate
with
that,
and
it
has
enabled
a
lot
more
speed
and
acceleration
in
that
space.
B
One
of
the
areas
where
the
challenges
still
lie
is
as
being
a
central
team
is
fine,
but
we
don't
speak
for
everyone,
so
we
do
have
coe
teams
that
are
within
the
various
groups
that
support
or
work
with
their
workloads
team.
Closely
and
at
times
the
feedback
has
been
pipelines
can
be
built
upon
on
top
of
each
other.
B
They
can
be
inconsistent,
they
can
be
complex,
so
teams
would
nearly
spend
as
much
time
figuring
out
the
complexities
of
the
automation
suites
to
change
and
update
along
with
their
workload
needs
and-
and
I
think
the
instability
is-
is
one
of
the
key
factors
where
they're
finding
themselves
debugging
a
lot
of
the
time
from
this,
and
we
obviously
work
with
a
lot
of
independent
dependent
systems.
So
it
was
key
that,
for
our
automation
and
pipeline
needs
that
these
are
stable
and
built
upon.
B
So
the
idea
of
of
having
this
common
library,
which
underpins
the
catalog
approach,
is,
is
that
we
ensure
we
we
build
the
stability,
this
reliability
on
top
of
the
simplicity
that
will
allow
the
majority
of
the
workloads
to
have
pretty
defined
goals,
the
ability
to
run
quicker
access
restrictions
and
everything
else.
I
think
it's
it's
as
the
pockets
evolve.
B
So
with
that,
it's
it's
joining
into.
I
suppose
how
we've
built
that
pipeline
at
scale
model
leveraging
catalogs
and
beyond.
So
one
of
the
first
areas
that
we've
taken
and,
as
I
said,
fidelity
is
a
large
large
company.
We
have
many
different
business
units,
those
business
units
work
across
many
different
sort
of
workloads,
so
we
identified
specifically
for
cloud
in
this
case
our
our
top
10
workload
patterns
that
we're
using.
B
So
what
we
have
done
is
identified
for
these
patterns
and
and
looking
to
build
out
the
sort
of
catalog
approach
based
on
these
workloads
that
team
can
use.
So
the
idea
would
be
that
paved
path
approach
is
defined
using
an
inner
source
model,
we're
taking
the
best
of
breed
of
knowledge
and
experience
from
these
business
units
to
help
sort
of
agree,
that
sort
of
80
20
rule
and
then
leave
the
option
for
the
unpaved
path
route
for
teams
that
want
to
go
themselves
and
I'll
talk
a
little
bit
about
later
on.
B
I
just
want
to
emphasize
standards,
change
policies,
change,
new
requirements
come
through
and
specifically
in
the
financial
side
that
we're
based
in
regulation
and
audit
is
a
really
critical
factor.
So
it's
constant
that
we
are
cognizant
of
the
fact
of
how
can
we
bake
in
audit
ready,
regulated
items
into
our
rules
so
that
these
become
a
trivial
item
to
do?
B
And
that's
a
key
goal
of
having
the
standard
pipeline
as
well,
that
we
can
take
the
burn
off
teams
for
these
extra
curricular
items
and
ensure
that
they're
as
best
as
possible,
focused
on
the
security
and
and
have
these
central
groups
as
much
as
possible.
Inform
where
these
standards
and
policies
change
and
then
let
the
teams
that
consume
them
elect
up
to
those.
B
So,
finally,
it's
it's
really
to
how
does
this
picture
come
together
and
the
approach
that
we're
taking,
as
as,
if
mentioned,
around,
achieving
this,
this
software
to
the
brig
platform
going
forward?
The
platform
itself
is
key
and
we
we
do
currently
support
like.
We
want
to
make
sure
that
self-service
and
then
and
the
enablement
of
this
platform
is
critical.
B
These
could
be,
as
is
mentioned,
and
our
central
team
can
provide
platform
specific.
We
could
be
using
open
source
curated,
making
sure
that
they're
certified
and
runtimes
and
we
could
require
vendor-specific
ones
that
teams
could
do
so.
The
flexibility
is
there
that,
if
teams
need
to
run
at
this
base
block,
they
can
run,
but
you
can
see
there
there's
higher
effort
and
low
compliance
around
that
and
more
effort
on
their
side
to
continue
down
that
route.
B
The
fundamental
step
above
that
is
the
fidelity
and
bu
shared
libraries,
and
one
thing
that
this
provides
going
back
to
my
original
slide
around
our
capability
map.
Is
it
we'll
cover
the
process?
If
you
want
to
think
of
it
like
the
lego
blocks
or
or
the
ikea
instructions
as
to
how
the
workloads
will
be,
will
be
built?
B
So,
with
this
model,
the
software
delivery
platform
will
help
provision
version
these
catalogs
through
this
model,
and
then
teams
can
just
adapt
and
receive
those
at
ease,
so
they're
just
focused
on
their
there's,
no
jenkins
files
or
anything
like
that,
for
example,
be
maintained
in
the
repositories.
These
are
all
centralized
away,
so
it
keeps
that
burden
away
from
them.
So
if
they
have
50
micro
services
using
a
similar
catalog,
it
can
just
make
a
change
and
then
adapt
if
we
need
to
add
up,
for
example,
a
new
security
feature
or
anything
like
that.
B
So
that's
a
huge
change
for
us
and
I
think
it's
one
of
the
more
exciting
features
that
we
can
adapt
and
then
to
build
upon
the
the
pipeline
catalog.
As
I
mentioned,
we're
in
a
financial
and
highly
regulated
space.
So
one
thing
for
us
is
is
how
do
we
ensure
especially
going
to
cloud
that
the
teams
are
meeting
the
required
standards
and
policies?
So
at
this
stage
it
becomes
a
little
bit
more
opinionated
as
we
go
up
here,
and
teams
can
opt
in
at
any
level
that
they
wish.
B
So,
for
example,
we'll
provide
some
certified
pipelines,
but
there
is
a
step,
for
example,
in
our
upstream
that
they
require
they
can
provide
that
their
own
in
their
own
shared
library,
for
example.
But
the
certified
phase
will
allow
us
to
ensure
that
these
are
all
and
approved,
ready
to
go,
follow
the
correct
change,
management
procedures
and
governance
gates,
and
all
that
is
collected,
as
I
say,
through
through
the
instrumentation
of
individual
capabilities
themselves.
That
will
help
us
gather
some
of
this
evidence
automatically
and
then
building
upon
that
further.
B
If
teams
want
to
take
literally
code
and
run
end-to-end
through
to
our
production
environments,
we'll
provide
a
full
service
for
that,
as
well,
so
again,
building
on
this
catalog
idea
and
tying
into
sort
of
the
deployment
strategies
and
and
the
audit
on
top
of
that
will
will
build
in
the
certified
and
regulated
workflows
and
then.
Finally,
a
flavor
of
that
is
is
just
that
final
regulation.
B
We
might
have
specific
workloads
that
do
require
stock,
for
example,
or
hipaa
based
regulation
built
into
it,
and
we'll
create
opinionation
around
that
to
ensure
that
the
right
checks
and
balances
are
in
place
to
meet
those
audit
requirements
and
with
the
goal
that
we
need
to
provide
evidence
to
those
approved
orders
at
any
time.
We
have
that
ready
to
go
so
in
a
nutshell,
stepping
back
it's
it's
a
combination
of
a
rich
shared
library,
a
rich
collaborative
environment
and
then
working
with
our
our
workload.
B
Definitions
to
define
catalogs,
to
allow
us
to
offer
that
to
the
majority
of
fidelity
to
to
to
take
on
board
and
run
with,
but
at
the
same
time
offer
key
flexibility
for
those
specific
edge
use
cases
that
they
have
that
they
can
still
layer
that,
on,
on
top
of
this,
to
cover
their
edge
cases
so
they're
never
blocked
or
they're,
never
sort
of
working
through
some
track
as
well.
So
it's
the
best
of
both
worlds
and
if
there
is
a
case
where
that
needs
to
come
into
the
global
library,
that's
where
we
can.
A
I
think
it
would
be
fair
as
well
to
say
jamie
is
that,
like
we
provide
these
capabilities
out
of
the
box
so
as
soon
as
that,
a
consumer
kind
of
on
boards
to
our
platform
right.
It's
just
offered
out
of
the
box
and
it's
a
choice,
then
from
their
perspective,
of
whether
they
want
to
go
the
simple
route
and
just
adopt
the
regulated,
workflows
or
whether
they
want
to
actually
do
more
experimentations
themselves,
and
then
they
have
that
kind
of
flexibility.
Like
you
mentioned,
you.
B
Know
100
yeah
and
I
think
a
key
point
as
well
is
is
underpinning
all
this
is,
is
the
experience
so
like
not
everything
is
static
in
nature
right,
so
we
have
to
think
about
day
two
activities.
Libraries
come
and
go
repost,
so
it's
there's
a
whole
experience.
That's
built
into
this
behind
that
allows
the
developer
to
self-serve.
B
I
suppose
how
they
they
do,
that
manage
the
versioning
of
some
of
these
elements
as
well,
so
that
they're
not
just
automatically
getting
stuff
that
hits
them,
and
so
they
have
a
very
controlled
way
or
they
can
opt
into
a
more
later
model
based
on
the
configurations
that
are
provided
so
the
template
catalog
is
very
exciting.
It
provides
areas
that
we
we
we
can
allow
that
standardization
and-
and
I
know
we're
working
with
our
vendors
as
well
just
to
sort
of
enhance
this
model
as
we
go
forward.
B
I
think
around
policy
enhancements
and
things
like
that
that
we
can
we
can
go
through.
That
would
even
further
offer
that
flexibility
and
additional
governance
and
regulatory
audit
requirements
that
we
need
that
we
may
have
to.
I
suppose,
right
at
the
library
level
that
we
could
inherit
more
natively
within
the
tuning
that
we
leverage
so.
B
But
yeah,
I
think,
like
we
have
to
be
realistic.
It's
a
large
firm
with
a
lot
of
different
maturity
levels,
so
teams
that
are
mature
that
want
to
go.
They
have
the
option
in
this
model
teams
that
I
think
was
one
of
the
big
bits
of
feedback
that
we
got
going,
especially
toward
cloud.
It
can
be
quite
not
only
focusing
on
the
app
but
the
policy
and
all
the
other
baggage
that
comes
with
that
like
how
do
they?
How
do
they
work
with
this?
B
A
B
B
I
think,
when
you
have
a
lot
more
of
the
intelligent
voices
and
influences
coming
from
around
the
firm
who
have
done
this
or
just
having
that
collective
voice
really
brings
a
richness
to
to
something
that
we've
had
before
and
I
think
actually
gives
more
confidence
to
those
using
it
and,
as
you
can
see,
as
you
go
up
the
food
chain
here,
there's
more
more
support
afforded
to
that
model
versus
teams
that
want
to
run
themselves.
So
it's
been
probably
our
biggest
challenge.
How
do
we
address
that?
B
A
So
happy
to
kind
of
take
any
kind
of
q
a
at
this
point,
or
you
know
we
can
talk
further
on
any
topic
really
at
all,
there's
a
question
there
from
zach
jamie
in
such
an
environment.
I
understand
it
takes
time
to
onboard
teams.
How
long
have
you
had
teams
using
it
and
how
far
would
you
say?
Adoption
is
on
to
cd
pipelines,
so
I
think
it's
probably
fair
to
say,
like
you
know,
we've
gone
through
various
iterations
in
our
firm
right.
You
know
two
years
so
not
so
successful.
A
I
think
we
kind
of
consolidated
on
the
things
that
we
don't
hasn't
worked
right.
You
know
we
are
very
much
bought
into
the
everything
is
cold
kind
of
capabilities
and
stuff
that's
there,
but
in
some
of
our
previous
iterations
it
was
very
much
up
to
the
very
seams
themselves.
Template
technologies
wasn't
advanced
enough,
you
know
being
able
to
do
reusability
wasn't
advanced
enough
and
it
was
very
challenging
for
kind
of
the
firm
to
be
able
to
adopt
kind
of
pipeline
as
code,
and
things
like
that.
A
So
I
think
baked
in
with
our
services
layer,
our
onboarding
services
and
kind
of
going
much
beyond
you
know
being
very
opinionated
within
the
platforms
themselves,
so
that
it's
not
just
on
boarding
my
project
in
my
area,
it's
configuring,
the
project,
adding
in
all
the
access
baking
in
the
pipe,
the
libraries
and
the
catalogs,
and
things
like
that.
On
top
of
that,
it
just
makes
you
know
users
from
the
very
beginning,
much
easier
for
them
to
get
on
board.
So
I
think
you
know
as
time
you
know
goes
on.
A
B
No,
I
think
you
hit
the
nail
on
the
head
and
it
really
to
me
comes
down
to
two
factors
tooling
and
our
maturity
in
in
this
journey
as
well.
As
you
mentioned,
we
had
a
proliferation
of
tooling.
Originally,
there's
been
some
efforts
to
standardize
that
focus
on
best
of
breed
where
the
biggest
values
coming
from
the
firm
and
that
again
simplified
the
the
complexity
downboarding
at
one
point
and
then
the
cloud
journey
isn't
something
new,
but
obviously
at
the
start,
we
we
did
probably
take
a
sprawl
approach.
B
Those
multiple
platforms
in
use,
as
I
mentioned
in
the
talk,
there's
definitely
standards
around
technology
that
we're
we're
we're
buying
into
infidelity
and
then
obviously
the
maturity
around
those,
whether
it
be
orchestration
patterns
or
the
workload
definitions
that
we're
doing
that
teams
are
definitely
standardizing
it
because
the
the
critical
value
fidelity
has
been
able
to
deliver
value
right.
So
I
think
the
to
our
maturities
probably
come
on
full
circle
with
ci.
There's.
B
Definitely
a
lot
of
consensus
around
that
approach,
as
cds,
obviously
a
bit
to
go,
but
definitely
I
think,
regardless
of
the
the
target
endpoint
that
we
have.
We
have
a
lot
more
standardization
around
that
which
we're
seeing
a
lot
more
adoption
on.
So
it's
all
a
journey,
but
we're
definitely
moving
a
lot
more
based
on
those,
the
mall
that
we've
just
shown
and
obviously
some
of
the
standardization
around
them.
The
tooling
and
our.
A
B
Sure
so
I
think
the
initiate
buy-in,
I
think,
first
of
all
like
like,
like
we
mentioned
there
beforehand,
it's
it's
it's
probably.
The
ci
was
very,
very
easy
phase
to
get
people
bought
in.
I
think
a
lot
of
teams
very
much
focus
on
a
container
pattern
or
or
otherwise
that
they
they
they
really
wanted
to.
I
suppose
understand
what
other
teams
were
using,
and
that
was
a
great
approach,
so
the
the
standardization
there
sort
of
easy
easy
win
down
the
line.
I
I
think
it's
it's.
B
A
I
think,
as
well
as
we're
kind
of
in
a
sweet
spot
ourselves
like
we're
central
I.t
and
the
firm
is
kind
of
basically
a
loop
around,
so
we're
very
plugged
into
all
the
different
business
units
itself,
so
the
development
teams
plus
out
to
their
consumers
that
are
kind
of
you
know
consuming
their
products
themselves.
So
you
know
we
can
pull
these
people
together.
A
Work
then,
as
a
friend
to
kind
of
get
to
standardization,
and
we
can
kind
of
ship
that
across
various
different
business
units.
So
then
it
becomes
a
homegrown
kind
of
thing.
In
order
to
adapt
that
kind
of
underlying
standardized
solutions
versus
everybody
trying
to
kind
of
combat
the
same
problems,
it
just
doesn't
make
sense
yeah
exactly
it's.
B
A
B
B
This
discussion
happens
at
the
heart
understanding
the
problems,
we're
trying
to
solve,
making
sure
that
they're
involved
in
the
in
the
output-
and
I
think
the
the
data
points
that
we
can
collect
as
well
is
critical
as
well,
so
that
there's
actually
a
card
for
adoption
right,
so
that
they're
getting
additional
insights
that
they
would
otherwise
have
to
to
craft
themselves.
So
I
think,
the
sooner
that
we
broke
that
barrier
and
realized
that
a
lot
of
the
reputable
we
noticed
that
that's
where
the
biggest
value
was.
A
B
A
That's
aligns
with
what
we're
trying
to
do
with
catalogs.
To
be
frank,
you
know
basically
just
provide
a
set
of
kind
of
template
pipelines
to
the
business
partners
based
around
patterns,
and
basically
developers
should
just
be
able
to
plug
in
parameters,
and
it's
you
know,
deploy
away
right
from
ci
to
cd.
So
what
do
you
think
jimmy.
B
Couldn't
agree
more,
I
think
that's
that's,
definitely
direction
that
we're
going
and,
as
we
have
these
frank
discussions
we
can
align,
I
suppose
our
overall
architectures
and
the
way
we
build
applications
to
it
to
enable
that
right.
But
to
your
point,
I
think,
with
the
workload
definitions
we
have
right
now,
that's
absolutely
the
the
approach
that
we've
been
taking
to
remove
pipeline
authoring
as
much
as
possible
and
and
align
it
to
literally
plug
and
play
and
let
them
go
off.
A
B
B
I
think
the
critical
point
here
is
inner
source
in
that,
where
we're
we're
gaining
the
scale
by
by
following
that
capability
model,
we
can
really
focus
where
the
and
and
then
bring
people
to
the
problem,
and
so
people
are
able
to
scale
from
that
perspective
and
then,
as
we
mentioned
there,
we
have
a
clear
model
around
our
shared
responsibilities,
so
teams
can
opt
in
and,
I
suppose
get
the
richness
from
from
the
majority.
So
it's
it's.
Definitely
how
we've
been
approaching
it.
A
I
think
it's
well.
It's
kind
of
you
know
it's
a
bit
of
a
divide
and
conquer
right
like
when
we
explained
our
kind
of
organizational
setup.
We
have
these
various
different
business
units,
but
then
you
take
the
sub
teams
from
within
that
that
are
doing
that
innovation
and
you,
you
extend
your
own
team
with
that.
A
So
it
may
feel,
like
you,
have
kind
of
a
large
team,
but
you
don't
have
a
massive
team,
like
you
know,
there's
less
than
50
collectively
kind
of
working
on
this
effort
at
any
given
point
in
time,
but
they're
able
to
kind
of
do
that
standardization
across
the
bus
and
then
we're
able
to
do
standardization
for
fidelity
itself
and
bring
it
up
that
layer.
So
from
that
kind
of
you
know
grassroots
kind
of
setup,
we're
able
to
do
a
lot
with
the
small
team,
I
would
say
in
comparison
to
other
companies.
B
And
I
think
the
coes
just
to
finally
like
the
like
their
individual
business
units
that
are
adopting
are,
are
key
to
this
as
well
right,
so
they're
they're,
the
ones
providing
feedback
that
point
of
view
and
ensuring
that
we're
we're
dealing
with
that
problem.
Where
beforehand
they
were
building
upon,
whereas
now
they're
just
part
of
the
discussion
from
the
get-go.
So
we're
we're
we're
trying
to
address
as
much
as
early
in
the
process
as
possible
and
through
feedback
minimize
any
maintenance
requirements
down
the
line
and
backward
compatibility
issues
that
may
have
risen
past.