►
From YouTube: Metadata Day 2022 - Experts Panel - Governance as Code
Description
We assembled a host of data experts across industry and academia to participate in a half-day workshop on Governance as Code and share their ideas with the attendees during this interactive 90 minute session.
0:00 Experts Panel Welcome
10:30 Nishant on the practical way to look at data governance and its objectives
14:30 Amol shares why a horizontal approach to data governance is not always a practical one
16:08 Joe's three-part framework for data governance model
17:41 Nishant shares tooling that combines tooling, process, and governance
44:45 Shirshanka and Juan discuss the metadata graph as the system to define and test policies
Panelists:
Nishant Bhajaria - Director of Privacy Engineering, Architecture, and Analytics, Uber
Teresa Tung - Cloud First Chief Technologist, Accenture
Amol Deshpande - Professor, Univ. of Maryland
Joe Hellerstein - Jim Gray Professor, UC Berkeley
Juan Sequeda - Principal Scientist, data.world
Shirshanka Das - Co-founder and Chief Executive Officer, Acryl Data
Learn more about DataHub: https://datahubproject.io
Join us on Slack: http://slack.datahubproject.io
Follow us on Twitter: https://twitter.com/datahubproject
A
Welcome
everyone
to
day
two
of
the
metadata
day
event.
The
theme,
as
you
know,
is
governance
is
code,
and
I
am
really
happy
that
we
had
a
great
lightning
talk
session.
I
was
up
at
8
30
a.m.
Listening
to
a
bunch
of
great
talks,
and
I
highly
recommend
you
go
back
and
listen
to
them
if
you
haven't
already,
but
to
give
a
quick
recap,
quick
intro,
to
who
I
am
I'm
shashanka
co-founder
and
ceo
of
acryl
data.
A
Prior
to
this,
I
was
at
linkedin
where
I
founded
the
data
hub
project.
If
you're
here
and
you
don't
hold
the
data
hub
project,
quick
intro
data
hub-
is
an
open
source
metadata
platform
number
one.
A
huge
amount
of
integrations
huge
amount
of
adoption,
we're
pretty
excited
to
see
the
community
grow
and
we're
part
of
this
meta-day-to-day
community,
creating
this
summit
and
conference-
and
it's
been
an
amazing
journey
so
far
moving
on
you
know,
the
community
itself
is
growing.
A
When
I
started
actual
data,
we
had
200
ish
people,
mostly
quiet
right
now
we
have
a
pretty
vibrant
community
of
3000,
plus
slack
members.
Maggie
is
doing
a
great
job
of
reaching
out
to
everyone
and
kind
of
making
them
feel
welcome
and
giving
them
a
way
to
contribute
and
make
an
impact
on
the
project.
We
are
worldwide
and
deployed
in
a
lot
of
different
companies
and
countries.
A
So
that's
us,
but
we're
here
for
metadata
day
and
a
quick
history
of
metadata
day.
We
all
like
lineage
right,
so
the
inaugural
session
of
metadata
day
happened
in
2020
a
lot
of
foundational
questions
but,
more
importantly,
a
rallying
understanding
of
the
importance
of
metadata
in
modern
data
practices,
whether
it
is
data,
discovery,
data
governance
or
data
observability
or
even
data
management.
A
I
spent
a
lot
of
time
there,
a
lot
of
thought
leaders
were
there
highly
recommend
you
go
back
and
check
out
those
videos
and
those
links.
2021
jamar
published
her
now
very
highly
cited
blog
post
and
we
spent
time
looking
at
investigating
data
mesh
as
an
interesting
idea
that
metadata
kind
of
has
enabled
and
we
so
so.
We
investigated
a
lot
of
concepts
at
the
intersection
of
metadata
and
how
it
enables
the
the
data
mesh
fast
forward
to
today.
A
We
are
talking
about
actually
a
key
pillar
of
data.
Mesh
and
zuma
called
it
out
beautifully
federated
computational
governance,
but
let's
boil
it
down
into
what
it
really
means
federated.
So
the
act
of
removing
centralization
from
the
governance,
processes
and
kind
of
giving
power
to
the
data
domains
federating
out
that
act
and
then
the
computational
aspects
of
governance,
meaning
taking
concepts
that
have
usually
been
just
in
people's
minds
and
policies
and
kind
of
bringing
them
down
into
actual
code
into
actual
software
systems.
A
Therefore,
governance
as
code,
and
so
that's
really
the
theme
for
our
metadata
day
and
that's
how
we
arrived
here.
Moving
on
you
know,
we
specifically
want
to
distill
the
high
level
ideas
of
governance
as
code
into
ideas
that
are
proven
to
work
at
small
and
large
companies.
We
have
a
huge
group
of
practitioners,
who've
actually
taken
and
implemented
modern
data
practices
at
a
lot
of
companies.
Here
we
want
to
talk
about
practical
implementation
that
you
can
put
into
production
tomorrow.
A
These
are
people
who
have
spent
decades
in
the
industry,
both
in
data
and
in
privacy
and
in
actually
coming
from
research
in
academia
and
industry.
So
I'm
really
fortunate
to
welcome
this
amazing
group
of
individuals,
we'll
we'll
go
in
the
order
of
the
headshots.
Of
course,
I
will
not
bother
you
by
introducing
myself
again
so
first
up,
nishant.
B
A
A
D
D
A
Their
prep
as
well
cool
joe
we're
just
having
a
little
tough
time
hearing
you,
so
you
might
want
to
check
on
your
audio
a
little
bit
for
people
who
didn't
hear
the
latter.
Part
of
that
was
a
professor
at
uc
berkeley
and
founded
a
company
called
trifecta,
pretty
well
known
as
a
data
transformation
company
moving
over
to
huan.
E
Hi
everybody
I'm
juan
cecada,
I'm
the
principal
scientist
at
data
world
work,
the
enterprise
data
catalog
for
the
modern
data
stack.
My
my
background
is
on
data
integration
using
semantics
and
graphs,
and
now
knowledge
graphs
for,
like
15
years
recently
wrote
a
book
on
the
on
the
topic.
I
started
this
at
my
phd
at
university
of
texas
at
austin
spent
out
a
company
called
capsenta,
which
was
acquired
by
didn't
world
a
couple
years
ago
and
and
metadata
and
data
catalogs.
This
is
my
life,
so
excited
to
be
here.
F
Hi
everyone,
my
name,
is
I'm
a
professor
at
university
of
maryland
at
college
park
where
I've
been
working
in
on
various
database
and
data
management
related
problems
for
many
years.
This
included
a
project
called
data
hub
where
we
were
looking
at
data
governance
issues,
among
others
in
end-to-end,
machine
learning,
life
cycle
management.
More
recently,
I
also
co-founded
a
company
called
wireville,
where
we
are
building
products
to
help
companies
comply
with
privacy
regulations
like
gdpr,
ccpa
and
others,
and,
of
course,
privacy,
compliance
and
metadata
management
or
data
governance
are
very
closely
intertwined
together.
G
A
So
a
lot
of
great
work
that
has
been
done
by
this
team,
both
in
research,
academia,
as
well
as
in
the
practical
field.
So
with
that
a
quick
segue
into
how
we
workshop
this,
so
so
a
group
of
us,
you
know
all
of
us.
We
got
back
into
the
workshop
yesterday
and
we
spent
time
on
a
few
burning
questions
when
it
comes
to
data
governance
and
specifically
governance
as
code,
and
so
the
way
we're
going
to
run.
A
A
We
basically
all
agreed
that
data
governance
by
itself
is
a
really
broad
topic,
and
it
includes
a
bunch
of
things:
data,
quality,
privacy,
access
management,
life
cycle
management,
but
really
what
it
drives
with
the
goal
of
all
of
this
is
to
drive,
increase,
trust
and
to
drive
increased
usage
of
data,
and
so
this
is
a
complicated
problem.
There
are
multiple
kinds
of
personas
involved,
multiple
kinds
of
concepts
involved
and
to
have
a
kind
of
a
lively
chat
about
this.
B
He
wants
to
kick
it
off.
I
guess
I'll.
Kick
it
off
all
right.
I
think,
for
me,
data
governance
is
about
making
sure
that
the
discipline
about
data,
how
to
collect
it,
what
to
collect
where
to
keep
it
who
to
use
it
for
those
sorts
of
decisions,
can
be
made
at
scale
using
automation
so
as
to
take
away
that
individual
decision
from
the
engineer
on
a
case
by
case
basis,
because
they
simply
don't
have
the
time.
How
do
you
bake
in
governance,
identity
into
the
data
itself
for
customers,
employees
of
identities?
B
Why
not
give
data
that
identity
and
feed
that,
like
a
first-class
citizen
and
the
more
you
embed
that
into
the
data,
the
more
you
connect
it
to
the
attendant
controls
and
the
more
you
automate
that,
on
an
ongoing
basis,
the
higher
the
possibility
that
you
can
keep
data
used
correctly
in
a
way
that
was
originally
intended
to
be
without
adding
to
the
risk
of
the
business?
The
reason
we
are
still
talking
about
it
is
because
we
have
decentralized
tech
infrastructure
at
most
companies
disconnected
engineers,
ci
cd
pipelines
that
are
often
bespoke.
B
So
the
things
that
have
made
us
successful
so
far
have
rewarded
separation
and
discontinuity
and
process
light.
We
now
need
to
move
towards
a
place
that
is
still
somewhat
light
on
process,
but
has
a
level
of
discipline
and
deterministic
decision
making
to
it,
and
for
me,
that's
what
data
governance
is
about.
The
fact
that
we
are
talking
about
it
too.
This
point
does
not
reflect
a
failure.
In
fact,
it
reflects
a
realization
that
the
things
that
have
kept
us
successful
so
far
aren't
sufficient
for
the
future
so
happy
to
discuss
further.
C
E
E
I
highly
recommend
this
book
and-
and
she
says
the
only
reason
why
we
do
data
governance
is
that
people
can
actually
use
the
data,
and
I
think
this
is
something
if
you're
going
to
go
use
the
data.
We
really
need
to
understand
all
the
stakeholders
involved.
It's
not
just
about
the
technical
data
producers,
but
it's
also
about
who
are
the
end.
E
A
Great
one
of
the
things
that
we've
also
noticed
is
you
know
often
when
you
think
about
this
problem
of
data
governance,
and
you
realize
that
it's
actually
an
end-to-end
problem,
because
you
know
it's
not
just
about
governance
in
your
warehouse.
You
also
have
to
expand
it
to
have
governance
on
your
streaming
ecosystem,
and
then
you
also
have
to
expand
it
to
include
governance
on
your
service
apis
and
all
your
third-party
data,
and
so
there's
a
obviously
a
thought
that
maybe
a
horizontal
approach
to
this
and
having
a
holistic
approach
to
this
is
good.
F
Yeah,
you
know
so,
as
as
tech
people
right,
we
like
to
look
for
elegant,
beautiful
and
comprehensive
solutions
and
for
data
governance.
That
solution
often
takes
the
form
of
a
horizontal
layer
where
you
understand
all
the
systems.
We
have
understand
all
the
data
we
have,
and
you
know
the
moment
we
have
it
like.
Like
you
know,
the
hope
is
that
once
we
build
it,
then
we
can
build
things
on
top
of
it,
but
there's
two
three
things
I
have
to
keep
in
mind.
F
One
is
that
building
that
horizontal
layer
is
actually
can
be
a
multi-year
effort
in
itself.
It
takes
a
lot
of
time
to
collect
all
the
data
and
many
of
the
real
reasons,
the
business
use
cases
or
other
compliance
use
cases.
They
require
that
information
today
and
I
cannot
wait
for
two
years
to
start
complying
with
gdpr.
I
need
to
know
where
my
data
is
stored
today,
I
need
to
know
where
it
is
being
transferred
today.
F
I
need
to
know
what
it's
being
used
for
today,
and
so
it's
really
important
to
focus
like
make
sure
we
have.
I
think,
tying
back
to
the
previous
slide,
that
whatever
we
are
doing
is
tied
to
those
business,
values
or
business
use
cases
to
make
sure
we
get
the
value
either
in
terms
of
actual
value
or
compliance
reasons,
but
while
doing
that
making
sure
that
we
are
not
doing
the
work
twice
right
like
many
times
the
same
things
you
need
for
privacy,
compliance
are
likely
to
be
a
big
part
of
data
governance.
F
A
C
D
D
Just
to
distill
it
down
to
the
very
basics:
you
have
to
start
with
policy,
preferably
policy
as
specification
right
and
that
can
be
code,
and
then
you
need
observability
of
what's
going
on
to
get
the
transparency
as
to
whether
the
policy
is
actually
being
met,
and
then
you
need
you
know
like
any
legislative
system.
It's
governance,
you
need
either
incentives
or
enforcement
or
both
right.
You
need
some
way
to
get
people
to
follow
that
policy.
That's
a
much
more
human
action
activity,
much
more
human
sort
of
engineering
problem
right.
D
A
B
Hear
it
and
I
really
miss
him-
my
publisher
is
going
to
hate
me.
If
I
don't
do
this,
I'm
supposed
to
do
this
in
every
appearance
I
make
so
I've
written
a
book
on
this
topic
as
well
data
privacy
runwork
for
engineers.
My
elephant
backdrop
is
obscuring
it
so
I'll
send
out
a
link
on
the
chat
channel,
I'm
actually
donating
all
the
proceeds
to
elephant
conservation.
B
So
that's
why
my
backdrop
as
well
so
unfortunately
hides
the
book
in
this
case,
but
to
your
question
abhijit,
pretty
relevant
question
and
when
you
work
for
the
kinds
of
companies
that
I
have
when
you
work
for
companies,
whereas
an
engineering
first
culture,
you
have
to
be
very
creative
in
terms
of
using
the
tools
available
to
you.
So
I
mentioned
an
example
of
a
tool
called
meditron
at
netflix.
That
was
a
third
party
that
was
a
homegrown
solution
that
we
built
for
preventing
access
to
data
by
third
parties
from
the
outside.
B
So
how
do
we
make
sure
that
the
keys
constantly
get
swapped?
How
do
we
make
sure
the
algorithm
constantly
gets
changed?
So
what
I
did
was
I
took
that
tool
from
the
security
organization
and
said
I'll
repurpose
it
for
privacy.
What
that
meant
is
when
folks
said
that
we
needed
access
to
the
data.
So
netflix
is
a
freedom
of
responsibility.
Engineers
can
access
everything
kind
of
culture,
so
we
couldn't
just
bring
down
a
top-down
process
where
everybody
had
to
go
to
central
I.t
for
permission.
So
what
we
said
is
fine.
B
B
If
you
don't
access
the
data
once
every
seven
days,
we
will
swap
the
keys
or
we
will
make
some
changes
so
as
to
make
you
come
to
us
and
ask
for
information
again
and
if
you
choose
not
to
do
that,
that
means
your
requirement
was
not
really
valid
and
we
will
change
the
keys
all
over
again
and
make
sure
you
get
locked
out
of
the
data.
What
that
means
is,
rather
than
taking
something
away
from
engineers
preemptively
we
take
it
away
from
them,
after
giving
them
evidence
that
they
don't
need
the
data.
B
This
is
an
example
of
tooling
process
and
governance.
All
at
once,
and
I
totally
agree-
it's
not
going
to
be
fixed
with
code.
You
need
to
understand
governance
in
the
context
of
how
the
organization
collects
and
uses
data
and
then
find
every
way
possible
to
repurpose
tools
that
already
exist,
because
for
one
thing
it's
going
to
be
hard
to
get
engineers
onboard
to
a
whole
new
tool
for
governance.
So
if
you
can
repurpose
existing
tools
as
a
combination,
it
is
an
economically
sound
argument.
It's
also
going
to
be
programmatically
much
easier,
great.
E
Quickly,
chime
in
here
as
I
love
this
example
that
shawn
says
another
example
I
have
from
one
of
our
customers.
I
work
with
at
prologist.
They
actually
everybody's
bonus
is
tied
to
data
quality.
Like
25
percent
of
everybody's
bonus,
the
company,
I
think,
that's
another
carrier,
that's
an
example
of
incentives
that
come
from
the
executive
level.
I
think
that's
the
type
of
stuff
I'm
seeing
kind
of
a
conversation
in
the
chat
we
need
executive
buy-in,
and
that
comes
from
the
example
from
the
ceo.
A
A
The
fact
that
there
are
multiple
personas
involved
is
definitely
a
huge
part
of
the
challenge
and
we've
we're
already
seeing
a
lot
of
conversation
about
how
to
bring
the
business
user
in
how
to
bring
the
technical
user
in
these
cohorts
have
kind
of
been
separated,
sometimes
intentionally
sometimes
unintentionally,
and
so
we
addressed
kind
of
the
next
question
head-on,
which
is
like
how
can
technical
and
business
users
actually
govern
data
coherently?
Is
there?
Is
there
even
hope,
and
so
the
first
kind
of
solve
there
that
we
discussed
was?
G
Yeah
sure,
well,
one
of
the
reasons
we
like
to
think
of
metadata
as
a
graph
is
that
it's
very
multi-dimensional.
You
have
a
lot
of
different
concerns
that
need
to
be
modeled.
You
have
a
lot
of
different
dimensions
of
the
domain
that
need
to
be
modeled.
You
have
you
know,
you
know,
dimensions
that
deal
with
just
representing
what
the
data
is.
You
need
to
represent
things
having
to
do
with
compliance.
G
You
need
lineage
and
graphs
tend
to
be
good
at
sort
of
bringing
together
different,
different
views
of
the
same
things,
the
things
being
you
know,
data
sets
and
users,
and
so
on.
So
it's
I
found
it
very
helpful
at
two
organizations
now
to
think
of
the
you
know
the
metadata
catalog
as
a
graph
and
to
model
it
that
way.
E
Yeah,
so
something
that
we've
realized
and
kind
of
seeing
a
lot
of
the
discussion
going
on
in
the
chat
is
we
we
need
to
think
about
governance
from
two
aspects.
Right,
there's
like
two:
I
would
put
them
into
two
cohorts
like
the
other
data
producers,
the
technical
folks,
and
then
you
have
the
data
consumers
more
on
the
business
side.
So
you
want
to
be
able
to
think
about
it.
E
What
what
are
the
needs
that
each
one
of
them
have
at
the
end
of
the
day
the
data
goes
through
and
you
you
need
to
make
sure
that
you're
using
the
data
right,
so
we
so
the
question
is:
who
needs
the
data?
What
is
it
for?
Let's
go
start
cataloging,
those
use
cases,
those
needs
those
business
glossary
terms
right,
like
let's
call
that
the
business
or
the
logical
layer
right
there
and
all
that
needs
to
get
connected
too
right.
E
So
you
have
the
the
business
terms,
the
people,
the
organizations,
the
use
cases,
let's
start
connecting
all
that
stuff
and
then
from
the
technical
side,
everything
is
I'm
gathering
metadata
tables
and
columns
or
dashboards.
So
lineage,
all
these
things.
I
do
sensitive
data
discovery,
I
put
all
this
stuff
together
and
then
we've
always
had
kind
of
this
gap
and
what
we
need
to
go
do
is
start
just
making
connections
between
the
technical
and
the
business
side.
E
So
I
think
that's
why
graphs
naturally
lead
to
be
able
to
code
to
connect
all
this
stuff
together,
but
I
think,
what's
important
is
to
be
able
to
go
think
about
it
as
two
lenses
for
the
consumers
for
the
consumers
and
the
producers,
and
even
when
you
think
about
tooling,
you
need
to
be,
you
think,
is
this
tool
more
for
the
producers.
Is
this
too
more
for
the
consumers
and
what
is
a
tool
in
the
process?
A
C
I
mean
that's
one
of
the
the
tenets
of
the
data
mesh
is
that
the
business
takes
a
bigger
ownership
of
data
products,
and,
if
anything,
I
want
my
business
right.
I
want
our
hr
team,
our
finance
team,
to
say
this
is
the
data
you
should
be
using
for
making
your
decisions.
I
want
to
see
the
same
thing
and
I
want
to
see
the
same
thing
that
they've,
you
know,
people
who
actually
know
about
hr
and
finance
have
approved.
C
So
I
would
say
the
business
is
not
just
a
consumer
they're,
better
suited
than
anybody
to
actually
describe
the
value
of
the
data
and
to
make
the
definitions
in
the
data,
and
so
something
very
pragmatic
that
could
be
done
there
is
that
you
know
maybe
the
business
users,
so
an
example
that
we've
worked
in,
is
it
with,
let's
say,
with
anti-money
laundering
or
finance.
There's
certain
reports
there's
certain
suspicious
activity
and
transactions.
C
Those
might
be
somewhere
that
the
business
will
spend
a
lot
of
time,
making
the
definitions
defining
even
the
quality
and
quality
as
it
relates
to
those
topics,
and
from
that
we
can
combine
this
with
technical
metadata
right.
We
can
actually
track
back
the
lineage
into
other
tables,
other
transformations
places
that
maybe
that
expert
didn't
have
time
to
label
right
and
but
we
can
actually
still
see,
because
we
can
see
that
somehow
the
data
is
being
derived
and
being
handled.
We
can
go
upstream
and
downstream
to
really
propagate
some
of
those.
C
A
And
related
to
this
concept
of
a
data
product
is
the
consequence
of
when
the
product
is
unhealthy,
who
gets
involved,
and
so
one
of
the
things
we
talked
about
is
whether
you
know
taking
the
software
engineering
approaches
of,
like
someone's,
always
on
call
for
a
service
right.
So
when
a
service
goes
down,
you
actually
know
who's
on
call
and
you
call
them
and
then
they
go
fix
the
service.
A
So
if
we
applied
that
same
concept
to
data,
we
realized
that
it's
actually
not
as
simple,
because
a
data
set
or
a
data
product
not
being
healthy,
could
have
multiple
reasons.
There
could
be
like
a
technical
reason
for
it
not
to
be
healthy,
because
maybe
the
pipeline
ran
unsuccessfully
and
just
failed
to
produce
the
data
set,
or
maybe
the
pipeline
actually
produced
data,
but
just
doesn't
meet
the
quality
semantics
that
you
expect
from
the
data
and
then
going
further
up.
A
So
that's
kind
of
one
thing
that
we
kind
of
finished
with,
as
our
closing
thought
on
this
particular
section
and
I'm
looking
at
kind
of
the
questions
coming
through,
I
think
we're
we
will
move
along
and
kind
of
the.
The
next
question
that
we
went
into
was
really
moving
from
this
understanding
of
all
right.
We
need
some
form
of
separation
of
personas,
but
we
need
a
consistent
metadata
graph.
We
need
to
bring
in
business
users
earlier
on
in
the
definitional
part
of
the
data
product.
A
We
need
to
have
incentive
structures
aligned
and
we
started
getting
deeper
into
the
workflow
of
a
data
producer
and
started
asking
the
question.
Well,
what
does
this
look
like
in
practice?
What
are
the
tools
and
context
that
a
data
producer
needs
so
that
they
can
fulfill
their?
You
know
their
duty
towards
data
governance.
G
We
talked
a
little
bit
about
the
the
distinction
between
you
know:
a
schema
at
a
physical
level
and
a
schema
plus
semantics,
which
is
really
needed.
There's
a
little
side
chat
here
about
gdpr
for
compliance
for
protecting
user
privacy.
We
need
to
know
what
the
data
means,
not
just
what
its
structure
is,
so
that
the
best
way
to
the
best
place
to
add
that
information
is
as
close
as
possible
to
the
place
where
the
you
know.
G
D
Yeah,
so
I
don't
know
if
josh
got
to
fully
wave
the
flag
for
that
idea
and
it's
a
good
idea.
So
I
want
to
take
a
moment
to
be
positive,
which
is
there
are
a
lot
of
practices
in
software
engineering,
where
we've
learned
to
have
iterative
processes
that
can
make
things
reliable
in
the
face
of
great
deals
of
complexity
and
the
software
engineering.
Business
is
probably
the
most
complex
artifacts
that
people
have
created
and
those
processes
are
very
helpful.
So
ideas
like
continuous
integration
and
testing
that
work
well
in
software
engineering.
D
And
when
you
talk
to
security
engineers,
they'll
tell
you
right
away
that
you
know
the
biggest
source
of
security
leaks
is.
Is
the
you
know
we're
like
squishy
things,
the
people
right?
That's
your
weakest
link
in
your
security
and
we
have
the
same
problem
in
a
lot
of
ways
in
data
governance
that
we
have
to
think
about
the
human
side.
So
we
have
to
think
about
why
wouldn't
a
person
do
a
bad
job
of
data
governance?
Why
would
we
not
trust
them
and
how
can
we
incent
them
to
be
trusted?
D
And
it's
not
the
same?
As
with
software
engineering,
it's
really
much
more
like
security
in
that
sense,
so
I
don't
think
it's
a
direct
copy
paste.
I
don't
think
that
just
doing
cicd
for
data
is
going
to
solve
all
our
problems.
I
think
we
need
to
think
about
kind
of
the
human
side
very
much
differently.
A
B
Shift
left
doesn't
work
unless
you
prepare
right,
so
my
general
approach
is
when
you
go
up
as
far
left
as
possible
to
identify
the
data
identify
ownership.
You
want
to
make
sure
that
that
is
going
to
give
the
producer
some
value,
because
at
the
end
of
the
day
the
engineers
haven't
made
commitments.
Remember
they
get
paid
compensated,
promoted
based
on
throughput
how
many
lines
of
code-
maybe
that's
a
bad
one,
but
how
many
tools
do
they
get
out
the
door?
What
does
the
engagement
look
like
if
that
doesn't
work?
B
Your
engineers
will
leave
your
company
and
then
you'll
be
left
to
secure
nothing
at
all.
So
you
want
to
make
sure
that
when
you
identify
service
owners,
data
ownership
asset
ownership,
you
want
to
correlate
that
to
actual
tooling.
So
if
you
register
your
service
with
me,
we
will
take
care
of
your
deletion.
We
will
take
care
of
your
extraction,
your
preservation,
your
encryption,
anonymization
dissemination.
All
of
that
will
be
taken
care
of
at
the
back
and,
of
course,
the
logistics
will
matter
in
terms
of
the
details.
That
is
when
does
that
happen?
B
Does
the
engineering
team
actually
check
the
work
before
it
happens,
but
fundamentally
there
has
to
be
an
immediate
value
to
the
engineers
saying
that
you
will
have
more
time
to
do
the
stuff
that
you
are
supposed
to
do
and
we
will
take
stuff
off
your
plate.
You
know
I
was
in
a
meeting
earlier
this
morning
where
one
of
my
colleagues
said.
B
A
Great
great
anecdotes
there
another
thing
we
talked
about
quite
a
bit
is:
do
we
centralize
all
the
tooling
or
do
we
decentralize
all
the
tooling,
and,
I
think
juan
you
know,
had
a
lot
of
interesting
ideas
there
around
when
to
centralize
and
when
not
to
centralize
and
whether
this
is
all
against
the
data
mesh
concept
or
actually
aligned
with
the
data
mesh
concept
and
so
juan?
Why
don't
you
tell
us
a
little
bit
about
your
thoughts
in
that
area?.
E
Yeah,
I
think
it's
the
next
slide
right.
There
we
go
so,
and
I
want
to
go
address
directly.
Pam
is
having
questions
here
and
I'm
saying
look
it
there
exists.
There
are
existing
kind
of
data,
governance,
tool,
teams
and
tools
and
all
that
stuff.
There
is
a
balance
between
centralization
and
decentralization
today,
most
of
stuff
that
we
see
in
organizations
that
you
have
a
central,
a
central
I.t
team
that
central
iot
team,
the
central
data
governance
team.
They
are
disconnected
a
lot
from
the
business,
they
don't
understand
the
business
context
right.
E
They
understand
the
technical
context,
but
then
how
are
why?
Why
are
they
expected
to
be
able
to
go
label
and
do
things
with
without
no
being
in
the
business
understanding
that
so
that
is
kind
of
the
discrepancy
we
have
now?
It
doesn't
mean
that
we
need
to
go
push
everything
decentralized
and
then
put
the
data
governance
teams
on
the
side,
and
that's
it
it's
really
to
try
to
find
this
balance.
So
the
question
is:
what
do
we
go
centralized
and
what
do
we
push
in
these
and
decentralize?
E
Again,
it's
a
famous
answer.
It
depends
right.
It
depends
on
your
industry.
What
regulated
you
are
right
if
you're
very
financed,
there's
a
lot
of
things
that
need
to
be
regulated
and
they
need
to
be
in
a
centralized
way,
depends
on
the
size
of
your
company
right
you're,
a
smaller
company,
100
200
people.
You
can't
afford
being
decentralized,
but
if
you're
a
larger
one
you
can,
you
may
start
growing
from
you
said
from
a
centralized
and
decentralized.
It
also
depends
on
the
culture
within
you.
Have
your
organization
right?
That's
another
aspect
to
go.
E
E
We're
going
to
go
central,
centralize
this
and
then
you're
going
to
pass
these
policies
out
to
the
decentralized
knowledge
and
you
go
off
and
you
go
implement
them
we're
defining
what
they
are
and
we're
going
to
give
you
the
tools,
so
you
can
automatically
automate
as
much
as
you
can,
but
your
your
risk.
You
are
responsible
for
the
implementation
of
these
things,
so
there
may
some
other
policies
that
you
want
to
be
able
to
go
do
in
a
decentralized
way.
I
want
to
go.
E
Do
some
special
type
of
tagging,
for
the
data
sets
that
I
own
all
right?
You
define
your
policies
for
your
data.
Sets
that
you
want
to
go.
Do
other
organizations
that
we
see
is
like
hey.
We
want
to
define
what
a
phone
number
is,
because
we
don't
want
anybody
else
to
redefine
what
a
phone
number
is
and
those
have
implications
from
customer
service
from
gdpr
a
phone
number
has
a
country
code,
an
area
code,
an
extension.
It
has
a
mobile
phone
number,
a
a
a
work
phone
number.
E
Mobile
phone
numbers
have
to
have
sms,
but
permission
even
has
these
types
and
all
that
stuff,
and
we
want
to
be
able
to
go
centralize
what
that
definition
is,
and
then
these
centralized
nodes
can
say
hey
am
I
am
I'm
going
to
use
that
to
go
check
my
data
quality?
Am
I
doing
that
correctly
or
not
I'm
going
to
go
use
that
so
I
can
generate
automatically
new
schemas.
So
when
I'm
going
to
go
to
find
a
new
system,
I
don't
have
to
think
about
what
a
phone
number
is.
It's
already
been
given
to
me.
E
A
A
In
fact,
what
we
see
most
people
rally
around
is
saying:
give
the
centralized
data
governance
team,
more
powers
to
actually
define
good
and
reduce
the
grunt
work
that
they
have
to
do
in
going
in,
and
you
know
doing
clean
room,
curation
and
your
tagging
and
all
of
that
stuff
and
allow
that
to
get
automated
away
as
much
as
possible.
So
those
are
really
the
the
themes
that
we
are
exploring.
A
So
moving
along
one
of
the
things
that
we
also
talked
about
is
so
what
can
we
do
in
practice?
Right,
and
one
thing
we
can
think
about
is
what
are
the
interception
points
like
you've
got?
Data
data
is
constantly
changing.
So
what
are
interesting
interception
points
for
us
to
actually
inject
these
governance,
either
monitoring
capabilities
or
actually
enforcement
capabilities
right
you've
definitely
defined
good.
Now.
A
Are
you
going
to
watch
if
good
is
happening,
or
are
you
going
to
actually
make
good
happen
and
both
are
are
valid
approaches,
and
so
we
need
to
find
interception
points.
What
are
these
well?
We
already
talked
about
one
of
them
when
you're,
defining
your
schemas
and
interestingly,
these
schemas,
don't
necessarily
have
to
be.
You
know
your
data,
warehouse,
schemas
or
your
tables.
This
could
also
be
upstream
your
streaming
ecosystem.
They
could
also
be
a
service
api
definitions.
Those
are
great
points
to
actually
interject.
A
You
could
have
a
schema
linter,
that's
actually
integrated
with
your
build
system,
so
these
are
all
places
that
almost
at
check-in
time,
you're
able
to
stop
bad
things
from
happening.
But
then
you
also
have
run
time.
Interception
points
like
when
pipelines
are
running
when
they're
transforming
data,
they
can
actually
check
whether
the
quality
of
a
data
set
meets
their
expectations
before
actually
running,
and
these
are
starting
to
emerge.
A
lot
of
new
systems
are
starting
to
produce
these
kind
of
hooks.
These
kind
of
capabilities
where
you
can
have
circuit
breaking
capabilities
inside
your
pipelines.
A
A
A
G
Allowing
engineers
to
annotate
their
data
with
policy
relevant
information
without
being
experts
in
the
policy,
it's
something
that
I've
I've
found
to
be
pretty
important
and
something
that
we're
focusing
on
again
at
linkedin,
so
say
back
to
the
blog
post.
We
have
an
example
of
you
know:
a
person
type
where
a
person
has
a
name
has
an
email
address.
You
know,
maybe
has
some
other
things
like
you
know
a
profile
picture.
G
We
don't
want
engineers
to
have
to
be
familiar
enough
with
our
data
policies
that
they
can
say.
Okay,
this
field
needs
to
be
protected
in
this
way.
This
other
field
needs
to
be
protected
in
this
way.
In
this
context,
we
want
them
just
to
be
able
to
say
you
know
this
field
represents
an
email
address.
This
field
represents
the
user's
profile
picture
and
from
there
we
have
associations
between
semantic
terms
and
policies,
but
we
want.
We
want
to
make
things
as
simple
as
possible
for
the
engineer
where
they
can.
B
Thank
you,
george.
That
was
great.
What
I
would
say
is
what
josh
is
describing
sort
of
the
brass
tacks,
like
you
at
least
need
this
for
the
program
to
succeed.
What
I
would
say
is,
I
would
open
the
road
to
engineer,
saying:
they're,
fine,
we
don't
need
you
to
understand
necessarily
how
categorization
happens,
but
I
tell
them.
Usually.
B
Privacy
and
security
are
the
forcing
function
as
to
why
categorization
actually
happens,
basically
that
unless
you
make
make
people
realize
that
there
is
danger
to
not
doing
this,
it
typically
doesn't
get
done
unless
it's
existentially
important
for
the
business.
What
I
would
tell
people
is,
as
your
relationship
with
engineering
improves,
as
your
tools
become
used
even
more
and
more,
you
want
to
tell
people
hey
so
far.
B
This
speaks
just
to
privacy
and
security,
and
I
I
tell
my
engineers
I'm,
like
you
know,
I
don't
want
you
to
delete
more
data
than
you
have
to,
because
I
don't
want
lyft
and
doordash
to
have
an
advantage
over
us
right.
So
we
will
do
the
initial
categorization
based
on
privacy
security
needs,
but
then
you
should
come
in
and
take
a
look
at
the
data.
Just
as
an
example,
if
I
have
josh
at
gmail.com,
that's
josh
the
customer.
B
B
So
there
is
a
balance
between
overburdening
engineers
with
too
much
process
and
not
letting
them
have
a
voice
at
all,
find
that
place
in
the
middle,
and
I
think
the
comment
about
how
things
get
defined
differently.
Over
time
applies
here
as
well,
the
role
of
the
engineer
also
changes
definition
as
your
relationship
changes.
G
Yeah,
I'm
not
subject
to
roles.
Maybe
we
should
say
a
little
bit
about
expertise
again.
We
want
to
think
make
things
easy
for
the
engineers,
but
you
do
need
experts
in
policy
like
you
need
a
legal
team,
you
need
someone
who's
thinking,
deeply
about
relating
data
policies
to
regulations
like
gdpr
to
you
know
the
company's
privacy
policy
and
so
on.
You
also
need
ontologists
or
people
who
are,
you
know,
have
deep
expertise
in
schema
design,
but
you
don't
want
to
require
again
engineers
to
have
this
deep
expertise
themselves.
A
So
you
know
juan-
and
I
geeked
out
about
this
for
quite
a
bit.
So
I
think
this
deserves
a
slide.
We,
we
kind
of
have
this
notion
of
metadata
as
driving
tests.
So
you
know,
we've
talked
a
lot
about
this
definitional
notion
of
defined
good
and
we're
basically
riffing
on
the
metadata
graph
itself.
As
being
that
system
against
which
you
can
define
a
policy
as
a
test
and
remember
these
policies
obviously
can
be
higher
level
or
they
could
actually
be
lower
level.
A
You
you
get
the
full
spectrum
of
the
business
graph
as
well
as
the
technical
graph
against
which
you
can
write
these
tests,
and
then
we
could
actually
evaluate
these
tests
continuously,
almost
as
metrics.
So,
instead
of
your
business
kpis
that
you're
evaluating
these
are
almost
like
your
data
ecosystem,
kpis
and
then
in
the
cases
where
these
tests
are
so
important
that
you
really
want
them
to
never
fail.
A
You
almost
translate
them
into
constraints
or
policies
that
are
enforced
at
the
right
interception
points
and
one
of
the
concrete
examples
we
talked
about
and
josh
also
had
some
ideas
here
around.
Like
you
know,
we
can
rally
around
the
concept
of
these
tier
zero
data,
sets
and
say:
okay,
tier
zero
data
sets
have
to
maintain
some
goodness.
A
And
how
do
you
define
goodness?
Well,
it
must
have
a
certain
amount
of
ownership.
It
must
meet
certain
freshness
criteria.
It
must
have
a
certain
amount
of
vetted
compliance
metadata
and
then
you
take
that
test
and
you
integrate
it
with
your
ci
cd
systems
and
your
orchestration
systems,
and
that
can
lead
to
some
really
good
outcomes.
You're,
no
longer
kind
of
reacting
to
bad
things
happening
later
on,
but
you're
able
to
kind
of
take
your
definition
of
what
a
good
tier,
zero
data
set,
looks
like
and
then
pushing
it
down
into
the
infrastructure
juan.
E
So
so
this
goes
to
the
heart
of
what
we
mean
by
having
governance
as
code
right.
If
we
want
to
go
automate
things,
we
really
need
things
to
be
inside
the
computation.
We
may
put
it
as
code,
and
I
think
in
this
aspect
we
wanted
it
to
be
in
define
a
declarative
manner
right,
so
these
schemas
these
constraints,
these
contracts,
these
policies,
these
need
to
be
formally
defined
in
a
way
that
we
can
go
compute
on
them
and
there's
existing
standards
out
there
right.
E
I
know
josh
and
I
go
back
a
long
time
to
w3c
stuff
and
standard
in
the
semantic
web
like
there's
hole,
there's
d-cat
for
data
catalog
of
academies,
bravo
dublin
course
scots
for
vocabularies
and
then
there's
the
whole
rdf
owl
shackle
stack
and
all
these
things
like
these
are
already
languages
that
exist
to
be
able
to
go
and
represent
things
formally
now.
What
we
want
to
go
do
is
to
represent
these
policies
as
code
and
then
operationalize
on
that
right
use
them.
So.
E
E
So
it's
a
quick
example
like
the
pii
stuff
right,
so
we
we
know
what
sensitive
data
could
be
so
much
stuff
we're
going
to
define
that
pii
means
means
number
id
number
email
ip
address,
whatever
you
want
to
go
to
find
that
that
needs
to
be
written
down
somewhere
as
code,
and
then
there
may
be
another
policy
that
says:
if
you
identify
something,
that's
pii,
you
need
to
slap
on
whatever.
That
is
a
restricted
policy
and
that
can
have
whatever
implications
to
go.
Do
now.
E
E
I
know
that
this
I
should
slap
that
as
restricted
policy-
and
I
know
the
lineage
of
that-
and
this
thing
goes
all
the
way
to
all
these
dashboards.
All
those
things
imply
that
they
should
have
restricted
policy.
I
should
also
inform
the
stewards
of
the
owners
of
all
these
pipelines
of
all
these
dashboards
of
all
those
tables
that
that
this
just
identified.
That
should
be
all
that's.
That's
the
automation
I'm
going
to
go.
E
Do
all
this
is
possible
because
one
we've
represented
that
governance
policies
this
code,
and
then
we
can
query
that
metadata
altogether
and
and
and
it's
all
connected
in
a
graph,
so
at
the
end
just
think
about
it,
represent
the
metadata
and
the
graph.
The
policies
are
part
of
the
graph.
You
query
that
all
together
and
then
you
start
propagating
changes
and
send
your
notifications,
and
I
think.
A
A
E
F
Music
right,
so
I
mean
you
know,
I
think
automation
is
where
we
want
to
get
to
right.
We
want,
we
want
all
of
these
things
to
happen
automatically.
We
are
able
to
look
for,
let's
say
sensitive
data
or
take
the
appropriate
action
or
like
try
to
do
this
even
at
the
level
of
processes.
Right,
if
you
want
to
say
that
the
same
process
for
doing
transformations
on
the
data,
if
someone
else
in
our
company
is
doing
it,
you
ideally
would
not
want
to
replicate
that
right.
F
If
a
machine
learning
model
has
already
been
built,
I
should
be
able
to
find
it
and
reuse
it
somewhere
else,
there's
obviously
a
goal
that
we
all
strive
towards.
You
know
I
did
research
on
this.
I
think
a
lot
of
people
are
researching
on
this,
but
it
also
is
it's
a
really
hard
problem
to
solve,
especially
in
a
big
enterprise
right.
There's,
a
lot
of
teams
involved
a
lot
of
data,
a
lot
of
processes
that
are
involved,
and
so
what
I
see-
and
my
experience
has
mostly
been
from
the
privacy
side.
F
What
I
see
is
that
companies
have
trouble
even
answering
simplest
questions
today.
It's
like
what
data
sets
do
I
have
where
are
they
stored
right?
They
literally
start
from
that
point,
because
there
is
not
even
a
simple
asset
inventory
for
them
to
get
started
with.
So
in
most
in
many
of
these
cases,
so
I
think
of
automation
in
two
different
places.
There
is
obviously
the
real
automation
where
we
want
to
go
inside,
do
all
the
discovery
and
and
things
at
that
level,
but
it
also
just
process
automation
right
today.
F
We
need
some
processes
in
place.
These
might
be
in
in
privacy,
world,
the
privacy
impact
assessments
or
high
risk
assessments
right,
a
very
pressing
task
for
many
companies,
and-
and
there
is
a
lot
of
back
and
forth
involved
the
questionnaires
surveys.
Many
people
need
to
be
involved
and
these
processes
can
be
automated
today
are
not
fully
automated,
but
you
can
reduce
the
friction
in
them.
F
A
lot
right
and
simple
example,
for
instance,
is
product
teams
or
developers
like
to
work
in
a
tool
like
jira
right
or
some
equivalent
tool
like
that
oftentimes,
you
can
set
up
back
and
forth
between
the
governance
tool
and
a
tool
like
jira
fairly
easily.
We
have
a
lot
of
apis
all
over
the
place,
integration
platforms
to
help
you
with
that.
F
So,
for
instance,
you
can
make
it
so
that
the
product
teams
and
the
dev
engineers
they
live
in
jira,
but
the
privacy
team
lives
in
lives
in
their
own
tools,
right
and-
and
you
do
the
back
and
forth
between
them
and
that
helps
reduce
the
friction
a
lot
so
now,
instead
of
a
complicated
process
trying
to
figure
out.
Oh,
when
did
we
start
collecting
social
security
number
who
approved
it?
F
What
all
needs
to
be
changed
in
order
to
fix
it,
because
we
really
should
not
be
collecting
as
a
sense,
instead
of
doing
that
at
the
very
end,
we
can
do
it
at
the
very
beginning.
Right
the
moment.
Someone
says
that
I
have
to
add
a
new
feature
immediately.
I
have
to
confirm
that
hey
I've
gotten
this
approved.
I
have
these
reasons
for
doing
it
and
that
all
can
be
done
in
jira
today,
right,
it's
not
that
difficult.
We
have
set
it
up
for
some
of
our
customers.
We
can
do
that
in
jira.
F
A
And
as
long
as
you
also
have
a
little
bit
of
additional
monitoring
on
top
of
the
process
automation,
then
I
think
you've
got
a
pretty
good
solve
one
specific
thing
I
had
noticed
at
a
previous
employer
was,
you
know
we
had
a
very
good
intake
process
where
we
would
sit
down
and
kind
of
validate
that
the
data
that
the
engineering
team
is
saying,
they're
collecting,
is
actually
indeed
what
they're
going
to
collect.
They
would
fill
out
a
nice
little
form
saying
this
is
what
we're
doing.
A
We
would
kind
of
give
them
the
stamp
of
approval
and
then
the
feature
would
get
built
out.
But
then,
when
modifications
to
the
feature
happen
later
on
no
one's
kind
of
paying
attention,
and
so
there's
that
little
bit
of
the
you
did
all
the
good
work
at
the
gate.
But
then
this
continuous
evaluation
thing
becomes
a
challenge
and
then
it
leads
sometimes
to
like
the
need
for
periodic
backfills.
I
guess
or
periodic
reprocessing
of,
are
you
sure,
you're
still
doing
what
you
said
you
would
do
a
year
ago.
A
All
right,
so
we've
talked
we've
gone
all
the
way
from
you
know,
defining
data
governance,
talking
about
the
different
personas
talking
about
certain
techniques,
a
way
of
thinking
about
the
problem
and
a
lot
of
it
has
been
somewhat
limited
to
the
metadata
universe.
Like
we've
talked
about
catalogs
we've
talked
about
catalogs
and
we've
talked
about
catalogs
as
kind
of
this
unifying
thing.
But
you
know
the
catalogs
are
not
the
only
thing
this.
It's
the
modern
data
stack,
despite
all
our
attempts
to
simplify
it
continues
to
be.
A
I
mean,
probably
during
this
call
another
tool
got
built
to
move
some
data
from
something
to
something
or
or
to
transform
some
data
in
some
interesting
way
and
probably
also
got
funded
in
the
in
the
meantime
right,
and
so
this
modern
stack
is
going
to
continue
to
stay
ever
evolving
ever
innovating.
So
how
do
we
ever
get
a
handle
around
it
like?
A
What
is
the
role
of
these
different
tools,
these
different
platforms
in
actually
enabling
good
data
governance,
so
that
was
kind
of
our
our
last
thing
that
we
were
kind
of
wrapping
the
conversation
with
and
one
of
the
things
at
least
I
have
noticed
you
know.
Prior
to
this,
I
was
at
linkedin
where
everything
was
kind
of
very
bespoke.
I
mean
we
were
big
users
of
open
source
and
like
as
I've
stepped
out
and
kind
of
seen
what
companies
are
now
doing.
What
this
modern
data
stack
starts.
A
Looking
like
I'm
I'm
noticing
that
the
modern
data
warehouses
are
already
lifting
the
abstraction
from
yes,
I
can
do
you
know
joins
super
fast
to
actually
I'm
also
giving
you
capabilities
like
tag-based
retention
access
management.
You
know
you
talk
to
snowflake
bigquery,
like
all
the
big
ones
like
they're,
starting
to
move
up
that
cognition
hierarchy,
and
that
means
that
these
platforms
are
starting
to
participate.
A
As
enablers
of
this
policy
application
that
we're
talking
about
you
know,
you
define
good,
you
monitor
it,
but
then
you're
now
able
to
start
applying
policies
into
these
systems,
and
so
there's
an
emergent
possibility
of
standardization,
of
capabilities
for
data
management.
That
we
think
is
pretty
cool
platforms,
are
kind
of
supporting,
not
just
here's.
A
sql
interface
go,
have
fun,
but
actually
capabilities
on
top
of
it
that
are
more
oriented
around
data
management
that
can
collaborate
nicely
with
a
policy
enforcement
engine.
A
A
D
Thank
you.
Okay.
I've
been
taken
out
of
my
box
yeah,
so
I
I
think
it's
easy
to
get
lost
in
the
soup.
We
have
17
different
things
in
our
organization
and
we're
getting
an
18th
one
tomorrow,
and
it's
a
mess,
and
just
start
by
imagining
that
you
own
the
whole
stack
for
a
minute,
and
there
are
people
who
do
own.
The
whole
stack
snowflake
owns
a
stack.
Amazon
certainly
owns
the
whole
stack.
It's
a
gigantic
one.
Probably
too
diverse
google
cloud
might
be
a
smaller
edition
of
a
public
cloud
with
many
offerings.
D
If
you
own
the
whole
stack,
what
would
be
your
ideal?
So
how
would
people
specify
policy?
How
would
people
monitor
things
across
the
pieces
of
the
stack
and
then
how
would
you
incentivize
people
to
use
the
stack
wisely
through
metrics
and
so
on?
And
this
is
not
it's
not
impossible
and
and
as
a
starting
point,
it
gets
us
thinking
about
what's
hard
because
there's
so
many
things
that
are
hard,
that
we
can't
control.
D
So
particularly,
you
know
the
idea
that
at
different
layers
of
the
stack
you
want
different
notions
of
roles
and
identities
really
makes
it
hard
to
do
cross-cutting
data
governance.
You
know
a
simple
example
would
be
you
know.
I
want
to
track
every
access
into
storage
like
s3,
so
suppose
that
our
base
storage
layer
was
a
ledger.
It
recorded
all
rights
and
kept
all
versions,
and
it
recorded
all
reads
totally
reasonable
thing
to
propose.
D
F
So
you
know
I
have.
I
have
all
kinds
of
thoughts,
and
many
of
these,
I
think,
are
a
great
research
question,
some
that
I'm
working
on
right
now
on
how
you
you
know
fake,
or
how
do
you
improve
data
management
systems,
to
make
some
of
these
things
easier,
for
instance,
and
list
out
a
few
of
them
one?
I
think
the
relational
model
for
many
of
these
data
warehouses
can
be
a
little
too
low
level
for
many
users
right.
I
think
data
warehouses
could
work
towards
bringing
that
abstraction.
F
Only
when
they're
up
we've
been
very
happy
with
the
relational
model
for
52
years.
At
this
point,
but
at
some
point
I
think
the
number
of
elements
you
have
to
deal
with
the
complex
connections
between
them
just
starts
becoming
too
much,
and
I
think
that
hinders
good
governance,
because
someone
who
is
looking
at
a
database
without
significant
help
cannot
tell
what's
going
on
in
that
database
and
how
to
get
the
data
out
of
it
that
you
might
need
for
various
purposes.
F
Other
things
like,
for
instance,
databases.
Once
you
have
access
to
database,
you
can
do
whatever
you
want
with
it.
Within
that
access
limitations,
there
is
no
easy
way
to
keep
track
of
why
you
are
using
it
right.
A
simple
thing
that
many
databases
could
potentially
support
is.
If
you
are
asking
a
query
that
involves
a
lot
of
data,
you
might
be
asked
why,
right?
Why
do
you?
Why
are
you
running
this
query
against
the
production
database,
especially
if
it's
something
new
right,
I
think
adding
some
of
this
functionality.
F
One
of
the
other
projects
that
we're
working
on
is
is
how
do
you
separate
sensitive
data
from
non-sensitive
data
automatically
in
the
database
system
right
if
you're
able
to
do
that
transparently,
that
could
really
help
in
many
different
situations.
It
can
reduce
the
impact
of
breaches
and
and
generally
speaking,
make
more
privacy
related
issues
simpler
to
manage.
So
I
think,
there's
a
ton
of
things
that
data
warehouses
could
do,
but
most
important
of
those
for
me
is
to
raise
the
abstraction,
allow
more
semantics
to
be
added
to
the
data
that
is
being
stored
inside
them.
A
One
interesting
detour
we
took
around
this
idea
of
adding
more
to
the
abstraction
is
the
introduction
of
quality
metrics
into
the
api
itself.
So
when
you're
accessing
data,
you
have
a
sense
of
what's
the
quality
of
your
data
as
part
of
that
access,
api
itself
and
joe
brought
up
an
interesting
point.
Well,
views
are
support
supposed
to
solve
this
right,
and
I
guess
logically,
but
we
haven't
seen
a
lot
of
practical
usage
of
views
to
encapsulate
data
quality
in
a
way
that
it
just
works
right.
A
A
Cool
and
then
we
started
talking
about
also
the
citizenry,
that
tools
need
to
exhibit
beyond
just
moving
up
the
cognition
stack
and
supporting
a
bunch
of
these
additional
capabilities
than
what
they
have
before,
and
the
first
thing
that
you
know
juan
wanted
to
had
a
very
passionate
plea
on
is
just
this
emit
as
much
metadata
as
possible,
and
I
think
teresa
just
said
something
similar
on
the
market
as
well,
so
perfect
timing
to
go
for
it.
What.
E
E
What
would
be
great
as
teresa's
saying
is
that
let's
demand
that
they
expose
as
much
metadata
whatever
metadata
is
out
there,
and
then
we
will
have
our
our
metadata
layer,
our
data
catalog,
whatever
you
want
to
go,
call
that
it
is
the
job
of
the
data
metadata
layer
to
catalog
those
points,
those
catalog
those
dots,
that's
that
that
stuff
that
comes
from
those
systems,
one
and
then
actually
start
connecting
the
dots
from
all
those
systems.
Right,
oh
this.
E
This
thing
is
here:
this
relates
is
here:
it's
move,
you
get
the
lineage
and
all
that
stuff
right
so
and
then
part
of
the
dots
that
you're
collecting
stuff
is
is
the
policies
right,
the
schemas,
the
constraints?
The
contracts
like
this
is
also
should
be
part
of
that
code,
and
then
all
this
gets
connected
and
that's
why
I'm
so
passionate
that,
because
it
needs
to
get
connected,
it's
a
graph
and
then,
as
as
joe,
was
saying
very
wise
words.
I
love
this
about
how
automation
is
not
just
about.
E
A
A
A
There
are
companies
that
have
taken,
for
example,
re-dash
and
data
hub
and
then
added
capabilities
within
re-dash
to
just
pull
in
additional
metadata
from
the
data
hub
layer,
but
I
think
even
for
commercial
vendors,
it
would
be
very
cool
if
they
started
opening
up
some
of
those
apis
so
that
we
are
able
to
propagate
metadata
across
multiple
systems
into
the
tools
where
people
are
and
really.
This
is
what
kind
of
we
all
believe
in
this.
E
And
I
want
to
bring
up
something
I
know.
Josh
was
commenting
and
I
think
when
it
comes
to
the
exhaust
it's
like.
Yes,
you
can
go,
create
the
metadata
lake
or
whatever,
but
I
mean
I
would
argue
that
metadata
is
not
as
complicated
as
just
any
other
data
system
that
any
schema
that
anybody
created
right.
If
you
look
at
any
relational
database,
I
mean
jdbc
is
out
there
and
already
has
some
learning
standards
about
these
things.
Right
tables
columns
all
that
the
data
types
all
that
stuff
we
already
have.
E
There
are
existing
standards
already
for
metadata
right.
The
the
the
the
w3c
has
dcat
the
data
catalog
vocabulary,
there's
provenance
to
be
able
to
correct
to
track
lineage,
doubling
core
the
library
scientists
have
been
doing
this
for
how
many
decades
they've
been
doing
this
now,
like
all
this
stuff,
already
exists,
and
it
would
be,
I
think
it's
it's
a
call
on
the
the
the
the
data
tools
out
there
to
say,
go
if
you're
going
to
go,
emit
your
your
your
metadata.
E
G
Yeah,
that
was
something
like
I,
like.
I
said
in
the
the
pre-chat
that
impressed
me
about
data.world
that
we're
really
using
these
existing
standards
and
to
kind
of
echo
something
from
the
chat.
I
think
the
reason
that
it
makes
sense
to
use
standards
in
the
metadata
space
is
that
there
are
more
commonalities
for
the
metadata
than
there
are
for
the
actual
data,
which
is,
you
know
highly
domain
specific,
but,
like
you
say,
we
have
a
lot
of
common
concepts
around.
G
E
And
I
would
argue,
that's
why
we
are
not
just
optimistic
joe,
but
that's
actually
a
reality.
I
mean
if
we
think
about
it.
A
data
catalog
is
a
a
meta
data
integration
system
and
any
data
catalog
out
there
is
already
integrating.
I
mean
data
hub.
How
many
systems
do
you
collect
data
from
like
that's
equivalent
of
how
many
sources
of
data?
Do
you
integrate
right?
E
If
you
think
about
it
from
a
data
integration
perspective
as
well,
I
gotta
go
integrate
two
three
databases:
that's
a
million
dollars
in
two
years
of
work,
but
now
we're
very
quickly
being
able
to
go.
Integrate
metadata
comes
from
all
these
systems.
I
mean
I
can
tell
you
data.
world.
We
can
add
a
collector
in
if
it's
not
a
days,
it's
hours.
A
I
used
to
think
that
dashboards
were
a
thing
and
that
everyone
knew
what
a
dashboard
was,
and
then
I
got
involved
in
integrating
with
power,
bi
and
tableau
and
re-dash,
and
a
few
of
these
other
bi
tools,
and
I
realized
that
in
some
of
these
tools
these
are
reports
and
in
some
of
these
tools
these
are
worksheets
and
some
of
these
tools.
There
are
charts
that
are
inside
these,
and
in
some
of
these
there
are
tiles,
and
sometimes
the
tiles
are
reusable
and
sometimes
they're.
A
Not
so
it's
actually
so
we
can
all
agree
about
tables,
because
funnily
enough
tables
are
actually
pretty
standardized,
but
even
there
there
are
details.
If
you
integrate
with
salesforce,
it
actually
gives
you
a
field
level
last
modified
time
on
the
schema.
You'll,
never
get
it
from
any
other
kind
of
database.
A
D
I'm
not
gonna
do
that.
Actually
I
just
wanna
amplify
something
that
teresa
said.
I
think
I
liked
her
attitude
towards
this,
which
is
that
it's
an
iterative
process
and
gotta
get
started
somewhere.
I
think
that
does
unify
some
of
the
optimism
and
the
pessimism
here
there
are
things
you
can
get
started
on.
Tables
are
easy.
It
gets
harder.
D
The
minute
you
even
pop
above
that's
like
what's
a
data
set
every
every
product
I've
been
involved
with
had
a
different
semantics
for
what's
a
data
set
and
then,
when
you
start
talking
about
things
like
what's
a
person
and
what's
a
product-
and
you
know
we
all
know-
that's
super
hard,
but
you
can
get
started
somewhere.
Identity
is
a
required
thing
in
most
platforms
that
we
work
with.
So
you
starting
with
identity,
is
really
good,
really
good,
and
you
know
I
guess
teresa
your
point.
D
C
Yeah
exactly,
I
think,
that's
how
you
get
the
value.
I
think
there
are
a
lot
of
questions
about
that
right,
so
clearly
do
what
you
need
to
be
to
be
private
and
secure
and
compliant.
But
then
you
can,
you
know,
start
with
again
the
reports
that
are
really
important:
the
critical
finance
and
hr
data.
That
is
very
well
understood,
right,
like
in
some
ways
that
data
is
actually
easy.
It's
probably
relational
and
well
structured,
but
everybody
in
the
business
likely
needs
it
to
power
the
business.
A
C
Well,
and
at
the
end
of
the
day
that
business
user
is
the
best
to
be
able
to
describe
that,
none
of
us
are
hr
finance
experts.
We
talked
a
lot
about
engineering,
but
like
real
engineers,
I
mean
beyond
data
and
software
engineers
right.
So
if
your
business
is
not
like
uber
or
linkedin,
if
your
business
is
in
a
different
sort
of
field,
it
is
still
becoming
a
digital
and
data
driven
business.
C
That's
where
everybody's
pivoting
towards
and
so
that's
exciting,
because
there
will
be
investment
needed
to
make
your
product
a
smart
product
or
make
your
your
business
data
driven,
and
so
that's
where
we
are
going
to
get
funding
to
even
make
some
of
these
changes.
It's
not
going
to
be
a
cost
driven
model,
but
it'll
be
a
value-driven
model
to
make
people
be
able
to
see
the
same
thing.
E
E
There's
no
one
size
fits
all
around
this
stuff,
and
I
think
when
you
start
balancing
the
centralization
decentralization,
you
are
pushing
kind
of
the
work
down
to
the
domains
that
actually
understand
the
data
and
they're
incentivized
to
go
to
go
deal
with
it,
and
I
want
to
share
with
folks
how
to
this
framework
that
I'm
thinking
about,
I
call
it
the
abcs
of
data
products.
So
if
you
push
the
push
the
the
data
products
to
a
domain,
think
about
accountability,
who
is
responsible
for
this
who
fixes
it
when
it
breaks
boundaries?
E
What
is
this
data
product?
What
isn't
it
contracts
and
expectations?
What
are
you
expecting
around
this?
What
are
the
slas?
How
do
you
want
to
access
the
data?
What
do
you
expect
the
quality
to
go
be
for
this
particular
data
product
downstream
consumers,
who's
going
to
be
the
user
of
this?
Who
are
the
or
the
next
possible
users
and
explicit
knowledge?
What
does
this
actually
mean?
What
does
the
schema
will
define?
E
How
is
this
data
product
can
be
used
with
other
data
products
or
should
not
be
do
it
and
at
the
end
of
the
day,
this
is
all
connected.
It's
all
metadata
needs
to
be
connected,
and
that's
why
you
say
your
metadata:
it
should
be
a
metadata
knowledge
graph.
So
that's
the
point
I
want
to
drive
here
close
with.
D
How
can
I
make
it
visible
and
then
how
can
I
get
the
incentives
in
place
that
we
improve
this
stuff
that
we
can
see
and
then
iterating
on
that
and
if
you
just
start
with,
like
tracking
identity,
you're
already
well
on
your
way
to
actually
some
of
the
issues
around
gdpr
and
stuff
right,
so
so,
starting
with
with
very
narrow
things
and
iterating
is
the
only
way
you're
going
to
engineer
your
way
through
this
stuff.
And
of
course
you
want
tools
and
techniques
along
the
way.
D
F
Yeah
you
know
I
mean
first,
I
want
to
say
that
you
know
I
might
have
come
across
somewhat
negative
in
some
of
my
comments,
but
I'm
actually
a
big
optimist
in
terms
of
trying
to
figure
out
ways
to
solve
this,
and
I
think
there's
a
ton
of
things
for
us
to
do.
As
as
data
governance,
people
I
mean
there's
as
data
business,
people
and-
and
you
know
just
a
huge
number
of
problems
right.
I
think
some
of
the,
like
my
things,
is
more
about
cautioning.
F
I
think
it
kind
of
plays
off
what
george's
side
right,
like
figure
out
what
you
can
chip
away
at
and
and
learn
from,
what's
been
done
in
the
past
right
in
the
integration
world.
For
what
25
years
we
have
struggled
with
solving
even
simplest
of
semantic
problems
right
in
the
in
the
semantic
web
world.
F
The
optimism
was
there
from
the
beginning
right:
let's,
let's
define
everything
as
services,
let's
describe
it
and
then,
if
you
can
interoperate,
it
hasn't
really
worked
out
that
well
and-
and
I
think,
making
sure
that
we
learn
from
those
making
sure
we
understand
like
that,
what
we're
doing
is
actually
solvable.
I
think
that's
that's
the
key
takeaway
from
my
perspective
here.
G
Sure,
well,
plus
one
to
what
juan
said
about
approaching
data
governance
from
an
all
graph
point
of
view,
not
only
because
I'm
not
a
fan
of
knowledge
graphs,
but
I
think
they're
very
appropriate
at
this
domain,
but
yeah,
I
guess
the
the
main
closing
thought
for
me
is
that
there's
a
lot
of
duplicate
work
being
done
in
this
area.
You
know
by
you,
know
big
companies
like
linkedin
and
uber
and
google
and
so
on,
but
also
I
imagine,
by
small,
smaller
companies
as
well.
G
A
G
G
With
respect
to
policies
yeah,
the
the
specific
policies
are,
are
gonna,
be
very
you
know
much
tied
to
you,
know
specific
privacy
policies
of
different
companies,
regulations
that
apply
to
one
company
and
not
another,
but
again,
to
the
extent
that
we
can
share
the
overall
approach
that
we're
taking
to
say
modeling
policies,
creating
policy.
Catalogs
linking
you
know,
semantic
terms,
two
policy
catalogs.
G
A
B
Yeah,
so
I'm
going
to
use
an
example
that
josh
and
I
worked
on
when
he
was
at
uber.
Unfortunately,
we
got
it
going
after
he
left
so
josh.
This
was
an
example
of
you,
planting
the
seeds
and
me
getting
the
shade.
So
the
example
is
when
we
were
pushing
the
company
to
move
towards
categorization
of
data
on
the
shift
left
spectrum.
We
said
that
not
only
are
we
adding
some
privacy
related
metadata
to
it,
but
we
are
actually
creating
a
schema
where
none
existed.
B
You
don't
know,
for
example,
three
levels
deep
in
this
json
blob,
you
could
have
an
ip
address
that
was
collected
from
somebody's
device
pre-consent.
You
don't
know
that
because
there
is
no
way
to
find
that
data,
so
we
will
create
schema
versions
of
this
data
and
then
you
can
decide
whether
the
unstructured
data
makes
sense
for
you
or
you
need
to
have
the
schema
that
we
have
built.
B
If
we,
if
you
take
our
schema,
you
will
at
least
at
a
minimum,
know
what
these
fields
represent,
so
that
automation
means
we
get
validation
from
engineers,
and
we
can
then
right
at
that
point,
correlate
the
data
to
future
policies
downstream,
and
we
can
do
it
at
scale,
because
the
ai
model
keeps
learning
as
to
the
manual
approvers
of
this
schema
process.
So
the
the
example
here
is
that
as
much
as
you
automate
things
for
privacy,
cub
compliance
or
governance,
there
is
a
business
benefit
as
well.
B
This
dichotomy,
where
you
have
to
make
room
for
privacy
or
security
or
governance,
so
that
you
don't
as
a
result,
you
don't
get
to
do
your
day
job
as
much
as
a
false
choice.
You
have
to
make
the
case
that
getting
governance
right
and
getting
the
automation
done
at
scale
and
getting
more
accurate
over
time
is
a
business
benefit,
and
we
have
seen
anecdotally
that
the
quality
of
data
has
improved.
B
As
a
result,
more
data
has
gotten
deleted,
which
means
less
cost
to
encrypt
and
store
that
data,
and
we've
also
seen
the
number
of
times
queries
were
timing
out,
because
the
data
size
was
just
too
darn.
Big
has
gone
down
as
well
and,
as
a
result,
more
people
are
contributing
to
the
automation
because
they
see
the
benefit
downstream.
B
A
Thanks
for
that-
and
I
think
you
know-
for
the
practitioners
who
are
looking,
what
can
we
take
away
from
it?
Despite
all
of
the
higher
level
concerns
right,
you
have
to
bring
the
business
users
along.
You
have
to
include
incentives
in
your
processes
to
make
sure
that
people
are
actually
brought
in
for
the
ride,
from
an
engineering
perspective
and
from
how
do
we
navigate
the
complexity
of
multiple
different
tools
and
multiple
different
concerns.
A
We
feel,
like
a
reference
architecture,
is
definitely
emerging
for
a
control
plane
that
can
enable
some
of
this
capabilities.
So
a
couple
of
examples
that
we've
already
gone
through
is
you
know,
examples
of
shifting
left.
You
know
you've
got,
and
this
is
pulled
from
data
hub,
but
you
know
the
idea
is
just
you've
got
a
schema.
You
can
annotate
the
you
know
in
this
case.
It's
a
pro
above
schema,
but
you
know
pick
your
favorite
schema
definition
language.
A
You
can
add
in
the
business
terms
the
business
context,
the
classification
terms
right
at
check-in
time
and
those
then
automatically,
as
your
cicd
system,
builds
the
artifacts
and
pushes
it
to
production
emits
metadata
that
gets
integrated
into
the
metadata
layer
instantly.
So
it's
not
like
someone's
going
in
and
trawling
through
logs
and
figuring
out
what
happened,
but
it's
actually
part
of
your
software
development
stack
descriptions,
context
as
well
as
pii
tags
or
team
tags.
A
If
you
look
at
a
lot
of
concepts
that
we
talked
about
and
if
you
had
to
take
it
back
as
a
single
picture
of
how
do
I
think
about
the
modern
stack?
You've
got
all
your
systems
up
to
the
left.
You
know
your
snowflakes
and
sparks
and
airflows
and
looker
and
bigquery
and
great
expectations.
All
of
these
different
systems,
they're
continuously
producing
metadata,
and
so
we
talked
about
metadata
exhaust.
We
hopefully
think
of
it
as
metadata,
structured
metadata
events
and
not
just
craft.
A
A
You
can
have
a
policy
that
says
you
know.
The
operational
characteristics
of
this
thing
has
to
be
good
landing
times
have
to
be
7
a.m
or
before,
and
you
can
also
add
governance
characteristics
like
the
ownership
of
this
needs
to
include
at
least
one
stakeholder
and
need
to
include
at
least
one
business
user
and
things
like
that,
and
then
you
need
to
turn
these
tests
into
actions
right.
So
you
have
to
have
a
system
that
can
continuously
evaluate
these
predicates
against
the
continuously
changing
nature
of
your
underlying
graph.
A
And
then
you
go
to
your
platforms
and
say
now:
I'm
gonna
drive
good
and
I'm
gonna
make
good
happen.
So
you
can
say
things
like.
We
talked
about
things
like
setting
retention
policies,
setting
data
access
policies
being
able
to
push
a
data
health
score
into
a
looker
dashboard
being
able
to
break
a
pipeline
just
before
it
was
about
to
run
and
create
bad
data.
A
All
of
these
things
can
actually
start
to
get
enabled
if
we
start
snapping
towards
this
kind
of
a
reference
architecture,
the
exact
technology
used
for
each
of
these,
I
don't
care,
I
would
prefer
it
be
data
hub,
but
I
don't
care,
but
really.
What
is
more
important
is
that
we
all
agree
that
this
is
a
way
where
we
can
allow
tools
and
technologies
to
thrive
while
still
having
this
ability
to
centrally
say
what
does
good
look
like,
monitor
it
and
then
being
able
to
actually
enforce
it.
A
So
this
is
at
least
the
way
I
like
to
kind
of
capture
in
a
picture,
a
lot
of
our
thoughts,
a
lot
of
what
we
discussed
as
practitioners
as
thought
leaders,
and
we
have
a
few
minutes
left.
I
know
that
we've
had
a
lot
of
chatter
going
and
hopefully,
we've
been
able
to
address
all
of
it,
and
we
can
take
a
few
minutes
to
just
see
if
there
are
additional
questions
that
we
would
like
to
answer
and
then
we'll
close
it
out
and
see
you
all
on
the
internets.