►
From YouTube: Enabling Developer Experience Journey in U.S. Bank - Ravikumar Tadikonda & Poonam Garg, U.S. Bank
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Enabling Developer Experience Journey in U.S. Bank - Ravikumar Tadikonda & Poonam Garg, U.S. Bank
In our journey, we learned that if you want your software product to succeed, the developer’s satisfaction and happiness are crucial. Happy developers create outstanding software in the long term. Positive experience makes them feel secure and motivated to work on excellent products and services. At U.S.Bank, we are building a single point of truth for the product life cycle, which includes creating, discovering, and maintaining the product/application for every technical, security, auditor, and leadership team. In this talk, we will cover the Journey of Backstage Adoption. We will highlight a few things that have enabled our engineering developer productivity using features such as catalog, technical documentation, software template & homepage.
A
A
B
Welcome
to
our
session
as
Ravi
said,
and
thank
you
Ravi
passing
me
along,
so
my
name
is
Poonam
Kirk
and
I'm.
Currently,
a
vice
president
engineering
leader
within
U.S
bank
and
I
carry
a
15
years
of
experience
and
I'll
lead
a
devops
team
within
U.S
Bank
I'm,
a
speaker
at
multiple
conferences,
which
includes
open
source,
not
in
Grace
Hopper.
B
In
addition
to
that
I'm
a
here
I'm
a
community
leader
of
the
wit
Network,
which
is
founded
by
the
Microsoft
and
I'm,
a
huge
technical
advocate
for
open
source
Technologies
and
tools
and
clouds
devops
practices.
In
addition
to
that,
I
hold
a
technical
membership
for
IEEE
senior
member
plus
BC
as
follow.
A
A
little
bit
about
us,
U.S
Bank,
we
are
the
fifth
largest
bank
we
operate
globally.
We
have
offices
in
U.S,
Canada
and
Europe.
We
are
heavily
regulated
industry.
You
all
know
that
Finance
industry
is
one
of
the
heavily
regulatory
industry
and
at
U.S
Bank.
We
are
all
about
empowering
people
and
to
reach
their
potential,
and
this
is
the
journey,
how
we
are
trying
to
empower
our
developer
internally
to
reach
their
potential.
This
is
all
about
the
developer
experience
how
we
Empower
our
internal
developers
to
reach
the
potential.
B
B
Because,
in
the
past
three
years
or
four
years,
I
miss
I
say
that
we
have
seen
that,
like
we
have
huge
talented
engineers
and
developers
that
comes
with
all
skills,
but
when
it
comes,
but
when
they
are
building
a
solutions
for
us,
they
come
across.
So
many
challenges
that
we
will
see
into
the
next
slide.
What
are
those,
and
so
that's
where
they
struggles
with
it
and
in
addition
to
that,
we
all
witnessed
covid-19
was
there,
so
it
adds
more
complexity
to
it
and
I
believe.
B
Most
of
you
felt
the
same
like
what
we
thought
so
here
are,
as
we
stated
in
a
previous
slide
like
we
put
our
people.
First,
that's
where
our
mission
started
and
now
questions
are
what
are
common
engineering
challenges
and,
as
we
all
know,
there
are
thousands
of
different
Technologies
systems
and
applications
are
available
for
business
and
integrating
the
third
party
systems
or
custom
applications
such
as
your
Erp,
or
through
using
apis
at
substantial
complexity
to
your
project
and
which
even
and
the
bigger
challenge
for
these
integrating
third
parties
are.
They
are
not
even
they
never.
B
They
are
hidden
during
the
start
of
your
software
development
process.
They
always
be
visible
when
it
is
their
end,
and
that
leads
to
what
extra
cost
compromised,
quality
plus,
sometimes
even
entire
failure
of
the
project,
and
the
question
is
how
so.
These
are
the
various
forms
that
you
have
been
witnessed
in
your
space.
They
comes
in
terms
of
process
as
an
onboarding.
B
B
B
But
it
comes
with
some
opportunities
like
when
we
build
this
application.
We
just
care
about
CLI
personas,
so
we
care
about
okay.
You
know,
let's
build
this
tool,
let's
figure
it
about
like
com
command
line
user
interface,
so
it
just
it
just
currently
supports
CLI
and
rest
of
the
personas
are
still
work
in
progress.
It
lacks
little
bit
application
inside.
We
have
it,
but
it
is
not
fully
integrated.
We
try
to
add
compliance
and
security.
Still
it's
a
work
in
progress
and
one
thing
that
I
would
like
to
call
it
out
here.
B
It
is
a
complex
solution,
because
when
we
build
this
application,
we
build
this
application
onto
our
one
of
the
commonly
used
language,
oops
language
that
you
might
all
use,
Java
and
plus.
Additionally,
we
use
that
plug
eclipse
start
vertex
plugin,
which
is
which
supports
to
only
I
believe,
like
Ruby,
kotlin
and
other
languages,
not
entire
language
tool
that
we
were
looking
for.
So
that's
where
we
say
like
it's,
a
very
complex
solution,
it's
hard
to
maintain
and
scale.
B
So
what
is
the
outcome?
Then?
We
build
this
with
this,
as
we
see
as
a
as
an
entire
organization
like
what
we
achieved
with
this
building
this
tool.
So
there
are
certain
events
once
first
one
is
like
we
try
to
empower
our
Engineers
with
the
mindset
of
like
okay
having
Innovation.
Secondly,
we
have
this
automation
piece,
that's
awesome.
We
try.
We
give
a
leverage
to
our
Engineers
to
adoption
of
new
technologies,
plus
we
try
to
bring
all
of
those
integrated
third-party
components
into
a
central
place.
B
So
that's
one
of
the
way
like
we
have
adopted
new
technology.
We
adopt
centralized
peace
and
we
bring
the
uniformity
within
our
back,
but
there
are
certain
opportunities.
So
opportunities
are.
We
have
still
some
places
for
other
part,
other
third-party
components
like
manual
process,
then
we
as
I
call
it
out
the
user.
Experience
is
just
only
for
CLI,
not
other
personas.
B
So
this
is
the
engineering
device.
No,
so
this
is
how
our
journey
is
and
no
matter
how
big
or
small
and
solving
a
software
developments
challenges
never
comes
easy
from
challenges
in
requirements
to
integrating
the
new
Tools
in
technology,
from
ensuring
end-to-end
Securities
in
Challenge
and
to
challenges
of
duplicating
efforts.
Software
product
development
requires
you
to
be
clear
and
stay
focused.
What
you
have
set
out
to
solve
in
order
to
achieve
what
you
have
set
out
for
your
mission,
that's
what
it
is,
and
now
I'm
gonna
pass
to
Ravi.
C
A
Want
to
provide
a
well
tooling
for
the
developer.
We
want
to
solve
the
developer
experience
at
the
end
to
end
so
we
in
the
beginning
of
the
year
we
looked
around.
What
is
the
thing
that
is
missing
from
the
our
internal
experience?
So
that's
where
we
come
up.
We
want
to
provide
a
single
pane
glass
experience
to
reduce
the
cognitive
load
and
make
it
easy.
The
goal
is:
make
it
easy
for
the
developer
as
backstage
says,
happy
developer,
happy
outcomes,
so
we
kind
of
looked
into
our
problem
area
into
three
different
buckets.
A
One
is:
how
do
we
help
developers
to
create
and
manage
Solutions?
How
do
we
they
make?
The
solutions
faster,
creates
faster
and
the
other
bucket
is
kind
of
discovering.
We
have
a
kind
of
little
bit
challenge.
We
have
multiple
different
cataloging
tools.
We
want
to
bring
all
of
them
together
to
make
it
easy
discover
and
to
encourage
the
ReUse
across
the
tapes
and
the
last
one,
but
very
important.
We
are
very
highly
regulated
industry.
We
want
to
provide
a
tool
that
will
provide
lot
of
insights
about
the
application
it
may
be
for
the
developer.
A
It
may
be
for
the
manager
it
and
it
is
for
the
Auditors
and
compliance
teams,
because
that's
the
biggest
factor
in
our
industry
and
when
we
took
this
holistic
approach,
we
we
haven't
stopped
at
the
developer
Persona.
We
looked
at
the
full
spectrum
of
things
that
we
have
to
do
so
we
looked
at
the
developer.
Persona
we
looked
at
the
managers,
they
have
to
manage
the
team
effectively.
We
looked
at
the
compliance
and
risk
factor
which
is
very
huge
and
audits,
are
very
huge.
We
because
we
are
globally.
A
We
are
audited
by
many
many
different
government
entities.
So
audit
is
a
big
thing.
We
want
to
solve
that
also
because,
at
the
end
of
the
day,
developers
Journey
won't
stop
at
coding.
It's
goes
beyond
so
that's
where
we
we
want
to
build
a
holistic
approach.
So
now
we
are
at
the
crossroads
of
what
we
do.
We
learn
something
with
our
new
tool:
internal
tool.
We
like
what
we
saw,
but
we
still
discount
few
factors
there.
A
So
then,
we
kind
of
looking
at
what
we
need
to
do
either
we
want
to
extend
one
of
our
internal
tools
or
whether
we
want
to
create
new
from
the
scratch
and
whether
we
need
to
buy
something
out
commercially
available.
That's
where
we
kind
of
saw
backstage
backstage,
and
this
is
where
I
will
show
how
we
are
using
backstage.
We
started
our
journey
with
the
backstage
we
saw.
There
is
a
natural
match
with
what
we
are
looking
for
and
what
is
backstage
was
offering
to
us
so,
but
we
are
still
skeptical.
C
A
Out
to
Francisco
and
Carl
here
from
the
American
Airlines,
we
had
a
great
conversation
with
him
and
we
saw
what
they
did
with
the
backstage
and
also
we
had
conversation
with
couple
of
Spotify
team
members
from
the
backstage.
That's
where
we
thought.
Okay.
This
is
the
right
approach
that
we
can
use
the
backstage
where
it
has
a
mix
of
things
like
where
you
can
Implement
your
own
stuff,
extend
with
the
plugins
and
adopt
quickly
so
from
here
I
will
show
how
we
are
going.
We
are
using
the
backstage
in
our
journey.
A
As
I
said,
this
is
a
journey
we
are
still
into
the
journey.
We
are
in
the
very
early
stage,
but
we
are
accelerating
very
fast,
so
the
main
bucket
that
we
want
to
solve
was
create
and
manage.
We
want
to
make
it
easy
so,
with
the
new
technologies
coming
day
in
and
day
out,
it's
always
challenging
and
we
want
to
end
being
a
regular
industry.
We
want
to
have
the
application,
create
and
follow
certain
standards
so
that
we
will
meet
our
regulatory
standards.
A
That's
where
we
want
to
use
that
create
and
manage
a
feature
we
want
to
provide,
and
we
kind
of
solve
this
using
the
two
features
of
the
backstage
one.
Is
the
templating
feature
software
template?
That's
where
we
created
some
of
the
templates,
and
this
is
a
space
where,
when
we
presented
that
internally
to
our
organization,
there
was
a
lot
of
excitement
in
the
house
and
a
lot
of
teams.
They
came
forward
and
they
want
to
create
more
and
more
plugins.
So
this
one
actually
accelerated
our
inner
sourcing
model.
A
A
And
the
other
one
is
it's
common,
quite
common
that
day
to
day,
you
need
to
navigate
through
multiple
systems,
a
developer
or
a
manager.
You
need
to
look
at
your
like
tickets
in
the
service.
Now
you
may
need
to
look
at
your
issues
in
the
jira.
You
may
need
to
look
at,
so
we
want
to
bring
everything.
So
if,
if
I
go
back,
our
goal
was
to
make
it
easy
and
provide
a
single
pane
gas
experience.
A
So
we
are
creating
a
dashboard
where
the
developers
or
managers
or
any
Persona
based
on
the
Persona
you
we
will
render
the
information
where
they
can
easily
look
at
the
system
and
the
status
that
could
be
their
outstanding
trainings
or
any
security
kind
of
thing.
So
this
is
a
great
place
where
they
can
land
here
and
they
can
navigate
from
here
if
they
have
to
take
any
actions
into
it.
A
The
next
one
is
Discovery
is
very
important,
like
you
need
to
know
what
you
have
in
your
organization
and
having
a
multiple
cataloging
system,
so
we
have
catalog
for
applications.
We
have
catalog
for
apis.
We
have
another
catalog
for
the
libraries,
so
we
want
to
bring
all
of
all
these
things
into
a
single
place
where
you
have
a
centralized
view
of
what
you
have
in
the
organization
so
that
you
can
extend
the
reusability
across
the
team
and
sharing
the
information,
and
this
is
our
catalog
information
we
right
now.
What
we
are
doing
is.
A
Not
last
in
the
priority,
but
it
is
very
important,
like
insights
as
I
said,
having
your
catalog
cataloging.
Your
item
is
okay,
but
you
need
to
know
the
real
fact
about
your
application.
That's
about
the
insights,
so
we
want
to
make
it
easy
to
get
the
application.
Insights
and
catalog
is
the
best
place
we
saw
like
we
want
to
extend
providing
cicad
status.
We
want
to
provide
the
application
vulnerabilities,
bringing
from
various
systems.
We
have
a
lot
of
code
scans
happen,
static,
Dynamic
and
all
those
things.
A
So
we
want
to
bring
everything
so
that
they
can
drill
down
into
each
application
how
the
application
health
is
going
on,
and
that
is
very
helpful
for
many.
Many
reasons
like
we
all
know
that,
and
another
factor
is
the
big
thing
about-
is
a
technical
documentation.
It's
common
in
any
organization,
probably
you
name
it.
You
have
multiple
ways:
you
can
document
your
application,
like
you
have
a
code
in
your
repository
and
your
documentation
may
be
in
the
SharePoint,
maybe
in
Wiki
or
somewhere
else,
and
what
happens
and
what
we
saw
is.
A
Even
though
the
developers
maintain
properly,
there
is
always
a
gap
between
what
your
code
is
doing
and
what
your
documentation
is.
So
we
want
to
bring
the
culture
of
a
document
as
a
code
and
that's
where
we
are
using
the
tech,
doc
plugin
to
bring
technical
documentation
into
a
central
place
and,
to
put
it
all
together.
This
is
our
view
of
that.
We
are
doing
we.
We
are
right
now
tackling
the
main
pillars
like
a
technical
documentation.
We
are
software
templates,
cataloging
and
we
are
still
working
on
our
insights,
part
of
it.
A
We
are
bringing
all
of
them
into
the
backstage
to
show
as
a
single
point
single
pane,
glass
experience,
and
so
with
that
what
we
are
getting
out
of
it
fewer
individual
systems
day
to
day,
you
can
probably
rely
on
Backstage
or
our
solution,
developer
experience
solution
so
that
you
can
manage
your
day-to-day
work
with
the
fewer
systems
and
consistent
user
experience,
whether
it
is
a
developer
experience
or
the
management
or
the
auditor,
they
all
go
to
the
same
place.
They
all
look
at
the
same
information.
A
It's
provide
the
reliability
of
the
information
and
Automation
and
standardization.
That's
where
the
tech
doc
sorry
templates
will
help
us
to
automate
our
application
Creation
with
the
standard
way
of
doing
so
that
we
can
trust
that
the
applications
that
are
built
is
following
the
standards
and
the
secure
methods
and
all
in
all,
also
onboarding.
It
is
easy
to
onboard,
so
it
solves
our
challenge
of
onboarding,
an
application
from
weeks
to
probably
in
a
couple
of
hours
you
will
have
with
the
template.
A
We
want
to
enable
the
developers
to
have
a
starter
application
to
deploy
within
no
time
and
all
in
all
easier
access
of
information,
and
the
other
thing
is
self-service.
We
still
evolving
in
the
self-service
area
where
you
can
probably
trigger
your
cacd
pipeline,
or
you
want
to
create
your
Cloud
resources,
those
kind
of
things
we
are
still
evolving
that
space.
But
our
goal
is
to
provide
the
self-service.
A
So
this
is
how
backstage
helped
us
to
take
our
goal
and
Mission
our
Dream.
Whatever
you
say,
to
help
us
with
a
cataloging
features
and
template
and
Tech
docs
and
the
other
like
lot
of
Open
Source
tool,
tooling
available
are
plugins.
They
are
helping
us
to
make
our
reality
our
goal
as
a
reality
with
that
I
will
pass
it
on
to
punu.
Okay,.
B
B
B
E
A
That's
a
good
question:
how
big
is
the
team?
So
when
we
started
we
started
with
one
person,
and
now
we
are
roughly
around
seven
to
eight.
It
depends
on
how
you
count
it,
including
the
product
manager
I'm,
the
technical
manager
for
that
and
we
are
still
expanding.
So
my
team
is
a
core
team
that
is,
will
take
care
of
the
platform,
the
internal
developer
platform
and
the
way
we
are
looking
at
is
we
are
going
in
the
inner
sourcing
model
so
that
any
other
team
can
contribute
to
that.
A
The
we
started
looking
at
the
backstage
last
year.
Actually
we
we
kind
of
we
have
one
cataloging
system
that
we
catalog
for
apis.
My
team
manages
that
we
want
to
kind
of
looking
at
Alternatives.
That's
where
we
started.
Looking
at
the
backstage,
you
need
to
understand
the
backstage
philosophy,
because
the
core
skills,
I,
think
node.js,
react
and
typescript
is
the
core
skills,
but
you
need
to
understand
the
ecosystem
and
how
to
use
your
backstage
backstage
is
a
tool
like
you
need
to
understand
deep.
A
If
you
are
going
into
full
blown
and
there
is
build
way-
small
learning,
I
won't
say
small.
There
will
be
a
good
learning
curve
to
understand
what
fits
best
to
your
organization
right.
Someone
can
start
with
a
simple
one,
Tech
doc,
to
give
a
quick
wing,
and
if
you
are
going
into
a
deep
cataloging,
maybe
that's
a
bigger
area.
I
I
would
say
that
requires
more
attention
and
Scaffolding
I
think
it's
a
relatively
easy
to
adopt.
A
F
F
But
but
we
said
that
we
have
to
see
it
right.
So
we
we
went
to
the
documents
and
everything
and
and
I
gave
the
team
like
one
Sprint,
our
one
Sprint
is
one
week
and
it
didn't
take
a
while
for
them
to
really
learn
it
because
the
following
week
someone
was
pinging
me
saying
that
Myrtle
I
I
I've
got
to
show
you
this
and
what
can
it
not
wait?
F
B
G
Can
I
can
I
ask
another
question
sure
so
talking
with
many
adopters
or
people
interested
in
backstage,
especially
in
highly
regulated
sectors
like
you
represent,
of
course,
and
there
are
believe
me
lots
of
banks,
but
also
in
the
pharmaceutical
Insurance.
One
of
the
most
recurring
question
is
okay.
How
we
can
deal
with
highly
regulatory
sector
and
all
the
constraints
that
we
have
in
terms
of
security
processes
and
I
mean
this
kind
of
tool
that,
for
example,
Esparto
Spotify.
We
use
in
a
very
open
manner,
because
we
don't
have
any
constraint.
G
Everyone
can
do
almost
everything
there
is
a
completely
different
philosophy.
So
it
would
be
very,
very
interesting
for
me
to
hear
what's
your
experience
of
being
a
great
example
of
a
high
regulator
sector,
how
did
you
manage
the
challenge?
How
do
you
manage
to
make
it
work
in
your
environment
because
I'm
pretty
sure
it
will
help
a
lot
of
people
here
in
the
room
and
not
only
in
the
room.
A
Initially,
it
was
a
lot
of
like
we
even
don't
know
whether
this
is
the
right
tool
and
whether,
when
we
pitch
this
idea
to
our
management
and
Executives,
we
don't
know
whether
this
will
fly
in.
But
the
way
we
were,
we
approached
this
one
is
actually
it
complements
what
we
are
trying
to
do,
or
it
will
helps
in
the
regulatory
Industries.
That's
where
I
was
talking
about
providing
a
standard
way
of
building
application.
You
are
guaranteeing
that
right.
Now,
I
was
talking
to
one
of
other,
my
colleague.
A
He
is
saying
that
yeah
they
they
hired
lot
of
Engineers
because
of
the
new
feature
and
each
one
is
building
their
micro
service
in
a
different
way,
and
that's
where
it
solves
all
right.
If
you
are
talking
about
the
regulations
and
all
those
kind
of
things,
if
you
create
your
template
in
a
standard
way,
and
if
you
add
all
your
bells
and
whistles
that's
where
it
helps
in
that
regulatory
environment,
you
are
guaranteed,
or
rather
you
are
making
sure
that
the
applications
that
are
building
is
following
the
best
standards.
A
A
And-
and
we
want
to
give
it
back
like
I-
said,
I
really
appreciate
Carl
here
he
spent
a
lot
of
time
with
us,
explaining
their
solution
and
I
will
highly
recommend
you
all
to
go
to
the
YouTube
and
search
for
American
Airlines
backstage
implementation.
That's
must
watch
if
you
are
getting
into
the
backstage.
Thank
you.
Carl
I
appreciate
what
you
do.
C
I'm,
sorry,
thank
you
so
much
for
presenting
this
is
really
helpful
and
I'm
in
a
similar
situation.
I
think,
as
you
are
in
a
regulated
industry
you
mentioned
in
terms
of
adoption,
you
mentioned
how
you
guys
have
software
templates
that
you're
defining
in
terms
of
the
organization
that
you're
in
how
much
traction
have
you
got
in
defining
enough?
What
you
feel
like
is
enough
and
how
much
more
do
you
have
you
mentioned
inner
sourcing?
A
So
from
the
couple
of
things
I
want
to
mention,
so
as
Poonam
initially
mentioned
the
in-house
tool,
that's
her
team
was
initially
managing
that
one
and
actually
we
are
replacing
inner
sourcing,
not
inner
sourcing,
the
in-house
built
template
tool,
of
course,
that
the
in
not
sourcing
it's
all
depends
on
what
is
the
mindset
of
the
organization?
So
if
you
ask
me
probably
a
couple
of
couple
of
years
back,
we
are
not
that
open
right
now
we
have
a
lot
of
excitement
in
the
inner
sourcing.
We
are
promoting
our
leadership
and
everyone.
A
We
encourage
inner
sourcing
and
right
now
the
my
situation
is
right.
Now
there
are
too
many
teams,
they
want
to
contribute
to
the
our
solution,
but
we
are
not
ready
to
help
them
out
because
we
are
also
kind
of
establishing
ourselves,
as
I
am
growing
the
team
and
I'm
adding
new
team
members
to
so
so
we
are
kind
of
taking
a
cautious
approach
right
now
we
are
working
two
to
three
teams
right
now
on
the
inner
sourcing
model,
because
we
want
to
create
a
model
for
others
to
come
in
so
I.
A
We
are
only
taking
few
teams
right
now
in
the
inner
sourcing
model
on
the
my
journey,
so
that
we
establish
fully
the
process
for
others
to
come,
and
we
want
to
create
the
guides
how
to
also
so
that,
if
someone
want
to
contribute
to
the
new
template,
we
want
to
so-called
golden
path:
blueprints
whatever
you
call
it.
So
we
want
to
create
a
well-documented
process,
internal
process,
how
they
can
add
to
the
solution.
A
We
expect
to
keep
going
up
and
because
we
have
thousands
of
applications
and
if
you
open
the
hood
underneath
that
we
have
probably
multiple
thousands
of
services,
and
if
you
extend
that
back
to
like
what
is
your
approved,
we
all
about,
we
need
to
look
at
what
is
your
approved
open
source
Library?
So
we
want
to
catalog
that
also.
So,
if
you
look
at
it,
multiple
thousands
I
don't
have
the
correct
number
here,
but
we
feel
that
it's
a
large
and
also
like.
We
want
to
catalog
everything
anything
possible
kind
of
thing.
A
I
J
J
I
was
wondering,
since
you
started
using
backstage,
have
you
guys
tried
using
it
for
Incident
Management
metrics
so
like
as
an
engineer,
is
troubleshooting
an
issue
and
he's
completely
lost?
There's
no
idea,
what's
going
on
it's
hard
to
find
information,
sometimes
and
I
feel
like
backstage,
would
be
perfect
for
that
and
I
was
wondering
if
you
guys
maybe
attract,
mean
time
to
detect
or
fix
metrics
after
implementing
backstage.
A
So
we
had
a
lot
of
conversations
about
that
metrics.
It
boils
down
to
not
only
that
what
are
like
we
want
to
capture
other
metrics,
but
we
are
still
debating
what
is
the
right
Matrix
right?
We
are
right
now
all
about
enabling
the
developer
that
then
we
want
to
just
track
them.
Then
we
will
want
to
go
in
to
see
what
is
the
real
data
looks
like
for
example,
incident.
We
have
our
Incident
Management
System,
that
is,
we
have
all
the
metrics
there.
A
So
that's
not
a
major
problem
for
us,
but
we
are
looking
at
the
overall
like
there
are
so
many
developer
efficiency
metrics
we
right
now.
We
have
that
as
a
probably
Target
for
later,
but
we
want.
We
are
looking
at
what
we
want
to
Monitor
and
log
so
that
we
can
measure
properly
and
what
makes
most
we
we
are
still
evolving
on
on
that
one.
We
don't
want
to
make
this
tool
to
make
developers
pressured
about
their
metrics.
A
D
Hi
got
a
mic
over
here,
so
especially
in
a
highly
regulated
industry
and
also
with
multiple
catalogs
that
you're
trying
to
put
together
and
a
lot
of
content
in
your
catalog.
How
are
you
guys
looking
at
the
accuracy
and
are
you
guys
using
catalog
info
yaml,
for
that?
Are
you
doing
certain
things
to
help
with
the
accuracy
of
the
catalog
or
anything
like
that?.
A
Yes,
that's
a
good
question:
I,
don't
think
we
solved.
I
will
explain
this.
I
will
take
you
back
this.
So
if
you
see
that
there
is
a
central
asset
system,
cataloging
right,
the
way
we
are
looking
at
is
when
we
are
creating
the
new
assets.
Through
back
the
developer
experience
portal
backstage
you
are
creating
a
new
asset,
so
the
asset
Journey
starts
from
the
backstage
developer
experience
platform,
and
then
we
want
to
send
it
to
a
central
repository
also
because
we
want
to
do
some
reporting
and
all
those
things.
A
Likewise,
we
still
know
that
there
are
other
assets
generate
from
some
other
catalog
kind
of
thing,
so
we
are
using
the
entity
providers
to
sync
asynchronously,
like
the
initially
we
kind
of
did
a
hard
bite
into
the
other
catalog
system,
but
which
changed
it
to
like
a
read
and
write
asynchronous
model.
So
first
we
will
write
into
our
own
backstage
catalog.
If
it
is
generating
from
the
cat
our
developer
portal,
then
it
will
sync
into
the
through
the
custom
entity
processor
to
the
other
Central
asset.
J
B
So
it's
like
our
my
project
when
it's
signing
a
house
app
as
I
stated,
and
it
just
builds
a
scaffolding
of
your
project,
and
so
our
Engineers
can
focus
on
building
the
business
logic.
So
he
asked
me
like:
can
I
use
your
template
because
it
matches
with
what
backstage
is
using
as
an
approach
and
that's
where
he
used
like
Java?
That's
you
that's
where
he
used
our
tablet
and
tried
to
see
that
whether
it
works
and
it's
it
sounds
like
it
was
done
in
a
days
right.
B
It
was
done
in
a
days
and
which
and
for
building,
ask
for
that.
Template
itself
took
almost
like
for
us
three
or
four
or
maybe
probably
a
month
for
that.
So
that's
where
we
see
like
you
know
backstage
is
an
opportunity
to
add
any
any
developers
means
any
developer,
which
has
like
even
I,
see
like
a
fresher
graduate
who
is
really
to
learn,
can
easily
create
templates
and
start
working
on
it.