Microsoft Purview is a Trap: The Hard Truth About Data Governance

1
00:00:00,000 --> 00:00:03,760
Microsoft purview isn't something you install, it's already in your tenant, waiting.

2
00:00:03,760 --> 00:00:07,040
You don't buy it, you don't go through a vendor evaluation, it's just there.

3
00:00:07,040 --> 00:00:10,680
Part of your Microsoft 365 subscription, it sits in the background like a feature you

4
00:00:10,680 --> 00:00:12,720
haven't thought about yet, and that's the trap.

5
00:00:12,720 --> 00:00:16,680
You flip a switch, there is no procurement gate to stop you, there is no planning meeting,

6
00:00:16,680 --> 00:00:19,760
there is no moment that forces you to sit down and ask, what are we actually trying to

7
00:00:19,760 --> 00:00:20,760
do here?

8
00:00:20,760 --> 00:00:23,280
What question does this catalog answer, who owns the answer?

9
00:00:23,280 --> 00:00:26,920
Six weeks later, the collection admin role has sprawled across your organization.

10
00:00:26,920 --> 00:00:29,680
Data governance teams can't say who has access to what.

11
00:00:29,680 --> 00:00:34,360
Nobody owns a single data product, the catalog is locked down and wide open at the same time.

12
00:00:34,360 --> 00:00:38,040
Business users opened it once, found chaos and stopped coming back, you have thousands

13
00:00:38,040 --> 00:00:41,960
of assets, you have policies nobody understands, you have roles assigned to people who don't

14
00:00:41,960 --> 00:00:45,520
even remember getting them, that's not a tooling problem, that's a rollout problem.

15
00:00:45,520 --> 00:00:49,800
This episode is about the structural flaw in how most organizations approach data governance

16
00:00:49,800 --> 00:00:51,720
and how to fix it.

17
00:00:51,720 --> 00:00:54,280
The problem, why ease becomes a trap?

18
00:00:54,280 --> 00:00:58,200
Starting costs nothing, so most teams start with nothing in mind, there is no friction,

19
00:00:58,200 --> 00:00:59,640
there is no forcing function, there is no problem.

20
00:00:59,640 --> 00:01:04,120
No moment where someone has to justify the investment or define success, you just turn it on and

21
00:01:04,120 --> 00:01:08,360
because you can scan without asking why, you do, you scan every source, you hand out access

22
00:01:08,360 --> 00:01:12,720
to whoever asks, you build no structure around it, the swamp builds itself, the catalog fills

23
00:01:12,720 --> 00:01:16,960
with thousands of assets nobody asked for, the claims table, the payouts table, the customer

24
00:01:16,960 --> 00:01:21,120
reference data, the temporary staging area someone created last month and forgot about,

25
00:01:21,120 --> 00:01:25,640
all of it flows into the same searchable space, undifferentiated, unlabeled and untouched

26
00:01:25,640 --> 00:01:26,640
by strategy.

27
00:01:26,640 --> 00:01:31,600
Permission sprawl, you grant collection admin to one team so they can manage their own registrations,

28
00:01:31,600 --> 00:01:35,240
then another team needs it, then the finance team, then the risk team, six months later you

29
00:01:35,240 --> 00:01:38,640
have 12 collection admins scattered across the organization.

30
00:01:38,640 --> 00:01:41,960
Nobody can say who has permission to do what, nobody can audit it, nobody can fix it without

31
00:01:41,960 --> 00:01:45,760
breaking someone's workflow, business users open the catalog once, they search for something

32
00:01:45,760 --> 00:01:49,240
they care about, they get back 10 results that look nothing like what they need, a raw

33
00:01:49,240 --> 00:01:53,240
table name, a technical field description, a timestamp column from a system nobody's heard

34
00:01:53,240 --> 00:01:54,240
of.

35
00:01:54,240 --> 00:01:56,600
They leave, they never come back, you spend the budget, you turn on the tools.

36
00:01:56,600 --> 00:02:01,000
You show leadership the feature, you lost the trust, the real cost isn't the licensing.

37
00:02:01,000 --> 00:02:04,920
It's not the storage, it's not even the time spent on misconfiguration, the real cost

38
00:02:04,920 --> 00:02:07,200
is the change management you never planned for.

39
00:02:07,200 --> 00:02:11,200
The organizational discipline required to make the catalog work, the business alignment

40
00:02:11,200 --> 00:02:14,640
that's harder to build after you've already scanned everything than it was to define before

41
00:02:14,640 --> 00:02:15,640
you started.

42
00:02:15,640 --> 00:02:19,960
Most organizations treat per view like a technology deployment, turn it on, configure it, run

43
00:02:19,960 --> 00:02:23,000
some scans, declare victory.

44
00:02:23,000 --> 00:02:26,240
But governance isn't technology, governance is structure.

45
00:02:26,240 --> 00:02:30,640
It's the deliberate choices you make about ownership, accountability and how information

46
00:02:30,640 --> 00:02:31,640
flows.

47
00:02:31,640 --> 00:02:32,720
Those choices have to come first.

48
00:02:32,720 --> 00:02:34,120
The tool is the byproduct.

49
00:02:34,120 --> 00:02:38,040
When you flip the switch without asking why you get a filing cabinet with the lights on,

50
00:02:38,040 --> 00:02:41,920
you get organization theater, you get the appearance of control with none of the substance

51
00:02:41,920 --> 00:02:45,160
and the deeper the catalog gets, the harder it is to undo.

52
00:02:45,160 --> 00:02:49,240
This is the moment where teams realize we moved fast and broke governance, we have to rebuild

53
00:02:49,240 --> 00:02:53,480
the entire model, we have to reassign permissions, we have to rename collections, we have to explain

54
00:02:53,480 --> 00:02:58,240
to business owners why their data disappeared and then reappeared in a different place, start

55
00:02:58,240 --> 00:03:01,840
from that point, from the consequence of doing it wrong and you understand why the right

56
00:03:01,840 --> 00:03:03,560
sequence matters.

57
00:03:03,560 --> 00:03:07,720
The real failure, big bang versus use case first, teams that end up with a mess don't start

58
00:03:07,720 --> 00:03:12,000
out trying to fail, they think they're being rational, they want to catalog the entire data

59
00:03:12,000 --> 00:03:16,560
estate, they look at the org chart, finance has data, sales has data, operations engineering

60
00:03:16,560 --> 00:03:21,040
claims, they all have data, so the team creates a collection for every department, they scan

61
00:03:21,040 --> 00:03:24,880
every single thing those departments own, they try to make every asset discoverable, it

62
00:03:24,880 --> 00:03:30,120
feels like progress, it feels like governance, but in reality it's the opposite.

63
00:03:30,120 --> 00:03:34,240
The moment you decide to catalog everything you've already failed, not because you didn't

64
00:03:34,240 --> 00:03:38,520
work hard enough, but because of your intent you chose to build for completeness, instead

65
00:03:38,520 --> 00:03:42,320
of building for a person, that distinction is fatal.

66
00:03:42,320 --> 00:03:46,000
Completeness without a specific purpose is just noise, it's a mountain of metadata about

67
00:03:46,000 --> 00:03:50,000
things nobody ever asked for, it's organized in a way that makes sense to the platform team,

68
00:03:50,000 --> 00:03:53,960
but it means nothing to the person who actually needs an answer, it's a massive failure disguised

69
00:03:53,960 --> 00:03:58,920
as total coverage, here is what actually matters, a use case is one sentence, it's one business

70
00:03:58,920 --> 00:04:02,800
question that a real human is waiting on right now, it's not, let's catalog our customer

71
00:04:02,800 --> 00:04:08,000
data, it's which customers paid their invoices on time for the last five cycles, it's

72
00:04:08,000 --> 00:04:12,440
not, we should organize our risk data, it's which loan applicants in the pipeline have

73
00:04:12,440 --> 00:04:18,520
a 30% chance of defaulting in year two, it's not, let's make our operational data discoverable,

74
00:04:18,520 --> 00:04:23,280
it's which claims are most likely to be fraudulent this quarter, that last sentence is specific

75
00:04:23,280 --> 00:04:28,000
enough to define your entire project, it tells you exactly which sources matter, like the

76
00:04:28,000 --> 00:04:32,520
policy admin system, the historical claims database and the payout records, it identifies

77
00:04:32,520 --> 00:04:36,400
the people who actually need the data, like fraud analysts and claims managers, it even

78
00:04:36,400 --> 00:04:40,160
tells you what success looks like, which is a score or a list that someone can actually

79
00:04:40,160 --> 00:04:44,160
act on, and it tells you what doesn't matter, you don't need customer service core logs,

80
00:04:44,160 --> 00:04:48,200
you don't need billing adjustment tables, you definitely don't need that test data someone

81
00:04:48,200 --> 00:04:52,000
created three years ago, none of that helps answer the question, so none of it belongs in

82
00:04:52,000 --> 00:04:56,000
the product, one use case pulls the entire rollout forward, when you start with a question

83
00:04:56,000 --> 00:05:00,200
instead of a checklist, everything changes, you don't catalog everything, you only register

84
00:05:00,200 --> 00:05:05,080
what the question requires, you don't create a claims collection and scan 10 years of archives

85
00:05:05,080 --> 00:05:09,760
and backups, instead you only pull in the policy table and the payouts that feed the fraud

86
00:05:09,760 --> 00:05:14,000
model, nothing else, you don't give the whole company read access to the catalog, you

87
00:05:14,000 --> 00:05:17,680
give it to the fraud team, you give it to the claims managers, you give it to the people

88
00:05:17,680 --> 00:05:21,280
who are actually going to use the answer, nobody else needs it yet, you don't build a governance

89
00:05:21,280 --> 00:05:25,400
domain for claims and fill it with random volunteers, you find the people who own fraud

90
00:05:25,400 --> 00:05:30,080
prevention, you assign one owner maybe two for backup and you let them run it, no committees,

91
00:05:30,080 --> 00:05:34,920
no forums, just owners, you don't just scan and hope something useful pops out, you scan

92
00:05:34,920 --> 00:05:39,200
the specific sources that answer the question, you build one data product and you test it with

93
00:05:39,200 --> 00:05:43,840
the fraud team, you measure if the model works and then you hand it over, that isn't a rollout,

94
00:05:43,840 --> 00:05:47,960
it's a pilot, it's controlled, it's focused and it delivers value you can actually see,

95
00:05:47,960 --> 00:05:52,080
the big bang approach creates noise and lets people hide from responsibility, everyone sees

96
00:05:52,080 --> 00:05:57,200
the data but nobody owns it, the use case first model creates focus, one team, one question,

97
00:05:57,200 --> 00:06:01,720
one answer and one owner, the chaos you see in most deployments doesn't come from the tool,

98
00:06:01,720 --> 00:06:06,080
it comes from the decision to organize for completeness instead of organizing for a customer.

99
00:06:06,080 --> 00:06:08,680
The second you ask, what should we catalog?

100
00:06:08,680 --> 00:06:12,600
Instead of what question should we answer, you've chosen noise over signal that one

101
00:06:12,600 --> 00:06:16,000
choice ruins everything that follows from your permissions and structure to the trust your

102
00:06:16,000 --> 00:06:19,920
users have in the system, now that we see where it breaks, let's look at the structure

103
00:06:19,920 --> 00:06:24,680
that actually keeps it together, the four layer permission blueprint, overview, nobody

104
00:06:24,680 --> 00:06:28,600
tells you this when you get your purview tenant but access control isn't just one thing,

105
00:06:28,600 --> 00:06:30,320
it's four.

106
00:06:30,320 --> 00:06:34,400
Most teams find this out the hard way, an analyst asks for read access so you grant it

107
00:06:34,400 --> 00:06:38,080
but they still can't see anything, you grant more power and suddenly they see things

108
00:06:38,080 --> 00:06:41,880
they shouldn't, you lock it down and now nobody can work, you spend an entire week

109
00:06:41,880 --> 00:06:45,280
debugging permissions and you still don't know where the boundaries are.

110
00:06:45,280 --> 00:06:49,960
The problem is that purview spreads access across four distinct layers, each one handles a

111
00:06:49,960 --> 00:06:53,680
different type of power, they each have their own roles and their own logic and they don't

112
00:06:53,680 --> 00:06:57,840
talk to each other, the four layers are the tenant level, the data map, the unified catalog

113
00:06:57,840 --> 00:07:01,760
settings and the governance domain, the tenant level is for the platform admins, these

114
00:07:01,760 --> 00:07:05,480
are the people who create domains and configure the whole account, they hold the keys to the

115
00:07:05,480 --> 00:07:09,240
kingdom and control who has the power to build in the first place, the data map is where

116
00:07:09,240 --> 00:07:10,960
the metadata actually lives.

117
00:07:10,960 --> 00:07:14,880
This is where you find your collections, your data sources and your scan settings, this

118
00:07:14,880 --> 00:07:19,080
layer controls who can see the raw metadata coming from your SQL databases or your fabric

119
00:07:19,080 --> 00:07:20,080
workspaces.

120
00:07:20,080 --> 00:07:23,960
The unified catalog is your control panel, this is where you assign roles for the glossary,

121
00:07:23,960 --> 00:07:27,720
data products and business concepts, it's the layer that manages the actual business

122
00:07:27,720 --> 00:07:29,120
meaning of your data.

123
00:07:29,120 --> 00:07:33,800
The governance domain is where ownership finally happens, this is where domain owners delegate

124
00:07:33,800 --> 00:07:37,720
tasks to stewards and data product owners, it's where the business actually runs the show

125
00:07:37,720 --> 00:07:40,000
and defines what the data represents.

126
00:07:40,000 --> 00:07:43,800
There are two rules that sit above all of this, if you get these wrong, the whole system

127
00:07:43,800 --> 00:07:45,240
falls apart.

128
00:07:45,240 --> 00:07:49,520
Rule number one is to always assign roles to intro groups, never to individuals, the moment

129
00:07:49,520 --> 00:07:54,200
you start adding people one by one, you lose the ability to manage the system, you lose

130
00:07:54,200 --> 00:07:58,960
your audit trail and you create technical debt that will take months to fix, use groups,

131
00:07:58,960 --> 00:08:00,640
every single time.

132
00:08:00,640 --> 00:08:04,440
Rule number two is to avoid creating a group for every single role in every layer, this

133
00:08:04,440 --> 00:08:08,200
is the instinct that kills most projects, you see four layers and dozens of roles, so

134
00:08:08,200 --> 00:08:13,760
you think you need a group for each one, you make a per view admin group, a data reader group

135
00:08:13,760 --> 00:08:18,040
and a collection admin group, then you realize you need five different versions of those

136
00:08:18,040 --> 00:08:21,440
for five different business units, suddenly you have 50 groups and nobody knows what they

137
00:08:21,440 --> 00:08:25,640
do, stop, a real person doesn't live in just one layer, an analyst who needs to read the

138
00:08:25,640 --> 00:08:30,080
catalog needs a role in the unified catalog and a reader role in the data map, that's

139
00:08:30,080 --> 00:08:33,600
two different layers, if you split those into two separate groups, you will spend your entire

140
00:08:33,600 --> 00:08:37,960
career debugging half-granted access, you need to bundle the permissions, a specific persona

141
00:08:37,960 --> 00:08:43,040
needs into one single group, package them together, create one group that says this person is a

142
00:08:43,040 --> 00:08:46,960
data reader and give that group the right roles across all the layers at once, you have four

143
00:08:46,960 --> 00:08:50,640
layers but you only need about five groups, you'll end up with more groups than layers

144
00:08:50,640 --> 00:08:54,760
because a group should be shaped around a human being, not around the software architecture,

145
00:08:54,760 --> 00:08:59,200
this is the difference between a mess and a structure, so let's break down each layer

146
00:08:59,200 --> 00:09:04,520
and see what they actually control, layer one, tenant level, the keys to everything, this

147
00:09:04,520 --> 00:09:08,360
layer is assigned at the organizational level, it sits above everything else, it applies

148
00:09:08,360 --> 00:09:12,840
to both the data map and the unified catalog, if you control the tenant level, you control

149
00:09:12,840 --> 00:09:17,000
who gets to build the platform, who assigns roles and who decides what people are allowed

150
00:09:17,000 --> 00:09:21,200
to see, two role groups matter here, the first is purview administrators, these are the people

151
00:09:21,200 --> 00:09:25,440
who create and delete domains, assign roles in the data map and configure the account, they

152
00:09:25,440 --> 00:09:29,400
can do almost anything, the second is data governance, this role carries the data governance

153
00:09:29,400 --> 00:09:33,760
admin assignment, which acts as the bridge between the tenant level and the business side,

154
00:09:33,760 --> 00:09:37,840
it delegates the first level of catalog access down to the next layer, before you assign

155
00:09:37,840 --> 00:09:42,280
anyone to these groups, check your account type, unified catalog features, sit behind enterprise

156
00:09:42,280 --> 00:09:46,120
licensing, not the free tier, if you're on the free version, you have scanning and basic

157
00:09:46,120 --> 00:09:51,040
discovery, but you don't have governance domains or data products, you have a catalog,

158
00:09:51,040 --> 00:09:55,360
but you lack the business structure that makes a catalog worth maintaining, if you are

159
00:09:55,360 --> 00:09:59,080
on enterprise, keep this layer tiny, this is the one place where you actually want the

160
00:09:59,080 --> 00:10:04,200
fewest people possible, no more than two or three admins on the default domain, not a team,

161
00:10:04,200 --> 00:10:08,840
not a department, three people maximum, here is the structure that works, make one a service

162
00:10:08,840 --> 00:10:12,600
principle, service principles are non-human identities used for automation, they don't

163
00:10:12,600 --> 00:10:17,000
need MFA, they don't need to remember passwords, and they handle the repetitive work that

164
00:10:17,000 --> 00:10:21,640
makes a human admins job tedious, they run scans and register sources, then they stop,

165
00:10:21,640 --> 00:10:25,840
they don't have broad discretionary power, make the second a break-class account, this

166
00:10:25,840 --> 00:10:29,600
is an account you touch only in an emergency, it stays stored securely, documented and

167
00:10:29,600 --> 00:10:34,200
audited, it isn't for day to day work, it exists in case the primary admin leaves the company

168
00:10:34,200 --> 00:10:38,520
or the main account gets compromised, it is your backstop.

169
00:10:38,520 --> 00:10:42,320
The third admin, if you even need one, is your primary working account, this is the person

170
00:10:42,320 --> 00:10:47,000
who manages the platform during normal operations, because this role can raise its own permissions,

171
00:10:47,000 --> 00:10:50,800
it should have the shortest activation window and the strictest approval requirements,

172
00:10:50,800 --> 00:10:55,400
that is the fear you need to understand, per view administrators can change almost anything,

173
00:10:55,400 --> 00:11:00,200
including their own access levels, they can make themselves a governance domain owner,

174
00:11:00,200 --> 00:11:04,600
elevate themselves to any level or grant themselves access to sensitive data products,

175
00:11:04,600 --> 00:11:08,720
a compromised admin at this level can do more damage than most people realize, never

176
00:11:08,720 --> 00:11:12,680
hand this out a standing access, never create a permanent member of the per view administrators

177
00:11:12,680 --> 00:11:16,960
group who logs in every day with that role active, that is a breach waiting for a calendar

178
00:11:16,960 --> 00:11:21,720
invite, the tenant layer decides who configures the platform, but the data map layer decides

179
00:11:21,720 --> 00:11:27,240
where your metadata physically lives, layer 2, data map, collections and domains, the data

180
00:11:27,240 --> 00:11:31,760
map is where metadata physically lives, it is your registry of every asset you have scanned,

181
00:11:31,760 --> 00:11:35,560
every source you have registered and every table that exists in your environment, this

182
00:11:35,560 --> 00:11:41,040
layer keeps an up to date map of your assets, you shape it with two tools, domains and collections,

183
00:11:41,040 --> 00:11:45,160
they sound similar but they serve completely different purposes, domains are technical

184
00:11:45,160 --> 00:11:49,920
boundaries, they sit at the top of the hierarchy to separate credentials, connections and scan

185
00:11:49,920 --> 00:11:55,400
rule sets, a domain is where you define which Azure SQL databases or snowflake connections

186
00:11:55,400 --> 00:12:00,040
get registered and which credentials apply to them, you get one default domain automatically

187
00:12:00,040 --> 00:12:03,600
when your per view account is set up, you can add up to four custom domains but you should

188
00:12:03,600 --> 00:12:07,560
only use them if you have a real technical boundary, a separate region or a legal entity

189
00:12:07,560 --> 00:12:11,960
with different regulations might justify it, but don't use domains for dev versus production,

190
00:12:11,960 --> 00:12:16,280
that split belongs in collections, don't use them to separate the platform team from

191
00:12:16,280 --> 00:12:20,240
the business unit that is an organizational distinction not a technical one, domains are

192
00:12:20,240 --> 00:12:24,160
expensive to manage so keep them minimal, collections are operational and access centric,

193
00:12:24,160 --> 00:12:28,320
they are your security boundary for metadata, they are the actual containers where your sources

194
00:12:28,320 --> 00:12:33,640
land and your scanned assets appear, a per view account supports up to 1000 collections

195
00:12:33,640 --> 00:12:37,920
organized up to eight levels deep, you almost certainly do not want that depth, resist the

196
00:12:37,920 --> 00:12:41,760
urge to nest collections to mirror your organizational chart, collections are meant to

197
00:12:41,760 --> 00:12:46,120
be navigable, if someone opens the catalog and finds a 16 level hierarchy that matches

198
00:12:46,120 --> 00:12:50,760
the company reporting structure, they will leave to find a spreadsheet, four data map roles

199
00:12:50,760 --> 00:12:55,240
control access within these collections, each one is assigned per collection and inherited

200
00:12:55,240 --> 00:12:59,520
by child collections, the collection admin manages the collection and assigns roles, the

201
00:12:59,520 --> 00:13:03,920
data source admin registers sources and runs scans, the data curator maintains metadata

202
00:13:03,920 --> 00:13:08,360
and certifies assets, the data reader can view the metadata, here is the critical inside

203
00:13:08,360 --> 00:13:13,440
most teams get wrong, shape collections around your internal business domains, not your platforms,

204
00:13:13,440 --> 00:13:17,560
your instinct will be to organize by what you see, as you are a sequel here, snowflake over

205
00:13:17,560 --> 00:13:22,160
there, a fabric workspace in another collection, platform teams think in platforms, which is

206
00:13:22,160 --> 00:13:27,040
natural but it is also backwards, collections are what business users browse and filter, the

207
00:13:27,040 --> 00:13:31,120
boundary they see must be a business boundary, not a technical one, when a claims analyst

208
00:13:31,120 --> 00:13:35,680
opens per view, they expect to see a collection labeled claims, they don't want to see Azure

209
00:13:35,680 --> 00:13:40,440
SQL policy admin database or snowflake premium cluster, if they work in pricing they

210
00:13:40,440 --> 00:13:44,280
expect to see underwriting and pricing, if they are in finance they expect to see finance,

211
00:13:44,280 --> 00:13:48,080
when the analyst opens the claims collection they know they are home, everything relevant

212
00:13:48,080 --> 00:13:52,800
to their job is in that one place, the raw claims table might live in Azure SQL while

213
00:13:52,800 --> 00:13:57,360
the enriched features live in fabric and the reports live in power BI, all of them belong

214
00:13:57,360 --> 00:14:01,240
in the claims collection, the platform is just an implementation detail, the business

215
00:14:01,240 --> 00:14:05,880
domain is the label that matters, platform teams still run the scans, the engineering team

216
00:14:05,880 --> 00:14:10,040
registers the SQL database and the fabric workspace, they configure the scan roles, that

217
00:14:10,040 --> 00:14:15,200
is operational work, but the label the business sees belongs to the business, the claims collection,

218
00:14:15,200 --> 00:14:20,000
the finance collection, the customer collection, there is one registration rule you need to know,

219
00:14:20,000 --> 00:14:24,040
you cannot register the same source twice in one account, if several teams need access

220
00:14:24,040 --> 00:14:29,000
to the same database register it in apparent collection and scan into subcollections, this

221
00:14:29,000 --> 00:14:33,880
ensures assets appear where each team expects them to be, environments splits like dev, test

222
00:14:33,880 --> 00:14:38,360
and production also live in collections, a half build test table should never sit beside

223
00:14:38,360 --> 00:14:42,720
production claims data because they are separated into different collections, keep collection

224
00:14:42,720 --> 00:14:47,000
admins few, this is where the sprawl begins if you are not careful, assign collection admin

225
00:14:47,000 --> 00:14:51,360
roles at the top level or at a specific subcollection, but never scatter them across the account

226
00:14:51,360 --> 00:14:55,960
like random permissions, collections answer where metadata sits and who can touch it, they

227
00:14:55,960 --> 00:15:00,000
do not answer what the business calls it or who owns the meaning, that is the next layers

228
00:15:00,000 --> 00:15:05,920
job, layer three unified catalog, the control panel, unified catalog lives inside the settings

229
00:15:05,920 --> 00:15:10,320
menu of the purview portal, you go to settings then unified catalog, this is the single control

230
00:15:10,320 --> 00:15:14,120
panel for the business side of your data, it's where you manage governance domains, data

231
00:15:14,120 --> 00:15:18,400
products, glossary terms and access policies, if you are getting support tickets asking why

232
00:15:18,400 --> 00:15:22,360
can't I see this, the answer usually starts right here, but before you start handing out

233
00:15:22,360 --> 00:15:27,240
access you need to look at a massive vulnerability most teams miss, it's called live view, if

234
00:15:27,240 --> 00:15:32,400
a user has red access on an Azure resource or a fabric workspace, they can see that asset

235
00:15:32,400 --> 00:15:36,520
in the unified catalog, they don't need purview permissions, they don't need your permission,

236
00:15:36,520 --> 00:15:40,840
Azure roles flow directly into the catalog and surface assets you might think are private,

237
00:15:40,840 --> 00:15:45,240
you need to audit your cloud resource permissions before you assume the catalog is locked down.

238
00:15:45,240 --> 00:15:49,720
If you don't, you'll wake up six months from now and realize the entire engineering team

239
00:15:49,720 --> 00:15:54,040
can see sensitive data products just because they have a reader role on the underlying storage

240
00:15:54,040 --> 00:15:56,160
account.

241
00:15:56,160 --> 00:16:00,840
Unified catalog uses three permission levels, tenant, catalog and governance domain, you've

242
00:16:00,840 --> 00:16:05,200
already handled the tenant level where the purview administrators live, the catalog level is

243
00:16:05,200 --> 00:16:09,480
different, this is where roles reach across every single governance domain in your account.

244
00:16:09,480 --> 00:16:13,440
The governance domain creator builds new domains and hands off ownership.

245
00:16:13,440 --> 00:16:16,960
The global catalog reader can see published concepts across the whole company unless the

246
00:16:16,960 --> 00:16:18,720
specific domain blocks them.

247
00:16:18,720 --> 00:16:23,160
The global asset curator attaches glossary terms to assets and columns anywhere in the catalog.

248
00:16:23,160 --> 00:16:26,960
Finally, the data health owner and data health reader manage the quality reporting that spans

249
00:16:26,960 --> 00:16:30,720
your entire estate, you need to be very careful with the reader roles because people constantly

250
00:16:30,720 --> 00:16:31,840
mix them up.

251
00:16:31,840 --> 00:16:34,920
Global catalog reader lets someone see published concepts everywhere.

252
00:16:34,920 --> 00:16:38,640
Local catalog reader, which you set inside a specific domain, limits their view to just

253
00:16:38,640 --> 00:16:39,840
that one area.

254
00:16:39,840 --> 00:16:42,160
You use the local version for regulatory walls.

255
00:16:42,160 --> 00:16:45,960
If data in one domain must stay invisible to everyone else for legal reasons, that's your

256
00:16:45,960 --> 00:16:46,960
tool.

257
00:16:46,960 --> 00:16:50,660
But if you overuse it, you'll fragment the catalog and end up rebuilding the exact same

258
00:16:50,660 --> 00:16:53,400
silos you were trying to break down in the first place.

259
00:16:53,400 --> 00:16:54,920
Here is the counter intuitive part.

260
00:16:54,920 --> 00:16:57,480
Your first instinct will be to lock everything down.

261
00:16:57,480 --> 00:17:01,240
You'll want to keep reader access tight and only open it for people who prove they needed,

262
00:17:01,240 --> 00:17:02,440
resist that.

263
00:17:02,440 --> 00:17:04,560
A reader sees metadata, not the actual data.

264
00:17:04,560 --> 00:17:07,160
They see table names, column descriptions, owners and lineage.

265
00:17:07,160 --> 00:17:10,480
They see the structure, but they never see customer records or financial details.

266
00:17:10,480 --> 00:17:12,840
They see what the data is, not what it contains.

267
00:17:12,840 --> 00:17:16,440
You should default to broad read access and give almost everyone in the company a reader

268
00:17:16,440 --> 00:17:17,440
role.

269
00:17:17,440 --> 00:17:19,520
A catalog that nobody can see isn't actually a catalog.

270
00:17:19,520 --> 00:17:22,080
It's just a bureaucracy pretending to be discovery.

271
00:17:22,080 --> 00:17:26,160
Save your hard restrictions for real regulatory boundaries, where the law says the data must

272
00:17:26,160 --> 00:17:27,280
stay hidden.

273
00:17:27,280 --> 00:17:30,720
When you hit those walls, you need to actually verify the restriction works before you tell

274
00:17:30,720 --> 00:17:32,280
anyone it's secure.

275
00:17:32,280 --> 00:17:35,680
There is one more rule you have to remember from the data map layer.

276
00:17:35,680 --> 00:17:38,400
Catalog read access by itself doesn't show you asset details.

277
00:17:38,400 --> 00:17:42,120
A reader still needs data reader access down in the data map to see what the scanned data

278
00:17:42,120 --> 00:17:43,400
actually looks like.

279
00:17:43,400 --> 00:17:45,960
This means one persona lives across two different layers.

280
00:17:45,960 --> 00:17:49,320
If you give someone global catalog reader, but forget to give them data reader, in the

281
00:17:49,320 --> 00:17:52,360
collections, they'll see the business concept but not the asset.

282
00:17:52,360 --> 00:17:54,840
They might understand what a suspicious claim is.

283
00:17:54,840 --> 00:17:58,040
But they won't be able to see which specific claims match that definition.

284
00:17:58,040 --> 00:18:00,560
To get the full picture, they need permissions in both places.

285
00:18:00,560 --> 00:18:03,440
This is where the business meaning connects to the physical data.

286
00:18:03,440 --> 00:18:06,720
And the next layer is where the business owners finally take the lead.

287
00:18:06,720 --> 00:18:09,760
Layer four, governance domain level, where business shows up.

288
00:18:09,760 --> 00:18:11,760
A governance domain is a boundary for ownership.

289
00:18:11,760 --> 00:18:14,040
It's fundamentally different from the layers below it.

290
00:18:14,040 --> 00:18:18,240
The data map handles the structure and the catalog handles visibility, but the governance

291
00:18:18,240 --> 00:18:20,200
domain is about power.

292
00:18:20,200 --> 00:18:21,760
This is where your business concepts live.

293
00:18:21,760 --> 00:18:26,080
It's where you find glossary terms that define what a suspicious claim actually means.

294
00:18:26,080 --> 00:18:30,720
It's where you find the OKRs that tie data to your strategy and the policies that decide

295
00:18:30,720 --> 00:18:31,720
who gets access.

296
00:18:31,720 --> 00:18:34,960
In this layer, the business owners run the show, not the platform teams.

297
00:18:34,960 --> 00:18:36,120
The roles change here too.

298
00:18:36,120 --> 00:18:39,920
You have the governance domain owner who is accountable for everything in that domain.

299
00:18:39,920 --> 00:18:41,280
You should always have at least two of them.

300
00:18:41,280 --> 00:18:43,400
A single owner is a single point of failure.

301
00:18:43,400 --> 00:18:47,200
If they leave the company or get promoted, the whole domain stalls out.

302
00:18:47,200 --> 00:18:50,800
Having two owners ensures the work keeps moving, then you have the data steward.

303
00:18:50,800 --> 00:18:52,080
They manage the business meaning.

304
00:18:52,080 --> 00:18:55,200
They handle the glossary, the OKRs and the policies.

305
00:18:55,200 --> 00:18:56,920
They are the keepers of definitions.

306
00:18:56,920 --> 00:19:00,840
Their job is to make sure that when someone says suspicious claim, everyone in the organization

307
00:19:00,840 --> 00:19:02,200
is talking about the same thing.

308
00:19:02,200 --> 00:19:04,480
The data product owner builds the actual products.

309
00:19:04,480 --> 00:19:08,760
They define the scope, decide which assets belong, and approve the quality standards.

310
00:19:08,760 --> 00:19:11,200
They own the relationship with the people using the data.

311
00:19:11,200 --> 00:19:14,760
When someone asks for access, the product owner is the one who decides if it makes sense

312
00:19:14,760 --> 00:19:16,720
to grant it.

313
00:19:16,720 --> 00:19:18,800
The governance domain reader is the simplest role.

314
00:19:18,800 --> 00:19:22,640
They can see the published metadata within that domain, but they can't change anything.

315
00:19:22,640 --> 00:19:24,960
They are there to discover what's already been built.

316
00:19:24,960 --> 00:19:28,560
On top of all this, you have specialized quality roles like data quality stewards and data

317
00:19:28,560 --> 00:19:29,640
quality readers.

318
00:19:29,640 --> 00:19:31,400
They don't worry about definitions or products.

319
00:19:31,400 --> 00:19:33,440
They just focus on the health of the data.

320
00:19:33,440 --> 00:19:36,320
This is where the abstraction stops and things get operational.

321
00:19:36,320 --> 00:19:40,080
To add a data asset to a product, a data product owner needs two things.

322
00:19:40,080 --> 00:19:44,440
They need that domain role in this layer, but they also need data reader access down in

323
00:19:44,440 --> 00:19:45,440
the data map.

324
00:19:45,440 --> 00:19:49,000
This is the ownership and physical access meet at this exact point.

325
00:19:49,000 --> 00:19:51,000
This isn't a mistake in the software.

326
00:19:51,000 --> 00:19:52,000
It's the design.

327
00:19:52,000 --> 00:19:56,200
The data map controls the technical metadata, while the governance domain controls the business

328
00:19:56,200 --> 00:19:57,200
decisions.

329
00:19:57,200 --> 00:19:58,760
You need both to actually function.

330
00:19:58,760 --> 00:20:01,720
This is the moment where the four layers become a working system.

331
00:20:01,720 --> 00:20:06,040
A governance domain owner assigns roles, then those people delegate the work to stewards

332
00:20:06,040 --> 00:20:07,240
and product owners.

333
00:20:07,240 --> 00:20:11,360
The steward defines the terms, the product owner builds the product, and the reader discovers

334
00:20:11,360 --> 00:20:12,360
it.

335
00:20:12,360 --> 00:20:16,240
It works unless the stewards and product owners also have data reader access in the right

336
00:20:16,240 --> 00:20:17,240
collections.

337
00:20:17,240 --> 00:20:18,400
These aren't four separate worlds.

338
00:20:18,400 --> 00:20:21,280
They are four different ways of looking at the same problem.

339
00:20:21,280 --> 00:20:23,560
The tenant layer decides who builds the system.

340
00:20:23,560 --> 00:20:25,600
The data map decides who manages the discovery.

341
00:20:25,600 --> 00:20:30,120
The catalog layer decides who sees the concepts, and the governance domain decides who owns

342
00:20:30,120 --> 00:20:31,120
the business.

343
00:20:31,120 --> 00:20:32,800
Each layer holds a different kind of power.

344
00:20:32,800 --> 00:20:36,120
You need all of them, and they only work if you are intentional about how you set them

345
00:20:36,120 --> 00:20:37,120
up.

346
00:20:37,120 --> 00:20:40,000
Now that you have the layers, the real question is how you turn them into a system

347
00:20:40,000 --> 00:20:41,360
that actually works.

348
00:20:41,360 --> 00:20:44,600
The five role groups, packaging permissions into reality.

349
00:20:44,600 --> 00:20:46,480
Most blueprints fall apart right here.

350
00:20:46,480 --> 00:20:50,920
You look at the four layers, tenant, data map, catalog, and governance domain, and you

351
00:20:50,920 --> 00:20:53,360
see dozens of roles scattered across them.

352
00:20:53,360 --> 00:20:56,160
The immediate instinct is to build a group for every single role.

353
00:20:56,160 --> 00:21:00,080
You create a purview administrator group, a unified catalog admin group, and a collection

354
00:21:00,080 --> 00:21:01,080
admin group.

355
00:21:01,080 --> 00:21:04,280
Then you add a data reader group and a governance domain owner group.

356
00:21:04,280 --> 00:21:07,040
You build a data steward group for claims and another for finance.

357
00:21:07,040 --> 00:21:10,720
Before you know it, you need five different collection admin groups because five different

358
00:21:10,720 --> 00:21:12,840
teams manage five different areas.

359
00:21:12,840 --> 00:21:17,120
One month later, you're staring at 40 groups and a massive spreadsheet just to figure out

360
00:21:17,120 --> 00:21:19,320
what a new analyst needs to do their job.

361
00:21:19,320 --> 00:21:20,840
Stop there, you're thinking about this wrong.

362
00:21:20,840 --> 00:21:23,640
A real person doesn't live in just one layer of the software.

363
00:21:23,640 --> 00:21:27,920
An analyst who needs to read the catalog also needs unified catalog read access and data

364
00:21:27,920 --> 00:21:29,600
reader access in the data map.

365
00:21:29,600 --> 00:21:33,680
A steward who manages glossary terms needs governance domain permissions, but they also need

366
00:21:33,680 --> 00:21:37,640
data map read permissions so they can actually see the assets those terms describe.

367
00:21:37,640 --> 00:21:41,280
And a domain owner needs to delegate permissions, which means they need read access across the

368
00:21:41,280 --> 00:21:44,040
data map and catalog layers to verify what they're handing out.

369
00:21:44,040 --> 00:21:48,320
If you split these permissions into separate groups, you'll spend your entire career explaining

370
00:21:48,320 --> 00:21:52,240
why someone can see a data product, but can't see the actual asset underneath it.

371
00:21:52,240 --> 00:21:56,280
You need to bundle every grant a specific persona needs into one single role group.

372
00:21:56,280 --> 00:21:59,240
It's one group per person type, not one group per role per layer.

373
00:21:59,240 --> 00:22:02,240
You want a group that says this person is a fraud analytics steward.

374
00:22:02,240 --> 00:22:04,440
They have what they need everywhere, all at once.

375
00:22:04,440 --> 00:22:06,360
The math here feels counterintuitive.

376
00:22:06,360 --> 00:22:08,960
You have four layers, but you only need about five groups.

377
00:22:08,960 --> 00:22:12,240
You end up with more groups than layers because a group is shaped around a human being

378
00:22:12,240 --> 00:22:13,960
rather than a technical tier.

379
00:22:13,960 --> 00:22:18,320
In small domains, one group might cover both steward chip and product ownership, while

380
00:22:18,320 --> 00:22:21,320
larger domains might require you to keep them separate.

381
00:22:21,320 --> 00:22:24,640
Your total count will usually drift between four and six depending on how your company is

382
00:22:24,640 --> 00:22:27,120
built, but five is the most common landing point.

383
00:22:27,120 --> 00:22:29,040
Let's walk through the groups that actually work.

384
00:22:29,040 --> 00:22:33,480
Group one is the purview administrator group, and these are the keys to the entire kingdom.

385
00:22:33,480 --> 00:22:35,840
You have to treat this group like plutonium.

386
00:22:35,840 --> 00:22:39,280
Because this role has the power to raise its own permissions, having permanent standing

387
00:22:39,280 --> 00:22:42,520
access is a security breach just waiting for a calendar invite.

388
00:22:42,520 --> 00:22:44,960
You should never make people permanent members of this group.

389
00:22:44,960 --> 00:22:49,520
Instead, make the membership eligible through Microsoft Entra-Privileged Identity Management.

390
00:22:49,520 --> 00:22:53,520
An admin activates their access only when they need it, for a few hours at a time, with a

391
00:22:53,520 --> 00:22:55,720
full audit trail and a required approval.

392
00:22:55,720 --> 00:22:59,760
The group stays empty by default and no one gets in without completing MFA and proving

393
00:22:59,760 --> 00:23:02,040
they have a specific task to finish.

394
00:23:02,040 --> 00:23:06,120
Group two is the Unified Catalog Admin Group, which is the real workhorse of the platform.

395
00:23:06,120 --> 00:23:09,320
This group is responsible for running scans and creating the collections and governance

396
00:23:09,320 --> 00:23:12,680
domains before handing ownership over to the people who will run them.

397
00:23:12,680 --> 00:23:16,280
They build the structural house, but they don't own the furniture or the business meaning

398
00:23:16,280 --> 00:23:17,280
inside.

399
00:23:17,280 --> 00:23:20,960
This isn't the group that manages stewards or assigns who owns which data product.

400
00:23:20,960 --> 00:23:24,360
Their only job is to prepare the platform so everyone else can actually use it.

401
00:23:24,360 --> 00:23:28,200
Group three is the governance domain admin group, but you don't create just one of these

402
00:23:28,200 --> 00:23:29,480
for the whole company.

403
00:23:29,480 --> 00:23:33,560
They make one for every domain, once the Unified Catalog Admin is created domain, they hand

404
00:23:33,560 --> 00:23:37,240
it off to the domain owners who then grant access to stewards and product owners within their

405
00:23:37,240 --> 00:23:38,240
own borders.

406
00:23:38,240 --> 00:23:41,760
The claims domain gets its own admin group and underwriting gets another one.

407
00:23:41,760 --> 00:23:46,160
This ensures that no central IT team has to play gatekeeper for every single access request,

408
00:23:46,160 --> 00:23:48,360
allowing each domain to be semi-autonomous.

409
00:23:48,360 --> 00:23:52,520
Group four is the data steward group and you'll need one for each business unit.

410
00:23:52,520 --> 00:23:55,960
Stewards own the actual business meaning inside their domain, which includes things like

411
00:23:55,960 --> 00:23:59,040
glossary terms, OKRs and critical data elements.

412
00:23:59,040 --> 00:24:02,680
You want to split these along business lines to ensure edit isolation, meaning a finance

413
00:24:02,680 --> 00:24:06,440
steward can't accidentally rewrite a glossary term that belongs to claims.

414
00:24:06,440 --> 00:24:11,280
This also helps with navigation as a tightly-scoped group keeps people from wandering into corners

415
00:24:11,280 --> 00:24:13,800
of the catalog where they don't belong.

416
00:24:13,800 --> 00:24:17,080
Group five is the data product owner group with one created per domain.

417
00:24:17,080 --> 00:24:20,920
The governance domain admin gives this group the right to build and manage data products

418
00:24:20,920 --> 00:24:24,720
so owners get their power from the domain rather than a ticket to IT.

419
00:24:24,720 --> 00:24:28,560
In a small domain you'll often see this group and the data steward group overlap because

420
00:24:28,560 --> 00:24:30,680
the same few experts are doing both jobs.

421
00:24:30,680 --> 00:24:35,440
In larger organizations you'll want to keep these roles separate to maintain clear responsibilities.

422
00:24:35,440 --> 00:24:39,520
Then you have the data reader group which is the one group you create for the entire company.

423
00:24:39,520 --> 00:24:43,120
While writing roles are split by business unit to prevent people from colliding, reading

424
00:24:43,120 --> 00:24:44,560
is the exact opposite.

425
00:24:44,560 --> 00:24:48,000
You should default to broad reading access by giving everyone a single data reader group

426
00:24:48,000 --> 00:24:51,680
that covers both the data map and the unified catalog at the same time.

427
00:24:51,680 --> 00:24:55,600
The entire point of having a catalog is to share metadata, so don't make it hard for

428
00:24:55,600 --> 00:24:57,000
people to find things.

429
00:24:57,000 --> 00:24:58,720
The chain of command flows downward.

430
00:24:58,720 --> 00:25:02,640
The purview administrator delegates power to the unified catalog admin who then delegates

431
00:25:02,640 --> 00:25:07,200
to each governance domain admin who finally hands off access to the stewards and product owners.

432
00:25:07,200 --> 00:25:10,920
This allows access to flow where it's needed without a single team becoming a bottleneck

433
00:25:10,920 --> 00:25:12,280
for the rest of the company.

434
00:25:12,280 --> 00:25:16,640
You should name these groups after the persona and the domain like SG purviewGD claims data

435
00:25:16,640 --> 00:25:20,080
steward so a new hire can read the name and know exactly what it grants.

436
00:25:20,080 --> 00:25:24,160
Now that you have the blueprint, you need to build the foundation.

437
00:25:24,160 --> 00:25:25,160
Collections?

438
00:25:25,160 --> 00:25:26,960
Organize for discovery not platforms.

439
00:25:26,960 --> 00:25:31,080
The foundation of your setup is the data you actually scan, but how you organize that data

440
00:25:31,080 --> 00:25:33,880
determinants if people use the tool or abandon it.

441
00:25:33,880 --> 00:25:37,680
There is a specific mistake that quietly kills adoption in most companies.

442
00:25:37,680 --> 00:25:41,480
Teams tend to organize their collections by the technical platform, putting Azure SQL

443
00:25:41,480 --> 00:25:45,760
in one spot, snowflake in another, and fabric or a data lake somewhere else.

444
00:25:45,760 --> 00:25:49,400
While this looks clean and logical from an infrastructure perspective, it is completely

445
00:25:49,400 --> 00:25:50,960
wrong for the end user.

446
00:25:50,960 --> 00:25:55,200
Imagine a claims manager opens the catalog to find fraud detection data and sees a list

447
00:25:55,200 --> 00:25:56,840
of technical collections.

448
00:25:56,840 --> 00:25:59,200
They don't see a folder labeled "claims".

449
00:25:59,200 --> 00:26:05,280
Instead they see Azure SQL, policy admin database or snowflake premium cluster.

450
00:26:05,280 --> 00:26:08,720
These technical names mean nothing to them and because they have no idea where to look,

451
00:26:08,720 --> 00:26:11,720
they'll just close the catalog and ask a human being for help.

452
00:26:11,720 --> 00:26:14,640
Your expensive discovery tool just became a total waste of time.

453
00:26:14,640 --> 00:26:18,160
You need to organize your collections by your internal business domains instead.

454
00:26:18,160 --> 00:26:22,440
This is what non-technical users actually understand and it's how they search and filter

455
00:26:22,440 --> 00:26:23,440
for information.

456
00:26:23,440 --> 00:26:26,280
Most people only care about their own corner of the company anyway.

457
00:26:26,280 --> 00:26:29,960
They don't need to know that claims data is spread across three different systems.

458
00:26:29,960 --> 00:26:32,560
They just need to know where the claims section is.

459
00:26:32,560 --> 00:26:35,960
Your specific use case will still tell you which sources to scan.

460
00:26:35,960 --> 00:26:39,120
If you're looking for fraud detection, you know you need the policy admin database, the

461
00:26:39,120 --> 00:26:41,080
payout tables and the features in fabric.

462
00:26:41,080 --> 00:26:45,280
But knowing which sources matter is different from knowing how to arrange them for a human

463
00:26:45,280 --> 00:26:46,280
to find.

464
00:26:46,280 --> 00:26:48,200
You have to arrange the data for the reader.

465
00:26:48,200 --> 00:26:51,960
Scan those sources into collections named after business domains, such as claims,

466
00:26:51,960 --> 00:26:53,560
finance or underwriting.

467
00:26:53,560 --> 00:26:57,880
Even if the raw claims table lives in Azure SQL and the enriched features live in fabric,

468
00:26:57,880 --> 00:27:00,360
you should put both of them under the claims collection.

469
00:27:00,360 --> 00:27:04,720
The platform is just an implementation detail that the user shouldn't have to worry about.

470
00:27:04,720 --> 00:27:07,480
The business domain is the only label that matters.

471
00:27:07,480 --> 00:27:09,400
There is one technical rule to remember.

472
00:27:09,400 --> 00:27:12,280
You cannot register the same source twice in one account.

473
00:27:12,280 --> 00:27:16,560
If multiple teams need access to the same SQL database, you should register it in a parent

474
00:27:16,560 --> 00:27:19,800
collection and then scan it into specific subcollections.

475
00:27:19,800 --> 00:27:23,400
This ensures that assets appear exactly where each team expects to find them.

476
00:27:23,400 --> 00:27:28,000
When it comes to dev tests and stage environments, you should use collections rather than domains.

477
00:27:28,000 --> 00:27:31,840
Many teams get this wrong because they think splitting environments by domain looks better

478
00:27:31,840 --> 00:27:32,840
on a whiteboard.

479
00:27:32,840 --> 00:27:36,560
However, if you scan Microsoft fabric, the system won't let you split those environments

480
00:27:36,560 --> 00:27:38,240
across separate domains.

481
00:27:38,240 --> 00:27:41,160
Fabric has its own internal structure, so the environment boundary has to live within

482
00:27:41,160 --> 00:27:42,160
your collections.

483
00:27:42,160 --> 00:27:46,840
You should nest these, so each business domain maintains its own split for dev, test and

484
00:27:46,840 --> 00:27:47,840
production.

485
00:27:47,840 --> 00:27:52,080
A claims collection should have subcollections for each environment, ensuring that a half-build

486
00:27:52,080 --> 00:27:56,160
test table never sits right next to production claims data.

487
00:27:56,160 --> 00:28:00,240
Your collections will follow your business domains and your governance domains will eventually

488
00:28:00,240 --> 00:28:01,240
do the same.

489
00:28:01,240 --> 00:28:02,800
This symmetry is exactly what you want.

490
00:28:02,800 --> 00:28:06,960
When a manager sees a claims collection in the data map and a claims domain in the catalog,

491
00:28:06,960 --> 00:28:08,680
they'll know they are in the right place.

492
00:28:08,680 --> 00:28:11,960
To keep these collections relatable, you should follow three simple habits.

493
00:28:11,960 --> 00:28:16,360
First, use friendly names instead of the random six letter codes per view generates.

494
00:28:16,360 --> 00:28:20,280
Second, make sure the name reflects the business domain so it echoes the governance domain.

495
00:28:20,280 --> 00:28:22,200
Finally, keep your hierarchy shallow.

496
00:28:22,200 --> 00:28:25,520
A non-technical user should be able to look at your collections and find what they need

497
00:28:25,520 --> 00:28:27,040
without needing a tour guide.

498
00:28:27,040 --> 00:28:30,520
Now that we know how to structure the catalog, we have to talk about ownership because

499
00:28:30,520 --> 00:28:33,960
structure means nothing if no one is in charge.

500
00:28:33,960 --> 00:28:36,480
Governance domains, collections and domains, rhyme.

501
00:28:36,480 --> 00:28:39,640
You have two layers that both follow your business domains.

502
00:28:39,640 --> 00:28:41,240
Collections live in the data map.

503
00:28:41,240 --> 00:28:43,240
Governance domains live in the unified catalog.

504
00:28:43,240 --> 00:28:44,480
They are separate systems.

505
00:28:44,480 --> 00:28:45,960
They serve different purposes.

506
00:28:45,960 --> 00:28:49,560
But if you have organized both correctly, they will look almost identical.

507
00:28:49,560 --> 00:28:51,240
A claims collection in the data map.

508
00:28:51,240 --> 00:28:53,800
A claims governance domain in the unified catalog.

509
00:28:53,800 --> 00:28:56,560
Seeing the same word in both places is not a coincidence.

510
00:28:56,560 --> 00:29:01,280
It is the specific experience that tells a claims manager they are in the right place.

511
00:29:01,280 --> 00:29:02,440
This is intentional design.

512
00:29:02,440 --> 00:29:03,480
It is not redundancy.

513
00:29:03,480 --> 00:29:04,720
The layers do different jobs.

514
00:29:04,720 --> 00:29:09,600
Collections act as the access boundary and the place people browse when they need raw metadata.

515
00:29:09,600 --> 00:29:12,640
They control who can register sources, who can run scans,

516
00:29:12,640 --> 00:29:14,600
and who can see that assets even exist.

517
00:29:14,600 --> 00:29:17,000
They are the security perimeter for your metadata.

518
00:29:17,000 --> 00:29:19,960
Governance domains are where ownership finally shows up.

519
00:29:19,960 --> 00:29:23,160
This is where you define what things mean and where you build data products.

520
00:29:23,160 --> 00:29:25,320
It is where you publish glossary terms and policies.

521
00:29:25,320 --> 00:29:29,000
It is where business owners delegate authority to stewards and product owners.

522
00:29:29,000 --> 00:29:31,600
Collections answer the question of where an asset is and who can touch it.

523
00:29:31,600 --> 00:29:35,040
While governance domains answer what that asset means and who is accountable for it.

524
00:29:35,040 --> 00:29:36,040
But here is the key.

525
00:29:36,040 --> 00:29:37,920
They will not line up perfectly and that is fine.

526
00:29:37,920 --> 00:29:42,560
A claims collection in the data map holds the raw claims table, the payouts table, and

527
00:29:42,560 --> 00:29:44,040
the claims metadata table.

528
00:29:44,040 --> 00:29:45,280
It is just the claims.

529
00:29:45,280 --> 00:29:49,400
But a fraud analytics governance domain does not live in a fraud analytics collection because

530
00:29:49,400 --> 00:29:51,280
it does not have its own collection.

531
00:29:51,280 --> 00:29:55,400
The fraud analytics domain owns a data product whose assets are scattered across multiple

532
00:29:55,400 --> 00:29:58,600
collections like claims, underwriting, and finance.

533
00:29:58,600 --> 00:30:02,640
The assets sit in different places but the ownership sits in one domain that pulls them

534
00:30:02,640 --> 00:30:05,000
together under one business question.

535
00:30:05,000 --> 00:30:08,320
At the same time the claims collection feeds into multiple domains.

536
00:30:08,320 --> 00:30:12,440
The claims domain owns claims specific data products but the fraud analytics domain uses

537
00:30:12,440 --> 00:30:15,200
claims data as part of a cross-domain product.

538
00:30:15,200 --> 00:30:18,760
The regulatory domain might also pull claims data to support compliance.

539
00:30:18,760 --> 00:30:23,020
The claims collection is the source and the domains are the governance lenses over that

540
00:30:23,020 --> 00:30:24,020
source.

541
00:30:24,020 --> 00:30:25,020
The overlap is many to many.

542
00:30:25,020 --> 00:30:26,020
This is not a problem.

543
00:30:26,020 --> 00:30:27,400
It is how you avoid silos.

544
00:30:27,400 --> 00:30:31,240
A source system serves one collection, one collection serves multiple domains, and one

545
00:30:31,240 --> 00:30:33,560
domain pulls assets from multiple collections.

546
00:30:33,560 --> 00:30:35,440
The network is intentionally loose.

547
00:30:35,440 --> 00:30:37,560
One rule actually matters in all of this.

548
00:30:37,560 --> 00:30:41,480
Everything you scan into the data map becomes immediately discoverable in the unified catalog.

549
00:30:41,480 --> 00:30:43,680
Your users do not live in two separate experiences.

550
00:30:43,680 --> 00:30:44,680
They live in one.

551
00:30:44,680 --> 00:30:48,520
The claims manager opens purview and searches for fraud detection.

552
00:30:48,520 --> 00:30:52,840
The system shows them assets from the claims collection contextualize through the fraud analytics

553
00:30:52,840 --> 00:30:53,840
domain.

554
00:30:53,840 --> 00:30:57,680
They see the data product, the glossary terms that define what suspicious means in this

555
00:30:57,680 --> 00:31:02,400
context, the access policy, and the lineage showing where the score comes from.

556
00:31:02,400 --> 00:31:05,640
Everything they need is in one place, but that only works if naming is intentional.

557
00:31:05,640 --> 00:31:10,320
If the manager opens the catalog and sees a collection called call x7f2qa or an asset

558
00:31:10,320 --> 00:31:13,600
called sqlprod_rohr_e2, they have already lost trust.

559
00:31:13,600 --> 00:31:15,480
They leave, they do not come back.

560
00:31:15,480 --> 00:31:18,000
Name every collection for the human who reads it.

561
00:31:18,000 --> 00:31:19,000
Claims.

562
00:31:19,000 --> 00:31:20,000
Finance.

563
00:31:20,000 --> 00:31:21,000
Customer.

564
00:31:21,000 --> 00:31:22,000
Use simple business names.

565
00:31:22,000 --> 00:31:25,240
For the domains themselves, you need a structure that lines data up with experts and survives

566
00:31:25,240 --> 00:31:27,280
the next organizational reog.

567
00:31:27,280 --> 00:31:31,280
Use a blend of subject area domains like claims and customer, functional domains like finance

568
00:31:31,280 --> 00:31:35,440
and risk, regulatory domains for compliance and privacy, and project domains like fraud

569
00:31:35,440 --> 00:31:36,440
analytics.

570
00:31:36,440 --> 00:31:39,840
You need multiple perspectives because data serves multiple purposes.

571
00:31:39,840 --> 00:31:41,640
Three habits keep this relatable.

572
00:31:41,640 --> 00:31:45,200
Its friendly names instead of system defaults because the friendly name is what people actually

573
00:31:45,200 --> 00:31:46,200
see.

574
00:31:46,200 --> 00:31:47,200
Spend real effort on naming.

575
00:31:47,200 --> 00:31:50,760
Let the governance domain name echo the collection name when they align and keep your

576
00:31:50,760 --> 00:31:51,880
hierarchies shallow.

577
00:31:51,880 --> 00:31:56,040
A non-technical user should be able to navigate your structure intuitively without a guide.

578
00:31:56,040 --> 00:31:59,760
This is how you avoid a fragmented experience where users have to search both the collection

579
00:31:59,760 --> 00:32:02,160
tree and the domain tree to find what they need.

580
00:32:02,160 --> 00:32:05,560
Your name things deliberately, so the two structures feel like they are describing the same

581
00:32:05,560 --> 00:32:07,280
landscape from different angles.

582
00:32:07,280 --> 00:32:10,560
Now we understand how to structure the catalog, but structure means nothing without clear

583
00:32:10,560 --> 00:32:11,560
ownership.

584
00:32:11,560 --> 00:32:15,880
That's where data products become the bridge that connects everything.

585
00:32:15,880 --> 00:32:18,520
The data product, where structure becomes value.

586
00:32:18,520 --> 00:32:23,320
A data product is a business concept with a name, a description, owners and a list of

587
00:32:23,320 --> 00:32:24,600
data assets.

588
00:32:24,600 --> 00:32:28,200
It is the layer where all the architectural work you have done actually converts into something

589
00:32:28,200 --> 00:32:29,480
people can use.

590
00:32:29,480 --> 00:32:31,680
Everything up to this point is enabling infrastructure.

591
00:32:31,680 --> 00:32:36,080
The four layers, the role groups, the collections organized by business domain and the governance

592
00:32:36,080 --> 00:32:39,640
domains are all necessary, but they are not where value happens.

593
00:32:39,640 --> 00:32:43,960
Value happens when a consumer opens the catalog, finds one thing and gets an answer.

594
00:32:43,960 --> 00:32:47,280
A data product groups assets under one specific use case.

595
00:32:47,280 --> 00:32:52,440
The consumer finds it, requests access once and receives everything they need behind it.

596
00:32:52,440 --> 00:32:56,160
Policies attach to the product cascade down to the assets and access approval happens at

597
00:32:56,160 --> 00:32:58,280
the product level rather than the asset level.

598
00:32:58,280 --> 00:33:00,960
The consumer never touches the complexity underneath.

599
00:33:00,960 --> 00:33:04,800
This is the moment the rollout pays off, take the fraud detection question, which claims

600
00:33:04,800 --> 00:33:07,040
are most likely to be fraudulent this quarter.

601
00:33:07,040 --> 00:33:08,040
That is one product.

602
00:33:08,040 --> 00:33:13,160
All it certified claims fraud signals and put it inside the fraud analytics governance domain.

603
00:33:13,160 --> 00:33:14,600
Now list the assets that power it.

604
00:33:14,600 --> 00:33:18,800
You have the raw claims table from the policy admin system in Azure SQL, the payout history

605
00:33:18,800 --> 00:33:23,280
from Snowflake and enriched features table in the fabric gold lake house and a scored output

606
00:33:23,280 --> 00:33:24,920
report in Power BI.

607
00:33:24,920 --> 00:33:29,560
That is four sources across multiple platforms with different ownership models underneath.

608
00:33:29,560 --> 00:33:32,960
But from the perspective of the fraud analyst, it is just one thing.

609
00:33:32,960 --> 00:33:37,320
Certified claims fraud signals has one owner, one access policy and one set of terms of

610
00:33:37,320 --> 00:33:38,000
use.

611
00:33:38,000 --> 00:33:42,080
It is a single contract that tells you what you can do with the data, how fresh it is and

612
00:33:42,080 --> 00:33:43,960
who to contact if something breaks.

613
00:33:43,960 --> 00:33:47,560
That owner is accountable for all four assets, even though they live in different places

614
00:33:47,560 --> 00:33:49,800
and are managed by different technical teams.

615
00:33:49,800 --> 00:33:53,880
The owner does not manage the SQL database or the Snowflake connection and they do not run

616
00:33:53,880 --> 00:33:55,120
the fabric pipelines.

617
00:33:55,120 --> 00:33:57,440
They own the product that emerges from all of it.

618
00:33:57,440 --> 00:34:02,320
They define what fraud signal means and attach a glossary term like suspicious claim that

619
00:34:02,320 --> 00:34:05,480
is defined once in the fraud analytics domain.

620
00:34:05,480 --> 00:34:08,720
Any asset tagged with that term inherits the product's access policy.

621
00:34:08,720 --> 00:34:12,160
The definition is the single source of truth and the enforcement is automatic.

622
00:34:12,160 --> 00:34:13,720
This is how governance scales.

623
00:34:13,720 --> 00:34:17,240
You do not make every asset its own policy document.

624
00:34:17,240 --> 00:34:21,000
Instead you group assets under products and apply policies at the product level.

625
00:34:21,000 --> 00:34:25,160
When an approved data scientist requests access to certified claims fraud signals, they do

626
00:34:25,160 --> 00:34:28,480
not request access to four different assets on four different platforms.

627
00:34:28,480 --> 00:34:30,680
They make one request and get one approval.

628
00:34:30,680 --> 00:34:35,200
In that moment, the data product owner or an approver checks if this person needs the

629
00:34:35,200 --> 00:34:37,480
data and if the purpose makes sense.

630
00:34:37,480 --> 00:34:41,680
Once access is approved, the system provisions all four assets at once.

631
00:34:41,680 --> 00:34:45,320
This stops the scientist from having to chase four different platform teams.

632
00:34:45,320 --> 00:34:48,400
Because you build use case first, you can prove value before you scale.

633
00:34:48,400 --> 00:34:51,000
You do not build 10 data products at the same time.

634
00:34:51,000 --> 00:34:55,240
You build one, test it with the fraud team and measure whether the model actually works.

635
00:34:55,240 --> 00:34:58,840
You find out if it predicts fraud, if the analyst trusts the score and if they can act

636
00:34:58,840 --> 00:34:59,840
on it.

637
00:34:59,840 --> 00:35:02,280
You gather that feedback and iterate before you hand it over.

638
00:35:02,280 --> 00:35:05,360
Keep the domain in draft and give the fraud team read access.

639
00:35:05,360 --> 00:35:07,440
They use it and tell you what works and what does not.

640
00:35:07,440 --> 00:35:11,120
You learn what is actually valuable before you spend time maintaining a catalog of things

641
00:35:11,120 --> 00:35:12,120
nobody asked for.

642
00:35:12,120 --> 00:35:13,520
Then you move to the next use case.

643
00:35:13,520 --> 00:35:16,720
One question is proven and the next is already lining up.

644
00:35:16,720 --> 00:35:19,000
This is the difference between a catalog and a swamp.

645
00:35:19,000 --> 00:35:22,080
A swamp is a thousand assets no one asked for.

646
00:35:22,080 --> 00:35:25,840
Organized in a way that only makes sense to the IT team and discovered by no one.

647
00:35:25,840 --> 00:35:29,280
A catalog is a curated set of answers to questions people actually need.

648
00:35:29,280 --> 00:35:31,280
It is built one question at a time.

649
00:35:31,280 --> 00:35:35,240
It is built by someone accountable, governed by policy and discoverable through business

650
00:35:35,240 --> 00:35:36,240
language.

651
00:35:36,240 --> 00:35:37,240
The product is the bridge.

652
00:35:37,240 --> 00:35:41,520
It pulls assets across collections and layers into one unit and it hides the plumbing

653
00:35:41,520 --> 00:35:43,600
from the person who just wants an answer.

654
00:35:43,600 --> 00:35:47,600
But there is one more critical piece before a product can actually work as data transforms

655
00:35:47,600 --> 00:35:52,360
through the medallion layers ownership transforms with it and that handoff has to be explicit.

656
00:35:52,360 --> 00:35:55,280
The medallion accountability chain bronzes to gold.

657
00:35:55,280 --> 00:35:57,480
Most catalogs ignore one specific question.

658
00:35:57,480 --> 00:35:59,360
It isn't because the answer is hard to find.

659
00:35:59,360 --> 00:36:03,920
It is because the answer is uncomfortable who actually owns the data after you transform it.

660
00:36:03,920 --> 00:36:06,000
You already know who owns the raw claims table.

661
00:36:06,000 --> 00:36:08,360
The policy admin team pulls it from the source system.

662
00:36:08,360 --> 00:36:10,080
They make sure the ingestion worked.

663
00:36:10,080 --> 00:36:12,720
They certify that the data was captured faithfully.

664
00:36:12,720 --> 00:36:14,440
Their job is fidelity not correctness.

665
00:36:14,440 --> 00:36:17,040
They vouch for what came out of the system that is their role.

666
00:36:17,040 --> 00:36:18,680
But then something changes.

667
00:36:18,680 --> 00:36:21,400
The fraud analytics team takes that raw data and starts working.

668
00:36:21,400 --> 00:36:22,560
They clean the claims.

669
00:36:22,560 --> 00:36:26,320
They join them to historical payout records from a completely different system.

670
00:36:26,320 --> 00:36:28,320
They engineer features in a fabric leg house.

671
00:36:28,320 --> 00:36:29,480
They score the results.

672
00:36:29,480 --> 00:36:32,320
They build a model to predict which claims are likely fraudulent.

673
00:36:32,320 --> 00:36:36,000
By the time that score hits the gold layer, the business ready zone, it isn't the policy

674
00:36:36,000 --> 00:36:37,440
admin team's data anymore.

675
00:36:37,440 --> 00:36:39,040
They didn't write those joins.

676
00:36:39,040 --> 00:36:40,520
They didn't engineer the features.

677
00:36:40,520 --> 00:36:41,840
They don't even understand the model.

678
00:36:41,840 --> 00:36:44,280
They can't explain why a specific claim got a high score.

679
00:36:44,280 --> 00:36:46,680
They can't stand behind a number they didn't create.

680
00:36:46,680 --> 00:36:48,600
But on paper, they still own the raw claim.

681
00:36:48,600 --> 00:36:49,840
So who owns the fraud score?

682
00:36:49,840 --> 00:36:52,520
Is it the policy admin team who brought in the source?

683
00:36:52,520 --> 00:36:55,320
Is it the engineering team who handled the transformation?

684
00:36:55,320 --> 00:36:56,800
Is it both?

685
00:36:56,800 --> 00:36:58,480
This is where most catalogs fail.

686
00:36:58,480 --> 00:36:59,480
They don't answer.

687
00:36:59,480 --> 00:37:00,480
They register the raw table.

688
00:37:00,480 --> 00:37:01,960
They scan the gold table.

689
00:37:01,960 --> 00:37:03,840
They build a data product that includes both.

690
00:37:03,840 --> 00:37:06,280
And then they leave the ownership ambiguous.

691
00:37:06,280 --> 00:37:10,560
The assumption is that we will figure out who is accountable when something breaks.

692
00:37:10,560 --> 00:37:11,560
That's theatre.

693
00:37:11,560 --> 00:37:12,560
It isn't governance.

694
00:37:12,560 --> 00:37:13,560
In reality, here is what happens.

695
00:37:13,560 --> 00:37:14,560
Something breaks.

696
00:37:14,560 --> 00:37:18,360
A regulator asks who is responsible for a fraud score that turned out to be wrong.

697
00:37:18,360 --> 00:37:19,880
Three different teams point at each other.

698
00:37:19,880 --> 00:37:22,800
The policy admin team says they provided accurate source data.

699
00:37:22,800 --> 00:37:24,760
The engineering team says they followed the spec.

700
00:37:24,760 --> 00:37:27,240
The product owner says everyone did their jobs.

701
00:37:27,240 --> 00:37:30,640
No one is actually accountable because accountability was never assigned.

702
00:37:30,640 --> 00:37:35,080
The solution is an explicit handoff, as data flows from bronze to silver to gold, accountability

703
00:37:35,080 --> 00:37:36,200
must flow with it.

704
00:37:36,200 --> 00:37:40,320
It moves from the source owner to the data product owner who's team did the work.

705
00:37:40,320 --> 00:37:42,040
The structure of ownership changes.

706
00:37:42,040 --> 00:37:44,200
The responsibility shifts, usually.

707
00:37:44,200 --> 00:37:45,760
That shift happens in the silver layer.

708
00:37:45,760 --> 00:37:47,240
Silver is where the magic happens.

709
00:37:47,240 --> 00:37:48,720
Raw data gets cleaned.

710
00:37:48,720 --> 00:37:50,160
Multiple sources get joined.

711
00:37:50,160 --> 00:37:51,160
Business rules get applied.

712
00:37:51,160 --> 00:37:54,200
By the time data reaches silver, it is no longer source aligned.

713
00:37:54,200 --> 00:37:56,400
It isn't a faithful copy of the system anymore.

714
00:37:56,400 --> 00:37:57,400
It has been interpreted.

715
00:37:57,400 --> 00:37:59,360
It has been shaped by business logic.

716
00:37:59,360 --> 00:38:03,200
Someone had to decide how to handle nulls or how to join ambiguous keys.

717
00:38:03,200 --> 00:38:05,480
Those decisions belong to the team that made them.

718
00:38:05,480 --> 00:38:06,800
So the ownership shifts.

719
00:38:06,800 --> 00:38:09,400
The policy admin team owns the raw claims in bronze.

720
00:38:09,400 --> 00:38:12,600
The fraud analytics product owner owns the gold features table.

721
00:38:12,600 --> 00:38:16,520
Someone in the middle, usually the central data engineering team, owns the silver layer.

722
00:38:16,520 --> 00:38:18,200
They own the transformation logic.

723
00:38:18,200 --> 00:38:19,200
They own the joints.

724
00:38:19,200 --> 00:38:22,760
They can explain why the data looks the way it does at that specific step.

725
00:38:22,760 --> 00:38:25,920
Each zone has an owner, each owner answers for what they actually built.

726
00:38:25,920 --> 00:38:27,560
You have to write this into the catalog.

727
00:38:27,560 --> 00:38:28,800
Don't just leave a comment.

728
00:38:28,800 --> 00:38:30,240
Use explicit assignments.

729
00:38:30,240 --> 00:38:33,680
Set the policy admin team as the owner of the bronze claims table.

730
00:38:33,680 --> 00:38:36,800
Set the fraud analytics product owner as the owner of the gold table.

731
00:38:36,800 --> 00:38:39,360
Set the data engineering team as the owner of the silver table.

732
00:38:39,360 --> 00:38:43,880
Draw the lineage to show exactly where the raw source ends and the derived product begins.

733
00:38:43,880 --> 00:38:46,360
This is the difference between governance and theatre.

734
00:38:46,360 --> 00:38:48,520
In theatre, you have policies and roles.

735
00:38:48,520 --> 00:38:52,000
In governance, you have clear accountability at every transformation point.

736
00:38:52,000 --> 00:38:53,000
Everyone is responsible.

737
00:38:53,000 --> 00:38:54,000
Someone can be asked.

738
00:38:54,000 --> 00:38:57,160
Someone can answer when the model breaks or the score doesn't match reality.

739
00:38:57,160 --> 00:39:01,080
The moment you write ownership explicitly at each layer, the medallion architecture stops

740
00:39:01,080 --> 00:39:02,400
being just a storage pattern.

741
00:39:02,400 --> 00:39:04,320
It becomes an accountability chain.

742
00:39:04,320 --> 00:39:05,480
Each layer has owners.

743
00:39:05,480 --> 00:39:08,600
Each owner is responsible for the quality and correctness of their layer.

744
00:39:08,600 --> 00:39:11,120
That is what separates a real rollout from a performative one.

745
00:39:11,120 --> 00:39:12,120
It isn't the tool.

746
00:39:12,120 --> 00:39:14,680
It's the clarity of who answers when something goes wrong.

747
00:39:14,680 --> 00:39:15,680
PIM.

748
00:39:15,680 --> 00:39:17,440
Caging the purview administrator.

749
00:39:17,440 --> 00:39:20,760
There is one role in purview that requires a different class of control.

750
00:39:20,760 --> 00:39:24,440
In purview administrator role, this role can change almost anything in your account.

751
00:39:24,440 --> 00:39:25,440
It can create domains.

752
00:39:25,440 --> 00:39:26,440
It can delete them.

753
00:39:26,440 --> 00:39:30,320
It can modify scan rules or reassign roles to other people.

754
00:39:30,320 --> 00:39:32,000
And here is the part that should concern you.

755
00:39:32,000 --> 00:39:33,480
It can raise its own permissions.

756
00:39:33,480 --> 00:39:36,800
A purview administrator can make themselves a governance domain owner.

757
00:39:36,800 --> 00:39:39,800
They can grant themselves access to sensitive data products.

758
00:39:39,800 --> 00:39:42,800
They can change the policies for the entire organisation.

759
00:39:42,800 --> 00:39:46,080
If that role is compromised, the damage is effectively unlimited.

760
00:39:46,080 --> 00:39:50,160
If credentials leak or a terminated account is reactivated, the scope of exposure covers

761
00:39:50,160 --> 00:39:51,440
the entire platform.

762
00:39:51,440 --> 00:39:54,280
The window to detect the problem is incredibly narrow.

763
00:39:54,280 --> 00:39:58,880
This is why the purview administrator group cannot work under traditional access models.

764
00:39:58,880 --> 00:40:01,440
You cannot make people permanent members of this group.

765
00:40:01,440 --> 00:40:03,200
You cannot let them use it every day.

766
00:40:03,200 --> 00:40:04,400
That is structural risk.

767
00:40:04,400 --> 00:40:07,800
The solution is Microsoft Enter Privileged Identity Management.

768
00:40:07,800 --> 00:40:08,800
PIM.

769
00:40:08,800 --> 00:40:10,400
PIM isn't a tool you layer on top later.

770
00:40:10,400 --> 00:40:12,960
It is structural governance for privileged roles.

771
00:40:12,960 --> 00:40:16,480
It enforces just-in-time access instead of standing access.

772
00:40:16,480 --> 00:40:19,600
When an admin needs to work, they don't log in with that role active.

773
00:40:19,600 --> 00:40:21,240
They request activation.

774
00:40:21,240 --> 00:40:22,240
Here is how it works.

775
00:40:22,240 --> 00:40:25,040
An admin realises they need to create a new governance domain.

776
00:40:25,040 --> 00:40:26,880
They don't use their admin account directly.

777
00:40:26,880 --> 00:40:29,920
They go into the PIM portal and request the purview administrator role.

778
00:40:29,920 --> 00:40:31,400
The system asks why they need it.

779
00:40:31,400 --> 00:40:35,520
They provide a justification like creating a new domain for a specific use case.

780
00:40:35,520 --> 00:40:37,920
The system requires multi-factor authentication.

781
00:40:37,920 --> 00:40:38,920
They complete it.

782
00:40:38,920 --> 00:40:41,000
The request goes to an independent approver.

783
00:40:41,000 --> 00:40:43,240
That person reviews the request to see if it makes sense.

784
00:40:43,240 --> 00:40:47,320
If it does, they approve it.

785
00:40:47,320 --> 00:40:51,360
Now the admin has the role active, but only for a set amount of time.

786
00:40:51,360 --> 00:40:53,120
Usually this is between one and four hours.

787
00:40:53,120 --> 00:40:54,120
They do the work.

788
00:40:54,120 --> 00:40:55,120
They create the domain.

789
00:40:55,120 --> 00:40:56,120
They assign the owners.

790
00:40:56,120 --> 00:40:57,120
Then they step away.

791
00:40:57,120 --> 00:40:58,400
The role expires automatically.

792
00:40:58,400 --> 00:40:59,400
The system revokes it.

793
00:40:59,400 --> 00:41:01,440
No one has to remember to remove the access.

794
00:41:01,440 --> 00:41:03,720
The system enforces the expiration itself.

795
00:41:03,720 --> 00:41:05,000
Every single activation is logged.

796
00:41:05,000 --> 00:41:06,560
You see who activated it and when.

797
00:41:06,560 --> 00:41:08,000
You see the justification they provided.

798
00:41:08,000 --> 00:41:10,960
You see how long they held the power and what they did with it.

799
00:41:10,960 --> 00:41:12,800
This creates an unbreakable audit trail.

800
00:41:12,800 --> 00:41:15,720
The configuration of PIM around purview is intentional.

801
00:41:15,720 --> 00:41:17,840
You set the maximum duration to four hours.

802
00:41:17,840 --> 00:41:19,840
You always require MFA on activation.

803
00:41:19,840 --> 00:41:23,640
This means even if someone steals a password, they can't activate the role without a phone

804
00:41:23,640 --> 00:41:24,640
or a hardware key.

805
00:41:24,640 --> 00:41:27,200
You require justification to force intentionality.

806
00:41:27,200 --> 00:41:31,080
You require approval for high-risk roles, so someone else has to sign off.

807
00:41:31,080 --> 00:41:34,960
You set up notifications to alert domain owners when these activations happen.

808
00:41:34,960 --> 00:41:38,360
These settings implement controlled access with real accountability.

809
00:41:38,360 --> 00:41:42,080
The blast radius of a compromised admin is now measured in hours, not months.

810
00:41:42,080 --> 00:41:43,520
The attack surface shrinks.

811
00:41:43,520 --> 00:41:48,960
It moves from someone with standing access to someone with credentials, a second factor,

812
00:41:48,960 --> 00:41:50,240
and an approval from a peer.

813
00:41:50,240 --> 00:41:52,920
The purview administrator group sits empty by default.

814
00:41:52,920 --> 00:41:54,320
No one is an active member.

815
00:41:54,320 --> 00:41:55,640
Users are made eligible.

816
00:41:55,640 --> 00:41:58,880
Eligibility means they can request activation, but they don't have the power until they

817
00:41:58,880 --> 00:42:00,320
actually activated.

818
00:42:00,320 --> 00:42:02,000
That distinction is critical.

819
00:42:02,000 --> 00:42:03,640
Eligible is not the same as active.

820
00:42:03,640 --> 00:42:04,640
Eligible is potential.

821
00:42:04,640 --> 00:42:05,960
Active is power.

822
00:42:05,960 --> 00:42:07,640
When an admin needs to work, they activate.

823
00:42:07,640 --> 00:42:09,280
When they are done, the role expires.

824
00:42:09,280 --> 00:42:12,960
When something breaks, you look at the log to see who activated what and why.

825
00:42:12,960 --> 00:42:16,200
This is the difference between trusting people and verifying their actions.

826
00:42:16,200 --> 00:42:19,320
This is structural control over the most powerful role in your account.

827
00:42:19,320 --> 00:42:22,520
Now, let's talk about how to actually roll this out.

828
00:42:22,520 --> 00:42:23,880
The rollout sequence.

829
00:42:23,880 --> 00:42:25,800
Start narrow, scale slow.

830
00:42:25,800 --> 00:42:27,160
Most teams fail here.

831
00:42:27,160 --> 00:42:30,520
Not because they picked the wrong structure, but because they tried to do everything at

832
00:42:30,520 --> 00:42:34,760
once, they spend weeks designing a perfect permission model and documenting role groups.

833
00:42:34,760 --> 00:42:38,480
They map collections to business domains and publish a rollout plan that looks like a

834
00:42:38,480 --> 00:42:39,960
military operation.

835
00:42:39,960 --> 00:42:45,840
After every source, create every domain, assign every role, go live across the whole enterprise,

836
00:42:45,840 --> 00:42:47,440
then reality shows up.

837
00:42:47,440 --> 00:42:51,280
Change management breaks because people don't understand why their permissions changed.

838
00:42:51,280 --> 00:42:55,600
The catalog fills with data, no one knows how to use, and support tickets pile up until

839
00:42:55,600 --> 00:42:57,280
adoption stalls.

840
00:42:57,280 --> 00:43:00,280
Executives ask why they spend money on a tool nobody uses.

841
00:43:00,280 --> 00:43:04,680
The team eventually declares the project a failure, but the real failure was the sequencing.

842
00:43:04,680 --> 00:43:05,680
There is a different way.

843
00:43:05,680 --> 00:43:07,880
Don't design once and implement everywhere.

844
00:43:07,880 --> 00:43:11,280
You need to design for one, implement for one, and learn from one before you replicate

845
00:43:11,280 --> 00:43:12,280
that success.

846
00:43:12,280 --> 00:43:16,080
Pick one business question that real people are waiting on right now.

847
00:43:16,080 --> 00:43:20,360
Not a broad theme like improving data governance or building a modern platform.

848
00:43:20,360 --> 00:43:24,120
Find a specific urgent question that someone is losing sleep over because they can't get

849
00:43:24,120 --> 00:43:25,320
the answer fast enough.

850
00:43:25,320 --> 00:43:26,720
That question is your seed.

851
00:43:26,720 --> 00:43:28,720
One sentence is all you need to get started.

852
00:43:28,720 --> 00:43:32,080
You might ask which claims are likely to be fraudulent this quarter or how many customers

853
00:43:32,080 --> 00:43:34,080
will turn in the next fiscal year.

854
00:43:34,080 --> 00:43:38,520
Maybe you need to know which transactions violate policy within 24 hours of initiation or which

855
00:43:38,520 --> 00:43:40,080
employees are flight risks.

856
00:43:40,080 --> 00:43:42,720
Pick something with real consequences if you get it wrong.

857
00:43:42,720 --> 00:43:45,320
That single sentence does all the heavy lifting for you.

858
00:43:45,320 --> 00:43:49,920
It tells you which sources matter, which collections to create, and which domains to establish.

859
00:43:49,920 --> 00:43:51,840
It identifies your first audience.

860
00:43:51,840 --> 00:43:54,360
One use case pulls the entire roll out forward.

861
00:43:54,360 --> 00:43:56,880
Everything else you build serves that one question.

862
00:43:56,880 --> 00:43:59,760
Build the permission structure specifically for that answer.

863
00:43:59,760 --> 00:44:01,360
You don't need five role groups yet.

864
00:44:01,360 --> 00:44:05,200
You just need a domain owner for your first domain and stewards to define what the business

865
00:44:05,200 --> 00:44:06,200
concepts mean.

866
00:44:06,200 --> 00:44:10,160
You need a data product owner to own the answer and readers to consume it.

867
00:44:10,160 --> 00:44:12,560
Create the groups you actually need and nothing more.

868
00:44:12,560 --> 00:44:16,240
Register only the sources that the question requires and scan nothing else.

869
00:44:16,240 --> 00:44:20,240
Create one collection and one governance domain but keep it in a draft state.

870
00:44:20,240 --> 00:44:23,160
Give your first audience the fraud team or the churn analysts.

871
00:44:23,160 --> 00:44:24,880
Read access while it is still a draft.

872
00:44:24,880 --> 00:44:27,440
Let them use it so they can tell you what is working.

873
00:44:27,440 --> 00:44:30,200
Gather feedback while it still costs nothing to change.

874
00:44:30,200 --> 00:44:34,240
Does the term "suspicious claim" match how the team actually talks?

875
00:44:34,240 --> 00:44:37,480
Does the data product include everything they need or are assets missing?

876
00:44:37,480 --> 00:44:41,120
You need to know if the access policy is too strict and if the naming in the collection

877
00:44:41,120 --> 00:44:42,120
is confusing.

878
00:44:42,120 --> 00:44:45,760
Check if the lineage story makes sense or if it raises questions about where the scores

879
00:44:45,760 --> 00:44:46,760
come from.

880
00:44:46,760 --> 00:44:48,840
Learn in the small, fix before you scale.

881
00:44:48,840 --> 00:44:50,160
Then move to the next question.

882
00:44:50,160 --> 00:44:53,600
Once one question is proven, the next should already be waiting in line.

883
00:44:53,600 --> 00:44:56,720
Build a second use case in the second domain using the same discipline.

884
00:44:56,720 --> 00:44:58,920
One question, one collection and one product.

885
00:44:58,920 --> 00:45:00,600
After that, get feedback and learn.

886
00:45:00,600 --> 00:45:02,640
Only publish the work when it is solid.

887
00:45:02,640 --> 00:45:04,800
The sequence matters more than you think.

888
00:45:04,800 --> 00:45:07,960
Use cases come first, permission second and sources third.

889
00:45:07,960 --> 00:45:11,640
Most organizations do this backward by scanning everything first and hoping governance

890
00:45:11,640 --> 00:45:13,480
appears naturally from a big catalog.

891
00:45:13,480 --> 00:45:17,520
Then they try to retrofit permissions onto a landscape that is too fragmented to govern.

892
00:45:17,520 --> 00:45:20,520
That is when accountability disappears and the catalog becomes noise.

893
00:45:20,520 --> 00:45:21,840
Start narrow on purpose.

894
00:45:21,840 --> 00:45:26,040
Each use case teaches you how people actually talk about data and where ownership boundaries

895
00:45:26,040 --> 00:45:27,360
naturally fall.

896
00:45:27,360 --> 00:45:30,740
Every data product you build becomes a template for the next one with the same structure and

897
00:45:30,740 --> 00:45:32,400
quality expectations.

898
00:45:32,400 --> 00:45:35,600
Each governance domain you establish proves that the model works.

899
00:45:35,600 --> 00:45:39,520
Six months in you will have five proven use cases and five governance domains.

900
00:45:39,520 --> 00:45:43,560
You have templates, playbooks and evidence of value to show the leadership team.

901
00:45:43,560 --> 00:45:46,640
Now you can scale with confidence because you aren't learning as you go.

902
00:45:46,640 --> 00:45:49,120
You are simply replicating something you've already proven.

903
00:45:49,120 --> 00:45:51,640
This is how you build trust instead of losing it.

904
00:45:51,640 --> 00:45:53,840
The failure modes, what to watch for.

905
00:45:53,840 --> 00:45:56,520
Even with a solid design, things still go wrong.

906
00:45:56,520 --> 00:45:58,280
This usually isn't because the model is broken.

907
00:45:58,280 --> 00:46:02,160
It happens because implementation is where organizations drift from the plan and watch governance

908
00:46:02,160 --> 00:46:03,160
collapse.

909
00:46:03,160 --> 00:46:04,480
The first failure looks innocent enough.

910
00:46:04,480 --> 00:46:07,960
A team says they need to manage their own collection so you grant them the collection

911
00:46:07,960 --> 00:46:08,960
admin role.

912
00:46:08,960 --> 00:46:11,680
They own the data, so it seems reasonable they should manage it.

913
00:46:11,680 --> 00:46:14,960
Then another team asks for autonomy and you granted again.

914
00:46:14,960 --> 00:46:19,440
By month six, you have admins scattered everywhere like permissions were seeded by the wind.

915
00:46:19,440 --> 00:46:22,840
No one knows who has what and the central team can't audit the mess.

916
00:46:22,840 --> 00:46:26,240
The domain owners don't even understand their own structure anymore.

917
00:46:26,240 --> 00:46:27,240
The domain is blunt.

918
00:46:27,240 --> 00:46:28,960
Keep your collection admins few.

919
00:46:28,960 --> 00:46:32,360
Assign them only at a top level collection or a specific sub collection.

920
00:46:32,360 --> 00:46:34,560
Never spray these permissions across the account.

921
00:46:34,560 --> 00:46:38,000
Make it a deliberate act rather than a default response to request.

922
00:46:38,000 --> 00:46:41,960
The moment you start saying they can be their own admin, you have lost control.

923
00:46:41,960 --> 00:46:43,480
The second failure is subtler.

924
00:46:43,480 --> 00:46:46,440
Data products get created but no one is assigned as the owner.

925
00:46:46,440 --> 00:46:49,960
The product exists and has an access policy but there is no name attached to it.

926
00:46:49,960 --> 00:46:51,240
There is no accountability.

927
00:46:51,240 --> 00:46:55,800
Six months later the product is stale because the data went out of sync with the documentation.

928
00:46:55,800 --> 00:46:58,520
A consumer finds a bug but has no one to contact.

929
00:46:58,520 --> 00:47:00,400
The product decays and trust drops.

930
00:47:00,400 --> 00:47:03,320
Prevent this by making ownership explicit and visible in the catalog.

931
00:47:03,320 --> 00:47:07,040
The owner must be responsible for the contract the product makes with consumers.

932
00:47:07,040 --> 00:47:11,400
If the data is supposed to be fresh daily and it isn't, that is the owner's failure.

933
00:47:11,400 --> 00:47:15,200
Ownership without accountability is just a title but adding accountability changes how people

934
00:47:15,200 --> 00:47:16,200
work.

935
00:47:16,200 --> 00:47:18,480
The third failure is frustrating for everyone involved.

936
00:47:18,480 --> 00:47:22,320
A user has read access in the data map but not in the unified catalog.

937
00:47:22,320 --> 00:47:26,080
They open an asset and understand what it is but when they click the data product they

938
00:47:26,080 --> 00:47:28,640
see insufficient permissions.

939
00:47:28,640 --> 00:47:32,120
They have one level of access in one layer and something else in another.

940
00:47:32,120 --> 00:47:33,320
Confusion and tickets flood in.

941
00:47:33,320 --> 00:47:38,160
This happens because read access was granted inconsistently across the different layers.

942
00:47:38,160 --> 00:47:42,480
One team granted a role in the collection while another team assigned someone to the domain.

943
00:47:42,480 --> 00:47:43,760
The solution is mechanical.

944
00:47:43,760 --> 00:47:49,040
You must grant read access across both the data map and unified catalog at the same time.

945
00:47:49,040 --> 00:47:51,880
Use the same groups for the same people every single time.

946
00:47:51,880 --> 00:47:54,800
The fourth failure happens quietly as the catalog fills with noise.

947
00:47:54,800 --> 00:47:59,160
Teams scan everything because the scan feels free and assets pile up that no one actually

948
00:47:59,160 --> 00:48:00,160
asked for.

949
00:48:00,160 --> 00:48:03,680
A business user looking for customer data finds a thousand tables from operational systems

950
00:48:03,680 --> 00:48:04,680
they don't understand.

951
00:48:04,680 --> 00:48:06,240
They leave and never come back.

952
00:48:06,240 --> 00:48:09,120
You spend the budget but lost the trust of the users.

953
00:48:09,120 --> 00:48:11,520
Prevent this by disciplining yourself to start narrow.

954
00:48:11,520 --> 00:48:13,800
Scan only the sources your first use case needs.

955
00:48:13,800 --> 00:48:16,000
Don't scan everything just because the tool allows it.

956
00:48:16,000 --> 00:48:17,960
The fifth failure is architectural.

957
00:48:17,960 --> 00:48:22,080
Teams domains and collections don't align because collections follow technical platforms while

958
00:48:22,080 --> 00:48:24,040
domains follow the org chart.

959
00:48:24,040 --> 00:48:25,680
These two structures are incompatible.

960
00:48:25,680 --> 00:48:28,640
Lineage stops making sense and ownership becomes unclear.

961
00:48:28,640 --> 00:48:31,040
Teams won't know which domain owns which collection.

962
00:48:31,040 --> 00:48:34,200
Prevent this by making your collections and governance domains rhyme.

963
00:48:34,200 --> 00:48:36,160
Both should follow your business domains.

964
00:48:36,160 --> 00:48:40,400
Using the same words in both places tells users they are navigating a coherent system rather

965
00:48:40,400 --> 00:48:42,480
than two separate worlds.

966
00:48:42,480 --> 00:48:43,760
Measuring introduction.

967
00:48:43,760 --> 00:48:45,160
The trap of ease.

968
00:48:45,160 --> 00:48:47,600
Microsoft purview isn't something you install.

969
00:48:47,600 --> 00:48:49,520
It's already sitting in your tenant waiting.

970
00:48:49,520 --> 00:48:50,520
You don't buy it.

971
00:48:50,520 --> 00:48:51,520
You don't download it.

972
00:48:51,520 --> 00:48:53,400
You don't even schedule a big implementation project.

973
00:48:53,400 --> 00:48:56,600
It just exists as part of your Microsoft 365 infrastructure.

974
00:48:56,600 --> 00:48:58,360
It's a feature that came with the package.

975
00:48:58,360 --> 00:49:01,360
You flip a single switch in the admin center and it turns on.

976
00:49:01,360 --> 00:49:02,600
No procurement gate.

977
00:49:02,600 --> 00:49:05,640
No moment that forces you to stop and think about what you're doing.

978
00:49:05,640 --> 00:49:08,920
No conversation with stakeholders about what success actually looks like.

979
00:49:08,920 --> 00:49:10,080
That ease is the trap.

980
00:49:10,080 --> 00:49:11,960
Six weeks later the switch has been flipped.

981
00:49:11,960 --> 00:49:13,720
Someone has scanned your databases.

982
00:49:13,720 --> 00:49:15,320
Someone has created a few domains.

983
00:49:15,320 --> 00:49:17,480
Someone has handed out access to anyone who asked.

984
00:49:17,480 --> 00:49:21,440
Now you're looking at a catalog that sprawls across your entire organization.

985
00:49:21,440 --> 00:49:22,600
Collection admins are everywhere.

986
00:49:22,600 --> 00:49:24,240
Nobody owns a single data product.

987
00:49:24,240 --> 00:49:27,720
The catalog is somehow both locked down and wide open at the same time.

988
00:49:27,720 --> 00:49:32,040
Half your organization can access metadata through Azure resources even though you never intended

989
00:49:32,040 --> 00:49:35,920
it, while the other half is asking why they're being denied access to data they use to browse

990
00:49:35,920 --> 00:49:36,920
freely.

991
00:49:36,920 --> 00:49:37,920
That's not a tooling problem.

992
00:49:37,920 --> 00:49:39,120
That's a rollout problem.

993
00:49:39,120 --> 00:49:41,640
This isn't about whether purview is good software.

994
00:49:41,640 --> 00:49:42,640
It is.

995
00:49:42,640 --> 00:49:46,160
This is about the structural flow in how most organizations approach governance when there's

996
00:49:46,160 --> 00:49:48,280
no forcing function to do it right.

997
00:49:48,280 --> 00:49:51,200
The whole problem is change management that nobody planned for.

998
00:49:51,200 --> 00:49:55,320
It's the difference between turning something on and actually deploying something.

999
00:49:55,320 --> 00:49:56,320
The problem.

1000
00:49:56,320 --> 00:49:58,320
Why ease becomes a trap?

1001
00:49:58,320 --> 00:49:59,560
Starting costs nothing.

1002
00:49:59,560 --> 00:50:01,640
So most teams start with nothing in mind.

1003
00:50:01,640 --> 00:50:02,920
There's no business case to write.

1004
00:50:02,920 --> 00:50:04,200
There's no budget conversation.

1005
00:50:04,200 --> 00:50:07,160
The feature is already licensed as part of your M365 spend.

1006
00:50:07,160 --> 00:50:08,160
Why not turn it on?

1007
00:50:08,160 --> 00:50:09,680
The friction to activate is zero.

1008
00:50:09,680 --> 00:50:11,640
The friction to plan is high.

1009
00:50:11,640 --> 00:50:13,160
So people skip the planning.

1010
00:50:13,160 --> 00:50:15,520
What happens next follows a predictable pattern.

1011
00:50:15,520 --> 00:50:16,720
Everyone gains access to purview.

1012
00:50:16,720 --> 00:50:17,720
They look at the data map.

1013
00:50:17,720 --> 00:50:19,320
They think we should scan everything.

1014
00:50:19,320 --> 00:50:22,000
Every database, every data lake, every fabric workspace.

1015
00:50:22,000 --> 00:50:24,160
The idea is to build a full picture of the data estate.

1016
00:50:24,160 --> 00:50:25,160
It feels productive.

1017
00:50:25,160 --> 00:50:26,800
It feels like you're taking control.

1018
00:50:26,800 --> 00:50:28,320
Then the scans run.

1019
00:50:28,320 --> 00:50:29,640
Thousands of assets appear.

1020
00:50:29,640 --> 00:50:31,560
Raw tables from operational systems.

1021
00:50:31,560 --> 00:50:33,520
Staging tables from ETL pipelines.

1022
00:50:33,520 --> 00:50:35,040
Test tables, nobody uses.

1023
00:50:35,040 --> 00:50:36,600
Ancient tables everyone forgot about.

1024
00:50:36,600 --> 00:50:38,840
Duplicate tables from failed migrations.

1025
00:50:38,840 --> 00:50:40,080
The catalog fills with noise.

1026
00:50:40,080 --> 00:50:44,560
The signal to noise ratio is so bad that finding an actual answer becomes harder than

1027
00:50:44,560 --> 00:50:46,440
just calling someone on the phone.

1028
00:50:46,440 --> 00:50:48,360
Business users open the catalog for the first time.

1029
00:50:48,360 --> 00:50:52,000
They look for something specific like a customer data set or a metric for revenue, but they

1030
00:50:52,000 --> 00:50:53,800
see a thousand results instead.

1031
00:50:53,800 --> 00:50:55,400
None of them have names that make sense.

1032
00:50:55,400 --> 00:50:58,760
They see SQL ProDraw, EU2 and TBL are staging before seven.

1033
00:50:58,760 --> 00:51:02,200
The names mean something to the DBAs who created them, but they mean nothing to the people

1034
00:51:02,200 --> 00:51:03,200
trying to find answers.

1035
00:51:03,200 --> 00:51:04,440
They close the catalog.

1036
00:51:04,440 --> 00:51:06,120
They never come back.

1037
00:51:06,120 --> 00:51:07,520
Meanwhile permissions sprawl.

1038
00:51:07,520 --> 00:51:09,960
Early access requests get approved loosely.

1039
00:51:09,960 --> 00:51:11,840
Someone needs to see a table so they get access.

1040
00:51:11,840 --> 00:51:14,320
Someone else needs access to the collection so they get added.

1041
00:51:14,320 --> 00:51:17,080
By month three, nobody knows who sees what anymore.

1042
00:51:17,080 --> 00:51:18,800
The central team can't answer the question.

1043
00:51:18,800 --> 00:51:22,040
The domain owners don't understand the permissions they've delegated.

1044
00:51:22,040 --> 00:51:26,000
New employees ask who they should talk to about access, and the answer is, "I'm not

1045
00:51:26,000 --> 00:51:28,120
sure, probably multiple people."

1046
00:51:28,120 --> 00:51:32,400
You spend the budget, you build the infrastructure, you deploy the platform, but you lost the trust.

1047
00:51:32,400 --> 00:51:35,720
The real cost of a failed rollout isn't the tool or the licensing.

1048
00:51:35,720 --> 00:51:37,400
Its organizational credibility.

1049
00:51:37,400 --> 00:51:41,200
It's the moment people decide that data governance is a waste of time because the tool

1050
00:51:41,200 --> 00:51:42,880
they were given doesn't work.

1051
00:51:42,880 --> 00:51:45,160
It's skepticism lingers for years.

1052
00:51:45,160 --> 00:51:46,160
The real failure.

1053
00:51:46,160 --> 00:51:48,200
Big bang versus use case first.

1054
00:51:48,200 --> 00:51:50,560
The fundamental mistake is starting with infrastructure.

1055
00:51:50,560 --> 00:51:54,120
Instead of starting with a question, most teams approach a rollout like this.

1056
00:51:54,120 --> 00:51:55,360
Here is our org chart.

1057
00:51:55,360 --> 00:51:58,400
Let's catalog everything to mirror how we are organized.

1058
00:51:58,400 --> 00:51:59,720
Finance gets a domain.

1059
00:51:59,720 --> 00:52:00,720
Operations gets a domain.

1060
00:52:00,720 --> 00:52:02,760
We scan the finance databases here.

1061
00:52:02,760 --> 00:52:05,960
And the ops databases there, we create all the governance domains at once.

1062
00:52:05,960 --> 00:52:07,080
We assign all the roles.

1063
00:52:07,080 --> 00:52:08,480
We publish everything.

1064
00:52:08,480 --> 00:52:10,960
Now we have a catalog that matches our org structure.

1065
00:52:10,960 --> 00:52:11,800
That feels productive.

1066
00:52:11,800 --> 00:52:13,320
It feels complete.

1067
00:52:13,320 --> 00:52:16,600
But in reality, it delivers nothing.

1068
00:52:16,600 --> 00:52:18,520
A claims manager opens the catalog.

1069
00:52:18,520 --> 00:52:20,280
They search for fraud detection data.

1070
00:52:20,280 --> 00:52:24,440
The system returns results from the claims domain, the fraud domain, and the risk management

1071
00:52:24,440 --> 00:52:25,440
domain.

1072
00:52:25,440 --> 00:52:26,360
They don't know which one they need.

1073
00:52:26,360 --> 00:52:28,120
They have to ask someone.

1074
00:52:28,120 --> 00:52:29,680
The catalog didn't answer their question.

1075
00:52:29,680 --> 00:52:31,360
The catalog just created more work.

1076
00:52:31,360 --> 00:52:35,600
This approach is backward because you are organizing the catalog before you understand

1077
00:52:35,600 --> 00:52:37,600
what questions it is supposed to answer.

1078
00:52:37,600 --> 00:52:40,680
You are building infrastructure hoping that structure will somehow create value.

1079
00:52:40,680 --> 00:52:42,360
It won't.

1080
00:52:42,360 --> 00:52:44,760
Structure without purpose is just noise at scale.

1081
00:52:44,760 --> 00:52:45,760
There is a better starting point.

1082
00:52:45,760 --> 00:52:47,400
A use case is one sentence.

1083
00:52:47,400 --> 00:52:50,640
One business question, real people are actually waiting on.

1084
00:52:50,640 --> 00:52:53,080
Which claims are likely to be fraudulent this quarter?

1085
00:52:53,080 --> 00:52:55,320
How many customers will we lose before renewal?

1086
00:52:55,320 --> 00:52:58,560
Which transactions violate our policies within 24 hours?

1087
00:52:58,560 --> 00:52:59,560
These aren't themes.

1088
00:52:59,560 --> 00:53:01,840
These are specific questions with business consequences.

1089
00:53:01,840 --> 00:53:02,840
Pick one.

1090
00:53:02,840 --> 00:53:04,200
That one sentence does immense work.

1091
00:53:04,200 --> 00:53:05,720
It names the sources that matter.

1092
00:53:05,720 --> 00:53:07,520
Not every database in your organization.

1093
00:53:07,520 --> 00:53:10,160
Just the ones required to answer that specific question.

1094
00:53:10,160 --> 00:53:12,400
It names the collection those sources belonging.

1095
00:53:12,400 --> 00:53:14,640
It names the governance domain that owns the answer.

1096
00:53:14,640 --> 00:53:15,960
It names your first audience.

1097
00:53:15,960 --> 00:53:18,480
These are the people who have been waiting for this answer.

1098
00:53:18,480 --> 00:53:20,520
And they will be your earliest advocates.

1099
00:53:20,520 --> 00:53:22,400
One use case pulls the entire roll out forward.

1100
00:53:22,400 --> 00:53:24,200
It forces prioritization.

1101
00:53:24,200 --> 00:53:27,760
It creates pressure to get governance right because someone is waiting on an answer.

1102
00:53:27,760 --> 00:53:28,760
It creates accountability.

1103
00:53:28,760 --> 00:53:29,960
It creates focus.

1104
00:53:29,960 --> 00:53:32,040
A big bank scan creates noise.

1105
00:53:32,040 --> 00:53:33,720
Use case first creates focus.

1106
00:53:33,720 --> 00:53:35,040
Noise kills adoption.

1107
00:53:35,040 --> 00:53:36,040
Focus builds it.

1108
00:53:36,040 --> 00:53:37,640
The four layer permission blueprint.

1109
00:53:37,640 --> 00:53:40,600
Per view spreads access across four distinct layers.

1110
00:53:40,600 --> 00:53:43,600
Most teams discover them one access denied ticket at a time.

1111
00:53:43,600 --> 00:53:44,600
Here is how it works.

1112
00:53:44,600 --> 00:53:45,760
You have the tenant layer.

1113
00:53:45,760 --> 00:53:48,560
This sits at the organizational level and applies to everything.

1114
00:53:48,560 --> 00:53:49,960
You have the data map layer.

1115
00:53:49,960 --> 00:53:53,680
This controls who can register sources and manage metadata in the scanning engine.

1116
00:53:53,680 --> 00:53:55,400
You have the unified catalog layer.

1117
00:53:55,400 --> 00:53:59,480
This lives in settings and controls who can see and create business concepts.

1118
00:53:59,480 --> 00:54:01,240
And you have the governance domain layer.

1119
00:54:01,240 --> 00:54:05,680
This sits inside each individual domain and controls glossary terms and data products.

1120
00:54:05,680 --> 00:54:07,560
Each layer grants a different kind of power.

1121
00:54:07,560 --> 00:54:08,920
Each layer has its own roles.

1122
00:54:08,920 --> 00:54:10,960
Each layer requires its own permission assignments.

1123
00:54:10,960 --> 00:54:14,320
A person who needs to create a data product doesn't just need one role.

1124
00:54:14,320 --> 00:54:17,360
They need permissions in multiple layers simultaneously.

1125
00:54:17,360 --> 00:54:19,280
That is where most roll outs break.

1126
00:54:19,280 --> 00:54:20,760
Teams treat these layers as separate.

1127
00:54:20,760 --> 00:54:22,320
They grant a role in one layer.

1128
00:54:22,320 --> 00:54:23,960
They grant a different role in another.

1129
00:54:23,960 --> 00:54:27,200
A week later, someone is confused about why they can't do their job.

1130
00:54:27,200 --> 00:54:29,440
They have permission in one layer but not another.

1131
00:54:29,440 --> 00:54:30,880
Half of the functionality works.

1132
00:54:30,880 --> 00:54:32,720
And the other half doesn't.

1133
00:54:32,720 --> 00:54:34,320
Support tickets.

1134
00:54:34,320 --> 00:54:36,080
Two rules sit above everything.

1135
00:54:36,080 --> 00:54:37,880
First, assign roles to entry groups.

1136
00:54:37,880 --> 00:54:39,320
Never to individual users.

1137
00:54:39,320 --> 00:54:42,760
A group doesn't care if someone leaves the organization or changes roles.

1138
00:54:42,760 --> 00:54:45,000
A group is stable if you assign to a user.

1139
00:54:45,000 --> 00:54:48,080
You will spend your life managing individual role assignments.

1140
00:54:48,080 --> 00:54:51,200
Second, don't create a group for every role in every layer.

1141
00:54:51,200 --> 00:54:54,720
That is how you end up with 40 groups in a spreadsheet trying to track which one is

1142
00:54:54,720 --> 00:54:55,720
which.

1143
00:54:55,720 --> 00:54:58,320
A real person needs grants in more than one layer at once.

1144
00:54:58,320 --> 00:54:59,840
Bundle those grants into role groups.

1145
00:54:59,840 --> 00:55:03,080
Package the permissions a persona needs into one unit, four layers.

1146
00:55:03,080 --> 00:55:04,360
Not about five groups.

1147
00:55:04,360 --> 00:55:07,080
That is the structure that actually works.

1148
00:55:07,080 --> 00:55:08,080
Layer one.

1149
00:55:08,080 --> 00:55:09,080
Tenant level.

1150
00:55:09,080 --> 00:55:10,080
The keys to everything.

1151
00:55:10,080 --> 00:55:12,560
The tenant layer lives at the very top of your organization.

1152
00:55:12,560 --> 00:55:14,880
It controls both the data map and the unified catalog.

1153
00:55:14,880 --> 00:55:17,960
This is where you hand out the most dangerous permissions in the entire system.

1154
00:55:17,960 --> 00:55:19,560
Two role groups matter here.

1155
00:55:19,560 --> 00:55:21,680
Per view administrators and data governance.

1156
00:55:21,680 --> 00:55:25,480
Per view administrators have the power to create domains and assign roles across the data

1157
00:55:25,480 --> 00:55:26,480
map.

1158
00:55:26,480 --> 00:55:28,720
They can change your scan rules and manage every connection.

1159
00:55:28,720 --> 00:55:32,480
Data governance admins hold the keys to the first level of catalog access.

1160
00:55:32,480 --> 00:55:35,040
This is the entry point for managing your business concepts.

1161
00:55:35,040 --> 00:55:38,360
But before you assign a single role, check your account type.

1162
00:55:38,360 --> 00:55:40,960
Unified catalog features require enterprise licensing.

1163
00:55:40,960 --> 00:55:44,400
If you stay on the free tier, you can flip the switch but half the features won't actually

1164
00:55:44,400 --> 00:55:45,400
work.

1165
00:55:45,400 --> 00:55:48,040
You have to commit to enterprise or accept the limitations from day one.

1166
00:55:48,040 --> 00:55:49,520
Keep this layer small.

1167
00:55:49,520 --> 00:55:51,120
Use the fewest privileges possible.

1168
00:55:51,120 --> 00:55:54,000
You want no more than two or three admins on the default domain.

1169
00:55:54,000 --> 00:55:56,400
One should be a service principle for your automation.

1170
00:55:56,400 --> 00:55:59,680
The other should be a break-class account for genuine emergencies.

1171
00:55:59,680 --> 00:56:01,480
Both of these stay inactive by default.

1172
00:56:01,480 --> 00:56:04,720
They should always require elevation before they can do anything.

1173
00:56:04,720 --> 00:56:06,600
There is one role you should actually fear.

1174
00:56:06,600 --> 00:56:10,920
The Per view administrator can change almost anything, including its own access levels.

1175
00:56:10,920 --> 00:56:14,280
Giving someone standing access to this role is just a security breach waiting for a calendar

1176
00:56:14,280 --> 00:56:15,280
invite.

1177
00:56:15,280 --> 00:56:17,160
Never handed out as a permanent membership.

1178
00:56:17,160 --> 00:56:18,640
Treat it like nuclear material.

1179
00:56:18,640 --> 00:56:21,120
The tenant layer decides who configures the platform.

1180
00:56:21,120 --> 00:56:24,400
The next layer decides where your metadata actually lives.

1181
00:56:24,400 --> 00:56:25,400
Layer 2.

1182
00:56:25,400 --> 00:56:26,400
Data map.

1183
00:56:26,400 --> 00:56:27,400
Collections and domains.

1184
00:56:27,400 --> 00:56:29,600
The data map is your live inventory.

1185
00:56:29,600 --> 00:56:32,320
It tracks assets across every source you register.

1186
00:56:32,320 --> 00:56:34,840
You shape this map using two specific tools.

1187
00:56:34,840 --> 00:56:36,440
Domains and collections.

1188
00:56:36,440 --> 00:56:39,240
Domains are technical boundaries at the top of the hierarchy.

1189
00:56:39,240 --> 00:56:42,440
They separate your credentials, your scan rules and your policies.

1190
00:56:42,440 --> 00:56:46,240
One domain cannot see another domain secrets or executed rules.

1191
00:56:46,240 --> 00:56:49,000
You get one default domain and up to four customers.

1192
00:56:49,000 --> 00:56:51,520
Only add a custom domain if you have a massive boundary.

1193
00:56:51,520 --> 00:56:55,040
Think separate global regions or legal entities in different countries.

1194
00:56:55,040 --> 00:56:57,320
Do not use them to separate dev from production.

1195
00:56:57,320 --> 00:56:59,880
That isn't a big enough reason to justify the complexity.

1196
00:56:59,880 --> 00:57:01,480
That's what collections are for.

1197
00:57:01,480 --> 00:57:02,480
Collections are operational.

1198
00:57:02,480 --> 00:57:04,080
They are your security boundary for metadata.

1199
00:57:04,080 --> 00:57:08,480
You can have up to 1,000 collections and eight levels of depth, but you should resist that

1200
00:57:08,480 --> 00:57:09,480
depth.

1201
00:57:09,480 --> 00:57:12,040
Don't build your collections to mirror your org chart.

1202
00:57:12,040 --> 00:57:13,280
Organizations change constantly.

1203
00:57:13,280 --> 00:57:17,160
If you tie your metadata to a specific department head, your structure will be outdated by

1204
00:57:17,160 --> 00:57:18,160
next Tuesday.

1205
00:57:18,160 --> 00:57:20,960
Four roles control access at the collection level.

1206
00:57:20,960 --> 00:57:23,160
The collection admin manages the roles.

1207
00:57:23,160 --> 00:57:26,320
The data source admin registers the sources and runs the scans.

1208
00:57:26,320 --> 00:57:27,760
The data creator creates the assets.

1209
00:57:27,760 --> 00:57:31,840
The data reader just views what is there because these permissions flow down to child collections.

1210
00:57:31,840 --> 00:57:35,080
You can run access at the top and it will cover everything below.

1211
00:57:35,080 --> 00:57:39,000
Shape your collections around business domains, not technical platforms.

1212
00:57:39,000 --> 00:57:43,200
Users need to find claims, not as your SQL policy admin database.

1213
00:57:43,200 --> 00:57:47,280
When a claims analyst opens the catalog and sees a folder named Claims, they know they

1214
00:57:47,280 --> 00:57:48,280
are in the right place.

1215
00:57:48,280 --> 00:57:49,480
That is how you drive adoption.

1216
00:57:49,480 --> 00:57:53,760
The platform teams should run the scans, but the labels belong to the business.

1217
00:57:53,760 --> 00:57:55,440
Keep your collection admins to a minimum.

1218
00:57:55,440 --> 00:58:00,400
Assign them at the top level or specific subcollections, but never spray them across the whole account.

1219
00:58:00,400 --> 00:58:04,040
The moment you treat a collection admin request like a standard ticket, you've lost control

1220
00:58:04,040 --> 00:58:05,040
of the system.

1221
00:58:05,040 --> 00:58:06,760
Collections answer where the metadata sits.

1222
00:58:06,760 --> 00:58:08,640
They don't answer what the business calls it.

1223
00:58:08,640 --> 00:58:09,640
That's the next layer.

1224
00:58:09,640 --> 00:58:12,760
Layer three unified catalog, the control panel.

1225
00:58:12,760 --> 00:58:14,520
Unified catalog lives in settings.

1226
00:58:14,520 --> 00:58:16,120
Then unified catalog.

1227
00:58:16,120 --> 00:58:17,440
Inside the purview portal.

1228
00:58:17,440 --> 00:58:21,120
That one area is the control panel for your entire business catalog.

1229
00:58:21,120 --> 00:58:24,360
It's where you assign every catalog level role under a single menu.

1230
00:58:24,360 --> 00:58:26,920
And this is where most why can't I see this?

1231
00:58:26,920 --> 00:58:28,120
Tickets are born.

1232
00:58:28,120 --> 00:58:29,600
But here's the problem.

1233
00:58:29,600 --> 00:58:31,760
There's a critical leak you need to know about.

1234
00:58:31,760 --> 00:58:35,800
A user with read access on an Azure or fabric resource can see that asset in the catalog

1235
00:58:35,800 --> 00:58:37,400
using live view.

1236
00:58:37,400 --> 00:58:41,240
Even if you never granted them catalog access, you need to audit your existing Azure role

1237
00:58:41,240 --> 00:58:44,600
assignments before you assume the catalog is private.

1238
00:58:44,600 --> 00:58:47,040
The unified catalog uses three permission levels.

1239
00:58:47,040 --> 00:58:50,480
The tenant level handles who creates domains and reaches across all catalogs.

1240
00:58:50,480 --> 00:58:54,440
The catalog level holds roles that span every governance domain globally.

1241
00:58:54,440 --> 00:58:57,320
The governance domain level sits inside each individual domain.

1242
00:58:57,320 --> 00:58:59,840
At the catalog level, several roles matter.

1243
00:58:59,840 --> 00:59:03,280
The governance domain creator builds domains and delegates ownership.

1244
00:59:03,280 --> 00:59:06,800
The global catalog reader sees published concepts across all domains unless you restrict

1245
00:59:06,800 --> 00:59:07,640
them.

1246
00:59:07,640 --> 00:59:10,680
The global asset curator adds glossary terms to assets.

1247
00:59:10,680 --> 00:59:13,480
The data health owner and reader build and read health reports.

1248
00:59:13,480 --> 00:59:15,320
Pay attention to the two reader roles.

1249
00:59:15,320 --> 00:59:17,760
The global catalog reader sees across the whole catalog.

1250
00:59:17,760 --> 00:59:21,760
With the local catalog reader, which you set inside a single domain limits reading to that

1251
00:59:21,760 --> 00:59:22,880
one domain only.

1252
00:59:22,880 --> 00:59:25,000
This role exists for regulatory roles.

1253
00:59:25,000 --> 00:59:27,200
For when the metadata itself must stay hidden.

1254
00:59:27,200 --> 00:59:29,560
If you overuse it, you fragment discovery.

1255
00:59:29,560 --> 00:59:30,800
You end up rebuilding the silos.

1256
00:59:30,800 --> 00:59:32,360
The catalog was supposed to tear down.

1257
00:59:32,360 --> 00:59:33,880
So flip your instinct here.

1258
00:59:33,880 --> 00:59:39,640
Most people think you should hand out read access slowly, restrictively, defensively.

1259
00:59:39,640 --> 00:59:42,120
Resist that.

1260
00:59:42,120 --> 00:59:45,000
A reader sees metadata, never data.

1261
00:59:45,000 --> 00:59:49,440
They see table names, column names, descriptions, owners and lineage.

1262
00:59:49,440 --> 00:59:53,600
They don't see a single row of actual data default to broadread because a catalog nobody

1263
00:59:53,600 --> 00:59:55,000
can see is useless.

1264
00:59:55,000 --> 00:59:56,720
One thing carries forward.

1265
00:59:56,720 --> 00:59:59,800
Catalog read access alone doesn't reveal asset details.

1266
00:59:59,800 --> 01:00:02,760
A true reader also needs data reader down in the data map.

1267
01:00:02,760 --> 01:00:05,560
One persona, two layers.

1268
01:00:05,560 --> 01:00:07,320
Grant both.

1269
01:00:07,320 --> 01:00:11,880
Inside each governance domain, a different set of roles runs the business of the data.

1270
01:00:11,880 --> 01:00:15,360
Therefore, governance domain level, where business shows up.

1271
01:00:15,360 --> 01:00:20,360
A governance domain is the boundary for shared ownership and discovery of data products.

1272
01:00:20,360 --> 01:00:21,680
This is where the business shows up.

1273
01:00:21,680 --> 01:00:25,480
This is where business owners, not platform teams, run the show.

1274
01:00:25,480 --> 01:00:29,440
The governance domain owner delegates all other domain roles and sets policies.

1275
01:00:29,440 --> 01:00:33,440
You should put at least two owners on every domain so it never has a single point of failure.

1276
01:00:33,440 --> 01:00:36,280
The data steward creates and manages glossary terms.

1277
01:00:36,280 --> 01:00:39,680
OKRs, policies and other business artifacts.

1278
01:00:39,680 --> 01:00:42,600
The data product owner creates and manages data products.

1279
01:00:42,600 --> 01:00:45,120
The governance domain reader reads published metadata.

1280
01:00:45,120 --> 01:00:48,680
This is where the two worlds meet to add a data asset to a data product.

1281
01:00:48,680 --> 01:00:54,040
A data product owner or data steward also needs data reader permission on that asset down

1282
01:00:54,040 --> 01:00:55,040
in the data map.

1283
01:00:55,040 --> 01:00:58,280
Business ownership and physical access touch at exactly this point.

1284
01:00:58,280 --> 01:01:00,120
One person, two layers again.

1285
01:01:00,120 --> 01:01:02,600
One persona spanning multiple permission layers.

1286
01:01:02,600 --> 01:01:05,640
This is where the four layers stop being abstract and become operational.

1287
01:01:05,640 --> 01:01:07,280
You understand tenant level power.

1288
01:01:07,280 --> 01:01:09,200
You understand data map organization.

1289
01:01:09,200 --> 01:01:11,440
You understand catalog visibility.

1290
01:01:11,440 --> 01:01:14,640
Now you understand how business meaning actually flows through the system.

1291
01:01:14,640 --> 01:01:18,440
The question becomes how do you package all these permissions into something people can

1292
01:01:18,440 --> 01:01:19,280
actually manage?