Listen now | Recording of AURA - Chris Gambill & Shane Gibson 14th August 2026

WEBVTT
Kind: captions
Language: en
00:00:00.160 --> 00:00:02.629
Hey Chris, welcome to another Aura Ask
00:00:02.639 --> 00:00:04.950
Us Anything show and sorry for everybody
00:00:04.960 --> 00:00:06.950
for being late. We had a Substack
00:00:06.960 --> 00:00:09.030
technical difficulties, but we got there
00:00:09.040 --> 00:00:11.030
in the end. How you going? You've been
00:00:11.040 --> 00:00:12.870
back to backing today, haven't you?
00:00:12.880 --> 00:00:15.749
>> I I have been doing all the things today
00:00:15.759 --> 00:00:18.390
for sure. I uh just got off with Scott
00:00:18.400 --> 00:00:21.670
Haynes from Data Bricks uh doing uh we
00:00:21.680 --> 00:00:24.390
created like a like a synthesizer with
00:00:24.400 --> 00:00:26.630
Omni. It was super cool. like just vibe
00:00:26.640 --> 00:00:31.349
coded a uh a
00:00:31.359 --> 00:00:34.050
uh yeah like a synthesizer like a
00:00:34.060 --> 00:00:35.750
[snorts] just a software synthesizer. It
00:00:35.760 --> 00:00:36.630
was super cool.
00:00:36.640 --> 00:00:37.030
>> Oh wow.
00:00:37.040 --> 00:00:39.670
>> In 40 40 minutes from scratch prompt it
00:00:39.680 --> 00:00:41.590
and uh and it created it from scratch
00:00:41.600 --> 00:00:42.869
and it worked.
00:00:42.879 --> 00:00:44.869
>> That's one of those weird use cases for
00:00:44.879 --> 00:00:46.790
using a data platform for
00:00:46.800 --> 00:00:49.910
>> Yeah. [laughter]
00:00:49.920 --> 00:00:51.750
I won't ask how many butterflies were
00:00:51.760 --> 00:00:53.029
killed while you did that, but that's
00:00:53.039 --> 00:00:56.150
okay. [laughter]
00:00:56.160 --> 00:00:58.470
Excellent. Hey, uh I think two subjects
00:00:58.480 --> 00:01:00.630
for today unless people pop on and give
00:01:00.640 --> 00:01:03.349
us something else in the chat. Um so I
00:01:03.359 --> 00:01:06.149
think we got some questions. Hey Maddie,
00:01:06.159 --> 00:01:07.670
feel free to ask questions if you want
00:01:07.680 --> 00:01:09.750
and we'll talk about anything you want
00:01:09.760 --> 00:01:12.950
us to. uh but at the moment we had uh
00:01:12.960 --> 00:01:14.710
some comments earlier about the
00:01:14.720 --> 00:01:17.109
difference between uh context planes
00:01:17.119 --> 00:01:19.830
from a technology point of view and you
00:01:19.840 --> 00:01:22.630
know that kind of thing and then how to
00:01:22.640 --> 00:01:25.030
collect and gather context that would go
00:01:25.040 --> 00:01:27.109
into it. Uh so that's one and then I
00:01:27.119 --> 00:01:28.310
think you and I have been kind of
00:01:28.320 --> 00:01:31.190
talking or working on master data
00:01:31.200 --> 00:01:34.069
management golden record stuff. So uh we
00:01:34.079 --> 00:01:35.510
might as well talk about that as well.
00:01:35.520 --> 00:01:38.550
So which which puppy do you want first?
00:01:38.560 --> 00:01:40.550
that that that's just coincidental that
00:01:40.560 --> 00:01:42.870
we didn't even orchestrate that like
00:01:42.880 --> 00:01:44.789
that was just happened to both be
00:01:44.799 --> 00:01:47.990
working on it. Um I I mean we could jump
00:01:48.000 --> 00:01:52.149
into the MDM piece first and then
00:01:52.159 --> 00:01:53.190
>> try to go from there.
00:01:53.200 --> 00:01:54.789
>> Bring Bringing back memories, right? I
00:01:54.799 --> 00:01:56.149
mean it's been a while since I've done
00:01:56.159 --> 00:01:58.469
hardcore MDM like I thought it might
00:01:58.479 --> 00:01:59.990
have been dead, right? Master data
00:02:00.000 --> 00:02:03.109
management. Well, and that's funny like
00:02:03.119 --> 00:02:06.069
um like I saw that the other day and
00:02:06.079 --> 00:02:09.029
from my perspective like I think we
00:02:09.039 --> 00:02:10.790
didn't call it master data management
00:02:10.800 --> 00:02:14.470
for a while but like the concept was
00:02:14.480 --> 00:02:17.270
always there right people struggled with
00:02:17.280 --> 00:02:19.910
it we we just called it like unified
00:02:19.920 --> 00:02:22.150
customer we called it customer 360 or we
00:02:22.160 --> 00:02:23.670
called it something else but it's really
00:02:23.680 --> 00:02:28.070
all MDM right um in fact to even to that
00:02:28.080 --> 00:02:30.790
point like when I started my coaching
00:02:30.800 --> 00:02:33.990
program like my I have my people do
00:02:34.000 --> 00:02:36.710
three projects, right? Three custom
00:02:36.720 --> 00:02:38.630
portfolio projects and the last one I
00:02:38.640 --> 00:02:40.949
always make them do like MDM with
00:02:40.959 --> 00:02:43.430
deterministic matching and probabistic
00:02:43.440 --> 00:02:45.509
matching and and understanding what the
00:02:45.519 --> 00:02:48.150
differences are and benefits and cost of
00:02:48.160 --> 00:02:50.070
each one and like it it's such an
00:02:50.080 --> 00:02:53.190
important topic for businesses I think.
00:02:53.200 --> 00:02:55.430
>> Yeah. I remember I used to work for SAS
00:02:55.440 --> 00:02:57.190
the software vendor many many decades
00:02:57.200 --> 00:02:59.910
ago before I had gray hair and uh they
00:02:59.920 --> 00:03:01.750
had a subsidiary dataf flux that they
00:03:01.760 --> 00:03:03.509
bought which uh was quite a cool tool. I
00:03:03.519 --> 00:03:05.350
really really liked it and it stayed a
00:03:05.360 --> 00:03:07.350
separate company uh from SAS which is
00:03:07.360 --> 00:03:10.309
probably why I liked it. Um, and what
00:03:10.319 --> 00:03:12.149
was interesting was that was used a lot
00:03:12.159 --> 00:03:15.270
for data quality. Um, but also master
00:03:15.280 --> 00:03:18.070
data. Um, and so back then, you know,
00:03:18.080 --> 00:03:19.910
we're trying to I can't remember whether
00:03:19.920 --> 00:03:21.430
data flux was probabistic or
00:03:21.440 --> 00:03:23.670
deterministic. Um, but it was one of
00:03:23.680 --> 00:03:25.509
them. And so we had to explain the two
00:03:25.519 --> 00:03:27.830
differences uh, and then show them how
00:03:27.840 --> 00:03:29.830
it worked. Um, and it had the whole, you
00:03:29.840 --> 00:03:31.030
know, dictionary, all that kind of
00:03:31.040 --> 00:03:34.149
stuff. Um but yeah I don't know whether
00:03:34.159 --> 00:03:37.750
master data management as a term is so
00:03:37.760 --> 00:03:39.509
common now I mean when I talk to people
00:03:39.519 --> 00:03:41.750
about it uh they say they want single
00:03:41.760 --> 00:03:44.470
view right you know golden record and
00:03:44.480 --> 00:03:46.229
and the first thing I say to them is
00:03:46.239 --> 00:03:48.070
okay there's two flavors two patterns
00:03:48.080 --> 00:03:49.509
which would you like and the answer
00:03:49.519 --> 00:03:51.270
typically it's both but I ask them if
00:03:51.280 --> 00:03:54.229
they want a single list so if we have
00:03:54.239 --> 00:03:57.670
customer in you know CRM and in service
00:03:57.680 --> 00:04:01.030
and in finance uh so three sources that
00:04:01.040 --> 00:04:03.670
old customer records not keyed the same
00:04:03.680 --> 00:04:05.429
across the organization cuz hell they
00:04:05.439 --> 00:04:07.509
never will be. Um, and we want to bring
00:04:07.519 --> 00:04:08.710
those back and we want to say they're
00:04:08.720 --> 00:04:10.229
the same and have a single list of
00:04:10.239 --> 00:04:11.670
customers, right? That that's a whole
00:04:11.680 --> 00:04:13.589
bunch of patents we have to do. And then
00:04:13.599 --> 00:04:16.789
the second one is uh single view, which
00:04:16.799 --> 00:04:20.150
for me is saying I've got a customer uh
00:04:20.160 --> 00:04:22.069
and they've got transactions in lots of
00:04:22.079 --> 00:04:23.990
systems. So they got transactions in CRM
00:04:24.000 --> 00:04:26.310
and they got transactions in some
00:04:26.320 --> 00:04:28.070
service and in finance and I want to
00:04:28.080 --> 00:04:29.830
bring all those transactions all those
00:04:29.840 --> 00:04:33.110
events all that data into one place and
00:04:33.120 --> 00:04:35.510
be able to see it against that one
00:04:35.520 --> 00:04:37.590
record. Uh and so I don't know about you
00:04:37.600 --> 00:04:39.270
but I often find we have to do both
00:04:39.280 --> 00:04:41.510
right we have to go and take a bunch of
00:04:41.520 --> 00:04:43.749
concept records and match them and then
00:04:43.759 --> 00:04:45.350
we have to take a bunch of transactional
00:04:45.360 --> 00:04:47.270
event records and then combine them and
00:04:47.280 --> 00:04:49.030
store them against those concepts. Is
00:04:49.040 --> 00:04:50.870
that how you see it?
00:04:50.880 --> 00:04:54.150
>> Yeah. Well, and that kind of goes to the
00:04:54.160 --> 00:04:56.310
matching piece of MDM and then the
00:04:56.320 --> 00:04:58.469
survivorship piece and then it then
00:04:58.479 --> 00:04:59.670
you're you're layering in the
00:04:59.680 --> 00:05:02.390
transactional piece, right? It's so it
00:05:02.400 --> 00:05:04.710
which is how we get to facts and
00:05:04.720 --> 00:05:06.469
dimensions, right? I mean, that's
00:05:06.479 --> 00:05:08.390
>> how we get to hubs and links. Yeah,
00:05:08.400 --> 00:05:10.150
>> hubs and links. [laughter]
00:05:10.160 --> 00:05:11.990
We'll call them hubs and links and
00:05:12.000 --> 00:05:13.350
because it it definitely gets more
00:05:13.360 --> 00:05:16.469
complex with MDM for sure. Uh but yeah,
00:05:16.479 --> 00:05:19.350
like when I've worked with some like
00:05:19.360 --> 00:05:21.990
Fortune 500 companies, like to your
00:05:22.000 --> 00:05:24.629
point, they have they have HubSpot, they
00:05:24.639 --> 00:05:27.270
have Salesforce, they have the random
00:05:27.280 --> 00:05:28.790
marketing team that's going out to
00:05:28.800 --> 00:05:30.629
events and keeping things on paper and
00:05:30.639 --> 00:05:32.230
bringing them back and putting them in
00:05:32.240 --> 00:05:35.590
Excel and wanting them uploaded. Um and
00:05:35.600 --> 00:05:37.909
then they always have some ERP system,
00:05:37.919 --> 00:05:39.749
right? They have their, you know, their
00:05:39.759 --> 00:05:42.070
finance piece, so like a Netswuite or
00:05:42.080 --> 00:05:44.790
something. And every one of those like
00:05:44.800 --> 00:05:47.270
one company I worked with, every one of
00:05:47.280 --> 00:05:51.510
those had a different version of
00:05:51.520 --> 00:05:55.430
Tech Mahandra. Uh Mahindra, Techmahendra
00:05:55.440 --> 00:05:58.150
uh is a is a company that operates like
00:05:58.160 --> 00:06:02.469
globally and some in some systems it was
00:06:02.479 --> 00:06:04.950
Techmahendra Limited and in some systems
00:06:04.960 --> 00:06:07.029
it was just Techmahendra and in some
00:06:07.039 --> 00:06:10.629
systems it was like somebody abbreviated
00:06:10.639 --> 00:06:14.629
Mahindra to just Mahind and like cut off
00:06:14.639 --> 00:06:17.749
the last part of it. Um,
00:06:17.759 --> 00:06:19.830
and you get that, right? You get that
00:06:19.840 --> 00:06:23.110
whether that is um because there's
00:06:23.120 --> 00:06:25.350
multiple different systems or you get
00:06:25.360 --> 00:06:26.790
that, you know, the article that I put
00:06:26.800 --> 00:06:29.350
out this week was, you know, you know,
00:06:29.360 --> 00:06:31.270
if somebody put something in multiple
00:06:31.280 --> 00:06:33.110
times in a single system and maybe they
00:06:33.120 --> 00:06:35.430
misspell it, you know, 10 times and
00:06:35.440 --> 00:06:37.909
three times it was correct, which one of
00:06:37.919 --> 00:06:39.830
those records is the one that you want
00:06:39.840 --> 00:06:41.830
to survive?
00:06:41.840 --> 00:06:44.550
But this one company, the Fortune 500
00:06:44.560 --> 00:06:46.309
company that I was talking about, like
00:06:46.319 --> 00:06:48.309
they needed to be able to see, okay,
00:06:48.319 --> 00:06:50.790
this is the cost of acquisition. This is
00:06:50.800 --> 00:06:52.469
what we're actually making from that
00:06:52.479 --> 00:06:55.670
customer. These are residuals. This is
00:06:55.680 --> 00:06:57.510
these are where it ties back into
00:06:57.520 --> 00:07:01.110
different opportunities at a global
00:07:01.120 --> 00:07:03.990
level for that particular customer. Um,
00:07:04.000 --> 00:07:06.469
instead of at each of the individual,
00:07:06.479 --> 00:07:08.469
think of like Walmarts, right? Walmart
00:07:08.479 --> 00:07:10.390
has a ton of different stores and then
00:07:10.400 --> 00:07:13.350
they have a master account. Um, anyways,
00:07:13.360 --> 00:07:14.710
I talked a bunch. Yeah.
00:07:14.720 --> 00:07:16.390
>> Yeah. No, I mean I think we'll come back
00:07:16.400 --> 00:07:18.309
to that hierarchy of matching and then
00:07:18.319 --> 00:07:20.230
also the idea of what is a master and
00:07:20.240 --> 00:07:22.710
then the survivorship rules, right? Um,
00:07:22.720 --> 00:07:24.150
but we got a question from Maddie. So,
00:07:24.160 --> 00:07:25.510
what kind of reference tables would you
00:07:25.520 --> 00:07:27.510
implement in every single company you're
00:07:27.520 --> 00:07:29.589
working for? I'm interviewing for dees
00:07:29.599 --> 00:07:31.670
now and they are surprised when I even
00:07:31.680 --> 00:07:33.670
mention one calendar table for the whole
00:07:33.680 --> 00:07:35.270
team.
00:07:35.280 --> 00:07:38.230
There we go. So that's um calendar when
00:07:38.240 --> 00:07:39.670
you talk about a calendar table I
00:07:39.680 --> 00:07:41.670
automatically think uh dimensional
00:07:41.680 --> 00:07:43.510
modeling star schema
00:07:43.520 --> 00:07:45.990
>> because from you know we we have a
00:07:46.000 --> 00:07:47.990
calendar dim right and and we need to be
00:07:48.000 --> 00:07:50.710
able to create that uh funny enough if
00:07:50.720 --> 00:07:53.430
you use data vault we don't tend to hold
00:07:53.440 --> 00:07:56.150
uh calendars or dates as a concept we
00:07:56.160 --> 00:07:58.710
hold them as attributes as detail um so
00:07:58.720 --> 00:08:00.390
it's really interesting like yeah since
00:08:00.400 --> 00:08:02.950
I hear calendar toggle and I hear dim
00:08:02.960 --> 00:08:04.950
I'm like yep that's a that's a lookup
00:08:04.960 --> 00:08:07.110
Um, okay. But you go first. What do you
00:08:07.120 --> 00:08:09.510
reckon? Like what what types of
00:08:09.520 --> 00:08:11.510
reference tables can answer that many
00:08:11.520 --> 00:08:12.790
different ways. But yeah, let's have a
00:08:12.800 --> 00:08:14.390
go and then we'll get M to come back and
00:08:14.400 --> 00:08:15.909
see if that was actually the question he
00:08:15.919 --> 00:08:17.029
asked us.
00:08:17.039 --> 00:08:20.309
>> Yeah. No. Uh, so
00:08:20.319 --> 00:08:21.990
one one calendar table for the whole
00:08:22.000 --> 00:08:24.230
team, for the whole for a whole org,
00:08:24.240 --> 00:08:26.550
right, is
00:08:26.560 --> 00:08:28.629
can be okay. I think it depends on the
00:08:28.639 --> 00:08:31.749
org. So, um, I've had situations where
00:08:31.759 --> 00:08:34.310
I've had like a I would we'll stick with
00:08:34.320 --> 00:08:36.469
the kind of a date dimension type
00:08:36.479 --> 00:08:37.990
situation [gasps]
00:08:38.000 --> 00:08:39.909
where
00:08:39.919 --> 00:08:41.589
to your point like if you're in data
00:08:41.599 --> 00:08:44.790
vault like each
00:08:44.800 --> 00:08:46.949
domain, each kind of vault is going to
00:08:46.959 --> 00:08:49.509
have its own attribute for what that
00:08:49.519 --> 00:08:52.870
date looks like, right? Um, because you
00:08:52.880 --> 00:08:54.870
because you have these concepts of
00:08:54.880 --> 00:08:58.710
calendar year or fiscal year, right? or
00:08:58.720 --> 00:09:01.509
uh it which throws everything else off.
00:09:01.519 --> 00:09:03.509
And being able to track things by
00:09:03.519 --> 00:09:08.870
quarter, by week, by month, by day. Um
00:09:08.880 --> 00:09:11.269
and how how granular do you need to get
00:09:11.279 --> 00:09:15.110
there. Um I went way down a different
00:09:15.120 --> 00:09:16.550
rabbit hole for a second, so I need to
00:09:16.560 --> 00:09:18.949
come back out, but you
00:09:18.959 --> 00:09:21.350
>> I did. So kind of reference.
00:09:21.360 --> 00:09:22.870
>> Well, hold on. So, so let's just take
00:09:22.880 --> 00:09:27.269
that one. So in the past I would uh when
00:09:27.279 --> 00:09:29.350
I was dimensionally modeling right uh I
00:09:29.360 --> 00:09:31.110
would would hold a reference table which
00:09:31.120 --> 00:09:33.670
had my calendars and I'd say I' I'd tag
00:09:33.680 --> 00:09:35.829
each of the dates you know with those
00:09:35.839 --> 00:09:40.710
date parts um fiscal calendar calendar
00:09:40.720 --> 00:09:43.509
you know uh calendar calendar um public
00:09:43.519 --> 00:09:46.870
holidays day of the week right uh but
00:09:46.880 --> 00:09:49.509
what we actually do now uh in BigQuery
00:09:49.519 --> 00:09:51.829
is we just treat that as calculated
00:09:51.839 --> 00:09:54.550
attributes because I can well well for
00:09:54.560 --> 00:09:56.550
the months, weeks, years and day of the
00:09:56.560 --> 00:09:58.070
week and that because I can basically
00:09:58.080 --> 00:10:00.470
create a calculated column that just
00:10:00.480 --> 00:10:01.829
looks at the date and gives me back
00:10:01.839 --> 00:10:03.670
those those values whenever I need it.
00:10:03.680 --> 00:10:06.070
So we don't do the lookups um from
00:10:06.080 --> 00:10:08.550
there. Now if we were doing uh event
00:10:08.560 --> 00:10:12.710
dates yeah so specific you know uh
00:10:12.720 --> 00:10:14.630
retail holidays and those kind of things
00:10:14.640 --> 00:10:17.350
where the big query functions uh by
00:10:17.360 --> 00:10:19.910
default don't do it. we may use a
00:10:19.920 --> 00:10:23.110
reference table and do a matching but we
00:10:23.120 --> 00:10:25.350
may actually create that as a function
00:10:25.360 --> 00:10:28.470
that we can call uh that then calculates
00:10:28.480 --> 00:10:31.030
it right so there a little bit more um
00:10:31.040 --> 00:10:32.949
uh kind of difference when we kind of
00:10:32.959 --> 00:10:35.430
look at that one so uh yeah so I suppose
00:10:35.440 --> 00:10:37.190
the key is if you're interviewing
00:10:37.200 --> 00:10:40.550
somebody um and they say hey they have
00:10:40.560 --> 00:10:43.110
an alternative way of dealing with dates
00:10:43.120 --> 00:10:45.110
then that's okay if they're like what's
00:10:45.120 --> 00:10:46.949
a reference table then uh
00:10:46.959 --> 00:10:48.790
>> then that's a problem Well, [laughter]
00:10:48.800 --> 00:10:50.949
yeah, as long as you're hiring a junior
00:10:50.959 --> 00:10:52.389
uh and you've got good training, then
00:10:52.399 --> 00:10:53.829
you're okay. All right, you you carry on
00:10:53.839 --> 00:10:54.949
where you were going with that because I
00:10:54.959 --> 00:10:55.910
got some other things around reference
00:10:55.920 --> 00:10:57.910
tables I want to jump in afterwards.
00:10:57.920 --> 00:11:03.030
>> And to be fair, I Matty's uh I talk to
00:11:03.040 --> 00:11:06.069
Mattie every week and so I know that
00:11:06.079 --> 00:11:08.710
he's hiring for seniors. So, yeah,
00:11:08.720 --> 00:11:10.069
that's that's my
00:11:10.079 --> 00:11:11.509
>> I have a little bit more context there.
00:11:11.519 --> 00:11:17.670
But um but yeah, that was
00:11:17.680 --> 00:11:18.150
>> uh
00:11:18.160 --> 00:11:19.829
>> I would agree. Oh, I was I remember
00:11:19.839 --> 00:11:22.710
where my train was going. Um
00:11:22.720 --> 00:11:24.389
like right now from a data bricks
00:11:24.399 --> 00:11:26.710
perspective, we we want you know when
00:11:26.720 --> 00:11:28.630
you we're talking your favorite your
00:11:28.640 --> 00:11:30.310
favorite topic medallion architecture.
00:11:30.320 --> 00:11:31.750
>> Oh, it's not an architecture, it's a
00:11:31.760 --> 00:11:33.990
classification system. [laughter]
00:11:34.000 --> 00:11:36.870
>> Um you know in in the gold layer a lot
00:11:36.880 --> 00:11:38.389
of times we're doing star schema type
00:11:38.399 --> 00:11:42.550
stuff, right? And so we have a calendar
00:11:42.560 --> 00:11:45.509
dimension and that has all of those
00:11:45.519 --> 00:11:48.790
different columns um a single calendar
00:11:48.800 --> 00:11:50.230
dimension that we're using across the
00:11:50.240 --> 00:11:55.030
org, right? Um, and what we do is often
00:11:55.040 --> 00:11:57.670
tag each of those columns with a
00:11:57.680 --> 00:12:00.870
specific tag so that somebody from sales
00:12:00.880 --> 00:12:04.150
doesn't necessarily need or want all the
00:12:04.160 --> 00:12:06.550
noise from all the financial columns
00:12:06.560 --> 00:12:10.069
that are needed for uh for that calendar
00:12:10.079 --> 00:12:13.030
dimension. Um, that way we could govern
00:12:13.040 --> 00:12:16.389
it. However, with metric views coming
00:12:16.399 --> 00:12:18.470
out
00:12:18.480 --> 00:12:20.310
in my head, what I've started to
00:12:20.320 --> 00:12:22.629
consider and think about is, do we still
00:12:22.639 --> 00:12:25.269
need that or can that be a metric view
00:12:25.279 --> 00:12:29.030
that we're setting up and then similar
00:12:29.040 --> 00:12:30.710
to, you know, functions or something?
00:12:30.720 --> 00:12:32.710
It's actually calculating [snorts] it on
00:12:32.720 --> 00:12:35.509
the fly when the report's being run.
00:12:35.519 --> 00:12:37.269
>> Yeah. And then you've got a couple of
00:12:37.279 --> 00:12:38.629
challenges there as well, right? So,
00:12:38.639 --> 00:12:40.790
first thing is cost. Yeah. Is it cheaper
00:12:40.800 --> 00:12:44.230
to join and store uh or query across
00:12:44.240 --> 00:12:45.829
joins than it is to calculate on the
00:12:45.839 --> 00:12:47.990
fly? Um so that's that's one thing I'd
00:12:48.000 --> 00:12:52.310
look at uh change. So if [clears throat]
00:12:52.320 --> 00:12:56.069
those reference tables are uh temporal,
00:12:56.079 --> 00:12:57.430
if you actually have to be able to
00:12:57.440 --> 00:13:00.550
change the the the data itself and you
00:13:00.560 --> 00:13:02.629
need to be able to track those changes,
00:13:02.639 --> 00:13:04.310
uh you pretty much don't want to do that
00:13:04.320 --> 00:13:05.990
as a function because now the function's
00:13:06.000 --> 00:13:07.430
going to have a massive amount of if
00:13:07.440 --> 00:13:08.870
statements in it, right? And so you want
00:13:08.880 --> 00:13:11.670
to bring that back to data. So one thing
00:13:11.680 --> 00:13:13.750
we tend to do is we we bring the
00:13:13.760 --> 00:13:15.670
reference tables in into our history
00:13:15.680 --> 00:13:18.150
layer into our our um immutable
00:13:18.160 --> 00:13:20.470
persistent storage. Uh and we treat them
00:13:20.480 --> 00:13:22.710
like any other data. So we actually um
00:13:22.720 --> 00:13:24.710
effective date each record. We then
00:13:24.720 --> 00:13:26.310
track changes over it because that
00:13:26.320 --> 00:13:28.550
pattern just makes it easy for us going
00:13:28.560 --> 00:13:31.509
forward. um we tend to apply those
00:13:31.519 --> 00:13:33.430
reference tables in our designed layer
00:13:33.440 --> 00:13:36.230
if we can, but sometimes we will
00:13:36.240 --> 00:13:38.470
actually only uh combine them in the
00:13:38.480 --> 00:13:42.550
consume layer um depending on uh how
00:13:42.560 --> 00:13:44.949
late we want to bind those changes like
00:13:44.959 --> 00:13:46.949
how often and will people restate. So
00:13:46.959 --> 00:13:49.030
sometimes you know we have ones where we
00:13:49.040 --> 00:13:51.110
have a bunch of codes and there's a
00:13:51.120 --> 00:13:53.509
bunch of descriptions um and we got one
00:13:53.519 --> 00:13:56.150
of those at the moment and we know that
00:13:56.160 --> 00:13:59.110
those descriptions will change
00:13:59.120 --> 00:14:01.829
as people improve the quality of them.
00:14:01.839 --> 00:14:03.670
And so we'll late bind those reference
00:14:03.680 --> 00:14:04.870
tables. We'll bring them right to the
00:14:04.880 --> 00:14:07.030
end of the consume, join them there, and
00:14:07.040 --> 00:14:09.030
therefore one change restates over all
00:14:09.040 --> 00:14:10.949
time. And that that's okay. There's some
00:14:10.959 --> 00:14:12.470
other ones where we go, no, actually
00:14:12.480 --> 00:14:13.829
it's the point in time that that
00:14:13.839 --> 00:14:15.990
reference data was created or effective
00:14:16.000 --> 00:14:17.750
for that's really important. So then we
00:14:17.760 --> 00:14:19.509
in our designed layer, we'll put it in
00:14:19.519 --> 00:14:20.470
there because now we're actually
00:14:20.480 --> 00:14:23.430
matching up the the history stuff. Um
00:14:23.440 --> 00:14:24.870
and then the question again
00:14:24.880 --> 00:14:26.949
architecturally you you've got to place
00:14:26.959 --> 00:14:30.150
these principles down as as principles
00:14:30.160 --> 00:14:33.030
or patterns that people can use. uh
00:14:33.040 --> 00:14:35.990
because I often use it like for MDM I
00:14:36.000 --> 00:14:37.670
often use it for matching you know this
00:14:37.680 --> 00:14:39.189
equals that right so I don't have to
00:14:39.199 --> 00:14:40.949
write a big freaking case statement
00:14:40.959 --> 00:14:42.550
somewhere right I'm like no no just give
00:14:42.560 --> 00:14:44.069
a reference table where I can maintain
00:14:44.079 --> 00:14:45.990
those relationships uh because they
00:14:46.000 --> 00:14:47.350
don't exist anywhere else right that's
00:14:47.360 --> 00:14:49.670
the key is that data uh we often use
00:14:49.680 --> 00:14:51.430
Google sheets as a way for people to
00:14:51.440 --> 00:14:53.910
maintain their reference data because we
00:14:53.920 --> 00:14:56.069
can expose that to big query without
00:14:56.079 --> 00:14:57.750
having to bring the data in if that
00:14:57.760 --> 00:15:00.150
makes sense um so they kind of become
00:15:00.160 --> 00:15:02.790
external tables so Yeah, when you talk
00:15:02.800 --> 00:15:04.550
about reference data, right, you start
00:15:04.560 --> 00:15:06.150
going down massive rabbit holes,
00:15:06.160 --> 00:15:07.750
especially architecturally and platform
00:15:07.760 --> 00:15:09.269
wise.
00:15:09.279 --> 00:15:11.350
>> Yeah. And you hit on a key point there,
00:15:11.360 --> 00:15:13.829
too. I think like I'm a big fan of
00:15:13.839 --> 00:15:16.150
tabled driven architecture, right, where
00:15:16.160 --> 00:15:18.470
you're storing things in a table as
00:15:18.480 --> 00:15:22.389
opposed to storing them in code. Um,
00:15:22.399 --> 00:15:24.230
it's just
00:15:24.240 --> 00:15:26.150
architecturally
00:15:26.160 --> 00:15:27.910
I feel like it's more business friendly
00:15:27.920 --> 00:15:30.470
too, right? It's just especially when
00:15:30.480 --> 00:15:33.269
you're even outside of calendars and
00:15:33.279 --> 00:15:37.590
dates like um KPIs and metrics, right?
00:15:37.600 --> 00:15:40.790
Calculations for KPIs and metrics
00:15:40.800 --> 00:15:42.870
are always in flux. Those are things
00:15:42.880 --> 00:15:45.430
that are living and you need to be able
00:15:45.440 --> 00:15:47.829
to track them to your point over time,
00:15:47.839 --> 00:15:50.790
right? Of okay, this it was this metric
00:15:50.800 --> 00:15:53.430
was this between this date and this date
00:15:53.440 --> 00:15:56.230
or this KPI was this between this date
00:15:56.240 --> 00:15:59.110
and this date. And um
00:15:59.120 --> 00:16:02.069
yeah, I've even built tools where we
00:16:02.079 --> 00:16:05.110
layer in a uh an interface for the
00:16:05.120 --> 00:16:07.269
business so that they could add and
00:16:07.279 --> 00:16:10.870
adjust KPIs as they need them. Um, that
00:16:10.880 --> 00:16:13.030
way it's not a full software development
00:16:13.040 --> 00:16:14.790
life cycle. That way the data team
00:16:14.800 --> 00:16:17.269
doesn't get blamed for being the
00:16:17.279 --> 00:16:20.150
bottleneck in the process of creating an
00:16:20.160 --> 00:16:23.030
KPI that the business wants to track.
00:16:23.040 --> 00:16:26.150
Um, yeah, it's it's interesting as I'm
00:16:26.160 --> 00:16:27.670
so we're doing some work on the metric
00:16:27.680 --> 00:16:29.670
stuff at the moment. So today I was just
00:16:29.680 --> 00:16:32.550
doing a mixing experiment with um Google
00:16:32.560 --> 00:16:34.550
BigQuery graph and their well they call
00:16:34.560 --> 00:16:36.230
me metrics. I call them measures because
00:16:36.240 --> 00:16:38.069
it can only do sums and averages. I
00:16:38.079 --> 00:16:40.230
can't actually do any complex
00:16:40.240 --> 00:16:42.069
calculations yet. Fingers crossed it
00:16:42.079 --> 00:16:44.870
will. Um, and it kind of reminded me
00:16:44.880 --> 00:16:47.189
that every time I'm using Claude to help
00:16:47.199 --> 00:16:50.550
me do some work, it is constantly
00:16:50.560 --> 00:16:53.910
writing the metric in SQL itself. Yeah.
00:16:53.920 --> 00:16:55.189
And I'm just I'm I'm creating this
00:16:55.199 --> 00:16:57.509
reinforcement process for it to say, no,
00:16:57.519 --> 00:17:00.230
the metric is stored in context. Uh, you
00:17:00.240 --> 00:17:02.310
need to go and see it and read it. And
00:17:02.320 --> 00:17:04.390
then I don't care if you write the SQL
00:17:04.400 --> 00:17:07.429
to execute it. Um, but actually you
00:17:07.439 --> 00:17:09.829
can't make the the thing up, right? I
00:17:09.839 --> 00:17:12.870
don't keep recreating it and and it's
00:17:12.880 --> 00:17:14.470
when it does it, it kind of makes it the
00:17:14.480 --> 00:17:16.309
same, but it it's not looking at the
00:17:16.319 --> 00:17:18.831
master of my metrics and I'm they're
00:17:18.841 --> 00:17:20.870
[laughter] over there, right? I don't
00:17:20.880 --> 00:17:22.230
care who executes it because that's
00:17:22.240 --> 00:17:24.309
cattle, but I certainly give a
00:17:24.319 --> 00:17:27.270
about who who masters it. Yeah,
00:17:27.280 --> 00:17:30.710
>> it right. It Yeah, 100%. And to the
00:17:30.720 --> 00:17:32.870
point of like the history tracking being
00:17:32.880 --> 00:17:35.510
having that when we do implement like
00:17:35.520 --> 00:17:38.710
that front end for the business tracking
00:17:38.720 --> 00:17:40.710
who changed it, right? And making sure
00:17:40.720 --> 00:17:43.190
that it's governed as far as who's
00:17:43.200 --> 00:17:45.029
allowed to change it. But uh but yeah,
00:17:45.039 --> 00:17:46.710
we because we care about who changes
00:17:46.720 --> 00:17:50.789
those things, right? And because because
00:17:50.799 --> 00:17:52.549
sure as heck if something comes goes
00:17:52.559 --> 00:17:54.630
wrong, right,
00:17:54.640 --> 00:17:56.789
the VP or whatever that's looking at
00:17:56.799 --> 00:17:59.110
that report's not going to their sales
00:17:59.120 --> 00:18:00.950
manager or whatever that changed the
00:18:00.960 --> 00:18:03.750
KPI. They're coming to the data team to
00:18:03.760 --> 00:18:05.990
ask questions about, hey, why is this
00:18:06.000 --> 00:18:07.590
why did this change or why is this
00:18:07.600 --> 00:18:09.830
wrong? And and if we think about that, I
00:18:09.840 --> 00:18:11.669
mean, because I I I do laugh when people
00:18:11.679 --> 00:18:13.909
say that AI will replace data engineers
00:18:13.919 --> 00:18:16.549
straight away. And then we see those,
00:18:16.559 --> 00:18:18.630
you know, those sexy demos where, you
00:18:18.640 --> 00:18:19.990
know, they ask a natural language
00:18:20.000 --> 00:18:21.510
question of how many customers I got and
00:18:21.520 --> 00:18:23.990
it works. And then you sit there and you
00:18:24.000 --> 00:18:25.990
go, so hold on, let's just put all these
00:18:26.000 --> 00:18:27.430
Lego blocks we just talked about
00:18:27.440 --> 00:18:30.230
together. So I have customer in three
00:18:30.240 --> 00:18:31.750
systems and I need to bring it in and
00:18:31.760 --> 00:18:33.270
give me a single list of customer by
00:18:33.280 --> 00:18:34.789
doing some matching to say those
00:18:34.799 --> 00:18:36.950
customer records are the same. And then
00:18:36.960 --> 00:18:38.710
I got to get transactions from all those
00:18:38.720 --> 00:18:40.470
other systems and then combine it. So I
00:18:40.480 --> 00:18:41.909
have a single view of everything that we
00:18:41.919 --> 00:18:43.990
did with that customer.
00:18:44.000 --> 00:18:45.830
Uh some of that data might be driven by
00:18:45.840 --> 00:18:47.990
reference tables, right? So we have this
00:18:48.000 --> 00:18:50.310
set of manually maintained tables
00:18:50.320 --> 00:18:52.070
outside those systems that are saying
00:18:52.080 --> 00:18:53.909
this is this or this is these dates or
00:18:53.919 --> 00:18:56.070
the series of flags and they change over
00:18:56.080 --> 00:18:58.630
time. So we know that you know a month
00:18:58.640 --> 00:19:01.190
ago this was the rule and uh this month
00:19:01.200 --> 00:19:04.630
this is the rule. We change our ETL code
00:19:04.640 --> 00:19:06.470
uh over time, right? Right. So we have
00:19:06.480 --> 00:19:09.830
these version sets of of ETL. Our data
00:19:09.840 --> 00:19:11.510
changes over time. So the data we're
00:19:11.520 --> 00:19:12.789
collecting in from all those source
00:19:12.799 --> 00:19:14.630
systems is temporal and it has effective
00:19:14.640 --> 00:19:16.950
dates and change records. Our business
00:19:16.960 --> 00:19:20.390
logic that we use in our ETL uh is may
00:19:20.400 --> 00:19:21.270
change. [clears throat]
00:19:21.280 --> 00:19:23.590
>> Uh and then our metric definitions will
00:19:23.600 --> 00:19:26.150
change. Now if you think about all those
00:19:26.160 --> 00:19:28.390
Lego blocks, all those potential changes
00:19:28.400 --> 00:19:30.950
to one record that can affect the number
00:19:30.960 --> 00:19:33.830
the VP gets, that's highly complex,
00:19:33.840 --> 00:19:35.029
right? And so it's kind of interesting
00:19:35.039 --> 00:19:37.430
to see whether the Genai tools will be
00:19:37.440 --> 00:19:39.669
able to deal with that complexity better
00:19:39.679 --> 00:19:40.950
than us.
00:19:40.960 --> 00:19:45.270
>> Yeah. Hey. Well, yeah. I I sat through a
00:19:45.280 --> 00:19:47.669
demo yesterday of [clears throat] metric
00:19:47.679 --> 00:19:51.590
views and omnient not omni of ontology,
00:19:51.600 --> 00:19:55.590
data bricks ontology and um and just
00:19:55.600 --> 00:19:57.350
layering the two together and and to
00:19:57.360 --> 00:19:59.830
your point of things being just SQL,
00:19:59.840 --> 00:20:02.230
right? Like they're
00:20:02.240 --> 00:20:05.669
um the metric views there are just SQL.
00:20:05.679 --> 00:20:08.150
If you could do the calculation in SQL,
00:20:08.160 --> 00:20:10.549
then you could create the that metric
00:20:10.559 --> 00:20:12.470
for it, which will be which will be
00:20:12.480 --> 00:20:15.909
cool. Um, and
00:20:15.919 --> 00:20:18.549
having enough context
00:20:18.559 --> 00:20:23.190
to put into your ontology layer. Um, and
00:20:23.200 --> 00:20:27.510
for it to be groomed in a way that
00:20:27.520 --> 00:20:33.190
when that COO or CDO or you know your
00:20:33.200 --> 00:20:36.230
CSO or whoever goes out and asks a plain
00:20:36.240 --> 00:20:37.830
text question that they're going to get
00:20:37.840 --> 00:20:41.350
a correct consistent answer for what
00:20:41.360 --> 00:20:44.149
they're asking. That all plays a role,
00:20:44.159 --> 00:20:48.310
right? having those different layers um
00:20:48.320 --> 00:20:50.870
within within your system that work
00:20:50.880 --> 00:20:54.230
together like that's going to be huge in
00:20:54.240 --> 00:20:56.950
the future. But it none of that replaces
00:20:56.960 --> 00:21:02.149
data engineering, right? None of that
00:21:02.159 --> 00:21:03.909
it evolves data engineering but none of
00:21:03.919 --> 00:21:06.149
it replaces data engineering.
00:21:06.159 --> 00:21:07.190
>> Yeah, I mean I think it should
00:21:07.200 --> 00:21:10.470
accelerate us or assist us. um you know
00:21:10.480 --> 00:21:11.909
we'll we'll see what happens when we get
00:21:11.919 --> 00:21:14.950
to automated AI and whether that works
00:21:14.960 --> 00:21:17.270
um but again if we talk about that
00:21:17.280 --> 00:21:20.310
context where do we find it you so one
00:21:20.320 --> 00:21:21.990
of the things that we've been quite
00:21:22.000 --> 00:21:24.710
lucky is because
00:21:24.720 --> 00:21:26.710
I've been building our way of working
00:21:26.720 --> 00:21:30.870
and teaching and coaching it as well um
00:21:30.880 --> 00:21:33.510
I have a lot of material that I've used
00:21:33.520 --> 00:21:35.750
to coach teams to do things the way we
00:21:35.760 --> 00:21:39.110
do them technically or or um in terms
00:21:39.120 --> 00:21:41.669
team design and and our value stream,
00:21:41.679 --> 00:21:43.990
the way we kind of daisy chain the work
00:21:44.000 --> 00:21:47.270
and our factory. And so what I found is
00:21:47.280 --> 00:21:49.909
um when I'm building out the context of
00:21:49.919 --> 00:21:52.470
how we work, I have this content that I
00:21:52.480 --> 00:21:55.510
can feed it. Um
00:21:55.520 --> 00:21:57.110
but I've still got to then go and
00:21:57.120 --> 00:21:58.470
actually refine it.
00:21:58.480 --> 00:22:02.149
>> Yeah. like it. So, one of the things is
00:22:02.159 --> 00:22:05.190
Nigel did a little bit of uh the context
00:22:05.200 --> 00:22:08.870
guides and somehow it brought up the
00:22:08.880 --> 00:22:11.990
SED2 word and then it just started
00:22:12.000 --> 00:22:14.549
seeding it everywhere and then it kept
00:22:14.559 --> 00:22:17.110
going I can't find any facts and I'm
00:22:17.120 --> 00:22:17.830
like because [clears throat] we don't
00:22:17.840 --> 00:22:20.149
run a dimensional model you dumbass. And
00:22:20.159 --> 00:22:21.909
then it took me a while to go, ah,
00:22:21.919 --> 00:22:23.110
that's where you're getting it from.
00:22:23.120 --> 00:22:25.110
Right? So I had to go back and edit the
00:22:25.120 --> 00:22:27.430
guides, effectively the context to take
00:22:27.440 --> 00:22:29.510
those words out because it's a language
00:22:29.520 --> 00:22:31.750
model. And you know, but like your
00:22:31.760 --> 00:22:33.830
survivor record, it saw that word too
00:22:33.840 --> 00:22:35.430
many times and it's like that's that's
00:22:35.440 --> 00:22:37.750
what it goes. So if I think about
00:22:37.760 --> 00:22:39.830
organizations I've worked with, I don't
00:22:39.840 --> 00:22:42.149
see a lot of documentation about the way
00:22:42.159 --> 00:22:44.470
they work, right? The policies, the
00:22:44.480 --> 00:22:46.789
patterns they use, the principles they
00:22:46.799 --> 00:22:50.230
follow. Um so I think you know to answer
00:22:50.240 --> 00:22:51.909
that question we had originally was like
00:22:51.919 --> 00:22:54.549
how do we get context I think we need
00:22:54.559 --> 00:22:56.310
context about the organization and I
00:22:56.320 --> 00:22:57.830
think we need context about our way of
00:22:57.840 --> 00:22:59.350
working and we should treat those as two
00:22:59.360 --> 00:23:01.510
different things. Um, and if you don't
00:23:01.520 --> 00:23:03.029
have a way of working context, you
00:23:03.039 --> 00:23:05.029
should start crafting it because I think
00:23:05.039 --> 00:23:06.870
that is going to help the agents work
00:23:06.880 --> 00:23:08.789
the way you do and understand what's
00:23:08.799 --> 00:23:10.230
been built before,
00:23:10.240 --> 00:23:12.549
>> right? But way better than any single
00:23:12.559 --> 00:23:14.950
engineer could do it, right? It's it's a
00:23:14.960 --> 00:23:17.830
this is a group activity. This is not a
00:23:17.840 --> 00:23:19.830
this is not a data team activity. This
00:23:19.840 --> 00:23:22.870
is a full business activity to get that
00:23:22.880 --> 00:23:24.149
context.
00:23:24.159 --> 00:23:25.270
>> Yeah. And there's a really good
00:23:25.280 --> 00:23:27.110
technique I used to use with teams when
00:23:27.120 --> 00:23:28.950
they were hiring. Uh, not so much now.
00:23:28.960 --> 00:23:31.350
So maybe it's with agents, but what we
00:23:31.360 --> 00:23:33.510
used to say is do a draft of a piece of
00:23:33.520 --> 00:23:35.430
of documentation.
00:23:35.440 --> 00:23:37.430
Um, and then when somebody joins the
00:23:37.440 --> 00:23:40.149
team, get them to read it and follow it
00:23:40.159 --> 00:23:43.190
and then they have to update it, right?
00:23:43.200 --> 00:23:44.710
They have to find something in there
00:23:44.720 --> 00:23:47.830
that is missing or confusing and they
00:23:47.840 --> 00:23:50.870
have to iterate it uh at the time that
00:23:50.880 --> 00:23:52.630
they're effectively reading it, right?
00:23:52.640 --> 00:23:54.870
So point in time, not a month later.
00:23:54.880 --> 00:23:56.789
>> And that constant iteration meant we got
00:23:56.799 --> 00:23:59.190
really really good documentation. So
00:23:59.200 --> 00:24:01.270
maybe maybe for you know nobody's hiring
00:24:01.280 --> 00:24:03.029
these days right? So maybe with agents
00:24:03.039 --> 00:24:05.029
it's write it, run it against an agent,
00:24:05.039 --> 00:24:07.190
see what it does, get feedback, update
00:24:07.200 --> 00:24:09.350
it, run it against it's almost like a
00:24:09.360 --> 00:24:11.029
TDD, right?
00:24:11.039 --> 00:24:13.029
>> Yeah. Yeah. Yeah.
00:24:13.039 --> 00:24:13.350
>> Yeah.
00:24:13.360 --> 00:24:15.110
>> I like that.
00:24:15.120 --> 00:24:18.070
>> Yeah. So um right, let's jump on to
00:24:18.080 --> 00:24:19.669
context technology and then maybe we'll
00:24:19.679 --> 00:24:22.149
come back to MDM. So
00:24:22.159 --> 00:24:22.549
>> yeah,
00:24:22.559 --> 00:24:24.149
>> what what are you seeing? Right. Like
00:24:24.159 --> 00:24:27.110
everybody's talking semantics, context.
00:24:27.120 --> 00:24:28.789
Uh obviously you're talking about omni
00:24:28.799 --> 00:24:31.029
agent and ontologies and all that but
00:24:31.039 --> 00:24:33.269
are you really and harnesses are you
00:24:33.279 --> 00:24:35.269
really seeing anything
00:24:35.279 --> 00:24:38.390
>> nailing it at the moment? Cuz I'm not
00:24:38.400 --> 00:24:40.310
>> nothing nothing that really nails it,
00:24:40.320 --> 00:24:43.029
right? It there's just
00:24:43.039 --> 00:24:45.510
like obviously I'm a data bricks person.
00:24:45.520 --> 00:24:48.789
We've had that discussion. Um and I
00:24:48.799 --> 00:24:54.470
think that the genie ontology will be
00:24:54.480 --> 00:24:55.990
helpful.
00:24:56.000 --> 00:24:58.549
Um,
00:24:58.559 --> 00:25:01.190
but yeah, nothing that is like, oh yeah,
00:25:01.200 --> 00:25:03.110
this is going to be the thing, right?
00:25:03.120 --> 00:25:06.310
It's not. Um, I like I like the
00:25:06.320 --> 00:25:07.750
concepts. I like where everything's
00:25:07.760 --> 00:25:12.390
going, but there's still
00:25:12.400 --> 00:25:14.390
work to do.
00:25:14.400 --> 00:25:15.990
So, talk me through that geneontology,
00:25:16.000 --> 00:25:19.430
right? cuz I I could read it as a
00:25:19.440 --> 00:25:22.310
platform that has a a structure, a
00:25:22.320 --> 00:25:24.390
schema, a product. Effectively, it
00:25:24.400 --> 00:25:26.950
allows me to capture an ontology, right?
00:25:26.960 --> 00:25:30.230
Capture words or terms, definitions,
00:25:30.240 --> 00:25:32.549
relationships, uh, and that and that
00:25:32.559 --> 00:25:34.870
kind of stuff. But I could also read
00:25:34.880 --> 00:25:36.950
into it that there's an out ofthe-box
00:25:36.960 --> 00:25:39.269
thing where I can ask for an ontology
00:25:39.279 --> 00:25:41.190
and it's going to give me the the
00:25:41.200 --> 00:25:43.909
content itself, not just the tooling to
00:25:43.919 --> 00:25:45.909
create and store the content. What's it
00:25:45.919 --> 00:25:49.750
doing? So it it does so um so I was
00:25:49.760 --> 00:25:51.750
lucky enough to kind of see a demo of it
00:25:51.760 --> 00:25:53.750
and so
00:25:53.760 --> 00:25:55.750
basically so there's there's a couple of
00:25:55.760 --> 00:25:57.350
pieces to it right just like you said
00:25:57.360 --> 00:26:00.390
there is the knowledge graph type
00:26:00.400 --> 00:26:03.029
ontology that happens right where based
00:26:03.039 --> 00:26:07.190
on who is asking the question because
00:26:07.200 --> 00:26:09.430
it's layered in data bricks with unity
00:26:09.440 --> 00:26:11.029
catalog and all the governance that
00:26:11.039 --> 00:26:15.510
comes with with that it um genie will
00:26:15.520 --> 00:26:18.549
understand. Okay, this is somebody in
00:26:18.559 --> 00:26:23.430
this sales org. This is the
00:26:23.440 --> 00:26:25.110
hopefully you have everything tagged
00:26:25.120 --> 00:26:29.350
right that you've uploaded into uh into
00:26:29.360 --> 00:26:32.310
your ontology layer in data bricks. Um
00:26:32.320 --> 00:26:34.070
data bicks is also coming out with this
00:26:34.080 --> 00:26:35.990
new concept called pages which is kind
00:26:36.000 --> 00:26:40.310
of like the confluence pages right. Um
00:26:40.320 --> 00:26:42.950
and uh and you could upload markdown
00:26:42.960 --> 00:26:45.350
files, you could upload PDFs, plain text
00:26:45.360 --> 00:26:47.510
files so that it has all this context,
00:26:47.520 --> 00:26:54.630
right? Um and there is a concept of
00:26:54.640 --> 00:26:58.870
uh a trust value, right? Based on who
00:26:58.880 --> 00:27:01.830
has contributed that document, who the
00:27:01.840 --> 00:27:03.430
owner of that, you know, creator of that
00:27:03.440 --> 00:27:06.470
document is, if they have other things,
00:27:06.480 --> 00:27:08.149
we we'll stick with sales, right? If
00:27:08.159 --> 00:27:09.990
they have other things in the sales org
00:27:10.000 --> 00:27:14.230
that they contribute to, um, then their
00:27:14.240 --> 00:27:15.990
trust ranking would be higher than
00:27:16.000 --> 00:27:17.830
somebody that has one thing sitting out
00:27:17.840 --> 00:27:20.789
there. Um, and you can thumbs up or
00:27:20.799 --> 00:27:24.149
thumbs down when you get an answer and
00:27:24.159 --> 00:27:27.269
it will raise or lower that that
00:27:27.279 --> 00:27:29.750
document's trust ranking so that the
00:27:29.760 --> 00:27:32.549
next time that Genie comes through and
00:27:32.559 --> 00:27:36.070
starts to look at that ontology layer,
00:27:36.080 --> 00:27:38.230
it's will maybe pick a different
00:27:38.240 --> 00:27:40.630
document because you thumbs down that
00:27:40.640 --> 00:27:43.430
document the last time. Um so it's it's
00:27:43.440 --> 00:27:46.470
kind of that learning loop of the based
00:27:46.480 --> 00:27:50.470
on that feedback that you provided. Um
00:27:50.480 --> 00:27:52.549
>> so yeah
00:27:52.559 --> 00:27:54.630
>> so again the the thumbs up thumbs down
00:27:54.640 --> 00:27:56.310
come out of our catalog friends right
00:27:56.320 --> 00:27:58.230
that was a feature out of catalog
00:27:58.240 --> 00:27:59.830
technologies and then I just wonder
00:27:59.840 --> 00:28:02.389
about survivorship. So, if I'm vibe
00:28:02.399 --> 00:28:04.310
coding with Claude to create these
00:28:04.320 --> 00:28:06.710
markdown files and then popping them in
00:28:06.720 --> 00:28:08.789
there and then I'm getting volume,
00:28:08.799 --> 00:28:10.710
right? I've done lots of sales documents
00:28:10.720 --> 00:28:11.830
even though they were all completely
00:28:11.840 --> 00:28:13.909
vibe coded. I I'm going to get up the
00:28:13.919 --> 00:28:16.070
ranking, right? Um I'm just kind of kind
00:28:16.080 --> 00:28:18.870
of thinking that through. And then I'm
00:28:18.880 --> 00:28:21.190
not com So, this is interesting. So when
00:28:21.200 --> 00:28:23.269
you say ontology,
00:28:23.279 --> 00:28:24.710
but then you talk about storing
00:28:24.720 --> 00:28:27.110
documents, it kind of looks like they've
00:28:27.120 --> 00:28:29.510
got a platform for context, but they're
00:28:29.520 --> 00:28:32.630
calling the platform ontology, right?
00:28:32.640 --> 00:28:34.950
Because
00:28:34.960 --> 00:28:37.750
>> it's a it's a ontology layer that looks
00:28:37.760 --> 00:28:39.110
at that context, right?
00:28:39.120 --> 00:28:41.029
>> Ah, okay. All right. Okay. Because I
00:28:41.039 --> 00:28:42.710
think if you know if people
00:28:42.720 --> 00:28:44.870
>> uses the context to graph out the
00:28:44.880 --> 00:28:45.830
ontology, right?
00:28:45.840 --> 00:28:48.070
>> Okay. All right. Okay. I'll be keen to
00:28:48.080 --> 00:28:50.230
see how it does that. Yeah. I I'm still
00:28:50.240 --> 00:28:51.990
of the opinion that actually a human in
00:28:52.000 --> 00:28:54.710
a loop. I think I think that type of
00:28:54.720 --> 00:28:56.310
context is actually the thing that will
00:28:56.320 --> 00:28:58.630
make or break the genai systems and
00:28:58.640 --> 00:29:00.789
therefore I think it needs to be a human
00:29:00.799 --> 00:29:02.470
in the loop and that in theory that's
00:29:02.480 --> 00:29:04.149
what the anthropic paper that came out
00:29:04.159 --> 00:29:05.669
said as well right as they tried to
00:29:05.679 --> 00:29:09.190
generate it and you know got was it 65%
00:29:09.200 --> 00:29:11.029
hit in the evals and then they put a
00:29:11.039 --> 00:29:12.710
human in the loop to write it properly
00:29:12.720 --> 00:29:14.310
and they went straight up. So I'm going
00:29:14.320 --> 00:29:15.590
to be intrigued by that but
00:29:15.600 --> 00:29:17.750
>> 85 or 87%. Yeah. I mean it was
00:29:17.760 --> 00:29:19.430
>> yeah something like that. Yeah,
00:29:19.440 --> 00:29:20.710
>> something in the 80s, I feel like.
00:29:20.720 --> 00:29:21.350
>> Yeah.
00:29:21.360 --> 00:29:23.190
>> Yeah. Okay. All right. Well, I'm with
00:29:23.200 --> 00:29:25.350
you. I think uh I think we're still in
00:29:25.360 --> 00:29:29.510
the early days of context technology. Um
00:29:29.520 --> 00:29:31.590
yeah, we're seeing the catalog vendors
00:29:31.600 --> 00:29:32.789
try to move into it. We're seeing the
00:29:32.799 --> 00:29:35.350
metric BI semantic layer vendors try to
00:29:35.360 --> 00:29:36.470
move into it. We're seeing all the
00:29:36.480 --> 00:29:38.149
platforms move into it because they know
00:29:38.159 --> 00:29:40.789
how important it is. Um, yeah. So, it's
00:29:40.799 --> 00:29:42.470
kind of a
00:29:42.480 --> 00:29:45.110
>> even Jira, right, with Robo, Robo will
00:29:45.120 --> 00:29:47.110
read the confluence pages to try and
00:29:47.120 --> 00:29:49.590
determine what you're doing, right? And
00:29:49.600 --> 00:29:51.190
>> hopefully it reads the last updated
00:29:51.200 --> 00:29:53.110
date, right? [laughter]
00:29:53.120 --> 00:29:54.950
>> Because
00:29:54.960 --> 00:29:57.350
I think so. So, that could even bring us
00:29:57.360 --> 00:29:59.430
back to the MDM strategy piece, right?
00:29:59.440 --> 00:30:01.590
When you're talking about deterministic,
00:30:01.600 --> 00:30:03.990
you know, rules and stuff, what do you
00:30:04.000 --> 00:30:06.710
how what deterministic rules do you use,
00:30:06.720 --> 00:30:08.870
>> right? master context.
00:30:08.880 --> 00:30:09.350
>> Right.
00:30:09.360 --> 00:30:12.149
>> There we go. Master context. That's a
00:30:12.159 --> 00:30:14.360
whole new category that we've justed
00:30:14.370 --> 00:30:15.190
[laughter]
00:30:15.200 --> 00:30:17.590
>> what what what survives, right? It's a
00:30:17.600 --> 00:30:20.389
Yeah. Your MDM strategy of what survives
00:30:20.399 --> 00:30:21.830
in your context layer.
00:30:21.840 --> 00:30:23.830
>> Yeah. So, actually same patterns, isn't
00:30:23.840 --> 00:30:24.549
it? Really
00:30:24.559 --> 00:30:25.430
>> same pattern, right? It's
00:30:25.440 --> 00:30:27.669
>> the same pattern. Yeah. the all of these
00:30:27.679 --> 00:30:31.430
things kind of group together and
00:30:31.440 --> 00:30:34.789
you have some type of trust hierarchy of
00:30:34.799 --> 00:30:37.430
in this case it's a p contributor but
00:30:37.440 --> 00:30:39.269
you know historically it's been whatever
00:30:39.279 --> 00:30:43.110
system it came from of this attribute is
00:30:43.120 --> 00:30:46.310
mostly tr have has a higher trust value
00:30:46.320 --> 00:30:49.990
from Salesforce and this attribute has a
00:30:50.000 --> 00:30:53.110
higher trust value from your ERP system
00:30:53.120 --> 00:30:55.830
because it's the billing address and
00:30:55.840 --> 00:30:58.310
Well, we're getting money, so they're
00:30:58.320 --> 00:30:59.830
being build and they're receiving their
00:30:59.840 --> 00:31:02.549
bill, right? Um, [clears throat]
00:31:02.559 --> 00:31:04.149
that was probably more true back in the
00:31:04.159 --> 00:31:06.310
day. Now, people get e bills and
00:31:06.320 --> 00:31:08.149
probably goes back to the email address,
00:31:08.159 --> 00:31:09.029
but
00:31:09.039 --> 00:31:10.870
>> address email and phone numbers still a
00:31:10.880 --> 00:31:12.950
bit of a right? Especially in
00:31:12.960 --> 00:31:14.710
fraud fraud use cases where they don't
00:31:14.720 --> 00:31:16.950
want you to find them. Um, so actually
00:31:16.960 --> 00:31:18.710
that's the third master data pattern
00:31:18.720 --> 00:31:20.470
though, right? So, I talked about um
00:31:20.480 --> 00:31:22.470
single list of of of a concept. So,
00:31:22.480 --> 00:31:24.470
single list of customer, supplier,
00:31:24.480 --> 00:31:27.830
product. uh single view so you know all
00:31:27.840 --> 00:31:29.350
the transactions for that supplier all
00:31:29.360 --> 00:31:31.029
the transactions for that product but
00:31:31.039 --> 00:31:34.549
the third one is uh surviving attribute
00:31:34.559 --> 00:31:37.110
so I now have a list of customers and
00:31:37.120 --> 00:31:41.110
they are a single list um but that
00:31:41.120 --> 00:31:44.389
customer Bob uh has a phone number in
00:31:44.399 --> 00:31:47.430
three systems so which phone number is
00:31:47.440 --> 00:31:49.509
the surviving phone number when we do
00:31:49.519 --> 00:31:51.350
that right and again it's it is the same
00:31:51.360 --> 00:31:53.590
techniques but it's another use case or
00:31:53.600 --> 00:31:55.269
pattern that we have to apply that uh
00:31:55.279 --> 00:31:58.470
that hierarchy of and survival record um
00:31:58.480 --> 00:32:00.710
patterns to it.
00:32:00.720 --> 00:32:02.950
>> Yeah. And that's like that's such an
00:32:02.960 --> 00:32:05.029
important piece in that whole MDM
00:32:05.039 --> 00:32:07.750
concept, right? Is what survives and how
00:32:07.760 --> 00:32:10.549
do you determine what survives,
00:32:10.559 --> 00:32:13.350
right? And and that's that I go back to
00:32:13.360 --> 00:32:16.389
that that is that is a data engineering
00:32:16.399 --> 00:32:19.269
function and it is a business
00:32:19.279 --> 00:32:23.750
conversation, right? Um, it is
00:32:23.760 --> 00:32:26.950
sometimes what survives needs to be a
00:32:26.960 --> 00:32:28.950
conversation that you have with like a
00:32:28.960 --> 00:32:32.630
COE, right? A, you know, kind of a your
00:32:32.640 --> 00:32:35.029
your Justice League for for lack of a
00:32:35.039 --> 00:32:36.549
better term, right? Because I'm a big
00:32:36.559 --> 00:32:39.669
nerd. And um so you put together your
00:32:39.679 --> 00:32:41.110
Justice League and you've got somebody
00:32:41.120 --> 00:32:42.789
from marketing, somebody from sales,
00:32:42.799 --> 00:32:44.710
somebody from finance, you know,
00:32:44.720 --> 00:32:47.269
somebody from each kind of business unit
00:32:47.279 --> 00:32:50.149
that can that you could kind of hash
00:32:50.159 --> 00:32:54.230
out, you know, for each attribute. What
00:32:54.240 --> 00:32:56.630
is the
00:32:56.640 --> 00:32:59.110
source of truth? I hate that statement,
00:32:59.120 --> 00:33:01.509
but but what is your source of source of
00:33:01.519 --> 00:33:04.230
truth for each of those attributes? and
00:33:04.240 --> 00:33:06.230
and then the data engineer takes all
00:33:06.240 --> 00:33:09.830
that context back and determine and sets
00:33:09.840 --> 00:33:12.389
those deterministic rules based on that
00:33:12.399 --> 00:33:14.389
information. Um
00:33:14.399 --> 00:33:18.230
>> yeah and and so again I tend to work on
00:33:18.240 --> 00:33:20.710
uh deterministic rules first if I can.
00:33:20.720 --> 00:33:23.909
>> Yeah. So code that says if I see this
00:33:23.919 --> 00:33:25.909
it's that you know so one we're doing at
00:33:25.919 --> 00:33:28.789
the moment is uh content titles um for a
00:33:28.799 --> 00:33:31.110
customer. though uh they fund media
00:33:31.120 --> 00:33:33.830
content and so when we're grabbing the
00:33:33.840 --> 00:33:36.710
data from say linear or uh TV or video
00:33:36.720 --> 00:33:39.430
on demand uh we'll have Shortland Street
00:33:39.440 --> 00:33:41.350
and we'll have Shortland Street bracket
00:33:41.360 --> 00:33:44.470
r close bracket because that's a rerun.
00:33:44.480 --> 00:33:46.870
Uh now actually funny enough they want
00:33:46.880 --> 00:33:48.870
to see both but that's always good. Um,
00:33:48.880 --> 00:33:50.789
but we know deterministically that we
00:33:50.799 --> 00:33:53.029
can then encode something that says if
00:33:53.039 --> 00:33:55.990
we see some words up front and we see R
00:33:56.000 --> 00:33:58.630
bracket r bracket, we can infer that uh
00:33:58.640 --> 00:34:00.389
and take that off and and match it,
00:34:00.399 --> 00:34:04.230
right? Um the same with episodes and and
00:34:04.240 --> 00:34:05.750
a bunch of other things, right? We can
00:34:05.760 --> 00:34:07.509
say if we strip out that episode
00:34:07.519 --> 00:34:09.510
pattern, we know that that's the the
00:34:09.520 --> 00:34:12.470
same content title. Um, but then we get
00:34:12.480 --> 00:34:14.550
to YouTube,
00:34:14.560 --> 00:34:17.829
uh, and the YouTube content,
00:34:17.839 --> 00:34:20.869
uh, the publishers change the title on a
00:34:20.879 --> 00:34:22.869
regular basis because they want us get
00:34:22.879 --> 00:34:25.270
more reach and engagement.
00:34:25.280 --> 00:34:27.270
>> And so that's a lot fuzzier, right? It's
00:34:27.280 --> 00:34:30.950
not not a rule. And so the kind of
00:34:30.960 --> 00:34:34.389
that's another level of matching. Um,
00:34:34.399 --> 00:34:37.109
and so we can't deterministically
00:34:37.119 --> 00:34:40.069
do it first, right? What?
00:34:40.079 --> 00:34:44.629
>> So, so for YouTube, you uh so that and
00:34:44.639 --> 00:34:46.149
this is getting into the weeds for a
00:34:46.159 --> 00:34:48.470
second, but for YouTube, there should be
00:34:48.480 --> 00:34:50.710
an underlying ID for each of those
00:34:50.720 --> 00:34:52.550
videos that doesn't change.
00:34:52.560 --> 00:34:53.270
>> Yes, there is.
00:34:53.280 --> 00:34:55.270
>> And you should be able to use that right
00:34:55.280 --> 00:34:57.510
as your matching criteria. But to your
00:34:57.520 --> 00:34:59.750
point, if you're using titles, yeah,
00:34:59.760 --> 00:35:03.190
there are some platforms that people are
00:35:03.200 --> 00:35:05.030
changing their titles all the time to
00:35:05.040 --> 00:35:08.150
try and either and even in some, right,
00:35:08.160 --> 00:35:10.390
if you're doing like AB testing in
00:35:10.400 --> 00:35:13.910
YouTube, it might show up one way to one
00:35:13.920 --> 00:35:15.750
person, one way to to another person
00:35:15.760 --> 00:35:17.750
literally in the same second, right?
00:35:17.760 --> 00:35:19.349
Have a different thumbnail, have a
00:35:19.359 --> 00:35:23.190
different title um in the same moment.
00:35:23.200 --> 00:35:23.589
>> Yeah.
00:35:23.599 --> 00:35:26.470
>> Yeah. And so one of the things we're
00:35:26.480 --> 00:35:28.630
we're kind of experimenting now is
00:35:28.640 --> 00:35:31.109
rather than spend a lot of design time
00:35:31.119 --> 00:35:33.589
up front trying to figure out what the
00:35:33.599 --> 00:35:35.270
deterministic rules are. So we have a
00:35:35.280 --> 00:35:37.349
bunch of simple ones that you know we'll
00:35:37.359 --> 00:35:39.349
take as always the 8020 rule right we'll
00:35:39.359 --> 00:35:42.230
take care of 80% of it. um we've just
00:35:42.240 --> 00:35:44.550
been prototyping this idea and I'm sure
00:35:44.560 --> 00:35:47.109
I kind of was that data flux maybe maybe
00:35:47.119 --> 00:35:48.950
not maybe it was zero I can't remember
00:35:48.960 --> 00:35:50.550
but this idea of treating as a
00:35:50.560 --> 00:35:52.230
reconciliation problem right a left
00:35:52.240 --> 00:35:56.069
right so giving a person in the loop
00:35:56.079 --> 00:35:59.829
saying here's what the master is and
00:35:59.839 --> 00:36:01.510
here's what we think the match is and
00:36:01.520 --> 00:36:03.829
here's the way why we think it's a match
00:36:03.839 --> 00:36:07.190
accepted or not and then using that data
00:36:07.200 --> 00:36:09.910
their their click data effectively to
00:36:09.920 --> 00:36:12.150
help reinforce is the model, the fuzzy
00:36:12.160 --> 00:36:12.950
model, right?
00:36:12.960 --> 00:36:13.990
>> The fuzzy model. Yeah.
00:36:14.000 --> 00:36:14.790
>> Yeah.
00:36:14.800 --> 00:36:17.349
>> Um and which brings us to like the
00:36:17.359 --> 00:36:21.270
fourth pattern for MDM, right? Of even
00:36:21.280 --> 00:36:23.829
you, so you do your best to match. You
00:36:23.839 --> 00:36:25.670
do your best for the survivorship, but
00:36:25.680 --> 00:36:27.589
inevitably things fall out, right? You
00:36:27.599 --> 00:36:30.630
cannot come up with deterministic rules
00:36:30.640 --> 00:36:32.710
and fuzzy matching is not going to catch
00:36:32.720 --> 00:36:36.550
everything. And so you put into place a
00:36:36.560 --> 00:36:39.270
pattern that feed feedback loop pattern
00:36:39.280 --> 00:36:42.150
right of your you expose and say okay
00:36:42.160 --> 00:36:44.950
business here business stakeholders here
00:36:44.960 --> 00:36:48.710
are here's what fell out right what
00:36:48.720 --> 00:36:52.390
matches and let them determine okay then
00:36:52.400 --> 00:36:54.310
give them you know some button clicks to
00:36:54.320 --> 00:36:56.550
be able to to do what they need to do
00:36:56.560 --> 00:37:00.870
there. Um or like and there's there's
00:37:00.880 --> 00:37:04.550
kind of two two patterns here. Or you
00:37:04.560 --> 00:37:07.349
reinforce like data grooming, right? And
00:37:07.359 --> 00:37:10.230
you have them fix that in the source
00:37:10.240 --> 00:37:13.430
system so that the next time that MDM
00:37:13.440 --> 00:37:16.310
pipeline runs, then things match the way
00:37:16.320 --> 00:37:18.069
that they're expected to,
00:37:18.079 --> 00:37:19.750
>> which is the way we should do it, right?
00:37:19.760 --> 00:37:22.230
Because then any Yeah. Because then the
00:37:22.240 --> 00:37:23.990
system's right. Yeah. anybody that uses
00:37:24.000 --> 00:37:26.230
that system sees the right name. That
00:37:26.240 --> 00:37:28.150
that's really where we should be. Um
00:37:28.160 --> 00:37:31.510
>> yeah, it and I would so I'm a big fan of
00:37:31.520 --> 00:37:33.030
okay, this is how it should be done.
00:37:33.040 --> 00:37:36.150
This is how [laughter] works in reality,
00:37:36.160 --> 00:37:38.390
right? Uh we've had these discussions
00:37:38.400 --> 00:37:41.990
before too. Um but uh but yes, I'm a big
00:37:42.000 --> 00:37:43.750
fan of pushing it back to the system,
00:37:43.760 --> 00:37:46.790
getting it right in the system. And
00:37:46.800 --> 00:37:50.390
sometimes the political environment in a
00:37:50.400 --> 00:37:54.470
business, sometimes the time constraints
00:37:54.480 --> 00:37:57.589
or whatever excuse of the moment is for
00:37:57.599 --> 00:37:59.910
the business, whatever you know
00:37:59.920 --> 00:38:02.069
challenges what the b of the business
00:38:02.079 --> 00:38:05.270
is. Sometimes that button click of okay
00:38:05.280 --> 00:38:07.430
yes these match is the only feedback
00:38:07.440 --> 00:38:08.630
that you're going to get and you're not
00:38:08.640 --> 00:38:10.310
going to get them to actually
00:38:10.320 --> 00:38:12.230
>> go back to the source system. Depends on
00:38:12.240 --> 00:38:13.990
the support that you have with the other
00:38:14.000 --> 00:38:15.430
leaders of the business. Right. But
00:38:15.440 --> 00:38:15.750
actually
00:38:15.760 --> 00:38:17.270
>> I'm wondering I'm wondering with things
00:38:17.280 --> 00:38:20.310
like MCPs now
00:38:20.320 --> 00:38:22.230
>> whether we could actually close that
00:38:22.240 --> 00:38:25.910
loop now. We we could I I've actually
00:38:25.920 --> 00:38:29.190
>> yeah built systems where we give them
00:38:29.200 --> 00:38:31.589
the button clicks and we say okay this
00:38:31.599 --> 00:38:34.390
is what matches and then we enrich that
00:38:34.400 --> 00:38:38.710
data back to Salesforce right and we're
00:38:38.720 --> 00:38:41.750
as a data engineering function actually
00:38:41.760 --> 00:38:44.150
pushing back into those systems those
00:38:44.160 --> 00:38:46.790
corrections that have been determined by
00:38:46.800 --> 00:38:47.750
the business.
00:38:47.760 --> 00:38:49.990
>> Yeah. rather than submitting it to a
00:38:50.000 --> 00:38:52.950
data stewards committee that never meets
00:38:52.960 --> 00:38:55.109
once meets once a month. So, you know,
00:38:55.119 --> 00:38:56.790
and always too busy. Um,
00:38:56.800 --> 00:38:57.190
>> yeah.
00:38:57.200 --> 00:38:58.790
>> Yeah. I wonder if that's the answer now
00:38:58.800 --> 00:39:01.670
is like just and with everybody wanting
00:39:01.680 --> 00:39:05.030
to use the MCPS to read the data, right?
00:39:05.040 --> 00:39:06.550
The fact that we can use it to push back
00:39:06.560 --> 00:39:08.230
is actually quite valuable
00:39:08.240 --> 00:39:10.069
>> and and that depends on like the size of
00:39:10.079 --> 00:39:12.310
the business, right? a smaller business
00:39:12.320 --> 00:39:15.750
>> probably more costefficient to just get
00:39:15.760 --> 00:39:17.670
them to push it to correct it in the
00:39:17.680 --> 00:39:22.310
front end. Um, and do you do you where
00:39:22.320 --> 00:39:24.150
do you want to incur that cost? Right?
00:39:24.160 --> 00:39:25.270
You're going to incur that cost
00:39:25.280 --> 00:39:27.589
somewhere either in manh hours fixing
00:39:27.599 --> 00:39:30.470
the front end or in compute
00:39:30.480 --> 00:39:32.390
programmatically doing it.
00:39:32.400 --> 00:39:34.390
>> Uh, and it depends on kind of the
00:39:34.400 --> 00:39:36.950
quality of your data too. If your data
00:39:36.960 --> 00:39:38.630
is
00:39:38.640 --> 00:39:42.950
crap, right? I mean, and you're spend
00:39:42.960 --> 00:39:46.950
and and there's not that reinforcement
00:39:46.960 --> 00:39:49.589
coaching loop back to the business of
00:39:49.599 --> 00:39:51.990
let's make sure that we're trying to do
00:39:52.000 --> 00:39:53.990
everything our due diligence up front of
00:39:54.000 --> 00:39:56.230
putting stuff in.
00:39:56.240 --> 00:39:58.230
Then I've seen where businesses don't
00:39:58.240 --> 00:39:59.990
have where data teams don't have that
00:40:00.000 --> 00:40:03.349
that support to push that coaching back
00:40:03.359 --> 00:40:05.990
to the front end people doing the data
00:40:06.000 --> 00:40:10.390
entry then the compute cost continues to
00:40:10.400 --> 00:40:12.550
scale and increase as well to make those
00:40:12.560 --> 00:40:15.670
corrections because they just the
00:40:15.680 --> 00:40:17.990
business learns that I I could just put
00:40:18.000 --> 00:40:20.950
in whatever and the data team's going to
00:40:20.960 --> 00:40:22.950
fix it on the back end. that just seems
00:40:22.960 --> 00:40:23.430
freaky.
00:40:23.440 --> 00:40:25.270
>> So it's one of those things that you
00:40:25.280 --> 00:40:26.950
have to balance and make sure that there
00:40:26.960 --> 00:40:29.190
is some type of coaching and feedback
00:40:29.200 --> 00:40:31.109
loop in the business that's supported by
00:40:31.119 --> 00:40:32.790
your leadership.
00:40:32.800 --> 00:40:33.990
>> And then one of the other patterns that
00:40:34.000 --> 00:40:35.109
we used to do was the idea of
00:40:35.119 --> 00:40:37.349
dictionaries, right? So you know
00:40:37.359 --> 00:40:40.150
William, Bill, same term. So we used to
00:40:40.160 --> 00:40:43.670
run these dictionaries of common terms
00:40:43.680 --> 00:40:46.150
and now I mean I'm just guessing we can
00:40:46.160 --> 00:40:49.030
just LLM that right? Like we don't we're
00:40:49.040 --> 00:40:50.950
treating it as a almost an ondemand
00:40:50.960 --> 00:40:53.190
function. we don't actually need to hold
00:40:53.200 --> 00:40:55.750
these dictionaries of terms in their
00:40:55.760 --> 00:40:57.270
relationships
00:40:57.280 --> 00:40:59.829
uh anymore because we just
00:40:59.839 --> 00:41:02.150
>> call an LLM and it would it be
00:41:02.160 --> 00:41:04.390
probabilist well yeah that's the
00:41:04.400 --> 00:41:05.109
question
00:41:05.119 --> 00:41:10.550
>> be probabilistic yeah
00:41:10.560 --> 00:41:12.390
>> or do we keep it deterministic do we
00:41:12.400 --> 00:41:14.470
keep the dictionaries and use lms to
00:41:14.480 --> 00:41:16.630
help us draft them
00:41:16.640 --> 00:41:20.870
>> so so funny story um
00:41:20.880 --> 00:41:23.990
So so many tools even when you're using
00:41:24.000 --> 00:41:27.190
a um
00:41:27.200 --> 00:41:29.270
a lot of those tools out those kind of
00:41:29.280 --> 00:41:31.349
data dictionary type tools out there
00:41:31.359 --> 00:41:34.630
whether it's data bricks or
00:41:34.640 --> 00:41:39.030
fabric or um what's that other big one
00:41:39.040 --> 00:41:42.150
um
00:41:42.160 --> 00:41:43.750
uh
00:41:43.760 --> 00:41:45.829
I don't remember I I'll I'll come to me
00:41:45.839 --> 00:41:48.790
here in an hour when we're done but but
00:41:48.800 --> 00:41:51.030
like literally there is a button that
00:41:51.040 --> 00:41:53.109
you click that it autopop populates with
00:41:53.119 --> 00:41:56.870
AI your
00:41:56.880 --> 00:41:59.430
your definition, right? You either you
00:41:59.440 --> 00:42:01.190
have the chance of deterministically
00:42:01.200 --> 00:42:04.550
filling it in or probabilistically
00:42:04.560 --> 00:42:06.630
hitting that button and letting AI
00:42:06.640 --> 00:42:12.150
assume what what's going on there. And
00:42:12.160 --> 00:42:15.270
I I would I've seen people that just go
00:42:15.280 --> 00:42:17.510
through and just click that the little
00:42:17.520 --> 00:42:20.710
magic wand and hit save and move on to
00:42:20.720 --> 00:42:23.430
the next thing that they're curating,
00:42:23.440 --> 00:42:26.069
right? Um
00:42:26.079 --> 00:42:27.510
yeah. Anyways,
00:42:27.520 --> 00:42:30.790
>> and and imagine again we're back to uh
00:42:30.800 --> 00:42:33.190
the model, the context model, choosing
00:42:33.200 --> 00:42:35.750
the most active person in that domain.
00:42:35.760 --> 00:42:38.309
Uh and now Mr. Clicky clicky clicky
00:42:38.319 --> 00:42:40.550
clicky is winning because they're uh
00:42:40.560 --> 00:42:42.790
they're they're seen as trusted.
00:42:42.800 --> 00:42:45.829
>> Yeah. Yep. Exactly. Because Yeah.
00:42:45.839 --> 00:42:47.190
Because it looks good. Somebody else
00:42:47.200 --> 00:42:48.630
looks at it and they're like, "Yeah,
00:42:48.640 --> 00:42:50.069
that looks good."
00:42:50.079 --> 00:42:50.309
>> Yeah.
00:42:50.319 --> 00:42:52.790
>> And then they've all of a sudden done 50
00:42:52.800 --> 00:42:53.670
million of them.
00:42:53.680 --> 00:42:55.510
>> It's a bit like uh how many tokens burnt
00:42:55.520 --> 00:42:57.430
and how many PRs you've committed,
00:42:57.440 --> 00:42:59.829
right? How many co-commits? That's a the
00:42:59.839 --> 00:43:03.190
sign of Yeah. if you're a top top
00:43:03.200 --> 00:43:06.309
contributor of of something quality or
00:43:06.319 --> 00:43:08.550
not. Yeah.
00:43:08.560 --> 00:43:11.910
>> Yeah. Yes. Now I'm trying to look up the
00:43:11.920 --> 00:43:16.439
name of that data dictionary company. Um
00:43:16.449 --> 00:43:16.870
[laughter]
00:43:16.880 --> 00:43:21.270
>> 2 2 a.m. 2 a.m. You got to be like 100.
00:43:21.280 --> 00:43:26.950
That's that's the magic time, right? Um
00:43:26.960 --> 00:43:28.630
Oh my gosh. I can't believe believe I
00:43:28.640 --> 00:43:29.270
can't remember it.
00:43:29.280 --> 00:43:30.390
>> That's right. If you stop thinking about
00:43:30.400 --> 00:43:31.829
it, we'll come back.
00:43:31.839 --> 00:43:33.430
>> Yeah, we'll come back to it.
00:43:33.440 --> 00:43:36.390
>> And then [clears throat] um
00:43:36.400 --> 00:43:39.109
so we got these different rule sets
00:43:39.119 --> 00:43:40.550
basically, right? Some of them
00:43:40.560 --> 00:43:42.950
deterministic, highly trusted, we put
00:43:42.960 --> 00:43:44.630
them up front, then we get down to some
00:43:44.640 --> 00:43:47.349
more fuzzy, lots of other fuzzy things,
00:43:47.359 --> 00:43:49.670
distancing algorithms,
00:43:49.680 --> 00:43:53.109
uh a whole lot of other ones. And so
00:43:53.119 --> 00:43:56.550
again, we've got to be able to observe
00:43:56.560 --> 00:44:00.870
which of those rule sets was applied to
00:44:00.880 --> 00:44:02.945
match that record. Right? So
00:44:02.955 --> 00:44:03.910
[clears throat] we should be logging
00:44:03.920 --> 00:44:05.910
that, right? We should be saying when we
00:44:05.920 --> 00:44:09.430
did this match, we used this rule set uh
00:44:09.440 --> 00:44:12.069
and therefore this was the thing that
00:44:12.079 --> 00:44:14.150
took the action to match it and and
00:44:14.160 --> 00:44:15.829
potentially there's a human in the loop.
00:44:15.839 --> 00:44:18.630
This person said yes as well because
00:44:18.640 --> 00:44:21.430
otherwise we got no idea.
00:44:21.440 --> 00:44:23.829
uh what happened? Right.
00:44:23.839 --> 00:44:26.309
>> Right. Well, and I think that that's a
00:44:26.319 --> 00:44:28.390
feedback loop, too, right? If you have
00:44:28.400 --> 00:44:31.430
your system, if you do, you know, we
00:44:31.440 --> 00:44:34.390
talk about build versus buy and you
00:44:34.400 --> 00:44:37.349
build it, you should have part of that
00:44:37.359 --> 00:44:39.990
build be that one, like you said, we're
00:44:40.000 --> 00:44:42.470
stamping that role that was used to do
00:44:42.480 --> 00:44:46.309
that deterministic match. And then
00:44:46.319 --> 00:44:49.109
over time, you're curating that too,
00:44:49.119 --> 00:44:51.910
right? of okay, we we had this
00:44:51.920 --> 00:44:55.190
deterministic match, but the business
00:44:55.200 --> 00:44:57.829
pushed back on 10% of this. Do we need
00:44:57.839 --> 00:44:59.270
to revisit that determinist
00:44:59.280 --> 00:45:01.349
deterministic match? Right? And you're
00:45:01.359 --> 00:45:04.150
storing, logging, tracking, all that so
00:45:04.160 --> 00:45:07.750
that you can make those adjustments over
00:45:07.760 --> 00:45:10.150
time because deterministic matching can
00:45:10.160 --> 00:45:14.309
be a living piece of your platform um
00:45:14.319 --> 00:45:18.230
and survivorship rules, right?
00:45:18.240 --> 00:45:20.790
But one of the things we do is we uh so
00:45:20.800 --> 00:45:22.390
we version our change rules effectively
00:45:22.400 --> 00:45:24.630
our transformation code. Um although we
00:45:24.640 --> 00:45:25.990
do it slightly differently in that our
00:45:26.000 --> 00:45:28.470
context holds the logic and we our
00:45:28.480 --> 00:45:30.150
code's cattle right. So actually we we
00:45:30.160 --> 00:45:31.750
version the context right this is the
00:45:31.760 --> 00:45:33.589
logic that we're using and the code
00:45:33.599 --> 00:45:35.670
itself just gets generated run and then
00:45:35.680 --> 00:45:39.510
disposed of. Um but whenever we insert a
00:45:39.520 --> 00:45:41.910
record or change a record, we we tag
00:45:41.920 --> 00:45:45.190
back to the unique ID or GID of this
00:45:45.200 --> 00:45:48.790
piece of logic uh with this version.
00:45:48.800 --> 00:45:52.470
Yeah. So we know what piece ran
00:45:52.480 --> 00:45:54.950
often when I'm working with data teams
00:45:54.960 --> 00:45:56.710
and I ask them that question, right? You
00:45:56.720 --> 00:46:00.550
know, say DBT, right? Um so how do you
00:46:00.560 --> 00:46:04.790
know which DBT code ran to populate that
00:46:04.800 --> 00:46:06.630
record? And they don't log it, right?
00:46:06.640 --> 00:46:09.910
They don't like yes the WT codes in git
00:46:09.920 --> 00:46:12.710
hopefully um but they don't append to
00:46:12.720 --> 00:46:14.710
the record or the log anywhere to say
00:46:14.720 --> 00:46:17.349
when we created this row or updated it
00:46:17.359 --> 00:46:19.589
it was this piece of logic this piece of
00:46:19.599 --> 00:46:21.750
context this piece of code that did it
00:46:21.760 --> 00:46:25.910
and so I I think often that pattern of
00:46:25.920 --> 00:46:28.950
logging everything is not baked in to a
00:46:28.960 --> 00:46:30.230
lot of people and they're not taught it
00:46:30.240 --> 00:46:31.589
is that what you're seeing
00:46:31.599 --> 00:46:34.230
>> they're they're not like audit any type
00:46:34.240 --> 00:46:37.990
of audit logs well Yeah. Yes. Because
00:46:38.000 --> 00:46:40.069
again that that all goes back to that
00:46:40.079 --> 00:46:44.470
free feedback loop like uh I like to use
00:46:44.480 --> 00:46:47.030
the example of data teams struggle with
00:46:47.040 --> 00:46:49.430
metrics to quantify
00:46:49.440 --> 00:46:51.670
results, right? Of what what do you
00:46:51.680 --> 00:46:53.829
measure your data team on?
00:46:53.839 --> 00:46:56.230
>> And
00:46:56.240 --> 00:46:58.390
comp you know teams struggle companies
00:46:58.400 --> 00:47:00.950
and teams struggle with with that
00:47:00.960 --> 00:47:03.589
because of this specific pattern that
00:47:03.599 --> 00:47:05.109
we're talking about here, right? They're
00:47:05.119 --> 00:47:09.109
not logging. They're not saving and you
00:47:09.119 --> 00:47:11.829
know in a table that is historical and
00:47:11.839 --> 00:47:15.910
trackable and measurable of
00:47:15.920 --> 00:47:18.870
what happened right whether that is data
00:47:18.880 --> 00:47:20.870
quality stuff of this is the number of
00:47:20.880 --> 00:47:23.270
records that were ingested during this
00:47:23.280 --> 00:47:25.589
time. This is the number of records that
00:47:25.599 --> 00:47:28.309
were cleaned out of that data set. This
00:47:28.319 --> 00:47:31.030
is you know um so that you could track
00:47:31.040 --> 00:47:34.710
those types of pieces over time. uh this
00:47:34.720 --> 00:47:37.750
is the feedback loop of you know this
00:47:37.760 --> 00:47:40.150
was wrong you know because and we got
00:47:40.160 --> 00:47:42.630
this information back from the business
00:47:42.640 --> 00:47:45.510
and going forward this is the new
00:47:45.520 --> 00:47:47.510
deterministic pattern that we're using
00:47:47.520 --> 00:47:51.349
and it improved our data quality by 10%
00:47:51.359 --> 00:47:53.030
nobody has the ability to track that
00:47:53.040 --> 00:47:55.670
because they don't because they don't
00:47:55.680 --> 00:47:57.750
track it right they don't they don't log
00:47:57.760 --> 00:47:59.190
that information
00:47:59.200 --> 00:48:01.829
>> um but yes that 100% is some because
00:48:01.839 --> 00:48:04.230
it's an afterthought uh And it's a team
00:48:04.240 --> 00:48:06.710
maturity thing too, right? Um, young
00:48:06.720 --> 00:48:10.710
teams, small teams, uh,
00:48:10.720 --> 00:48:13.430
don't have
00:48:13.440 --> 00:48:15.910
the history within themselves to know
00:48:15.920 --> 00:48:18.150
that that's even a thing to worry about.
00:48:18.160 --> 00:48:21.510
And they're often in a place where
00:48:21.520 --> 00:48:22.710
they're just trying to get the next
00:48:22.720 --> 00:48:23.990
thing done. [clears throat]
00:48:24.000 --> 00:48:24.630
>> It just
00:48:24.640 --> 00:48:25.829
>> Yeah. Well, they haven't been burnt,
00:48:25.839 --> 00:48:27.109
right? They haven't been hit by the bus
00:48:27.119 --> 00:48:28.870
by not logging it. So, they go,
00:48:28.880 --> 00:48:30.549
"Actually, I had no clue who changed
00:48:30.559 --> 00:48:33.910
what and what it impacted." Um so then
00:48:33.920 --> 00:48:35.990
if we look at master data management
00:48:36.000 --> 00:48:38.309
right that that matching that
00:48:38.319 --> 00:48:40.150
survivorship
00:48:40.160 --> 00:48:43.670
do you think it should be a system on
00:48:43.680 --> 00:48:45.190
the side like let's assume we're not
00:48:45.200 --> 00:48:46.630
going to go buy one right we're going to
00:48:46.640 --> 00:48:48.549
build because we're a typical data
00:48:48.559 --> 00:48:52.630
engineering team today. Um and so
00:48:52.640 --> 00:48:55.430
is it a system on the side right where
00:48:55.440 --> 00:48:58.150
data comes in that system runs does the
00:48:58.160 --> 00:49:00.069
matching survivorship and then the data
00:49:00.079 --> 00:49:01.910
is populated and everything else reads
00:49:01.920 --> 00:49:06.630
the data and pushes it forward. Is it uh
00:49:06.640 --> 00:49:08.710
and the answer to this one's no is it
00:49:08.720 --> 00:49:10.950
handcrafted in every data transformation
00:49:10.960 --> 00:49:14.390
flow right the matching thingy or is it
00:49:14.400 --> 00:49:17.589
some kind of context engine that the
00:49:17.599 --> 00:49:19.990
data transformation flows can call to
00:49:20.000 --> 00:49:21.510
say hey I need to do some matching
00:49:21.520 --> 00:49:23.750
almost like a service right hey this is
00:49:23.760 --> 00:49:25.910
what I got yeah thank you very much and
00:49:25.920 --> 00:49:27.910
then carry on which which way do you do
00:49:27.920 --> 00:49:29.589
it you trying to treat it as something
00:49:29.599 --> 00:49:32.710
that is hydrated in the code every time
00:49:32.720 --> 00:49:34.790
it runs or do you treat it as a system
00:49:34.800 --> 00:49:37.190
that does the work and stores the data.
00:49:37.200 --> 00:49:40.549
I I like to hydrate it as the data comes
00:49:40.559 --> 00:49:42.470
because that makes your code and your
00:49:42.480 --> 00:49:44.230
platform a little bit more modular so
00:49:44.240 --> 00:49:47.910
that when you do do go from mastering c
00:49:47.920 --> 00:49:51.990
customer to mastering supplier then it's
00:49:52.000 --> 00:49:54.150
you have kind of a
00:49:54.160 --> 00:49:58.470
>> a single pattern right that has
00:49:58.480 --> 00:50:01.750
helper tables that depending on the
00:50:01.760 --> 00:50:04.150
domain that's being worked on that's
00:50:04.160 --> 00:50:08.230
being mastered it can look to whether
00:50:08.240 --> 00:50:11.670
it's that a JSON file or I like I like
00:50:11.680 --> 00:50:14.790
storing it in tables just because
00:50:14.800 --> 00:50:16.950
I'm old and a data guy and I like
00:50:16.960 --> 00:50:20.950
tables. Um but you know store store
00:50:20.960 --> 00:50:22.790
those rules in a table again so that you
00:50:22.800 --> 00:50:25.270
could track it over time so that you can
00:50:25.280 --> 00:50:28.069
quantify that over time because then it
00:50:28.079 --> 00:50:30.470
could be then that table in itself has
00:50:30.480 --> 00:50:34.470
dual purpose of hydrating that code as
00:50:34.480 --> 00:50:37.510
well as being a dimension in a model uh
00:50:37.520 --> 00:50:40.390
you know in uh in some type of query
00:50:40.400 --> 00:50:43.910
that you're going to use downstream. Um,
00:50:43.920 --> 00:50:46.309
and uh,
00:50:46.319 --> 00:50:48.790
yeah, that's my that's my two cents. I I
00:50:48.800 --> 00:50:50.790
think that it's a it's a better fit
00:50:50.800 --> 00:50:53.430
because otherwise you're basically hard
00:50:53.440 --> 00:50:56.790
coding that information into your code
00:50:56.800 --> 00:50:59.270
and it's I'm not a fan of that.
00:50:59.280 --> 00:51:00.710
>> Yeah, I think I think of it as an
00:51:00.720 --> 00:51:02.390
engine, right? You kind of pass it over
00:51:02.400 --> 00:51:03.990
to the engine and the engine runs it and
00:51:04.000 --> 00:51:05.670
then passes you back the result almost
00:51:05.680 --> 00:51:07.430
like a service. Um but there was a good
00:51:07.440 --> 00:51:09.990
point that you just made as well is that
00:51:10.000 --> 00:51:11.430
although you can have a relatively
00:51:11.440 --> 00:51:14.549
generic engine, the domain
00:51:14.559 --> 00:51:16.710
uh that you're trying to master data for
00:51:16.720 --> 00:51:20.150
actually needs more context. So you know
00:51:20.160 --> 00:51:21.670
if you're mastering people or
00:51:21.680 --> 00:51:23.829
organizations you're going to rely so
00:51:23.839 --> 00:51:25.990
let's say we're going to master people.
00:51:26.000 --> 00:51:27.190
We're going to rely on things like
00:51:27.200 --> 00:51:28.630
social security number, driver's
00:51:28.640 --> 00:51:31.109
license, phone number if we have to,
00:51:31.119 --> 00:51:32.870
email if we really have to, right?
00:51:32.880 --> 00:51:34.710
There's a bunch of known patterns of of
00:51:34.720 --> 00:51:36.710
what we can use to suggest there's a
00:51:36.720 --> 00:51:39.190
match and then the you know value or the
00:51:39.200 --> 00:51:41.510
survivorship value of it. Um
00:51:41.520 --> 00:51:42.790
organization we're going to look for
00:51:42.800 --> 00:51:44.470
some kind of government organization
00:51:44.480 --> 00:51:46.950
number tax number that kind of thing. we
00:51:46.960 --> 00:51:49.030
enter product, it's slightly different.
00:51:49.040 --> 00:51:51.030
Suppliers, their organizations, right?
00:51:51.040 --> 00:51:53.670
So, um, yeah, these kind of different
00:51:53.680 --> 00:51:56.150
rules. Well, not different. They're not
00:51:56.160 --> 00:51:58.230
really rules, are they? Cuz the the
00:51:58.240 --> 00:52:00.630
rules are the algorithms or the layers
00:52:00.640 --> 00:52:01.910
that we're running. These different lot
00:52:01.920 --> 00:52:03.270
helpers, I think, is the right word that
00:52:03.280 --> 00:52:06.069
you use, right? Helper patterns um for
00:52:06.079 --> 00:52:08.309
that. So, again, it's not a simple
00:52:08.319 --> 00:52:11.030
problem, right? Um, master data
00:52:11.040 --> 00:52:13.589
management is quite complex in itself.
00:52:13.599 --> 00:52:15.670
>> Always complex. Yeah, always comp.
00:52:15.680 --> 00:52:17.030
That's why we're we have so many
00:52:17.040 --> 00:52:19.910
platforms out there, right, that um that
00:52:19.920 --> 00:52:21.670
people could buy off the shelf and and
00:52:21.680 --> 00:52:25.190
try to use and and then my experience
00:52:25.200 --> 00:52:28.390
over the years has been that businesses
00:52:28.400 --> 00:52:30.069
have a tendency to come back to the
00:52:30.079 --> 00:52:33.910
build piece, right? Um because
00:52:33.920 --> 00:52:35.910
>> people have a unique
00:52:35.920 --> 00:52:38.870
>> Yeah. Uh I I think I found that that
00:52:38.880 --> 00:52:41.030
happens because when we buy a platform,
00:52:41.040 --> 00:52:42.630
we're not buying a solution. we're
00:52:42.640 --> 00:52:45.030
buying a tool that can be configured and
00:52:45.040 --> 00:52:47.589
actually all the hard work it helps um
00:52:47.599 --> 00:52:50.230
but it doesn't it doesn't outsource all
00:52:50.240 --> 00:52:53.190
the effort right it just assists us and
00:52:53.200 --> 00:52:56.069
yeah I I think uh yeah I'm like you I
00:52:56.079 --> 00:52:58.790
think um kind of building it uh to a
00:52:58.800 --> 00:53:00.150
degree depending on how big you are and
00:53:00.160 --> 00:53:02.790
all that that context right and how many
00:53:02.800 --> 00:53:04.069
>> how many of these things you have to do
00:53:04.079 --> 00:53:05.910
and how complex it is.
00:53:05.920 --> 00:53:08.790
>> Yeah. Yeah. Absolutely.
00:53:08.800 --> 00:53:11.190
>> Excellent. All right. Before we close it
00:53:11.200 --> 00:53:14.870
out, has anybody got any questions? Uh,
00:53:14.880 --> 00:53:16.390
>> yeah, we've had a handful of people on.
00:53:16.400 --> 00:53:16.790
>> Yeah.
00:53:16.800 --> 00:53:19.430
>> Who's got questions?
00:53:19.440 --> 00:53:21.030
>> Anything we should discuss in the last
00:53:21.040 --> 00:53:22.630
couple of minutes given we're slightly
00:53:22.640 --> 00:53:25.990
late coming on.
00:53:26.000 --> 00:53:27.670
>> We'll take that as a no. All right.
00:53:27.680 --> 00:53:30.549
Well, let's uh let's see what the uh
00:53:30.559 --> 00:53:32.870
universe aligns with over the next
00:53:32.880 --> 00:53:36.069
month. And it's always uh kind of yeah
00:53:36.079 --> 00:53:38.230
it's always interesting when uh one of
00:53:38.240 --> 00:53:40.069
the awesome foresome is posting
00:53:40.079 --> 00:53:42.470
something and I'm like oh I'm working on
00:53:42.480 --> 00:53:44.630
that or I've been
00:53:44.640 --> 00:53:46.230
>> it's like yeah [laughter]
00:53:46.240 --> 00:53:48.069
>> it's always funny because I feel like
00:53:48.079 --> 00:53:50.950
there's cycles to this right it feels it
00:53:50.960 --> 00:53:53.030
sometimes it feels like we're all
00:53:53.040 --> 00:53:57.670
working on something similar uh in in
00:53:57.680 --> 00:54:00.150
kind of the same time range. It's funny.
00:54:00.160 --> 00:54:02.069
>> Yeah. I think the buser data management
00:54:02.079 --> 00:54:03.670
one freaked me out though
00:54:03.680 --> 00:54:05.910
>> cuz I I haven't done an iteration on
00:54:05.920 --> 00:54:09.109
this for quite a while and then I just
00:54:09.119 --> 00:54:13.109
literally doing it and then
00:54:13.119 --> 00:54:14.710
Oh, there we go. [clears throat] It's a
00:54:14.720 --> 00:54:17.430
service alert in the UK.
00:54:17.440 --> 00:54:20.630
Excuse me. Don't know what it's for. Uh
00:54:20.640 --> 00:54:22.790
oh, wildfires. There we go. There's uh
00:54:22.800 --> 00:54:24.470
everybody there's wildfires in the UK.
00:54:24.480 --> 00:54:26.470
That's why we smoke. [laughter]
00:54:26.480 --> 00:54:27.990
Um,
00:54:28.000 --> 00:54:30.470
>> yeah, like context, metric layers,
00:54:30.480 --> 00:54:32.470
platforms, all that all that other stuff
00:54:32.480 --> 00:54:35.030
that's uh
00:54:35.040 --> 00:54:37.589
it's not a wildfire in the UK that um
00:54:37.599 --> 00:54:39.270
stuff that's been happening for a while.
00:54:39.280 --> 00:54:41.910
But uh yeah, the idea that we kind of
00:54:41.920 --> 00:54:43.589
both stumbled across master data
00:54:43.599 --> 00:54:45.030
management stuff at the moment as well,
00:54:45.040 --> 00:54:46.790
that did freak me out. So
00:54:46.800 --> 00:54:49.430
>> yeah, it worked out though. It gave us a
00:54:49.440 --> 00:54:51.750
good topic for today for sure.
00:54:51.760 --> 00:54:54.950
H [sighs and gasps] I have
00:54:54.960 --> 00:54:58.790
lost.
00:54:58.800 --> 00:55:02.470
>> Oh, there you go. I'm back again.
00:55:02.480 --> 00:55:03.270
>> You're back.
00:55:03.280 --> 00:55:06.069
>> I'm back. Yep. Excellent. All right.
00:55:06.079 --> 00:55:08.309
Well, thank you very much and uh we'll
00:55:08.319 --> 00:55:11.109
catch up with you in a month's time.
00:55:11.119 --> 00:55:12.309
>> Sounds great.
00:55:12.319 --> 00:55:13.829
>> Excellent. All right. Catch everybody
00:55:13.839 --> 00:55:17.880
later everybody. Bye.