How to Master Dataverse Business Skills for Scale

1
00:00:00,000 --> 00:00:04,160
The gap between building in Dataverse and architecting with Dataverse is not a skill issue.

2
00:00:04,160 --> 00:00:05,360
It is a thinking issue.

3
00:00:05,360 --> 00:00:08,760
Most organizations treat Dataverse like an expensive spreadsheet.

4
00:00:08,760 --> 00:00:10,200
They build one table per app.

5
00:00:10,200 --> 00:00:13,960
They copy data across five different places because it feels convenient in the moment.

6
00:00:13,960 --> 00:00:18,320
They scatter business logic across power-automate flows, plugins, and business rules.

7
00:00:18,320 --> 00:00:22,800
Then they wonder why changing a single rule requires a treasure hunt through the entire environment.

8
00:00:22,800 --> 00:00:24,360
But here is what is happening underneath.

9
00:00:24,360 --> 00:00:28,040
A structural floor is costing enterprises millions in maintenance and rework.

10
00:00:28,040 --> 00:00:33,000
Yet almost nobody names it. Dataverse business skills isn't about clicking buttons or learning the latest feature.

11
00:00:33,000 --> 00:00:34,400
It means thinking relationally.

12
00:00:34,400 --> 00:00:39,120
It means designing systems that don't break when you scale from 100 users to 10,000.

13
00:00:39,120 --> 00:00:42,440
You need to build architectures where security is structural, not bolted on at the end.

14
00:00:42,440 --> 00:00:47,680
The goal is keeping business logic consistent across every single app that touches your data.

15
00:00:47,680 --> 00:00:52,440
By the end of this episode, you will understand the three pillars that separate architects from builders.

16
00:00:52,440 --> 00:00:55,240
You will see patterns that actually work at enterprise scale.

17
00:00:55,240 --> 00:01:00,200
And you will have a 90-day roadmap to prove that relational thinking works in your organization.

18
00:01:00,200 --> 00:01:04,280
The problem, nobody names, grid thinking versus relational intelligence.

19
00:01:04,280 --> 00:01:09,320
There is a metaphor destroying enterprise dataverse environments right now, the spreadsheet metaphor.

20
00:01:09,320 --> 00:01:12,760
When people think about dataverse, they usually just think about tables.

21
00:01:12,760 --> 00:01:14,000
They see columns and rows.

22
00:01:14,000 --> 00:01:18,080
They add a column for every new requirement and create a new table for every new app.

23
00:01:18,080 --> 00:01:21,880
It feels intuitive and visual because you can see your data right in front of you.

24
00:01:21,880 --> 00:01:23,720
And it works until it doesn't.

25
00:01:23,720 --> 00:01:25,720
Imagine you have customer data in a table.

26
00:01:25,720 --> 00:01:28,840
The sales app needs extra customer attributes, so you add them.

27
00:01:28,840 --> 00:01:31,760
Then operations needs different data, so you add even more columns.

28
00:01:31,760 --> 00:01:36,200
Suddenly you are looking at 200 columns where some are used by sales, some by operations,

29
00:01:36,200 --> 00:01:37,880
and some by nobody at all.

30
00:01:37,880 --> 00:01:39,600
The table became a dumping ground.

31
00:01:39,600 --> 00:01:40,800
Then you build a second app.

32
00:01:40,800 --> 00:01:43,400
You ask yourself if it should use the same customer table,

33
00:01:43,400 --> 00:01:47,520
but it feels easier to just copy the data into a new table for that specific app.

34
00:01:47,520 --> 00:01:49,600
Now your customer information lives in two places.

35
00:01:49,600 --> 00:01:52,400
When an account number changes, you have to update both tables.

36
00:01:52,400 --> 00:01:55,200
But you eventually forget the third table where that data also lives.

37
00:01:55,200 --> 00:01:56,240
One version is right.

38
00:01:56,240 --> 00:01:57,520
Three versions are wrong.

39
00:01:57,520 --> 00:01:59,160
You have conflicting versions of the truth.

40
00:01:59,160 --> 00:02:00,160
This is grid thinking.

41
00:02:00,160 --> 00:02:03,360
It feels like organization, but in reality, it is just chaos.

42
00:02:03,360 --> 00:02:06,120
Relational intelligence starts with a different question.

43
00:02:06,120 --> 00:02:07,840
It isn't, where do I put this?

44
00:02:07,840 --> 00:02:10,600
It is, what business concept does this represent?

45
00:02:10,600 --> 00:02:12,720
And what else does it connect to?

46
00:02:12,720 --> 00:02:16,280
Building one table per app is a strategy that scales directly into failure.

47
00:02:16,280 --> 00:02:21,160
When you hit 1000 users, the maintenance will crush you because you aren't maintaining one app anymore.

48
00:02:21,160 --> 00:02:24,960
You are maintaining dozens of copies of similar logic, data and security rules.

49
00:02:24,960 --> 00:02:27,640
The cost stays hidden until it becomes impossible to ignore.

50
00:02:27,640 --> 00:02:31,320
It hides in your development time when a two-week project takes six weeks

51
00:02:31,320 --> 00:02:33,320
because you are untangling conflicting structures.

52
00:02:33,320 --> 00:02:38,280
It hides in maintenance when you spend two days every month just reconciling duplicate account numbers.

53
00:02:38,280 --> 00:02:42,640
It hides in the decisions you can't make because you don't know which version of the data is actually correct.

54
00:02:42,640 --> 00:02:43,800
The problem becomes visible.

55
00:02:43,800 --> 00:02:48,480
The moment you need a fundamental change, a single security rule might affect five different apps.

56
00:02:48,480 --> 00:02:52,680
But your business logic is scattered across flows, calculated columns and plugins.

57
00:02:52,680 --> 00:02:56,600
You change it once and forget the other three spots, so the system breaks silently.

58
00:02:56,600 --> 00:03:00,280
The moment arrives when a system built for 100 users holds at 1000.

59
00:03:00,280 --> 00:03:03,200
This doesn't happen because datavers can't handle the load.

60
00:03:03,200 --> 00:03:07,600
It happens because the architecture never learned how to think relationally about scale.

61
00:03:07,600 --> 00:03:08,520
Transition.

62
00:03:08,520 --> 00:03:09,800
This isn't a technical failure.

63
00:03:09,800 --> 00:03:14,320
It is an architectural one, and it all starts with how you think about your data.

64
00:03:14,320 --> 00:03:15,920
The three structural flaws.

65
00:03:15,920 --> 00:03:18,840
Floor one, data duplication as the root cause.

66
00:03:18,840 --> 00:03:23,440
When you are building apps at high speed, duplicating data feels like a clever shortcut.

67
00:03:23,440 --> 00:03:27,560
But in reality, it is just debt that grows until you can no longer pay it off.

68
00:03:27,560 --> 00:03:30,160
Your main CRM table holds all your customer information,

69
00:03:30,160 --> 00:03:35,520
but then the sales team builds their own app and copies names, IDs and account statuses into a separate table

70
00:03:35,520 --> 00:03:37,280
because it makes their queries faster.

71
00:03:37,280 --> 00:03:41,640
Operations follows suit with their own version, and by the six month mark you have five different tables

72
00:03:41,640 --> 00:03:43,800
all claiming to hold the same customer data.

73
00:03:43,800 --> 00:03:48,920
At that point, you no longer have a single source of truth or worse, you have five competing versions of it.

74
00:03:48,920 --> 00:03:52,720
Imagine an account number was typed incorrectly two years ago and finally gets caught.

75
00:03:52,720 --> 00:03:57,120
It fixes the mistake in one table, but finance is still pulling reports from a different one,

76
00:03:57,120 --> 00:04:01,560
leading to a weak long argument between departments about who actually has the right numbers.

77
00:04:01,560 --> 00:04:07,880
The reality is that neither of them is right because they are both looking at outdated, disconnected versions of the same exact concept.

78
00:04:07,880 --> 00:04:13,480
This is the moment where a single source of truth stops being a corporate philosophy and becomes a requirement for survival.

79
00:04:13,480 --> 00:04:17,360
When your customer information has one definition and one owner in one location,

80
00:04:17,360 --> 00:04:20,160
you change it once and that change flows everywhere instantly.

81
00:04:20,160 --> 00:04:25,080
Duplication does the opposite by forcing you to manage five different versions while hoping they somehow stay in sync.

82
00:04:25,080 --> 00:04:28,200
The cost of trying to reconcile these differences is massive.

83
00:04:28,200 --> 00:04:32,320
I have seen finance teams spend two full days every single month just cross checking account numbers

84
00:04:32,320 --> 00:04:34,440
and status flags across three different tables.

85
00:04:34,440 --> 00:04:37,520
They end up building manual spreadsheets to bridge the gaps

86
00:04:37,520 --> 00:04:41,760
and when those spreadsheets inevitably break the entire month and close gets delayed.

87
00:04:41,760 --> 00:04:47,320
That isn't a data problem, it is an architectural failure that creates endless manual work for your people.

88
00:04:47,320 --> 00:04:50,200
Ordered risks also start building up where you can't see them.

89
00:04:50,200 --> 00:04:55,000
When an auditor asks you to prove a decision was made using correct data and your answer is,

90
00:04:55,000 --> 00:04:56,760
it depends on which table you look at.

91
00:04:56,760 --> 00:04:59,840
You are inviting a much deeper compliance investigation.

92
00:04:59,840 --> 00:05:03,560
Regulators see duplicate systems and immediately wonder which one is real,

93
00:05:03,560 --> 00:05:09,520
which triggers forensic reviews that shift your costs from simple reconciliation to massive auditor fees.

94
00:05:09,520 --> 00:05:12,080
Then you have the compliance violations that emerge out of nowhere.

95
00:05:12,080 --> 00:05:16,320
You might delete a customer's personal data to comply with the GDPR request in your primary table

96
00:05:16,320 --> 00:05:21,680
but six months later an old report pulls that same data from a secondary table where it still exists.

97
00:05:21,680 --> 00:05:27,120
You have violated a major regulation without even knowing it because your data was living in too many places at once.

98
00:05:27,120 --> 00:05:31,160
Floor 2. Logic scattered across apps, flows and forms.

99
00:05:31,160 --> 00:05:35,160
The rules that run your business should never exist in five different places at the same time.

100
00:05:35,160 --> 00:05:39,840
Take a simple order validation rule where an amount cannot exceed a customer's credit limit.

101
00:05:39,840 --> 00:05:43,240
In a messy system, that logic might live in a power automate flow,

102
00:05:43,240 --> 00:05:48,040
a plug-in that triggers on a save, a calculated field on a form, and a business rule all at once.

103
00:05:48,040 --> 00:05:51,960
When that credit limit rule eventually needs to change, you have to go on a hunt

104
00:05:51,960 --> 00:05:54,440
to find every single spot where it was programmed.

105
00:05:54,440 --> 00:05:58,840
You might find the flow and update it, but two months later you discover a calculated field

106
00:05:58,840 --> 00:06:02,480
was still using the old logic and approving orders that should have been blocked.

107
00:06:02,480 --> 00:06:06,560
You end up with a compliance issue that stayed hidden because the system didn't actually crash,

108
00:06:06,560 --> 00:06:08,040
it just diverged silently.

109
00:06:08,040 --> 00:06:10,080
This kind of brittleness is purely mechanical.

110
00:06:10,080 --> 00:06:13,120
When you build logic through a series of disconnected integrations,

111
00:06:13,120 --> 00:06:17,200
every piece of the puzzle depends on every other piece staying exactly the same forever.

112
00:06:17,200 --> 00:06:21,200
If one flow breaks, the process is downstream stop working without any warning,

113
00:06:21,200 --> 00:06:23,840
leaving apps waiting for data that is never going to arrive.

114
00:06:23,840 --> 00:06:31,600
Citizen developers often inherit these systems and try to fix a flow completely unaware that their change now conflicts with logic hidden somewhere else.

115
00:06:31,600 --> 00:06:34,800
The real nightmare of maintenance isn't getting a rule right the first time,

116
00:06:34,800 --> 00:06:40,160
it is the impossible task of finding and updating every single instance of that rule simultaneously.

117
00:06:40,160 --> 00:06:42,400
Performance always takes a hit in these scenarios,

118
00:06:42,400 --> 00:06:46,560
an approval process that used to take two seconds now drags on for 12

119
00:06:46,560 --> 00:06:49,600
because it is waiting on a chain of asynchronous flows,

120
00:06:49,600 --> 00:06:52,720
and eventually your users will just bypass the system entirely.

121
00:06:52,720 --> 00:06:56,800
Flo 3. Security as an afterthought, not a design.

122
00:06:56,800 --> 00:07:01,520
Trying to bolt security onto the top of a flat, unorganized data model almost always fails in practice.

123
00:07:01,520 --> 00:07:04,240
You might design a support table that everyone starts building on,

124
00:07:04,240 --> 00:07:09,120
but then a new compliance mandate says staff can only see cases from their specific region.

125
00:07:09,120 --> 00:07:11,360
You try to add a security role to fix this,

126
00:07:11,360 --> 00:07:14,800
but because the underlying schema doesn't actually enforce regional boundaries,

127
00:07:14,800 --> 00:07:16,960
you are relying entirely on a filter.

128
00:07:16,960 --> 00:07:20,320
One small configuration mistake, and suddenly everyone can see everything,

129
00:07:20,320 --> 00:07:23,280
or you over adjust the role, and now nobody can see anything at all.

130
00:07:23,280 --> 00:07:27,280
The system simply cannot enforce rules that the original design never anticipated.

131
00:07:27,280 --> 00:07:31,520
Row-level security is a beautiful thing when your data is structured to support it from day one.

132
00:07:31,520 --> 00:07:36,640
However, it becomes incredibly fragile when your architecture was never built to handle those kinds of permissions.

133
00:07:36,640 --> 00:07:40,080
The bad news usually arrives months later in an audit finding,

134
00:07:40,080 --> 00:07:43,680
showing that sensitive data was accessible to the wrong users for weeks.

135
00:07:43,680 --> 00:07:46,240
The investigation into what went wrong takes months,

136
00:07:46,240 --> 00:07:48,320
and the cost to fix it is even higher,

137
00:07:48,320 --> 00:07:51,600
or because security was treated as a layer to apply later,

138
00:07:51,600 --> 00:07:53,520
rather than a core design element.

139
00:07:53,520 --> 00:07:57,760
A healthcare organization I know learnt this lesson the hard way after their post-launch security model

140
00:07:57,760 --> 00:07:59,760
was found to be in violation of HIPAA.

141
00:07:59,760 --> 00:08:03,200
Because their data wasn't structured to enforce the necessary privacy rules,

142
00:08:03,200 --> 00:08:06,560
they had to spend nine months and six figures on a total redesign.

143
00:08:06,560 --> 00:08:07,360
Transition.

144
00:08:07,360 --> 00:08:09,760
These three floors are not actually separate problems,

145
00:08:09,760 --> 00:08:12,000
but are instead symptoms of a single disease,

146
00:08:12,000 --> 00:08:14,560
which is the failure to think relationally.

147
00:08:14,560 --> 00:08:17,360
The shift from transactional to structural thinking.

148
00:08:17,360 --> 00:08:22,160
Developing relational intelligence begins by asking a completely different set of questions.

149
00:08:22,160 --> 00:08:24,320
Most people start with transactional thinking,

150
00:08:24,320 --> 00:08:27,360
which focuses on how to store a specific piece of information right now,

151
00:08:27,360 --> 00:08:29,360
so they can launch the next app.

152
00:08:29,360 --> 00:08:32,320
They just want to put a customer name here and an account balance there

153
00:08:32,320 --> 00:08:33,760
and call the job finished.

154
00:08:33,760 --> 00:08:36,720
Relational thinking, however, asks how that piece of information relates

155
00:08:36,720 --> 00:08:38,480
to everything else in the ecosystem.

156
00:08:38,480 --> 00:08:42,480
You have to consider which other concepts depend on that customer data

157
00:08:42,480 --> 00:08:44,560
and which business processes are going to touch it.

158
00:08:44,560 --> 00:08:47,920
You need to know that when one value changes every other part of the system

159
00:08:47,920 --> 00:08:50,160
that needs to know is actually informed.

160
00:08:50,160 --> 00:08:52,160
The difference here is purely architectural.

161
00:08:52,160 --> 00:08:54,080
A builder focuses on the transaction,

162
00:08:54,080 --> 00:08:56,320
but an architect focuses on the structure.

163
00:08:56,320 --> 00:09:01,520
An architect understands that customer isn't just a convenient place to store names and phone numbers,

164
00:09:01,520 --> 00:09:03,840
but is a fundamental business concept.

165
00:09:03,840 --> 00:09:05,920
It is the hub that connects your orders,

166
00:09:05,920 --> 00:09:09,120
invoices, support cases, and payment histories,

167
00:09:09,120 --> 00:09:12,800
and every one of those connections must be modeled correctly.

168
00:09:12,800 --> 00:09:14,480
When you start thinking structurally,

169
00:09:14,480 --> 00:09:17,200
you realize that a customer is never a simple thing.

170
00:09:17,200 --> 00:09:20,400
It is the intersection where all your different business processes meet.

171
00:09:20,400 --> 00:09:25,520
If you model that intersection poorly by duplicating tables or scattering rules across different apps,

172
00:09:25,520 --> 00:09:28,800
those processes are eventually going to crash into each other.

173
00:09:28,800 --> 00:09:33,120
You can find clarity by asking what business concept a table actually represents.

174
00:09:33,120 --> 00:09:34,880
If you have a table called "Temper customer"

175
00:09:34,880 --> 00:09:37,040
because you only needed it for one specific app,

176
00:09:37,040 --> 00:09:38,480
you aren't building a concept,

177
00:09:38,480 --> 00:09:40,960
you are just avoiding a difficult design choice.

178
00:09:40,960 --> 00:09:42,640
Likewise, a table called "Customer"

179
00:09:42,640 --> 00:09:46,480
that has 300 fields for 50 different apps isn't a concept either.

180
00:09:46,480 --> 00:09:48,480
It is just a dumping ground for data.

181
00:09:48,480 --> 00:09:53,120
Relational thinking forces you to be honest about the actual concepts your business uses to operate.

182
00:09:53,120 --> 00:09:54,960
Once you name those concepts clearly,

183
00:09:54,960 --> 00:09:57,680
you can finally start modeling them in a way that works.

184
00:09:57,680 --> 00:10:00,000
This approach forces you to have difficult conversations

185
00:10:00,000 --> 00:10:03,120
with the business side of the house before you ever start building.

186
00:10:03,120 --> 00:10:05,920
You might find that sales uses the term "account"

187
00:10:05,920 --> 00:10:07,680
while finance uses "customer"

188
00:10:07,680 --> 00:10:10,240
and operations talks about a "build-to-party".

189
00:10:10,240 --> 00:10:12,160
You have to figure out if these are the same thing

190
00:10:12,160 --> 00:10:13,680
or if they are truly different.

191
00:10:13,680 --> 00:10:16,640
Because if they are the same, you don't need three tables.

192
00:10:16,640 --> 00:10:18,160
These might sound like technical questions

193
00:10:18,160 --> 00:10:20,240
but they are actually revealing whether your company

194
00:10:20,240 --> 00:10:22,480
even has a shared definition of what a customer is.

195
00:10:22,480 --> 00:10:25,760
Most organizations eventually discover they don't have one

196
00:10:25,760 --> 00:10:27,520
and while that discovery is uncomfortable,

197
00:10:27,520 --> 00:10:30,400
it is the only way to build an architecture that can actually scale.

198
00:10:30,400 --> 00:10:33,200
The four dimensions of relational design.

199
00:10:33,200 --> 00:10:36,320
Relational intelligence is built on four specific dimensions

200
00:10:36,320 --> 00:10:37,680
and if you miss even one of them,

201
00:10:37,680 --> 00:10:40,240
the entire system will eventually fail at scale.

202
00:10:40,240 --> 00:10:42,080
First is normalization.

203
00:10:42,080 --> 00:10:44,960
This is about removing redundancy without killing your performance.

204
00:10:44,960 --> 00:10:47,760
You want one customer record instead of five different copies

205
00:10:47,760 --> 00:10:50,560
and you need one status definition rather than seven variations

206
00:10:50,560 --> 00:10:52,240
scattered across different tables.

207
00:10:52,240 --> 00:10:54,720
It is about building a clean, intentional structure.

208
00:10:54,720 --> 00:10:57,040
Next, you have relationships.

209
00:10:57,040 --> 00:10:59,360
This means connecting your concepts correctly.

210
00:10:59,360 --> 00:11:01,680
The question isn't how many tables you can link together

211
00:11:01,680 --> 00:11:05,360
but rather what the actual relationship is between those concepts in the real world.

212
00:11:05,360 --> 00:11:08,480
One customer has many orders, many employees work in one department

213
00:11:08,480 --> 00:11:11,200
and a single product might belong in many different catalogs.

214
00:11:11,200 --> 00:11:14,320
These real world connections determine how you model the data

215
00:11:14,320 --> 00:11:17,840
so you must choose your logic based on how the business actually functions.

216
00:11:17,840 --> 00:11:18,800
Then come invariants.

217
00:11:18,800 --> 00:11:20,800
These are the rules that must never be broken.

218
00:11:20,800 --> 00:11:23,120
An order cannot exist without a customer

219
00:11:23,120 --> 00:11:25,440
and an invoice cannot exist without an order.

220
00:11:25,440 --> 00:11:28,160
These are not just suggestions or best practices

221
00:11:28,160 --> 00:11:30,000
they are structural requirements.

222
00:11:30,000 --> 00:11:32,640
Relational design enforces these rules at the data layer

223
00:11:32,640 --> 00:11:35,440
so that no app, flow or form can ever violate them.

224
00:11:35,440 --> 00:11:37,200
Finally, there is integration.

225
00:11:37,200 --> 00:11:40,000
This is how data flows in and out without creating new silos.

226
00:11:40,480 --> 00:11:42,240
External systems push orders in

227
00:11:42,240 --> 00:11:44,800
while your system exports fulfillment status back out

228
00:11:44,800 --> 00:11:47,520
and the relationships must hold true across those boundaries.

229
00:11:47,520 --> 00:11:49,680
You won't have to reconcile data manually

230
00:11:49,680 --> 00:11:52,400
because the structure itself enforces consistency.

231
00:11:52,400 --> 00:11:54,240
If you skip any of these dimensions,

232
00:11:54,240 --> 00:11:55,680
failure is coming for you.

233
00:11:55,680 --> 00:11:58,560
Skip normalization and you are back to maintaining duplicates

234
00:11:58,560 --> 00:12:01,520
but if you skip relationships, your logic stays scattered.

235
00:12:01,520 --> 00:12:03,760
Skip invariants and your data becomes unreliable

236
00:12:03,760 --> 00:12:05,120
and if you skip integration,

237
00:12:05,120 --> 00:12:08,160
your systems will eventually become completely incompatible.

238
00:12:08,160 --> 00:12:10,080
The cost of not thinking relationally.

239
00:12:10,080 --> 00:12:11,520
The numbers here are stark.

240
00:12:11,520 --> 00:12:13,680
Organizations that lack relational intelligence

241
00:12:13,680 --> 00:12:16,240
spend 40% of their development time on rework.

242
00:12:16,240 --> 00:12:18,320
They aren't building new features or moving the needle.

243
00:12:18,320 --> 00:12:21,200
They are just fixing structural mistakes made months ago.

244
00:12:21,200 --> 00:12:23,040
When two apps collide on the same data,

245
00:12:23,040 --> 00:12:25,520
the fix usually takes three weeks of engineering time.

246
00:12:25,520 --> 00:12:29,040
65% of enterprises now report that they simply do not trust

247
00:12:29,040 --> 00:12:30,400
their operational data.

248
00:12:30,400 --> 00:12:33,040
This isn't because the data was entered incorrectly by a human

249
00:12:33,040 --> 00:12:34,800
but because the structure holding that data

250
00:12:34,800 --> 00:12:36,560
offers no guarantee of consistency.

251
00:12:36,560 --> 00:12:39,600
73% of low-code projects fail specifically

252
00:12:39,600 --> 00:12:40,960
because of poor data design.

253
00:12:40,960 --> 00:12:43,440
It isn't a problem with complex logic or two limitations.

254
00:12:43,440 --> 00:12:45,280
It is a total foundation failure.

255
00:12:45,280 --> 00:12:48,800
Audit findings continue to pile up with the same recurring theme.

256
00:12:48,800 --> 00:12:51,200
Companies cannot prove who made a specific decision

257
00:12:51,200 --> 00:12:52,880
because the data trail is broken,

258
00:12:52,880 --> 00:12:54,400
which isn't a paperwork problem.

259
00:12:54,400 --> 00:12:56,080
It is an architectural confession.

260
00:12:56,080 --> 00:12:58,240
The business impact compounds over time.

261
00:12:58,240 --> 00:13:00,880
Decisions are delayed because nobody knows which data is real

262
00:13:00,880 --> 00:13:02,320
and compliance risks stays high

263
00:13:02,320 --> 00:13:04,480
because security was never designed into the structure.

264
00:13:04,480 --> 00:13:06,880
Innovation eventually stalls

265
00:13:06,880 --> 00:13:09,040
because the foundation simply cannot support it.

266
00:13:09,760 --> 00:13:11,760
Pillar 1. Entity mapping.

267
00:13:11,760 --> 00:13:13,760
The first skill that separates a true architect

268
00:13:13,760 --> 00:13:15,760
from a basic button clicker is entity mapping.

269
00:13:15,760 --> 00:13:17,600
This is the art of taking the absolute mess

270
00:13:17,600 --> 00:13:19,360
that comes out of business conversations

271
00:13:19,360 --> 00:13:22,320
and translating it into a clean functional schema.

272
00:13:22,320 --> 00:13:24,480
When your stakeholders start talking about customers,

273
00:13:24,480 --> 00:13:26,320
accounts, prospects, and contacts,

274
00:13:26,320 --> 00:13:27,600
they are speaking loosely.

275
00:13:27,600 --> 00:13:29,600
They have years of experience using these terms

276
00:13:29,600 --> 00:13:32,080
so they just assume you understand the distinction between them

277
00:13:32,080 --> 00:13:33,840
but in reality you don't, not yet.

278
00:13:33,840 --> 00:13:37,360
Entity mapping forces you to ask exactly

279
00:13:37,360 --> 00:13:39,840
what business concept each word represents.

280
00:13:39,840 --> 00:13:42,400
You have to figure out if a prospect is just a contact

281
00:13:42,400 --> 00:13:43,840
you haven't converted yet

282
00:13:43,840 --> 00:13:46,720
or if an account is fundamentally different from a customer.

283
00:13:46,720 --> 00:13:48,720
These questions sound simple on the surface

284
00:13:48,720 --> 00:13:49,920
but they rarely are,

285
00:13:49,920 --> 00:13:52,800
mostly because the business itself might not have a clear answer.

286
00:13:52,800 --> 00:13:54,800
I've seen this play out in a real scenario

287
00:13:54,800 --> 00:13:56,400
where a sales team was trying to use

288
00:13:56,400 --> 00:13:58,960
four separate tables in Dataverse for customer,

289
00:13:58,960 --> 00:14:00,880
account, prospect, and contact.

290
00:14:00,880 --> 00:14:02,800
When I asked if these were four unique concepts

291
00:14:02,800 --> 00:14:04,560
or just variations of one thing,

292
00:14:04,560 --> 00:14:06,320
the team couldn't give me a straight answer.

293
00:14:06,320 --> 00:14:08,160
They actually argued for an hour.

294
00:14:08,160 --> 00:14:10,080
What emerged from that meeting was messy,

295
00:14:10,080 --> 00:14:12,640
sometimes a customer and an account were the same thing

296
00:14:12,640 --> 00:14:14,240
but other times they weren't.

297
00:14:14,240 --> 00:14:15,520
A contact was always a person

298
00:14:15,520 --> 00:14:17,200
while an account was sometimes a company.

299
00:14:17,200 --> 00:14:19,200
That confusion eventually lives in your schema.

300
00:14:19,200 --> 00:14:22,160
You end up with four tables just because four different words exist

301
00:14:22,160 --> 00:14:24,960
not because you actually have four distinct concepts to track.

302
00:14:24,960 --> 00:14:26,320
Entity mapping works differently

303
00:14:26,320 --> 00:14:28,400
because it starts with a diagnostic interview.

304
00:14:28,400 --> 00:14:31,200
You ask what unique identifier a record has,

305
00:14:31,200 --> 00:14:32,720
what other concepts it connects to

306
00:14:32,720 --> 00:14:35,440
and who cares when that specific data point changes.

307
00:14:35,440 --> 00:14:38,400
Through those conversations, the patterns finally start to emerge.

308
00:14:38,400 --> 00:14:40,960
You realize a customer is a legal entity you can build,

309
00:14:40,960 --> 00:14:43,440
while an account is a specific contract relationship

310
00:14:43,440 --> 00:14:44,640
with that customer.

311
00:14:44,640 --> 00:14:46,480
A contact is a person who works there

312
00:14:46,480 --> 00:14:48,480
and a prospect is just a potential customer

313
00:14:48,480 --> 00:14:49,600
you haven't signed yet.

314
00:14:49,600 --> 00:14:51,920
Now you have four concepts with clear relationships.

315
00:14:51,920 --> 00:14:53,680
Your model can finally reflect reality

316
00:14:53,680 --> 00:14:56,080
instead of reflecting the team's internal confusion.

317
00:14:56,080 --> 00:14:58,640
This discovery process isn't just a theoretical exercise.

318
00:14:58,640 --> 00:15:00,400
You have to draw relationship diagrams

319
00:15:00,400 --> 00:15:01,920
to see where the logic breaks.

320
00:15:01,920 --> 00:15:03,280
You map a customer to an account

321
00:15:03,280 --> 00:15:05,120
because one customer has many accounts

322
00:15:05,120 --> 00:15:07,120
and then you connect that account to a contact.

323
00:15:07,120 --> 00:15:08,560
When you visualize it this way,

324
00:15:08,560 --> 00:15:10,320
the inconsistencies jump out at you.

325
00:15:10,320 --> 00:15:12,560
If someone claims a prospect is a type of customer,

326
00:15:12,560 --> 00:15:14,560
you simply ask if they share the same attributes

327
00:15:14,560 --> 00:15:17,040
and if the answer is no, then it isn't a type of customer.

328
00:15:17,040 --> 00:15:18,400
It's a stage in a process

329
00:15:18,400 --> 00:15:20,800
and that requires a completely different modeling approach.

330
00:15:20,800 --> 00:15:22,960
This forces clarity before you ever start building.

331
00:15:22,960 --> 00:15:25,280
Most teams skip this step entirely

332
00:15:25,280 --> 00:15:27,360
and they only discover they modeled the wrong thing

333
00:15:27,360 --> 00:15:28,800
after the app is finished.

334
00:15:28,800 --> 00:15:31,680
Fixing that mistake later can cost you months of rework.

335
00:15:31,680 --> 00:15:34,080
The biggest mistake is treating every single data point

336
00:15:34,080 --> 00:15:35,440
as if it's equally important.

337
00:15:35,440 --> 00:15:37,840
Every field feels vital when a stakeholder asks for it

338
00:15:37,840 --> 00:15:40,320
but entity mapping forces you to prioritize.

339
00:15:40,320 --> 00:15:42,560
You have to decide which fields define the concept

340
00:15:42,560 --> 00:15:45,840
and which ones are just extra data the concept happens to collect.

341
00:15:45,840 --> 00:15:48,320
A customer must have a name and an ID to exist

342
00:15:48,320 --> 00:15:51,120
but while a phone number is useful, it isn't defining.

343
00:15:51,120 --> 00:15:52,560
If the phone number changes,

344
00:15:52,560 --> 00:15:54,160
the customer is still the same customer.

345
00:15:54,160 --> 00:15:57,680
Normalization forces this clarity automatically.

346
00:15:57,680 --> 00:15:59,520
If you find yourself trying to store the same data

347
00:15:59,520 --> 00:16:00,720
in two different tables,

348
00:16:00,720 --> 00:16:02,480
you fail the entity mapping test.

349
00:16:02,480 --> 00:16:04,720
Either those tables represent the same concept

350
00:16:04,720 --> 00:16:05,760
and should be merged

351
00:16:05,760 --> 00:16:08,160
or they are different concepts and need to stay separate.

352
00:16:08,160 --> 00:16:11,120
When your mapping is correct, redundancy becomes impossible.

353
00:16:11,120 --> 00:16:13,680
The business outcome of this work arrives immediately.

354
00:16:13,680 --> 00:16:15,520
Development becomes significantly faster

355
00:16:15,520 --> 00:16:17,040
because your foundation is solid.

356
00:16:17,040 --> 00:16:18,640
When a new app needs customer data,

357
00:16:18,640 --> 00:16:20,960
you don't copy fields or create a new table.

358
00:16:20,960 --> 00:16:24,080
You simply reference the canonical customer table you already built.

359
00:16:24,080 --> 00:16:26,400
Your build time drops from three weeks down to five days

360
00:16:26,400 --> 00:16:27,680
not because you're a genius

361
00:16:27,680 --> 00:16:29,280
but because a good foundation stops you

362
00:16:29,280 --> 00:16:31,360
from repeating the same work over and over.

363
00:16:31,360 --> 00:16:33,200
Pillar 2, logic delegation.

364
00:16:33,200 --> 00:16:35,440
The second skill you need to master is understanding

365
00:16:35,440 --> 00:16:36,960
exactly where your logic belongs.

366
00:16:36,960 --> 00:16:39,120
Most organizations build their systems backward.

367
00:16:39,120 --> 00:16:40,960
They put UI validation in the forms

368
00:16:40,960 --> 00:16:42,720
and handle calculations in the flows

369
00:16:42,720 --> 00:16:44,160
which creates a massive mess

370
00:16:44,160 --> 00:16:46,240
because every layer can be bypassed.

371
00:16:46,240 --> 00:16:47,520
If you change the form,

372
00:16:47,520 --> 00:16:49,040
the flow has no idea what happened.

373
00:16:49,040 --> 00:16:50,080
If you disable the flow,

374
00:16:50,080 --> 00:16:52,320
the form starts calculating the wrong numbers.

375
00:16:52,320 --> 00:16:54,720
Relational thinking inverts that entire mess.

376
00:16:54,720 --> 00:16:57,600
It dictates that logic should live exactly where the data lives

377
00:16:57,600 --> 00:17:00,000
which keeps it as close to the truth as possible.

378
00:17:00,000 --> 00:17:03,040
You move your calculations and your validations away from the UI

379
00:17:03,040 --> 00:17:04,720
and down into the data layer itself.

380
00:17:04,720 --> 00:17:07,040
This distinction is critical because of performance.

381
00:17:07,040 --> 00:17:08,720
Server side logic like business rules,

382
00:17:08,720 --> 00:17:10,240
calculated fields and plugins,

383
00:17:10,240 --> 00:17:12,000
all execute inside dataverse.

384
00:17:12,000 --> 00:17:14,080
This means there is no network latency

385
00:17:14,080 --> 00:17:17,120
and no waiting around for external cloud services to wake up.

386
00:17:17,120 --> 00:17:19,680
In fact, server side logic is 11 times faster

387
00:17:19,680 --> 00:17:22,000
than cloud flows for the exact same operations.

388
00:17:22,000 --> 00:17:25,200
It isn't just 10% faster, it is 11 times faster.

389
00:17:25,200 --> 00:17:28,560
A real scenario illustrates how much this actually impacts the user.

390
00:17:28,560 --> 00:17:30,880
One company I worked with had an approval process

391
00:17:30,880 --> 00:17:33,200
living entirely in power automate flows.

392
00:17:33,200 --> 00:17:35,040
When an order exceeded a credit limit,

393
00:17:35,040 --> 00:17:37,040
a flow would trigger to check the customers credit

394
00:17:37,040 --> 00:17:38,480
and evaluate the amount.

395
00:17:38,480 --> 00:17:40,320
That whole process took 45 seconds

396
00:17:40,320 --> 00:17:41,760
and the users constantly complained

397
00:17:41,760 --> 00:17:43,440
that the system felt slow.

398
00:17:43,440 --> 00:17:45,360
We eventually moved that logic into a plugin

399
00:17:45,360 --> 00:17:48,000
which is just server side code running inside dataverse.

400
00:17:48,000 --> 00:17:50,160
It was the same logic and the same business rule

401
00:17:50,160 --> 00:17:52,320
but the processing time dropped to four seconds.

402
00:17:52,320 --> 00:17:53,840
The difference wasn't the rule itself,

403
00:17:53,840 --> 00:17:55,680
the difference was where the rule was running.

404
00:17:55,680 --> 00:17:58,960
Cloud flows have to wait on network calls and service bus messages

405
00:17:58,960 --> 00:18:01,840
but plugins execute directly inside the data engine.

406
00:18:01,840 --> 00:18:03,280
That isn't a matter of philosophy,

407
00:18:03,280 --> 00:18:04,400
it's a matter of physics,

408
00:18:04,400 --> 00:18:07,920
understanding what belongs where requires you to use specific categories.

409
00:18:07,920 --> 00:18:09,680
Business rules that enforce invariance

410
00:18:09,680 --> 00:18:12,240
like making sure an order doesn't exceed a credit limit

411
00:18:12,240 --> 00:18:14,960
must stay server side so they can't be bypassed.

412
00:18:14,960 --> 00:18:17,520
Calculated fields that pull values from related records

413
00:18:17,520 --> 00:18:19,600
or roll-up fields that aggregate child records

414
00:18:19,600 --> 00:18:20,880
also belong in the data layer.

415
00:18:20,880 --> 00:18:22,320
Any plugin that needs to execute

416
00:18:22,320 --> 00:18:24,720
at the exact same time a data change happens

417
00:18:24,720 --> 00:18:25,840
should be server side.

418
00:18:25,840 --> 00:18:28,480
Power automate is meant for a different kind of work.

419
00:18:28,480 --> 00:18:30,640
It handles orchestration across multiple systems

420
00:18:30,640 --> 00:18:33,680
and integration when you need to push data to external platforms.

421
00:18:33,680 --> 00:18:36,880
It's great for notifications like emails or teams messages

422
00:18:36,880 --> 00:18:39,200
and for routing approvals to the right people.

423
00:18:39,200 --> 00:18:41,440
These operations naturally need more time

424
00:18:41,440 --> 00:18:42,800
and they need to be asynchronous

425
00:18:42,800 --> 00:18:44,640
because they rely on external access.

426
00:18:44,640 --> 00:18:47,200
The mistake is using those flows for basic calculations.

427
00:18:47,200 --> 00:18:48,800
If your flow has to read an account

428
00:18:48,800 --> 00:18:50,400
just to check a credit limit,

429
00:18:50,400 --> 00:18:52,960
that is validation logic and you need to move it.

430
00:18:52,960 --> 00:18:56,000
If you don't and the rule changes you'll end up updating 10 different flows

431
00:18:56,000 --> 00:18:57,840
because your logic is scattered everywhere

432
00:18:57,840 --> 00:18:59,840
or worse you'll miss three of those flows

433
00:18:59,840 --> 00:19:02,400
and the system will start behaving inconsistently.

434
00:19:02,400 --> 00:19:04,160
Proper delegation reverses that problem.

435
00:19:04,160 --> 00:19:05,440
When you change the rule once,

436
00:19:05,440 --> 00:19:08,240
it applies everywhere because it lives in one central place.

437
00:19:08,240 --> 00:19:10,160
Whether an order is created through a web app,

438
00:19:10,160 --> 00:19:11,760
a mobile app or an API,

439
00:19:11,760 --> 00:19:13,440
it will always run the same validation.

440
00:19:13,440 --> 00:19:16,080
This happens because the validation is tied to the data layer

441
00:19:16,080 --> 00:19:17,760
rather than a specific interface.

442
00:19:17,760 --> 00:19:20,640
The governance outcome follows naturally from the setup.

443
00:19:20,640 --> 00:19:24,560
Your IT team can audit all business logic from a single location in the data layer.

444
00:19:24,560 --> 00:19:27,360
You don't have to go on a treasure hunt through 50 different flows

445
00:19:27,360 --> 00:19:30,080
just to wonder where a specific rule actually lives.

446
00:19:30,080 --> 00:19:32,320
Pillar 3, security as architecture.

447
00:19:32,320 --> 00:19:34,080
The third pillar is a mindset shift.

448
00:19:34,080 --> 00:19:36,320
Security is not a policy. It is structure.

449
00:19:36,320 --> 00:19:40,640
Most organizations try to bolt security on top of a finished model.

450
00:19:40,640 --> 00:19:43,520
They have the data and then they try to wrap rules around it.

451
00:19:43,520 --> 00:19:45,760
You see this when a manager says users in the East region

452
00:19:45,760 --> 00:19:46,960
should only see East cases.

453
00:19:46,960 --> 00:19:48,000
The rule sounds simple,

454
00:19:48,000 --> 00:19:51,120
but the problem is that the data was never structured to enforce it.

455
00:19:51,120 --> 00:19:54,000
Everything changes when you apply relational thinking.

456
00:19:54,000 --> 00:19:55,920
Before you ever store a single row of data,

457
00:19:55,920 --> 00:19:58,080
you have to ask how access will be controlled.

458
00:19:58,080 --> 00:20:00,240
That answer has to shape the model itself.

459
00:20:00,240 --> 00:20:02,560
Row-level security and business unit segregation

460
00:20:02,560 --> 00:20:03,840
are architectural choices,

461
00:20:03,840 --> 00:20:05,200
not just IT policies.

462
00:20:05,200 --> 00:20:08,240
And if your data doesn't naturally separate by business unit,

463
00:20:08,240 --> 00:20:11,120
then trying to force security onto it becomes fragile.

464
00:20:11,120 --> 00:20:13,120
You end up fighting the system to prevent access

465
00:20:13,120 --> 00:20:16,320
through complex rules instead of letting the data structure do the work.

466
00:20:16,320 --> 00:20:17,200
That isn't governance.

467
00:20:17,200 --> 00:20:18,720
That's managing by exception.

468
00:20:18,720 --> 00:20:21,520
A healthcare organization I know learnt this the hard way.

469
00:20:21,520 --> 00:20:23,280
They built their entire model first

470
00:20:23,280 --> 00:20:26,240
and then compliance stepped in with HIPAA requirements.

471
00:20:26,240 --> 00:20:28,560
They tried to add row-level security after the fact

472
00:20:28,560 --> 00:20:30,240
but the data wasn't ready for it.

473
00:20:30,240 --> 00:20:32,880
Some records had region information while others were blank

474
00:20:32,880 --> 00:20:36,320
which meant the security rules applied inconsistently across the system.

475
00:20:36,320 --> 00:20:37,280
They went live anyway

476
00:20:37,280 --> 00:20:40,000
and auditors immediately found patient data visible to staff

477
00:20:40,000 --> 00:20:41,280
who had no business seeing it.

478
00:20:41,280 --> 00:20:43,840
It took a nine-month redesign and a six-figure check

479
00:20:43,840 --> 00:20:46,320
to fix a mistake that should have been handled at the start.

480
00:20:46,320 --> 00:20:49,760
Design time security thinking is the only way to prevent that kind of disaster.

481
00:20:49,760 --> 00:20:52,080
If patient privacy depends on region segregation,

482
00:20:52,080 --> 00:20:54,960
you must structure the data around those regions from day one.

483
00:20:54,960 --> 00:20:57,040
If role-based access is the priority,

484
00:20:57,040 --> 00:20:59,200
the model has to capture those roles accurately.

485
00:20:59,200 --> 00:21:01,440
You can't just add rules and hope they stick.

486
00:21:01,440 --> 00:21:02,640
You have to design the system

487
00:21:02,640 --> 00:21:04,800
so the rules enforce themselves naturally.

488
00:21:04,800 --> 00:21:07,040
Achieving least privilege without creating bottlenecks

489
00:21:07,040 --> 00:21:08,800
requires intentional architecture.

490
00:21:08,800 --> 00:21:11,680
You want to give a user every permission they need to do their job

491
00:21:11,680 --> 00:21:14,080
but you cannot give them access to data they don't.

492
00:21:14,080 --> 00:21:15,840
This balance doesn't happen by accident.

493
00:21:15,840 --> 00:21:18,080
A salesperson needs to see invoice history

494
00:21:18,080 --> 00:21:20,640
but they definitely don't need to see competitor pricing.

495
00:21:20,640 --> 00:21:23,520
If your model treats all financial data as one big bucket,

496
00:21:23,520 --> 00:21:26,320
your security rules are forced into an all-or-nothing trap.

497
00:21:26,320 --> 00:21:28,560
You have to design differently by separating data

498
00:21:28,560 --> 00:21:30,400
based on who is supposed to see it.

499
00:21:30,400 --> 00:21:32,480
When you do this, the compliance conversation shifts.

500
00:21:32,480 --> 00:21:35,280
You stop trying to prove that you're trying to be secure

501
00:21:35,280 --> 00:21:37,120
and start proving that you actually are.

502
00:21:37,120 --> 00:21:38,960
You become ordered ready from the first day

503
00:21:38,960 --> 00:21:40,480
because security is structural,

504
00:21:40,480 --> 00:21:41,840
rather than an afterthought.

505
00:21:41,840 --> 00:21:44,000
Any change you make to the system tomorrow

506
00:21:44,000 --> 00:21:46,160
will automatically respect those boundaries

507
00:21:46,160 --> 00:21:48,320
because they are baked into the model itself.

508
00:21:48,320 --> 00:21:50,800
These three pillars have to work as a single unit.

509
00:21:50,800 --> 00:21:52,880
Entity mapping defines what you are building

510
00:21:52,880 --> 00:21:55,360
while logic delegation puts the rules where they belong.

511
00:21:55,360 --> 00:21:57,360
Security as architecture ensures

512
00:21:57,360 --> 00:22:00,080
those access controls actually hold up under pressure.

513
00:22:00,080 --> 00:22:01,760
Together they represent the thin line

514
00:22:01,760 --> 00:22:04,400
between a professional architecture and a lucky accident.

515
00:22:04,400 --> 00:22:07,680
What changes when you think architecturally?

516
00:22:07,680 --> 00:22:09,120
Moving from a builder to an architect

517
00:22:09,120 --> 00:22:10,880
isn't about making things more complex.

518
00:22:10,880 --> 00:22:12,240
It's a shift in your scope.

519
00:22:12,240 --> 00:22:13,600
A builder works vertically.

520
00:22:13,600 --> 00:22:14,720
They focus on one app

521
00:22:14,720 --> 00:22:16,000
and ask how to make it fast

522
00:22:16,000 --> 00:22:17,360
or how to hit a looming deadline.

523
00:22:17,360 --> 00:22:19,360
They want to know the absolute minimum they need

524
00:22:19,360 --> 00:22:20,400
to ship the product.

525
00:22:20,400 --> 00:22:21,680
These are important questions

526
00:22:21,680 --> 00:22:24,240
and the builder role is necessary for getting things done

527
00:22:24,240 --> 00:22:25,920
but an architect works horizontally.

528
00:22:25,920 --> 00:22:28,480
They realize that one app never exists in a vacuum.

529
00:22:28,480 --> 00:22:29,840
It is just one small piece

530
00:22:29,840 --> 00:22:31,840
of a much larger operating model.

531
00:22:31,840 --> 00:22:33,840
The questions change to how this new piece fits

532
00:22:33,840 --> 00:22:35,520
with everything else and what else might break

533
00:22:35,520 --> 00:22:37,120
when this new capability is added.

534
00:22:37,120 --> 00:22:40,800
This mindset shift reshapes every single decision you make.

535
00:22:40,800 --> 00:22:42,720
When a builder hears that sales needs to see

536
00:22:42,720 --> 00:22:44,080
customer credit history,

537
00:22:44,080 --> 00:22:46,640
they just add a field and finish the task in an hour.

538
00:22:46,640 --> 00:22:48,240
An architect hears that same request

539
00:22:48,240 --> 00:22:49,920
and pauses to ask better questions.

540
00:22:49,920 --> 00:22:51,680
They wonder if three other apps

541
00:22:51,680 --> 00:22:54,000
will eventually need that same credit history

542
00:22:54,000 --> 00:22:55,680
or if the data needs to be synchronized

543
00:22:55,680 --> 00:22:56,800
across different systems.

544
00:22:56,800 --> 00:22:58,480
They look at whether the data is stable

545
00:22:58,480 --> 00:23:00,480
or if it needs to be refreshed constantly.

546
00:23:00,480 --> 00:23:02,560
The final solution might still be adding a field

547
00:23:02,560 --> 00:23:04,320
but now that field is placed in context

548
00:23:04,320 --> 00:23:05,200
and built to scale.

549
00:23:05,200 --> 00:23:06,720
Architects are obsessed with reuse.

550
00:23:06,720 --> 00:23:08,160
They want a solution built once

551
00:23:08,160 --> 00:23:10,560
and used by many people across the organization.

552
00:23:10,560 --> 00:23:13,440
They design a schema for the customer concept as a whole,

553
00:23:13,440 --> 00:23:16,000
not just for one specific apps version of a customer.

554
00:23:16,000 --> 00:23:17,360
They build a security model

555
00:23:17,360 --> 00:23:18,800
that serves every application

556
00:23:18,800 --> 00:23:21,600
instead of bolting permissions onto each one individually.

557
00:23:21,600 --> 00:23:22,960
They centralize business rules

558
00:23:22,960 --> 00:23:25,040
so they aren't scattered across the environment.

559
00:23:25,040 --> 00:23:27,360
There is a very practical reason to make this shift.

560
00:23:27,360 --> 00:23:29,440
Architects usually command compensation

561
00:23:29,440 --> 00:23:32,160
that is 40 to 60% higher than builders.

562
00:23:32,160 --> 00:23:34,720
This isn't a reward for making things complicated.

563
00:23:34,720 --> 00:23:36,880
It is a recognition that architectural decisions

564
00:23:36,880 --> 00:23:38,640
have a massive ripple effect.

565
00:23:38,640 --> 00:23:40,640
A builder's choice is only effect one app

566
00:23:40,640 --> 00:23:43,200
but an architect's decisions affect the entire system.

567
00:23:43,200 --> 00:23:44,800
That leverage compounds over time.

568
00:23:44,800 --> 00:23:47,600
Relational thinking changes how you justify your time.

569
00:23:47,600 --> 00:23:49,520
A builder might say a certain task

570
00:23:49,520 --> 00:23:51,200
will add three days to the launch date.

571
00:23:51,200 --> 00:23:53,760
An architect will point out that while it adds three days now

572
00:23:53,760 --> 00:23:55,680
it saves four weeks of rework later

573
00:23:55,680 --> 00:23:57,520
when the next app needs that same data.

574
00:23:57,520 --> 00:23:59,120
Suddenly the math on that decision

575
00:23:59,120 --> 00:24:00,640
looks very different to the business.

576
00:24:00,640 --> 00:24:01,840
Eventually you reach a point

577
00:24:01,840 --> 00:24:03,360
where you stop defending your design

578
00:24:03,360 --> 00:24:04,480
and start explaining it.

579
00:24:04,480 --> 00:24:06,080
A builder justifies their work by saying

580
00:24:06,080 --> 00:24:07,360
they needed to move fast.

581
00:24:07,360 --> 00:24:10,560
An architect explains their design by pointing to the relationships

582
00:24:10,560 --> 00:24:12,080
and showing how the structure serves

583
00:24:12,080 --> 00:24:14,400
five different business processes at once.

584
00:24:14,400 --> 00:24:16,240
One person is defending a choice

585
00:24:16,240 --> 00:24:18,480
while the other is articulating a principle.

586
00:24:18,480 --> 00:24:20,160
The architect's responsibility.

587
00:24:20,160 --> 00:24:23,200
Accountability shifts the moment you step into the role of an architect.

588
00:24:23,200 --> 00:24:24,960
You are no longer responsible for making sure

589
00:24:24,960 --> 00:24:26,160
a single app succeeds

590
00:24:26,160 --> 00:24:27,920
but instead you are responsible

591
00:24:27,920 --> 00:24:29,840
for ensuring the entire system doesn't fail

592
00:24:29,840 --> 00:24:31,520
because of the choices you made.

593
00:24:31,520 --> 00:24:34,880
Poor architectural decisions compound exactly like high interest debt.

594
00:24:34,880 --> 00:24:36,320
A shortcut you take today

595
00:24:36,320 --> 00:24:38,640
like promising to standardize a process later

596
00:24:38,640 --> 00:24:41,360
usually costs ten times more to fix just six months down the road.

597
00:24:41,360 --> 00:24:42,960
This happens because other apps start

598
00:24:42,960 --> 00:24:44,240
depending on that shortcut

599
00:24:44,240 --> 00:24:45,360
and before you know it

600
00:24:45,360 --> 00:24:47,680
multiple teams have built their entire workflow

601
00:24:47,680 --> 00:24:49,280
on top of a flawed foundation.

602
00:24:49,280 --> 00:24:51,440
The actual cost of change multiplies every time

603
00:24:51,440 --> 00:24:53,840
a new app touches that original mistake.

604
00:24:53,840 --> 00:24:55,840
This reality forces architects to say no

605
00:24:55,840 --> 00:24:57,520
much more often than they say yes.

606
00:24:57,520 --> 00:25:00,000
They aren't trying to be gatekeepers or stop progress

607
00:25:00,000 --> 00:25:02,400
but they are responsible for the long term consequences

608
00:25:02,400 --> 00:25:04,720
that the requesting teams simply cannot see yet.

609
00:25:04,720 --> 00:25:06,800
The real skill here is explaining why a shortcut

610
00:25:06,800 --> 00:25:08,080
will cost more later

611
00:25:08,080 --> 00:25:10,160
without sounding like you are just being difficult.

612
00:25:10,160 --> 00:25:11,600
You might tell a stakeholder that

613
00:25:11,600 --> 00:25:13,120
while you could build a feature in two weeks

614
00:25:13,120 --> 00:25:15,840
using a quick fix taking six weeks to do it the right way

615
00:25:15,840 --> 00:25:17,440
is the better investment.

616
00:25:17,440 --> 00:25:18,560
You choose the longer path

617
00:25:18,560 --> 00:25:21,680
because when the finance department needs that same data in three months

618
00:25:21,680 --> 00:25:24,560
the quick way would have forced eight weeks of painful rework

619
00:25:24,560 --> 00:25:26,080
that isn't killing innovation.

620
00:25:26,080 --> 00:25:27,280
It's protecting it.

621
00:25:27,280 --> 00:25:30,400
You are making decisions that future teams can build on top of

622
00:25:30,400 --> 00:25:32,320
rather than having to find ways to build around.

623
00:25:32,320 --> 00:25:34,400
Trust in an architect builds from being right

624
00:25:34,400 --> 00:25:35,280
about the hard things.

625
00:25:35,280 --> 00:25:37,120
You don't have to be right every single time

626
00:25:37,120 --> 00:25:39,200
but you need to be right about the heavy decisions

627
00:25:39,200 --> 00:25:40,720
that take months to prove out.

628
00:25:40,720 --> 00:25:42,800
When a team eventually admits they try to short cut

629
00:25:42,800 --> 00:25:45,200
and hit the exact wall you predicted half a year ago

630
00:25:45,200 --> 00:25:47,120
that is how you earn real credibility.

631
00:25:47,120 --> 00:25:49,920
The business outcome is always the same.

632
00:25:49,920 --> 00:25:53,200
You see fewer emergency fixes as architectural debt shrinks

633
00:25:53,200 --> 00:25:54,720
and you get more planned improvements

634
00:25:54,720 --> 00:25:56,560
because the foundation actually supports them.

635
00:25:56,560 --> 00:25:59,120
Skill development path.

636
00:25:59,120 --> 00:26:00,160
Entity mapping.

637
00:26:00,160 --> 00:26:02,880
Learning how to map entities is a skill anyone can pick up.

638
00:26:02,880 --> 00:26:04,640
It doesn't require you to buy new tools

639
00:26:04,640 --> 00:26:07,200
but it does require you to change the way you ask questions.

640
00:26:07,200 --> 00:26:09,040
Start exactly where you are right now

641
00:26:09,040 --> 00:26:11,440
by auditing your current dataverse environment.

642
00:26:11,440 --> 00:26:14,480
Look at every single table and ask yourself why it exists.

643
00:26:14,480 --> 00:26:16,240
Don't look for a philosophical answer

644
00:26:16,240 --> 00:26:18,240
but look for a practical one that defines

645
00:26:18,240 --> 00:26:20,960
what specific business concept that table represents.

646
00:26:20,960 --> 00:26:23,760
You will start to see patterns almost immediately.

647
00:26:23,760 --> 00:26:25,120
You might find three different tables

648
00:26:25,120 --> 00:26:26,800
that all hold customer information

649
00:26:26,800 --> 00:26:28,400
and when you interview the teams

650
00:26:28,400 --> 00:26:30,560
you'll find that sales, finance, and operations

651
00:26:30,560 --> 00:26:32,160
each build their own version.

652
00:26:32,160 --> 00:26:35,280
The reason for this is never that the data is fundamentally different

653
00:26:35,280 --> 00:26:37,920
but it's almost always because one team needed it fast.

654
00:26:37,920 --> 00:26:39,520
Now you're stuck with three separate tables

655
00:26:39,520 --> 00:26:41,520
doing the exact same overlapping work.

656
00:26:41,520 --> 00:26:44,720
Identify this redundancy clearly by walking through your schema.

657
00:26:44,720 --> 00:26:46,880
Look for columns that appear in multiple tables

658
00:26:46,880 --> 00:26:48,880
and note where the same data is being stored

659
00:26:48,880 --> 00:26:50,320
in five different places.

660
00:26:50,320 --> 00:26:53,200
Write these findings down, not to point fingers or blame anyone

661
00:26:53,200 --> 00:26:55,920
but so you can finally see the actual state of your system.

662
00:26:55,920 --> 00:26:57,760
Next, you need to map the relationships

663
00:26:57,760 --> 00:26:59,360
by drawing a functional diagram.

664
00:26:59,360 --> 00:27:00,800
It doesn't have to be pretty

665
00:27:00,800 --> 00:27:04,160
but it does need to show how a customer connects to an order.

666
00:27:04,160 --> 00:27:06,320
If one customer has many orders write down

667
00:27:06,320 --> 00:27:08,640
customer one and order on your paper.

668
00:27:08,640 --> 00:27:10,400
If a product appears in many orders

669
00:27:10,400 --> 00:27:12,160
and many orders have many products

670
00:27:12,160 --> 00:27:14,400
mark that as product M and order.

671
00:27:14,400 --> 00:27:16,640
Continue this process until every relationship

672
00:27:16,640 --> 00:27:18,560
like an order belonging to a business unit

673
00:27:18,560 --> 00:27:19,680
is visible in front of you.

674
00:27:19,680 --> 00:27:21,120
This is where you find the gaps.

675
00:27:21,120 --> 00:27:23,040
Look for places where relationships should exist

676
00:27:23,040 --> 00:27:24,240
but are currently missing.

677
00:27:24,240 --> 00:27:26,320
If a support case belongs to a customer

678
00:27:26,320 --> 00:27:28,480
but your schema doesn't enforce that rule,

679
00:27:28,480 --> 00:27:29,360
you need to add it.

680
00:27:29,360 --> 00:27:30,800
If an invoice references an order

681
00:27:30,800 --> 00:27:32,480
but they aren't connected in the system,

682
00:27:32,480 --> 00:27:34,080
you have found a structural weakness

683
00:27:34,080 --> 00:27:35,200
that needs to be fixed.

684
00:27:35,200 --> 00:27:37,360
This exercise forces a level of clarity.

685
00:27:37,360 --> 00:27:39,200
You can't get any other way.

686
00:27:39,200 --> 00:27:41,680
Take a critical process like order to invoice

687
00:27:41,680 --> 00:27:43,680
and map every entity involved

688
00:27:43,680 --> 00:27:44,960
from the customer and product

689
00:27:44,960 --> 00:27:47,040
down to the shipping and billing addresses.

690
00:27:47,040 --> 00:27:48,800
Once you've drawn how they all connect,

691
00:27:48,800 --> 00:27:51,040
try to explain it to someone who isn't technical.

692
00:27:51,040 --> 00:27:52,320
If they can't follow your logic,

693
00:27:52,320 --> 00:27:54,080
it means your model isn't clear enough yet.

694
00:27:54,080 --> 00:27:56,720
Validation happens during that specific conversation.

695
00:27:56,720 --> 00:27:58,160
If you can't explain to a stakeholder

696
00:27:58,160 --> 00:28:00,160
why you need separate entities for order lines

697
00:28:00,160 --> 00:28:02,640
and invoice lines without saying it's technical,

698
00:28:02,640 --> 00:28:04,080
then you have failed the test.

699
00:28:04,080 --> 00:28:06,080
The model has to make sense for the business first

700
00:28:06,080 --> 00:28:07,840
and the technical side comes second.

701
00:28:07,840 --> 00:28:10,080
The moment of true insight is when you realize

702
00:28:10,080 --> 00:28:11,840
your current model actually contradicts

703
00:28:11,840 --> 00:28:13,520
how the business works in the real world.

704
00:28:13,520 --> 00:28:15,280
You might find that finance and sales

705
00:28:15,280 --> 00:28:17,520
use completely different definitions for revenue

706
00:28:17,520 --> 00:28:19,680
yet your model treats them as the same thing.

707
00:28:19,680 --> 00:28:21,040
That isn't just a schema problem.

708
00:28:21,040 --> 00:28:22,720
It's a fundamental business problem

709
00:28:22,720 --> 00:28:24,400
that your data model is finally revealing.

710
00:28:24,400 --> 00:28:25,760
That is what success looks like.

711
00:28:25,760 --> 00:28:28,240
You aren't searching for a perfect model that never changes.

712
00:28:28,240 --> 00:28:31,360
You are looking for a model that makes your business assumptions explicit

713
00:28:31,360 --> 00:28:34,880
so you can finally discuss whether those assumptions are actually correct.

714
00:28:34,880 --> 00:28:36,480
The final checkpoint is simple.

715
00:28:36,480 --> 00:28:37,920
Can you explain this entire model

716
00:28:37,920 --> 00:28:39,520
using only business concepts?

717
00:28:39,520 --> 00:28:40,960
You shouldn't need technical jargon

718
00:28:40,960 --> 00:28:42,880
because these entities represent real things

719
00:28:42,880 --> 00:28:44,480
the organization cares about every day

720
00:28:44,480 --> 00:28:47,680
and skill development path, logic delegation.

721
00:28:47,680 --> 00:28:50,000
Learning to delegate logic starts with an inventory

722
00:28:50,000 --> 00:28:52,560
you need to know where your logic currently lives

723
00:28:52,560 --> 00:28:54,000
and whether it actually belongs there

724
00:28:54,000 --> 00:28:57,040
start by auditing your power automate flows every single one.

725
00:28:57,040 --> 00:28:59,440
Don't just say it's an automation.

726
00:28:59,440 --> 00:29:01,280
Ask what the work actually is.

727
00:29:01,280 --> 00:29:03,760
Is it a validation, a calculation, a notification

728
00:29:03,760 --> 00:29:05,120
or is it orchestration?

729
00:29:05,120 --> 00:29:06,800
You have to categorize these ruthlessly

730
00:29:06,800 --> 00:29:08,960
because the location determines the performance.

731
00:29:08,960 --> 00:29:12,560
Validation and calculation are your primary candidates for migration.

732
00:29:12,560 --> 00:29:15,280
If a flow reads data, evaluates a condition

733
00:29:15,280 --> 00:29:17,360
and makes a decision based on that result,

734
00:29:17,360 --> 00:29:18,400
that is validation.

735
00:29:18,400 --> 00:29:19,920
Validation belongs on the server.

736
00:29:19,920 --> 00:29:22,080
If a flow pulls values from related records

737
00:29:22,080 --> 00:29:23,760
and combines them to get a total

738
00:29:23,760 --> 00:29:24,800
that is calculation.

739
00:29:24,800 --> 00:29:26,720
Calculation also belongs on the server.

740
00:29:26,720 --> 00:29:28,720
Notifications and orchestration, however,

741
00:29:28,720 --> 00:29:30,400
should stay exactly where they are.

742
00:29:30,400 --> 00:29:32,880
If a flow sends an email posts a message to teams

743
00:29:32,880 --> 00:29:34,320
or calls an external API,

744
00:29:34,320 --> 00:29:35,600
keep it in power automate.

745
00:29:35,600 --> 00:29:37,200
Flows are built for that kind of communication

746
00:29:37,200 --> 00:29:37,920
and they do it well.

747
00:29:37,920 --> 00:29:38,960
When you start the move,

748
00:29:38,960 --> 00:29:40,880
look for the high volume candidates first.

749
00:29:40,880 --> 00:29:43,600
Find the flows that trigger thousands of times every day

750
00:29:43,600 --> 00:29:44,560
because those are the ones where

751
00:29:44,560 --> 00:29:46,400
server-side migration creates a massive

752
00:29:46,400 --> 00:29:48,240
compounding performance boost.

753
00:29:48,240 --> 00:29:50,240
Pick one simple task to start with.

754
00:29:50,240 --> 00:29:52,240
Maybe you have a flow that checks an order amount

755
00:29:52,240 --> 00:29:53,920
against a customer's credit limit.

756
00:29:53,920 --> 00:29:55,120
That is a pure calculation,

757
00:29:55,120 --> 00:29:56,240
so move it into dataverse

758
00:29:56,240 --> 00:29:58,000
by creating a calculated field.

759
00:29:58,000 --> 00:30:00,640
Set your formula so that if the order amount exceeds the limit,

760
00:30:00,640 --> 00:30:02,160
the field returns a warning.

761
00:30:02,160 --> 00:30:05,520
Once you deploy and test that the field calculates correctly,

762
00:30:05,520 --> 00:30:07,280
you can measure the actual impact.

763
00:30:07,280 --> 00:30:10,800
In the old model, validation only happened when the flow triggered

764
00:30:10,800 --> 00:30:13,120
but now it happens the moment a record is created.

765
00:30:13,120 --> 00:30:14,640
There is no flow to wait for.

766
00:30:14,640 --> 00:30:15,600
There is no latency.

767
00:30:15,600 --> 00:30:16,400
It is just data.

768
00:30:16,400 --> 00:30:17,600
Once you have done this once,

769
00:30:17,600 --> 00:30:19,760
you understand the mechanics of the new pattern.

770
00:30:19,760 --> 00:30:21,440
The logic lives in dataverse now

771
00:30:21,440 --> 00:30:23,280
and the app simply reads the field value

772
00:30:23,280 --> 00:30:24,720
without any extra processing.

773
00:30:24,720 --> 00:30:26,640
Don't try to move every rule at once

774
00:30:26,640 --> 00:30:28,800
because that is exactly how migrations fail.

775
00:30:28,800 --> 00:30:31,600
Pick the validation logic in your most critical path,

776
00:30:31,600 --> 00:30:34,400
move it, and watch it work before you touch the next one.

777
00:30:34,400 --> 00:30:37,200
The transition period is where you protect the system.

778
00:30:37,200 --> 00:30:39,440
Keep your old flow running while you build the new logic

779
00:30:39,440 --> 00:30:41,360
and let them both run for a full week.

780
00:30:41,360 --> 00:30:43,520
Compare the results to ensure the server-side version

781
00:30:43,520 --> 00:30:45,440
calculates identically to the old one.

782
00:30:45,440 --> 00:30:48,320
Disable the flow but keep it in the environment for three months

783
00:30:48,320 --> 00:30:49,840
just in case you need to revert.

784
00:30:49,840 --> 00:30:51,280
The final checkpoint is defensive.

785
00:30:51,280 --> 00:30:53,920
You should be able to explain exactly why each piece of logic

786
00:30:53,920 --> 00:30:54,960
lives where it does.

787
00:30:54,960 --> 00:30:57,040
If you moved validation to dataverse,

788
00:30:57,040 --> 00:31:00,160
the reason is that server-side execution is instant.

789
00:31:00,160 --> 00:31:01,760
You aren't waiting on network latency

790
00:31:01,760 --> 00:31:03,520
or external services anymore.

791
00:31:03,520 --> 00:31:05,200
The answer shouldn't be a guess.

792
00:31:05,200 --> 00:31:06,400
It should be a structural fact.

793
00:31:06,400 --> 00:31:09,920
Changes become much easier once your logic is centralised in one place.

794
00:31:09,920 --> 00:31:11,360
If a credit limit rule changes,

795
00:31:11,360 --> 00:31:13,360
you update the calculated field once

796
00:31:13,360 --> 00:31:16,000
and every order respects that new limit immediately.

797
00:31:16,000 --> 00:31:18,720
This doesn't happen because flows are synchronising data.

798
00:31:18,720 --> 00:31:21,120
It happens because the rule lives in the data itself.

799
00:31:21,120 --> 00:31:23,520
The maintenance burden drops the moment you stop hunting

800
00:31:23,520 --> 00:31:26,320
through 50 different flows to find a single rule.

801
00:31:26,320 --> 00:31:28,880
Skill development path, security architecture,

802
00:31:28,880 --> 00:31:30,800
designing security architecturally starts

803
00:31:30,800 --> 00:31:33,920
by looking at what you have and asking why it exists.

804
00:31:33,920 --> 00:31:35,440
Map out your current access model.

805
00:31:35,440 --> 00:31:37,680
Don't think in general terms, get specific.

806
00:31:37,680 --> 00:31:39,600
Create a table that lists user roles,

807
00:31:39,600 --> 00:31:42,800
the tables they can access and the specific columns they can see.

808
00:31:42,800 --> 00:31:44,560
The simple act of writing this down

809
00:31:44,560 --> 00:31:46,640
usually reveals where the system is broken.

810
00:31:46,640 --> 00:31:50,000
Now ask the hard question, is this access based on a job function

811
00:31:50,000 --> 00:31:51,520
or is it just based on history?

812
00:31:51,520 --> 00:31:54,160
If a user has read access to every case in the system

813
00:31:54,160 --> 00:31:55,520
because they asked for it once,

814
00:31:55,520 --> 00:31:57,840
that isn't security, that isn't accommodation.

815
00:31:57,840 --> 00:32:01,360
If their job actually requires seeing every case to perform a task,

816
00:32:01,360 --> 00:32:02,400
that is a function.

817
00:32:02,400 --> 00:32:04,720
You have to distinguish between these two ruthlessly.

818
00:32:04,720 --> 00:32:06,320
Next, identify your security gaps.

819
00:32:06,320 --> 00:32:08,400
Look for places where people are seeing data

820
00:32:08,400 --> 00:32:09,520
that should be private.

821
00:32:09,520 --> 00:32:11,840
If a support case contains salary information

822
00:32:11,840 --> 00:32:13,840
that is visible to staff outside of HR,

823
00:32:13,840 --> 00:32:14,800
you have a gap.

824
00:32:14,800 --> 00:32:17,280
If accounts belonging to specific regions are visible

825
00:32:17,280 --> 00:32:19,920
to everyone in the company, you have another gap.

826
00:32:19,920 --> 00:32:22,320
Document these gaps before you try to fix them.

827
00:32:22,320 --> 00:32:25,200
Map the natural boundaries that already exist in your organization.

828
00:32:25,200 --> 00:32:28,240
Think about business units, departments and geographic regions.

829
00:32:28,240 --> 00:32:29,520
In a healthcare organization,

830
00:32:29,520 --> 00:32:31,920
regional officers manage their own cases

831
00:32:31,920 --> 00:32:34,160
which creates a natural data boundary.

832
00:32:34,160 --> 00:32:36,240
Your data structure should respect those boundaries.

833
00:32:36,240 --> 00:32:38,000
When you design the role structure,

834
00:32:38,000 --> 00:32:39,680
focus on actual job functions.

835
00:32:39,680 --> 00:32:42,320
Don't just copy a standard template because it's easy.

836
00:32:42,320 --> 00:32:44,720
A salesperson needs to read accounts in their territory,

837
00:32:44,720 --> 00:32:46,720
along with contacts and opportunities.

838
00:32:46,720 --> 00:32:48,720
A manager might need those same permissions

839
00:32:48,720 --> 00:32:50,800
plus the ability to create new accounts.

840
00:32:50,800 --> 00:32:53,920
A field rep might only need to see their own assigned cases.

841
00:32:53,920 --> 00:32:56,160
Every role should be a direct reflection of a function.

842
00:32:56,160 --> 00:32:57,440
Now build the relationships.

843
00:32:57,440 --> 00:32:59,920
A role grants a permission

844
00:32:59,920 --> 00:33:02,640
and that permission defines an action like "create"

845
00:33:02,640 --> 00:33:04,480
or "read" on a table.

846
00:33:04,480 --> 00:33:07,040
The scope determines who they can see that data for.

847
00:33:07,040 --> 00:33:09,680
A salesperson has a read permission on opportunities

848
00:33:09,680 --> 00:33:11,120
but the scope is territorial.

849
00:33:11,680 --> 00:33:13,120
The logic follows a clear path.

850
00:33:13,120 --> 00:33:16,240
User to role, role to permission and permission to table.

851
00:33:16,240 --> 00:33:18,720
This exercise forces you to do a reality check.

852
00:33:18,720 --> 00:33:21,520
Try designing security for a new business process from scratch.

853
00:33:21,520 --> 00:33:23,920
If support tickets need to be segregated by region,

854
00:33:23,920 --> 00:33:25,520
you'll need a region field on the case

855
00:33:25,520 --> 00:33:27,120
and a role with regional scope.

856
00:33:27,120 --> 00:33:28,960
Diagram this out before you build anything.

857
00:33:28,960 --> 00:33:30,720
The diagram will show you exactly what you need

858
00:33:30,720 --> 00:33:32,160
before you waste time in the tool.

859
00:33:32,160 --> 00:33:33,520
The checkpoint here is Forensic.

860
00:33:33,520 --> 00:33:35,200
If an auditor asked you to prove

861
00:33:35,200 --> 00:33:38,080
why a specific person can see a specific piece of data,

862
00:33:38,080 --> 00:33:38,960
could you do it?

863
00:33:38,960 --> 00:33:40,480
You should be able to draw a straight line

864
00:33:40,480 --> 00:33:42,320
from their job function through a role definition

865
00:33:42,320 --> 00:33:43,440
to their permissions.

866
00:33:43,440 --> 00:33:45,680
If that explanation is messy or confusing,

867
00:33:45,680 --> 00:33:47,600
your design isn't ready for production.

868
00:33:47,600 --> 00:33:50,240
Security becomes much easier once it is structural.

869
00:33:50,240 --> 00:33:51,840
When a new user joins the team,

870
00:33:51,840 --> 00:33:53,040
you assign them a role

871
00:33:53,040 --> 00:33:55,680
and they automatically see the cases for their unit.

872
00:33:55,680 --> 00:33:58,080
You aren't setting individual permissions on records

873
00:33:58,080 --> 00:34:00,080
because the structure is doing the work for you.

874
00:34:00,080 --> 00:34:01,520
Changes are safer in this model.

875
00:34:01,520 --> 00:34:03,600
If a credit limit rule moves to a calculated field

876
00:34:03,600 --> 00:34:04,560
and you need to hide it,

877
00:34:04,560 --> 00:34:06,480
you just apply a security profile.

878
00:34:06,480 --> 00:34:07,840
The model supports the change

879
00:34:07,840 --> 00:34:09,680
because it was built into the foundation

880
00:34:09,680 --> 00:34:11,360
not bolted on as an afterthought.

881
00:34:11,360 --> 00:34:12,960
The patterns that scale,

882
00:34:12,960 --> 00:34:15,440
pattern one, the master data model.

883
00:34:15,440 --> 00:34:17,360
Large organizations eventually realize

884
00:34:17,360 --> 00:34:18,960
they all need the same thing.

885
00:34:18,960 --> 00:34:20,400
Canonical data entities.

886
00:34:20,400 --> 00:34:22,000
These are core business concepts

887
00:34:22,000 --> 00:34:23,920
to find once and use everywhere.

888
00:34:23,920 --> 00:34:25,360
Take the concept of a customer.

889
00:34:25,360 --> 00:34:26,560
In a massive company,

890
00:34:26,560 --> 00:34:28,720
you might find customer defined five different ways

891
00:34:28,720 --> 00:34:30,400
because sales has their version

892
00:34:30,400 --> 00:34:32,560
while finance and operations build their own.

893
00:34:32,560 --> 00:34:34,160
Each team created a definition

894
00:34:34,160 --> 00:34:35,760
that matched their specific needs

895
00:34:35,760 --> 00:34:38,640
but the result is five separate tables doing the same work.

896
00:34:38,640 --> 00:34:40,080
This leads to data conflicts

897
00:34:40,080 --> 00:34:41,600
and reconciliation nightmares

898
00:34:41,600 --> 00:34:43,360
where updates made in one system

899
00:34:43,360 --> 00:34:44,480
never reach the others.

900
00:34:44,480 --> 00:34:46,640
The master data model flips this logic.

901
00:34:46,640 --> 00:34:49,280
Customer is defined once for the entire organization

902
00:34:49,280 --> 00:34:50,960
rather than for a single department.

903
00:34:50,960 --> 00:34:52,960
It includes every attribute and relationship

904
00:34:52,960 --> 00:34:55,680
the business cares about in one single source of truth.

905
00:34:55,680 --> 00:34:59,120
This same rule applies to your products, orders, and contracts.

906
00:34:59,120 --> 00:35:00,880
These aren't just tables in a database.

907
00:35:00,880 --> 00:35:03,440
They are the way your organization actually thinks.

908
00:35:03,440 --> 00:35:04,640
When you build a new app,

909
00:35:04,640 --> 00:35:07,040
you don't redesign the customer entity from scratch.

910
00:35:07,040 --> 00:35:08,800
You simply extend the master model

911
00:35:08,800 --> 00:35:10,720
or add a single field if it's missing.

912
00:35:10,720 --> 00:35:12,400
The real benefit here is velocity.

913
00:35:12,400 --> 00:35:14,560
If a new sales tool needs customer info,

914
00:35:14,560 --> 00:35:16,640
you don't spend three weeks designing a schema

915
00:35:16,640 --> 00:35:17,840
and building relationships.

916
00:35:17,840 --> 00:35:20,800
You spend one week wiring it into the existing foundation.

917
00:35:20,800 --> 00:35:22,080
Building becomes faster

918
00:35:22,080 --> 00:35:23,840
and data quality improves automatically

919
00:35:23,840 --> 00:35:26,400
because every app is looking at the exact same information.

920
00:35:26,400 --> 00:35:27,280
But there is a risk.

921
00:35:27,280 --> 00:35:28,640
If your master model is wrong,

922
00:35:28,640 --> 00:35:30,640
then every single thing you build on top of it

923
00:35:30,640 --> 00:35:31,680
will be wrong too.

924
00:35:31,680 --> 00:35:33,520
This approach requires serious discipline

925
00:35:33,520 --> 00:35:34,640
and intentional design.

926
00:35:34,640 --> 00:35:35,440
You can't rush it.

927
00:35:35,440 --> 00:35:37,200
The upfront investment is much higher

928
00:35:37,200 --> 00:35:38,800
but the payoff down the road compounds.

929
00:35:38,800 --> 00:35:40,480
I saw this happen with a mid-market company

930
00:35:40,480 --> 00:35:42,640
that had 50 power apps running at once.

931
00:35:42,640 --> 00:35:44,800
Every single app had its own customer table

932
00:35:44,800 --> 00:35:46,800
with different fields and different rules.

933
00:35:46,800 --> 00:35:48,800
When they finally move to a master data model,

934
00:35:48,800 --> 00:35:51,840
they merge 12 different versions of customer into one entity.

935
00:35:51,840 --> 00:35:53,600
Development time for new apps

936
00:35:53,600 --> 00:35:55,280
dropped from six weeks down to two weeks.

937
00:35:55,280 --> 00:35:56,880
Data quality jumped 40%.

938
00:35:56,880 --> 00:35:58,160
Not because the apps were better

939
00:35:58,160 --> 00:36:00,000
but because the redundancy finally collapsed.

940
00:36:00,000 --> 00:36:01,440
Don't try to do everything at once.

941
00:36:01,440 --> 00:36:03,200
Start with your most critical concept,

942
00:36:03,200 --> 00:36:04,320
like customer or product

943
00:36:04,320 --> 00:36:06,160
and get the business to agree on a design.

944
00:36:06,160 --> 00:36:08,400
Deploy that first, then move to the next one.

945
00:36:08,400 --> 00:36:11,680
Pattern 2, the transactional outbox.

946
00:36:11,680 --> 00:36:13,760
Data integration usually fails quietly.

947
00:36:13,760 --> 00:36:15,840
It doesn't scream for help, it just stops working.

948
00:36:15,840 --> 00:36:17,680
You create an order record in Dataverse

949
00:36:17,680 --> 00:36:18,880
and expect an event to fire

950
00:36:18,880 --> 00:36:20,480
so your warehouse stays updated.

951
00:36:20,480 --> 00:36:22,080
But the event gets lost in transit.

952
00:36:22,080 --> 00:36:23,600
The warehouse never sees the order.

953
00:36:23,600 --> 00:36:26,160
Days go by before anyone notices the mismatch

954
00:36:26,160 --> 00:36:27,760
and by then your other systems

955
00:36:27,760 --> 00:36:30,080
have already made decisions based on bad data.

956
00:36:30,080 --> 00:36:31,520
The transactional outbox pattern

957
00:36:31,520 --> 00:36:33,360
exists to stop the silent failure.

958
00:36:33,360 --> 00:36:34,640
The logic is straightforward.

959
00:36:34,640 --> 00:36:37,200
Every time a critical record changes in Dataverse,

960
00:36:37,200 --> 00:36:40,800
the system writes a new entry into a dedicated outbox table.

961
00:36:40,800 --> 00:36:43,440
This write happens inside the exact same transaction

962
00:36:43,440 --> 00:36:44,960
as the data change itself.

963
00:36:44,960 --> 00:36:47,440
Either both of them succeed or both of them fail.

964
00:36:47,440 --> 00:36:49,440
There is no middle ground where your data updates

965
00:36:49,440 --> 00:36:51,120
but the event record vanishes.

966
00:36:51,120 --> 00:36:53,440
Later a downstream service checks that outbox table

967
00:36:53,440 --> 00:36:54,480
at regular intervals.

968
00:36:54,480 --> 00:36:56,400
It picks up each entry and processes it.

969
00:36:56,400 --> 00:36:58,080
Once the work is done, the service marks

970
00:36:58,080 --> 00:36:59,360
that entry is complete.

971
00:36:59,360 --> 00:37:01,440
If the processing fails for any reason,

972
00:37:01,440 --> 00:37:03,360
the entry stays in a pending state

973
00:37:03,360 --> 00:37:05,520
and the service simply tries again later.

974
00:37:05,520 --> 00:37:08,720
Eventually, every single integration is guaranteed to fire.

975
00:37:08,720 --> 00:37:12,000
The pattern is simple but the impact on your architecture is massive.

976
00:37:12,000 --> 00:37:13,440
Your integration has become reliable

977
00:37:13,440 --> 00:37:15,600
without you having to build custom orchestration logic

978
00:37:15,600 --> 00:37:16,560
for every single move.

979
00:37:16,560 --> 00:37:18,720
You don't need to bake complex retry loops

980
00:37:18,720 --> 00:37:19,920
into every individual flow

981
00:37:19,920 --> 00:37:21,360
because the structure of the pattern

982
00:37:21,360 --> 00:37:23,120
handles the heavy lifting for you.

983
00:37:23,120 --> 00:37:24,800
I saw this play out with a retail company

984
00:37:24,800 --> 00:37:26,640
that kept their order system in Dataverse.

985
00:37:26,640 --> 00:37:27,920
When a customer placed an order

986
00:37:27,920 --> 00:37:29,840
that data had to reach the fulfillment center,

987
00:37:29,840 --> 00:37:30,800
the accounting software,

988
00:37:30,800 --> 00:37:32,480
and the shipping provider all at once.

989
00:37:32,480 --> 00:37:35,680
Without an outbox, things were constantly falling through the cracks.

990
00:37:35,680 --> 00:37:37,280
They would have an order in Dataverse

991
00:37:37,280 --> 00:37:38,480
that never made it to fulfillment

992
00:37:38,480 --> 00:37:39,520
or a package would ship

993
00:37:39,520 --> 00:37:40,960
but the customer was never built.

994
00:37:40,960 --> 00:37:42,160
It was pure chaos.

995
00:37:42,160 --> 00:37:43,680
Everything changed when they implemented

996
00:37:43,680 --> 00:37:44,880
the transactional outbox.

997
00:37:44,880 --> 00:37:47,120
Now every order change writes to that outbox table

998
00:37:47,120 --> 00:37:48,640
in one clean transaction.

999
00:37:48,640 --> 00:37:50,400
Downstream services read the table,

1000
00:37:50,400 --> 00:37:51,520
process the orders,

1001
00:37:51,520 --> 00:37:52,880
and mark them finished.

1002
00:37:52,880 --> 00:37:55,520
The mysterious gaps in their data disappeared overnight.

1003
00:37:55,520 --> 00:37:56,400
To build this,

1004
00:37:56,400 --> 00:37:58,880
you only need one extra table called outbox.

1005
00:37:58,880 --> 00:38:00,560
You'll need columns for the record ID,

1006
00:38:00,560 --> 00:38:02,080
the record type, the operation,

1007
00:38:02,080 --> 00:38:03,920
a timestamp, and a processed flag.

1008
00:38:03,920 --> 00:38:05,920
When a record changes, you insert an entry,

1009
00:38:05,920 --> 00:38:08,400
then you just set up a flow or an azure function

1010
00:38:08,400 --> 00:38:10,320
to read those unprocessed entries

1011
00:38:10,320 --> 00:38:11,760
and handle the rest.

1012
00:38:11,760 --> 00:38:12,640
Pattern 3.

1013
00:38:12,640 --> 00:38:15,120
The saga pattern for distributed transactions.

1014
00:38:15,120 --> 00:38:17,040
Modern systems don't live in a vacuum.

1015
00:38:17,040 --> 00:38:19,520
An order isn't just a row in one database.

1016
00:38:19,520 --> 00:38:22,000
It spans across Dataverse for your CRM,

1017
00:38:22,000 --> 00:38:24,640
an ERP for your inventory and a separate billing system.

1018
00:38:24,640 --> 00:38:26,480
Because these systems are distributed,

1019
00:38:26,480 --> 00:38:28,000
a traditional database transaction

1020
00:38:28,000 --> 00:38:29,520
won't work across those boundaries.

1021
00:38:29,520 --> 00:38:31,920
You can't just hit save and expect three different clouds

1022
00:38:31,920 --> 00:38:32,960
to stay in sync.

1023
00:38:32,960 --> 00:38:35,440
The saga pattern is how you manage this complexity.

1024
00:38:35,440 --> 00:38:38,240
It breaks a large process into smaller individual steps

1025
00:38:38,240 --> 00:38:39,840
that target different systems.

1026
00:38:39,840 --> 00:38:43,200
Crucially, every step has a matching, compensating action.

1027
00:38:43,200 --> 00:38:44,960
If you get to step three and it fails,

1028
00:38:44,960 --> 00:38:46,960
the system automatically runs the compensations

1029
00:38:46,960 --> 00:38:49,360
for steps one and two to undo what they did.

1030
00:38:49,360 --> 00:38:51,200
Think about a customer placing an order.

1031
00:38:51,200 --> 00:38:54,000
In step one, you reserve the inventory in your ERP.

1032
00:38:54,000 --> 00:38:56,880
If that works, step two creates an invoice in the billing system.

1033
00:38:56,880 --> 00:38:59,600
If that also works, step three creates a fulfillment record

1034
00:38:59,600 --> 00:39:00,480
in the warehouse.

1035
00:39:00,480 --> 00:39:03,440
But if that warehouse step fails, the compensation kicks in.

1036
00:39:03,440 --> 00:39:06,160
It cancels the invoice and releases the inventory reservation.

1037
00:39:06,160 --> 00:39:07,520
The customer sees a clean result

1038
00:39:07,520 --> 00:39:09,200
because the order either succeeded everywhere

1039
00:39:09,200 --> 00:39:10,400
or it failed everywhere.

1040
00:39:10,400 --> 00:39:12,720
This pattern does require high observability.

1041
00:39:12,720 --> 00:39:15,120
Every step has to log exactly what happened,

1042
00:39:15,120 --> 00:39:17,600
so the compensation logic knows what to undo.

1043
00:39:17,600 --> 00:39:20,480
You also need a correlation ID for each saga instance,

1044
00:39:20,480 --> 00:39:22,160
so you can trace the path of an order

1045
00:39:22,160 --> 00:39:24,080
as it moves across your different systems.

1046
00:39:24,080 --> 00:39:26,560
Your compensation steps must also be idempotent,

1047
00:39:26,560 --> 00:39:29,920
meaning if you run them twice by mistake, the result stays the same.

1048
00:39:29,920 --> 00:39:32,560
In a dataverse environment, you usually implement sagas

1049
00:39:32,560 --> 00:39:34,240
using a workflow orchestrator.

1050
00:39:34,240 --> 00:39:37,200
You might have an Azure function watching a sagas step table in dataverse.

1051
00:39:37,200 --> 00:39:39,520
It reads the pending steps, calls the external systems

1052
00:39:39,520 --> 00:39:40,800
and logs the results.

1053
00:39:40,800 --> 00:39:42,320
If any system sends back a failure,

1054
00:39:42,320 --> 00:39:45,120
the orchestrator triggers the compensation steps immediately.

1055
00:39:45,120 --> 00:39:47,360
The real benefit here is reliability

1056
00:39:47,360 --> 00:39:49,200
in a world where systems are scattered.

1057
00:39:49,200 --> 00:39:50,880
You aren't pretending that transactions work

1058
00:39:50,880 --> 00:39:52,080
across different platforms.

1059
00:39:52,080 --> 00:39:54,080
Instead, you are acknowledging those boundaries

1060
00:39:54,080 --> 00:39:56,080
and designing a system that respects them.

1061
00:39:56,080 --> 00:39:59,040
Your compensation is explicit, your testing is easier,

1062
00:39:59,040 --> 00:40:00,640
and your debugging is finally clear.

1063
00:40:00,640 --> 00:40:04,560
Pattern 4. The normalized reference data strategy.

1064
00:40:04,560 --> 00:40:07,920
Reference data is the glue that holds your entire system together.

1065
00:40:07,920 --> 00:40:10,080
Think about status values, country codes,

1066
00:40:10,080 --> 00:40:12,720
product categories, or currency definitions.

1067
00:40:12,720 --> 00:40:15,600
These small data points show up in almost every table you build

1068
00:40:15,600 --> 00:40:17,680
and how you handle them determines whether your system

1069
00:40:17,680 --> 00:40:19,680
stays consistent or falls apart.

1070
00:40:19,680 --> 00:40:22,080
The weak approach is to simply copy reference values

1071
00:40:22,080 --> 00:40:24,080
into every table that needs them.

1072
00:40:24,080 --> 00:40:26,640
You store a status as a text field in your orders table,

1073
00:40:26,640 --> 00:40:29,200
then do it again in cases and again in invoices.

1074
00:40:29,200 --> 00:40:30,800
Eventually different values start appearing

1075
00:40:30,800 --> 00:40:32,560
in different tables for the exact same concept

1076
00:40:32,560 --> 00:40:34,160
and the result is total chaos.

1077
00:40:34,160 --> 00:40:36,720
The better pattern is to define canonical reference tables

1078
00:40:36,720 --> 00:40:38,640
where each concept, like a status,

1079
00:40:38,640 --> 00:40:40,480
lives in its own single source of truth.

1080
00:40:40,480 --> 00:40:42,240
When a column needs a status value,

1081
00:40:42,240 --> 00:40:44,240
it uses a lookup to that specific table

1082
00:40:44,240 --> 00:40:45,920
instead of a manual text entry.

1083
00:40:45,920 --> 00:40:48,960
This means you can change a status name in one single place

1084
00:40:48,960 --> 00:40:51,920
and it instantly updates across your entire environment.

1085
00:40:51,920 --> 00:40:53,600
I saw this play out in a real scenario

1086
00:40:53,600 --> 00:40:55,600
where different departments use different names

1087
00:40:55,600 --> 00:40:56,800
for the same thing.

1088
00:40:56,800 --> 00:40:58,480
Sales called a record active,

1089
00:40:58,480 --> 00:40:59,760
finance called it open,

1090
00:40:59,760 --> 00:41:02,480
and operations insisted on calling it live.

1091
00:41:02,480 --> 00:41:05,040
Because they had one data set with three different names,

1092
00:41:05,040 --> 00:41:06,640
reports couldn't aggregate anything

1093
00:41:06,640 --> 00:41:08,480
because the values simply didn't match.

1094
00:41:08,480 --> 00:41:11,680
Implementing a canonical status table forced everyone to align

1095
00:41:11,680 --> 00:41:15,280
and once active, open, and live all became a single active status.

1096
00:41:15,280 --> 00:41:17,120
The reports suddenly started working.

1097
00:41:17,120 --> 00:41:18,560
Building this pattern takes discipline

1098
00:41:18,560 --> 00:41:20,640
because you have to identify these reference concepts

1099
00:41:20,640 --> 00:41:21,760
early in the process.

1100
00:41:21,760 --> 00:41:24,320
You need to create a dedicated table for each one,

1101
00:41:24,320 --> 00:41:25,840
document the values clearly,

1102
00:41:25,840 --> 00:41:29,200
and use lookups instead of letting people type into text fields.

1103
00:41:29,200 --> 00:41:30,720
Once you've built this foundation,

1104
00:41:30,720 --> 00:41:32,880
you have to enforce it during design reviews

1105
00:41:32,880 --> 00:41:35,280
to ensure new apps use the canonical data

1106
00:41:35,280 --> 00:41:37,520
rather than creating their own local versions.

1107
00:41:37,520 --> 00:41:39,680
These patterns aren't new inventions,

1108
00:41:39,680 --> 00:41:41,760
but they are proven methods for organizations

1109
00:41:41,760 --> 00:41:43,680
that need to operate at a massive scale.

1110
00:41:43,680 --> 00:41:45,840
The master data model speeds up your development,

1111
00:41:45,840 --> 00:41:48,640
the transactional outbox makes your integrations reliable

1112
00:41:48,640 --> 00:41:51,520
and the saga pattern manages your distributed complexity.

1113
00:41:51,520 --> 00:41:53,520
When you combine those with normalized reference data

1114
00:41:53,520 --> 00:41:55,120
to keep your values consistent,

1115
00:41:55,120 --> 00:41:56,560
you finally have the infrastructure

1116
00:41:56,560 --> 00:41:59,120
that lets relational intelligence actually work.

1117
00:41:59,120 --> 00:42:01,520
Case study one, from Chaos to Architecture,

1118
00:42:01,520 --> 00:42:03,840
a mid-market manufacturing company I worked with

1119
00:42:03,840 --> 00:42:06,080
had grown much faster than their systems could handle.

1120
00:42:06,080 --> 00:42:08,880
They had 200 power apps deployed across the company,

1121
00:42:08,880 --> 00:42:10,640
but there was no central governance at all.

1122
00:42:10,640 --> 00:42:12,480
Teams were just building whatever they needed,

1123
00:42:12,480 --> 00:42:13,760
the moment they needed it,

1124
00:42:13,760 --> 00:42:16,000
and the outcome was exactly what you'd expect.

1125
00:42:16,000 --> 00:42:18,720
Constant, unpredictable failures.

1126
00:42:18,720 --> 00:42:20,720
An update to a customer table would suddenly break

1127
00:42:20,720 --> 00:42:22,880
three other apps that depended on that structure,

1128
00:42:22,880 --> 00:42:24,800
mostly because the developers didn't even know

1129
00:42:24,800 --> 00:42:26,480
those dependencies existed.

1130
00:42:26,480 --> 00:42:28,720
In another instance, a critical finance workflow

1131
00:42:28,720 --> 00:42:31,360
just stopped firing because someone archived a lookup table

1132
00:42:31,360 --> 00:42:32,800
without checking who was using it.

1133
00:42:32,800 --> 00:42:35,360
Reports were failing silently every single day

1134
00:42:35,360 --> 00:42:37,040
because underlying data definitions

1135
00:42:37,040 --> 00:42:39,920
were shifting without any kind of notification or oversight.

1136
00:42:39,920 --> 00:42:41,360
The diagnosis was structural,

1137
00:42:41,360 --> 00:42:42,800
and the problem was that grid thinking

1138
00:42:42,800 --> 00:42:44,480
had taken over the entire culture.

1139
00:42:44,480 --> 00:42:46,640
Every team was thinking about their specific app

1140
00:42:46,640 --> 00:42:49,120
in a vacuum, which meant relationships weren't mapped

1141
00:42:49,120 --> 00:42:50,800
and redundancy was everywhere.

1142
00:42:50,800 --> 00:42:52,800
Security was being applied inconsistently

1143
00:42:52,800 --> 00:42:54,320
on an app-by-app basis,

1144
00:42:54,320 --> 00:42:56,000
and the logic was scattered so thin

1145
00:42:56,000 --> 00:42:57,280
that nobody could track it.

1146
00:42:57,280 --> 00:42:58,800
They thought they had a technology problem,

1147
00:42:58,800 --> 00:43:00,880
but in reality, they had an engineering crisis

1148
00:43:00,880 --> 00:43:02,560
caused by a lack of a shared model.

1149
00:43:02,560 --> 00:43:04,480
Their first step wasn't a massive rebuild,

1150
00:43:04,480 --> 00:43:07,440
but rather an attempt to understand the mess they already had.

1151
00:43:07,440 --> 00:43:09,120
They ordered it all 200 apps

1152
00:43:09,120 --> 00:43:11,920
to identify which core business entities were being touched,

1153
00:43:11,920 --> 00:43:14,560
and they mapped out which tables held customer info,

1154
00:43:14,560 --> 00:43:16,800
product data, and orders.

1155
00:43:16,800 --> 00:43:19,440
That mapping exercise revealed that customer data was living

1156
00:43:19,440 --> 00:43:22,560
in 17 different tables with 17 different structures.

1157
00:43:22,560 --> 00:43:24,960
Some tables had shipping addresses while others didn't,

1158
00:43:24,960 --> 00:43:28,240
and some tracked tax IDs while others used business registrations.

1159
00:43:28,240 --> 00:43:30,320
The definitions were in total conflict,

1160
00:43:30,320 --> 00:43:32,240
so whenever two apps tried to coordinate

1161
00:43:32,240 --> 00:43:33,280
around a single customer,

1162
00:43:33,280 --> 00:43:35,600
they were essentially speaking two different languages.

1163
00:43:35,600 --> 00:43:37,760
The challenge was that they couldn't just flip a switch

1164
00:43:37,760 --> 00:43:39,600
and shut everything down to start over.

1165
00:43:39,600 --> 00:43:40,800
These apps were live,

1166
00:43:40,800 --> 00:43:42,800
and the teams and customers were relying on them

1167
00:43:42,800 --> 00:43:44,160
every minute of the day.

1168
00:43:44,160 --> 00:43:45,680
The solution was to build a new,

1169
00:43:45,680 --> 00:43:48,320
clean model alongside the existing chaos

1170
00:43:48,320 --> 00:43:50,000
and migrate the data piece by piece,

1171
00:43:50,000 --> 00:43:52,160
and they started with the customer entity

1172
00:43:52,160 --> 00:43:53,680
by designing a single record

1173
00:43:53,680 --> 00:43:55,760
that included every necessary attribute.

1174
00:43:55,760 --> 00:43:58,240
They built out the proper relationships to addresses,

1175
00:43:58,240 --> 00:43:59,760
contacts, and hierarchies,

1176
00:43:59,760 --> 00:44:02,400
and then they picked the simplest apps to migrate first.

1177
00:44:02,400 --> 00:44:04,320
By building those new apps on the clean model

1178
00:44:04,320 --> 00:44:06,400
and letting them run parallel to the old ones,

1179
00:44:06,400 --> 00:44:09,280
they could stabilize the system before moving the users over.

1180
00:44:09,280 --> 00:44:11,360
Only after the new version proved it was solid,

1181
00:44:11,360 --> 00:44:13,920
did they finally decommission the old messy versions.

1182
00:44:14,640 --> 00:44:16,400
This parallel approach definitely took longer

1183
00:44:16,400 --> 00:44:17,920
than a total rebuild would have,

1184
00:44:17,920 --> 00:44:20,800
and it was certainly messier to manage two systems at once.

1185
00:44:20,800 --> 00:44:22,800
However, it didn't break the live environment,

1186
00:44:22,800 --> 00:44:24,880
and it gave the teams a chance to see the new model

1187
00:44:24,880 --> 00:44:26,480
working before they had to commit to it.

1188
00:44:26,480 --> 00:44:28,240
It gave the organization time to adapt,

1189
00:44:28,240 --> 00:44:31,040
and they learned more about their own data as they moved.

1190
00:44:31,040 --> 00:44:32,480
About three months into the project,

1191
00:44:32,480 --> 00:44:35,040
the metrics really started to shift in a big way.

1192
00:44:35,040 --> 00:44:38,480
Development time for new apps dropped from six weeks down to just two,

1193
00:44:38,480 --> 00:44:41,280
and that wasn't because the developers were working harder.

1194
00:44:41,280 --> 00:44:43,840
It happened because the foundation was finally there,

1195
00:44:43,840 --> 00:44:45,200
the schema design was finished,

1196
00:44:45,200 --> 00:44:46,560
and the relationships were clear.

1197
00:44:46,560 --> 00:44:48,640
Developers could now extend the existing system

1198
00:44:48,640 --> 00:44:51,040
rather than building every single thing from scratch,

1199
00:44:51,040 --> 00:44:52,560
even a third-party integration

1200
00:44:52,560 --> 00:44:54,320
that used to take four weeks of custom mapping

1201
00:44:54,320 --> 00:44:55,360
was finished in three days,

1202
00:44:55,360 --> 00:44:58,400
because the common customer entity provided the link immediately.

1203
00:44:58,400 --> 00:44:59,520
By the 12-month mark,

1204
00:44:59,520 --> 00:45:02,000
production incidents had dropped by 40%.

1205
00:45:02,000 --> 00:45:04,160
This didn't happen because the code was suddenly perfect,

1206
00:45:04,160 --> 00:45:06,560
but because the redundancy had been collapsed.

1207
00:45:06,560 --> 00:45:08,400
When a piece of customer information changed,

1208
00:45:08,400 --> 00:45:09,760
it changed everywhere at once,

1209
00:45:09,760 --> 00:45:12,000
so there was no longer a scenario where one app

1210
00:45:12,000 --> 00:45:14,880
saw an old version of a customer while another app saw the new one.

1211
00:45:14,880 --> 00:45:19,360
The big lesson here wasn't about achieving a perfect architecture right out of the gate.

1212
00:45:19,360 --> 00:45:22,240
It was about being intentional with the architecture you do have.

1213
00:45:22,240 --> 00:45:24,080
You don't need a flawless design before you start,

1214
00:45:24,080 --> 00:45:26,400
but you do need the willingness to design on purpose

1215
00:45:26,400 --> 00:45:28,640
instead of letting your structure emerge by accident.

1216
00:45:28,640 --> 00:45:31,280
That gradual migration allowed them to prove the model worked,

1217
00:45:31,280 --> 00:45:34,720
and that proof was what finally turned the skeptics into believers.

1218
00:45:34,720 --> 00:45:37,760
Case study 2, security as a structural problem.

1219
00:45:37,760 --> 00:45:40,480
A healthcare organization was managing patient cases

1220
00:45:40,480 --> 00:45:42,240
across several different regions,

1221
00:45:42,240 --> 00:45:45,120
and the reality of their situation was high stakes compliance.

1222
00:45:45,120 --> 00:45:46,960
The rules were simple.

1223
00:45:46,960 --> 00:45:49,600
Staff in one region should never see data from another.

1224
00:45:49,600 --> 00:45:51,520
To handle this, they set up data verse,

1225
00:45:51,520 --> 00:45:53,360
built out their case management system,

1226
00:45:53,360 --> 00:45:56,160
and deployed their security roles before going live.

1227
00:45:56,160 --> 00:45:59,120
Everything seemed fine until an audit six months later,

1228
00:45:59,120 --> 00:46:00,800
uncovered a major violation.

1229
00:46:00,800 --> 00:46:04,400
It turned out that staff in the northern region could see every case from the south,

1230
00:46:04,400 --> 00:46:07,680
and the reason was a fundamental flaw in how they built the system.

1231
00:46:07,680 --> 00:46:10,160
The case table had no structural boundaries at all,

1232
00:46:10,160 --> 00:46:12,960
so when the security role said a user could read cases,

1233
00:46:12,960 --> 00:46:14,560
it didn't specify which ones.

1234
00:46:14,560 --> 00:46:18,160
They had tried to layer row-level security on top of a flat data model,

1235
00:46:18,160 --> 00:46:20,320
but that kind of setup is incredibly brittle.

1236
00:46:20,320 --> 00:46:22,960
When an admin made a small change to improve query performance,

1237
00:46:22,960 --> 00:46:24,800
the security layer broke silently,

1238
00:46:24,800 --> 00:46:27,760
and nobody noticed until the auditors arrived months later.

1239
00:46:27,760 --> 00:46:30,480
The fix for this wasn't just writing a better security rule,

1240
00:46:30,480 --> 00:46:33,280
because the real solution was restructuring the data

1241
00:46:33,280 --> 00:46:35,360
to enforce those boundaries naturally.

1242
00:46:35,360 --> 00:46:38,400
They started by creating specific business units for each region,

1243
00:46:38,400 --> 00:46:41,440
and made the region field mandatory for every single case.

1244
00:46:41,440 --> 00:46:43,520
They designed new roles with a regional scope

1245
00:46:43,520 --> 00:46:47,360
so that a case manager could only see files belonging to their specific business unit.

1246
00:46:47,360 --> 00:46:50,560
By doing this, the relationship between the user, their role, and the data

1247
00:46:50,560 --> 00:46:52,720
became a physical part of the system structure.

1248
00:46:52,720 --> 00:46:54,400
This shift required a massive migration

1249
00:46:54,400 --> 00:46:57,040
because the existing cases didn't have regions assigned to them yet.

1250
00:46:57,040 --> 00:46:59,440
Every record had to be audited and classified,

1251
00:46:59,440 --> 00:47:01,520
which brought up difficult questions about cases

1252
00:47:01,520 --> 00:47:04,240
that started in one region, but moved to another.

1253
00:47:04,240 --> 00:47:07,680
The organization had to decide if a case belonged to the place it was created,

1254
00:47:07,680 --> 00:47:09,840
or the place where the work was actually happening.

1255
00:47:09,840 --> 00:47:12,720
The audit forced a level of clarity they didn't have before.

1256
00:47:12,720 --> 00:47:16,080
And once that logic was defined, the system could finally enforce it.

1257
00:47:16,080 --> 00:47:17,360
They didn't just flip a switch.

1258
00:47:17,360 --> 00:47:20,960
Instead, they deployed the new structure to a test environment first.

1259
00:47:20,960 --> 00:47:23,200
They ran side-by-side reports to make sure the new model

1260
00:47:23,200 --> 00:47:25,440
showed the exact same data as the old rules.

1261
00:47:25,440 --> 00:47:27,600
The data migration took three weeks to finish,

1262
00:47:27,600 --> 00:47:29,680
and they spent another four weeks on validation

1263
00:47:29,680 --> 00:47:31,200
and testing to be absolutely sure.

1264
00:47:31,200 --> 00:47:32,960
It was a slow and deliberate process,

1265
00:47:32,960 --> 00:47:35,360
but it was also auditable and proven to work.

1266
00:47:35,360 --> 00:47:39,920
Once the new system was live, the entire compliance process changed for the better.

1267
00:47:39,920 --> 00:47:42,080
In the past, auditors had to manually check

1268
00:47:42,080 --> 00:47:44,160
if complex security rules were working,

1269
00:47:44,160 --> 00:47:45,920
which was a slow and exhausting task.

1270
00:47:45,920 --> 00:47:48,800
Now, they just had to verify the data structure itself.

1271
00:47:48,800 --> 00:47:50,720
If a case sits in the Northern Business Unit,

1272
00:47:50,720 --> 00:47:52,800
a Southern staff member simply cannot see it,

1273
00:47:52,800 --> 00:47:55,280
and there are no exceptions or rules to double check.

1274
00:47:55,280 --> 00:47:58,720
The structure made it impossible for a violation to happen in the first place.

1275
00:47:58,720 --> 00:47:59,840
By the time they were done,

1276
00:47:59,840 --> 00:48:03,280
the organization went from 47 audit exceptions down to zero.

1277
00:48:03,280 --> 00:48:07,440
This didn't happen because their rules got more complicated or better in a traditional sense.

1278
00:48:07,440 --> 00:48:12,000
It happened because they used structure to make non-compliance a physical impossibility.

1279
00:48:12,000 --> 00:48:15,120
Case study three, performance through relational design.

1280
00:48:15,120 --> 00:48:17,600
A services company built a system in Dataverse

1281
00:48:17,600 --> 00:48:18,960
to manage their consultants,

1282
00:48:18,960 --> 00:48:22,720
tracking everything from project assignments to skill inventories and budgets.

1283
00:48:22,720 --> 00:48:25,600
In the beginning, the system worked exactly like it was supposed to,

1284
00:48:25,600 --> 00:48:28,240
and users could log in and run reports without any issues.

1285
00:48:28,240 --> 00:48:31,360
But as the company grew from 400 consultants to 2000,

1286
00:48:31,360 --> 00:48:33,600
the entire system started to fall apart.

1287
00:48:33,600 --> 00:48:36,160
Forms that used to be instant were taking 12 seconds to load,

1288
00:48:36,160 --> 00:48:38,080
and some of them just timed out and crashed.

1289
00:48:38,080 --> 00:48:39,360
When they looked into the problem,

1290
00:48:39,360 --> 00:48:43,280
they realized the model was denormalized in a way that couldn't handle the new scale.

1291
00:48:43,280 --> 00:48:45,040
Every time someone opened a consultant form,

1292
00:48:45,040 --> 00:48:48,400
the system had to pull data from nine different related tables at once.

1293
00:48:48,400 --> 00:48:50,080
It was grabbing project assignments,

1294
00:48:50,080 --> 00:48:52,160
skill inventories, and billing rates.

1295
00:48:52,160 --> 00:48:55,360
And each one of those lookups added another join to the process.

1296
00:48:55,360 --> 00:48:58,240
Running nine joins on a single form for thousands of people

1297
00:48:58,240 --> 00:49:01,040
meant the system was executing incredibly expensive queries.

1298
00:49:01,040 --> 00:49:03,520
Every single time a user clicked a name.

1299
00:49:03,520 --> 00:49:05,680
To fix this, they had to go back to basics

1300
00:49:05,680 --> 00:49:08,160
and normalize the data by separating the entities properly.

1301
00:49:08,160 --> 00:49:10,240
They treated the consultant as one entity

1302
00:49:10,240 --> 00:49:12,080
and the skill inventory as another,

1303
00:49:12,080 --> 00:49:14,880
recognizing that the relationship between them was a complex

1304
00:49:14,880 --> 00:49:16,320
many-to-many map.

1305
00:49:16,320 --> 00:49:19,360
However, they also knew that querying that relationship directly

1306
00:49:19,360 --> 00:49:21,120
was exactly what was slowing them down.

1307
00:49:21,120 --> 00:49:23,120
That's when they took account intuitive step

1308
00:49:23,120 --> 00:49:25,280
and introduced denormalization by design.

1309
00:49:25,280 --> 00:49:28,320
They decided to add a cached version of the most important information

1310
00:49:28,320 --> 00:49:30,400
directly onto the main consultant record.

1311
00:49:30,400 --> 00:49:32,960
This included the primary skill, the current project,

1312
00:49:32,960 --> 00:49:34,640
and the billing rate for the year.

1313
00:49:34,640 --> 00:49:37,200
They didn't do this because the normalized design was wrong,

1314
00:49:37,200 --> 00:49:39,280
but because they realized that high traffic areas

1315
00:49:39,280 --> 00:49:41,840
need specific optimization to stay fast.

1316
00:49:41,840 --> 00:49:43,920
They set up an automated flow so that whenever

1317
00:49:43,920 --> 00:49:45,840
a consultant's primary skill changed,

1318
00:49:45,840 --> 00:49:47,920
the cached field updated automatically.

1319
00:49:47,920 --> 00:49:51,360
This meant the consultant form only had to load two tables instead of nine

1320
00:49:51,360 --> 00:49:54,800
and the load time immediately dropped from 12 seconds down to two.

1321
00:49:54,800 --> 00:49:57,600
The denormalization was strategic and carefully managed,

1322
00:49:57,600 --> 00:50:00,000
allowing the system to keep a single source of truth

1323
00:50:00,000 --> 00:50:01,280
while using the cache for speed.

1324
00:50:01,280 --> 00:50:03,760
Before they moved anything to production,

1325
00:50:03,760 --> 00:50:07,040
they ran extensive load tests against both the old and new models.

1326
00:50:07,040 --> 00:50:09,120
They measured every query and response time

1327
00:50:09,120 --> 00:50:13,280
to make sure the cached data stayed perfectly in sync with the main records.

1328
00:50:13,280 --> 00:50:15,920
Every change they made was measured and proven through data

1329
00:50:15,920 --> 00:50:17,760
rather than just being a lucky guess.

1330
00:50:17,760 --> 00:50:19,200
After the new system went live,

1331
00:50:19,200 --> 00:50:22,800
they saw a 60% increase in how much people actually used the software.

1332
00:50:22,800 --> 00:50:25,040
This wasn't because they added flashy new features,

1333
00:50:25,040 --> 00:50:28,240
but simply because the system finally worked the way it was supposed to.

1334
00:50:28,240 --> 00:50:32,400
Staff could actually get their work done without the frustration of waiting for a screen to load.

1335
00:50:32,400 --> 00:50:35,280
The big lesson here is that relational design isn't just about having the

1336
00:50:35,280 --> 00:50:36,720
fewest number of tables possible.

1337
00:50:36,720 --> 00:50:40,240
It's about building the right relationships and using performance-aware caching

1338
00:50:40,240 --> 00:50:42,240
whenever the system needs to move faster.

1339
00:50:42,240 --> 00:50:44,240
The ROI of getting it right.

1340
00:50:44,240 --> 00:50:46,880
The financial case for relational intelligence is straightforward

1341
00:50:46,880 --> 00:50:48,560
once you are willing to actually measure it.

1342
00:50:48,560 --> 00:50:50,400
It starts with development velocity.

1343
00:50:50,400 --> 00:50:51,920
When your architecture is intentional,

1344
00:50:51,920 --> 00:50:55,120
teams do not have to redesign the foundations for every new project

1345
00:50:55,120 --> 00:50:57,680
because they can simply extend what already exists.

1346
00:50:57,680 --> 00:50:59,840
A properly architected dataverse environment

1347
00:50:59,840 --> 00:51:02,400
means new apps take weeks to build instead of months

1348
00:51:02,400 --> 00:51:04,320
and that difference compounds over time.

1349
00:51:04,320 --> 00:51:07,200
If a team ships three apps in a year instead of just one,

1350
00:51:07,200 --> 00:51:10,160
that represents a 100% increase in productivity

1351
00:51:10,160 --> 00:51:12,240
which is pure financial value.

1352
00:51:12,240 --> 00:51:15,680
A 500 person organization running this pattern across multiple teams

1353
00:51:15,680 --> 00:51:20,880
can see a 50 to 70% reduction in the time it takes to get solutions into the hands of users.

1354
00:51:20,880 --> 00:51:23,680
You can translate those gains directly into labor hours.

1355
00:51:23,680 --> 00:51:28,240
An architect working at $200 per hour costs the company $400 per hour

1356
00:51:28,240 --> 00:51:30,400
when you factor in benefits and overhead.

1357
00:51:30,400 --> 00:51:34,240
Saving just one week of architecture work across 50 new apps annually adds up

1358
00:51:34,240 --> 00:51:36,000
to $20,000 in savings.

1359
00:51:36,000 --> 00:51:39,360
When you look at a large enterprise building 50 new apps per year,

1360
00:51:39,360 --> 00:51:42,320
you are looking at a million dollars saved just by getting the design

1361
00:51:42,320 --> 00:51:43,920
and schema right the first time.

1362
00:51:43,920 --> 00:51:46,560
The maintenance burden is where the real money shows up.

1363
00:51:46,560 --> 00:51:49,680
Relational design reduces rework by 40 to 60%.

1364
00:51:49,680 --> 00:51:51,120
Not because the code is better,

1365
00:51:51,120 --> 00:51:53,280
but because you have eliminated redundancy.

1366
00:51:53,280 --> 00:51:55,520
When customer data lives in one single place,

1367
00:51:55,520 --> 00:52:00,240
you do not have teams manually reconciling five different versions of the same information.

1368
00:52:00,240 --> 00:52:04,000
If your business rules live in dataverse instead of being scattered across various flows,

1369
00:52:04,000 --> 00:52:06,720
you only have to change them once instead of five times.

1370
00:52:06,720 --> 00:52:09,600
When security is part of the structure instead of being bolted on later,

1371
00:52:09,600 --> 00:52:12,320
you stop paying annual audit costs to fix missing controls.

1372
00:52:12,320 --> 00:52:15,200
Imagine an organization with 50 apps built on fractured schemas.

1373
00:52:15,200 --> 00:52:17,520
They might spend 10 hours per month on each app

1374
00:52:17,520 --> 00:52:20,960
just managing redundancy, syncing data and patching security gaps.

1375
00:52:20,960 --> 00:52:23,200
That adds up to 500 hours every month.

1376
00:52:23,200 --> 00:52:24,960
Or 6000 hours annually,

1377
00:52:24,960 --> 00:52:28,800
which means you are spending over a million dollars a year just to manage the chaos.

1378
00:52:28,800 --> 00:52:32,000
Data quality improvements also show up in how fast you can make decisions.

1379
00:52:32,000 --> 00:52:34,880
If your operational data is only 85% accurate,

1380
00:52:34,880 --> 00:52:36,880
which is typical for these messy systems,

1381
00:52:36,880 --> 00:52:38,720
you simply cannot trust your reports.

1382
00:52:38,720 --> 00:52:42,240
You cannot rely on automation because you are uncertain about the foundation,

1383
00:52:42,240 --> 00:52:44,720
so you end up making decisions much slower.

1384
00:52:44,720 --> 00:52:47,520
Normalize models push that accuracy to 95% or higher,

1385
00:52:47,520 --> 00:52:50,960
which allows decisions to accelerate an automation to become reliable.

1386
00:52:50,960 --> 00:52:54,480
While the financial impact of faster decisions is hard to quantify,

1387
00:52:54,480 --> 00:52:59,120
even a 20% improvement in speed across an organization creates a massive compounding effect.

1388
00:52:59,120 --> 00:53:03,760
Compliance also finds its way into the ROI calculation through avoided costs.

1389
00:53:03,760 --> 00:53:07,360
Audit exceptions are expensive because every single one requires an investigation,

1390
00:53:07,360 --> 00:53:09,120
documentation and a fix.

1391
00:53:09,120 --> 00:53:12,480
Architecturally sound systems reduce these findings by 80%,

1392
00:53:12,480 --> 00:53:15,120
which is the difference between 47 exceptions and zero,

1393
00:53:15,120 --> 00:53:19,120
since each investigation and fix costs between $3,000 and $10,000,

1394
00:53:19,120 --> 00:53:23,760
an organization with 100 exceptions is spending up to a million dollars on remediation.

1395
00:53:23,760 --> 00:53:26,880
If you reduce that by 80% through good architecture,

1396
00:53:26,880 --> 00:53:29,920
you are looking at hundreds of thousands of dollars in avoided costs.

1397
00:53:29,920 --> 00:53:31,600
When you look at the aggregate picture,

1398
00:53:31,600 --> 00:53:35,120
a 500 person organization with a hundred million dollars in revenue

1399
00:53:35,120 --> 00:53:38,160
can realize two to four million dollars in annual savings.

1400
00:53:38,160 --> 00:53:40,080
That is two to four percent of total revenue,

1401
00:53:40,080 --> 00:53:41,440
which is not just a small win,

1402
00:53:41,440 --> 00:53:43,200
but a major strategic advantage.

1403
00:53:43,200 --> 00:53:46,320
To calculate your own ROI, you need to start with a baseline.

1404
00:53:46,320 --> 00:53:50,000
Ask yourself how much time your organization currently spends on maintenance,

1405
00:53:50,000 --> 00:53:54,880
reconciliation and fixing mistakes, document how many audit exceptions you see annually

1406
00:53:54,880 --> 00:53:57,040
and how long it takes to build a new app from scratch.

1407
00:53:57,040 --> 00:53:59,360
Once you implement relational design on new projects,

1408
00:53:59,360 --> 00:54:02,800
you can measure the difference and see the specific ROI for your company.

1409
00:54:02,800 --> 00:54:04,960
The hidden benefit is not found in a spreadsheet,

1410
00:54:04,960 --> 00:54:07,040
but in your own career trajectory.

1411
00:54:07,040 --> 00:54:11,120
Architects usually command 40 to 60% higher compensation than builders,

1412
00:54:11,120 --> 00:54:13,600
not because they are smarter, but because they provide more value.

1413
00:54:14,240 --> 00:54:16,720
When you shift from being a builder to an architect,

1414
00:54:16,720 --> 00:54:19,120
you move from being replaceable to being strategic

1415
00:54:19,120 --> 00:54:21,120
and your paycheck will eventually follow that shift.

1416
00:54:21,120 --> 00:54:23,600
The risk of not mastering these skills,

1417
00:54:23,600 --> 00:54:25,040
the opposite is also true,

1418
00:54:25,040 --> 00:54:27,520
and failing to master relational intelligence carries a cost

1419
00:54:27,520 --> 00:54:29,120
that grows every single day.

1420
00:54:29,120 --> 00:54:31,760
Organizations that lack this skill eventually hit a plateau.

1421
00:54:31,760 --> 00:54:34,880
The research shows that enterprises trying to adopt AI and co-pilot

1422
00:54:34,880 --> 00:54:39,520
without strong data architecture only see adoption rates between 20 and 30%.

1423
00:54:39,520 --> 00:54:43,920
Their AI initiatives run into the same old problem of garbage in and garbage out.

1424
00:54:43,920 --> 00:54:46,400
You cannot train an AI model on unreliable data

1425
00:54:46,400 --> 00:54:48,880
and you cannot make confident decisions based on information

1426
00:54:48,880 --> 00:54:50,640
that is duplicated or conflicting.

1427
00:54:50,640 --> 00:54:53,680
The organizations that actually reach 80% adoption

1428
00:54:53,680 --> 00:54:57,520
are the ones with architects who designed their data intentionally from the start.

1429
00:54:57,520 --> 00:55:01,040
Technical debt accumulates just like high interest debt on a credit card.

1430
00:55:01,040 --> 00:55:05,840
Each new app built on a weak foundation adds more complexity instead of more capability,

1431
00:55:05,840 --> 00:55:08,880
so you end up building workarounds instead of functionality.

1432
00:55:08,880 --> 00:55:10,560
Integration logic becomes a mess,

1433
00:55:10,560 --> 00:55:12,640
where flows, spawn more flows and plugins,

1434
00:55:12,640 --> 00:55:17,600
spawn more plugins until you realize that changing one field requires touching 12 different places.

1435
00:55:17,600 --> 00:55:20,400
Your development speed does not just slow down,

1436
00:55:20,400 --> 00:55:21,760
it actually reverses,

1437
00:55:21,760 --> 00:55:25,600
and what used to take two weeks to build now takes two weeks just to modify.

1438
00:55:25,600 --> 00:55:28,240
Compliance risk increases every time you take a shortcut.

1439
00:55:28,240 --> 00:55:30,800
Poor data structures force expensive audits because

1440
00:55:30,800 --> 00:55:34,560
row-level security that is bolted onto a flat model usually fails.

1441
00:55:34,560 --> 00:55:36,560
Audit teams find these exceptions,

1442
00:55:36,560 --> 00:55:38,640
which leads to remediation and rework

1443
00:55:38,640 --> 00:55:40,480
that costs the company time and money.

1444
00:55:40,480 --> 00:55:44,480
We saw one organization go through seven audit cycles with over 50 exceptions

1445
00:55:44,480 --> 00:55:46,880
each before they finally address the structural problem.

1446
00:55:46,880 --> 00:55:48,480
The total cost of those failed audits,

1447
00:55:48,480 --> 00:55:50,720
including the investigations and the re-audits,

1448
00:55:50,720 --> 00:55:52,480
ended up well into the seven figures.

1449
00:55:52,480 --> 00:55:55,440
Decision making also slows down when you cannot trust the data.

1450
00:55:55,440 --> 00:55:57,200
When the information is unreliable,

1451
00:55:57,200 --> 00:55:59,440
you do not trust the automation or the reports.

1452
00:55:59,440 --> 00:56:01,760
So you demand manual verification for everything.

1453
00:56:01,760 --> 00:56:03,040
That verification takes time,

1454
00:56:03,040 --> 00:56:05,920
which means you are making slower decisions just to feel confident.

1455
00:56:05,920 --> 00:56:07,520
While confidence is a good thing,

1456
00:56:07,520 --> 00:56:11,760
slow decisions mean you are missing out on opportunities that your competitors are grabbing.

1457
00:56:11,760 --> 00:56:13,840
Talent retention starts to suffer as well.

1458
00:56:13,840 --> 00:56:16,080
Builders get frustrated when they are constantly asked

1459
00:56:16,080 --> 00:56:18,800
to build on top of broken foundations and architects leave

1460
00:56:18,800 --> 00:56:21,760
when they cannot convince leadership to fix structural flaws.

1461
00:56:21,760 --> 00:56:23,840
You will lose your best people to organizations

1462
00:56:23,840 --> 00:56:25,360
that have better architectures

1463
00:56:25,360 --> 00:56:28,160
and the cost to replace them is immediate and significant.

1464
00:56:28,160 --> 00:56:31,120
The ultimate cost of failure shows up as emergency re-rides,

1465
00:56:31,120 --> 00:56:32,320
compliance violations,

1466
00:56:32,320 --> 00:56:34,160
and a lost competitive advantage.

1467
00:56:34,160 --> 00:56:38,160
One healthcare organization had to completely overhaul their case management system

1468
00:56:38,160 --> 00:56:39,760
after a major audit violation,

1469
00:56:39,760 --> 00:56:43,360
which resulted in 18 months of extra work and millions in costs.

1470
00:56:43,360 --> 00:56:47,040
That violation only happened because they did not design their security

1471
00:56:47,040 --> 00:56:49,280
as part of the architecture from day one.

1472
00:56:49,280 --> 00:56:53,040
The hard truth is that you cannot automate your way out of a bad architecture.

1473
00:56:53,040 --> 00:56:56,320
You cannot just throw more tools at the problem or higher enough staff

1474
00:56:56,320 --> 00:56:58,560
to manage the chaos through pure effort.

1475
00:56:58,560 --> 00:57:01,520
Only intentional design can fix these structural problems.

1476
00:57:01,520 --> 00:57:05,120
And relational intelligence is the only discipline that actually works at scale.

1477
00:57:05,120 --> 00:57:08,320
Your first steps, the 90-day roadmap.

1478
00:57:08,320 --> 00:57:09,680
Knowing what to do is one thing,

1479
00:57:09,680 --> 00:57:12,240
but knowing where to start is where most people get stuck.

1480
00:57:12,240 --> 00:57:16,640
This 90-day roadmap is designed to ground relational thinking in actual physical action.

1481
00:57:16,640 --> 00:57:19,360
This isn't about a total company transformation on day one.

1482
00:57:19,360 --> 00:57:22,720
It is a proof of concept to show that relational intelligence actually works

1483
00:57:22,720 --> 00:57:24,480
inside your specific organization.

1484
00:57:24,480 --> 00:57:26,240
The first two weeks are all about diagnosis.

1485
00:57:26,240 --> 00:57:28,960
You need to walk through your current dataverse environment

1486
00:57:28,960 --> 00:57:30,960
but you aren't there to judge the mess.

1487
00:57:30,960 --> 00:57:32,400
You are there to understand it.

1488
00:57:32,400 --> 00:57:35,760
List out your tables and ask yourself why each one exists

1489
00:57:35,760 --> 00:57:38,960
and what specific business concept it is supposed to represent.

1490
00:57:38,960 --> 00:57:42,160
Look for where data is being duplicated across multiple tables.

1491
00:57:42,160 --> 00:57:43,840
In a typical sales organization,

1492
00:57:43,840 --> 00:57:47,760
you might find tables for accounts, contacts, companies, and organizations.

1493
00:57:47,760 --> 00:57:50,800
Every single one of those represents a customer-like concept.

1494
00:57:50,800 --> 00:57:52,960
So you have to figure out which ones overlap

1495
00:57:52,960 --> 00:57:55,600
and why all four exist in the first place.

1496
00:57:55,600 --> 00:57:58,880
This audit is how you reveal grid thinking patterns in your own backyard.

1497
00:57:58,880 --> 00:58:00,880
Weeks 3 and 4 shift into design.

1498
00:58:00,880 --> 00:58:02,880
Pick one critical business process

1499
00:58:02,880 --> 00:58:05,840
that touches multiple parts of your company.

1500
00:58:05,840 --> 00:58:07,840
Order to cash is a classic choice for this.

1501
00:58:07,840 --> 00:58:09,120
Map out every entity involved,

1502
00:58:09,120 --> 00:58:11,920
like the customer, the product, the order, and the invoice.

1503
00:58:11,920 --> 00:58:15,280
Ask how they relate and what specific fields each one actually needs.

1504
00:58:15,280 --> 00:58:17,360
You shouldn't try to redesign the whole world.

1505
00:58:17,360 --> 00:58:19,360
So just focus on this one process

1506
00:58:19,360 --> 00:58:21,760
and draw a diagram showing those relationships.

1507
00:58:21,760 --> 00:58:23,600
Get your stakeholders to validate it.

1508
00:58:23,600 --> 00:58:27,520
The person running sales should look at the customer entity and agree it's what they need.

1509
00:58:27,520 --> 00:58:30,880
While the finance team looks at the invoice and agrees on what belongs there.

1510
00:58:30,880 --> 00:58:32,880
This design becomes your master template.

1511
00:58:32,880 --> 00:58:34,640
Weeks 5 through 8 are for the pilot.

1512
00:58:34,640 --> 00:58:37,440
You are going to build one new solution

1513
00:58:37,440 --> 00:58:40,080
using that relational design you just mapped out.

1514
00:58:40,080 --> 00:58:42,480
If your diagram showed that a customer relates to an order

1515
00:58:42,480 --> 00:58:44,000
through a one-to-many relationship,

1516
00:58:44,000 --> 00:58:46,320
then go ahead and build that exact relationship.

1517
00:58:46,320 --> 00:58:49,280
Use it, create test orders, and see if the design actually holds up

1518
00:58:49,280 --> 00:58:50,560
when you use it in the real world.

1519
00:58:50,560 --> 00:58:52,160
You need to measure the difference here.

1520
00:58:52,160 --> 00:58:55,120
Track how long it took to build this using relational design

1521
00:58:55,120 --> 00:58:56,560
compared to your average project.

1522
00:58:56,560 --> 00:59:00,480
Look for unexpected complications and see if the structure stays solid under pressure.

1523
00:59:00,480 --> 00:59:02,320
Weeks 9 through 12 are about expansion.

1524
00:59:02,320 --> 00:59:05,760
You take that same pattern and apply it to the next business process.

1525
00:59:05,760 --> 00:59:06,880
Don't do everything at once.

1526
00:59:06,880 --> 00:59:08,720
Just do one more and then one more after that.

1527
00:59:08,720 --> 00:59:12,160
You are building momentum and showing other teams that this approach actually works.

1528
00:59:12,160 --> 00:59:13,760
As each new solution goes live,

1529
00:59:13,760 --> 00:59:16,160
you need to capture the metrics on development time,

1530
00:59:16,160 --> 00:59:18,400
data quality, and integration reliability.

1531
00:59:18,400 --> 00:59:20,160
These patterns compound over time.

1532
00:59:20,160 --> 00:59:22,640
By week 12 you should have three or four new solutions

1533
00:59:22,640 --> 00:59:25,440
that prove relational design makes development faster.

1534
00:59:25,440 --> 00:59:27,280
The 90-day checkpoint is simple.

1535
00:59:27,280 --> 00:59:29,120
Can you show measurable improvement?

1536
00:59:29,120 --> 00:59:30,800
You need to know if solutions built this way

1537
00:59:30,800 --> 00:59:33,520
took less time to develop than your organizational average.

1538
00:59:33,520 --> 00:59:35,520
Check if they have fewer bugs after launch

1539
00:59:35,520 --> 00:59:37,760
and if your new integrations are more reliable.

1540
00:59:37,760 --> 00:59:39,920
If the answer is yes, you finally have proof.

1541
00:59:39,920 --> 00:59:41,760
That proof is what converts the skeptics.

1542
00:59:41,760 --> 00:59:44,080
When you run into resistance, just show the data.

1543
00:59:44,080 --> 00:59:45,760
Let the results do the talking for you.

1544
00:59:45,760 --> 00:59:48,640
A team might complain that this design approach feels too restrictive

1545
00:59:48,640 --> 00:59:51,680
but you should wait until they try building on a relational foundation

1546
00:59:51,680 --> 00:59:53,760
and realize they shipped four weeks faster.

1547
00:59:53,760 --> 00:59:55,840
That is how a skeptic becomes an advocate.

1548
00:59:55,840 --> 00:59:58,080
This investment is almost entirely about time.

1549
00:59:58,080 --> 01:00:00,880
You don't need major new tools or expensive licensing costs

1550
01:00:00,880 --> 01:00:03,120
and you aren't buying a fancy data modeling platform.

1551
01:00:03,120 --> 01:00:04,880
You are simply changing how you think

1552
01:00:04,880 --> 01:00:08,400
that costs nothing except the hours you spend doing it right instead of rushing.

1553
01:00:08,400 --> 01:00:11,360
Building a center of excellence

1554
01:00:11,360 --> 01:00:14,400
A 90-day pilot proves that relational intelligence actually works

1555
01:00:14,400 --> 01:00:17,040
but scaling that success across an entire company

1556
01:00:17,040 --> 01:00:18,480
requires a real structure.

1557
01:00:18,480 --> 01:00:20,000
You need a center of excellence.

1558
01:00:20,000 --> 01:00:22,000
But let's be clear about what a COE is not.

1559
01:00:22,000 --> 01:00:24,400
It isn't another slow-moving governance committee or a group

1560
01:00:24,400 --> 01:00:26,080
that exists just to attend meetings.

1561
01:00:26,080 --> 01:00:28,880
It's a dedicated team that owns and pushes relational thinking

1562
01:00:28,880 --> 01:00:30,880
into every corner of your organization.

1563
01:00:30,880 --> 01:00:32,640
You need a core group to make this happen.

1564
01:00:32,640 --> 01:00:35,120
This starts with an architect who understands relational design

1565
01:00:35,120 --> 01:00:36,400
and can mentor others.

1566
01:00:36,400 --> 01:00:39,360
A long-sider data steward to manage quality standards.

1567
01:00:39,360 --> 01:00:42,320
You also need a security lead focused on access and compliance

1568
01:00:42,320 --> 01:00:44,400
plus a business analyst who can translate

1569
01:00:44,400 --> 01:00:46,800
messy business concepts into clean data models.

1570
01:00:46,800 --> 01:00:48,480
The charter for this group is simple.

1571
01:00:48,480 --> 01:00:50,560
They define standards, provide templates

1572
01:00:50,560 --> 01:00:53,040
and review designs to help teams move faster.

1573
01:00:53,040 --> 01:00:55,680
This isn't about gatekeeping or slowing projects down.

1574
01:00:55,680 --> 01:00:56,880
It's about enabling them.

1575
01:00:56,880 --> 01:01:00,000
When the architect validates an entity diagram

1576
01:01:00,000 --> 01:01:03,040
before a team starts building, they aren't there to say no.

1577
01:01:03,040 --> 01:01:06,640
They are there to show the team how to think about the problem correctly

1578
01:01:06,640 --> 01:01:08,400
so they don't have to rebuild it later.

1579
01:01:08,400 --> 01:01:12,960
Because the COE provides templates, new teams never have to start from a blank canvas

1580
01:01:12,960 --> 01:01:16,080
and they immediately inherit patterns that are already proven to work.

1581
01:01:16,080 --> 01:01:18,320
Your first major deliverable is an entity catalog.

1582
01:01:18,320 --> 01:01:21,200
You have to define the core business concepts that everyone uses,

1583
01:01:21,200 --> 01:01:23,840
like customer, product, order or case.

1584
01:01:23,840 --> 01:01:25,600
Every single one of these gets documented

1585
01:01:25,600 --> 01:01:28,320
so everyone knows exactly what fields a customer record has

1586
01:01:28,320 --> 01:01:29,760
and why those fields exist.

1587
01:01:29,760 --> 01:01:32,880
This catalog becomes the ultimate reference point for the company.

1588
01:01:32,880 --> 01:01:34,000
When a new project starts,

1589
01:01:34,000 --> 01:01:36,640
the team references the catalog instead of wasting time

1590
01:01:36,640 --> 01:01:40,320
creating their own local disconnected versions of the same data.

1591
01:01:40,320 --> 01:01:42,960
The second deliverable is a set of design templates.

1592
01:01:42,960 --> 01:01:44,400
When a developer starts a new project,

1593
01:01:44,400 --> 01:01:47,920
they shouldn't be guessing how to structure a hierarchical organization

1594
01:01:47,920 --> 01:01:50,000
or how to set up a many to many relationship.

1595
01:01:50,000 --> 01:01:51,600
They should have a template for that.

1596
01:01:51,600 --> 01:01:54,480
These templates show exactly how to implement common patterns

1597
01:01:54,480 --> 01:01:56,240
or design an approval workflow.

1598
01:01:56,240 --> 01:01:58,640
This doesn't just ensure consistency across the board.

1599
01:01:58,640 --> 01:02:01,040
It drastically accelerates the entire design phase.

1600
01:02:01,040 --> 01:02:02,800
The third deliverable is governance,

1601
01:02:02,800 --> 01:02:04,400
but not the kind you're used to.

1602
01:02:04,400 --> 01:02:06,960
The architect reviews major schemas before they hit production

1603
01:02:06,960 --> 01:02:09,440
to catch structural issues while they're still easy to fix.

1604
01:02:09,440 --> 01:02:11,040
This isn't a sign of distrust.

1605
01:02:11,040 --> 01:02:12,400
It's a way to spread knowledge.

1606
01:02:12,400 --> 01:02:15,120
Every single design review is an opportunity to teach a team

1607
01:02:15,120 --> 01:02:17,040
something new about relational thinking.

1608
01:02:17,040 --> 01:02:19,040
The ultimate goal is to make relational thinking

1609
01:02:19,040 --> 01:02:20,320
the default way of working.

1610
01:02:20,320 --> 01:02:23,360
It shouldn't be a special process reserved for high profile projects.

1611
01:02:23,360 --> 01:02:24,880
It should just be how you build things.

1612
01:02:24,880 --> 01:02:28,240
Eventually teams will expect their solutions to be designed this way.

1613
01:02:28,240 --> 01:02:31,200
They'll assume the entity they need already exists in the catalog

1614
01:02:31,200 --> 01:02:33,600
and if it doesn't, they'll naturally work with the COE

1615
01:02:33,600 --> 01:02:34,800
to edit the right way.

1616
01:02:34,800 --> 01:02:37,600
A center of excellence usually takes six to 12 months

1617
01:02:37,600 --> 01:02:39,440
to really mature, so you have to be patient.

1618
01:02:39,440 --> 01:02:42,080
This is a cultural shift, not a quick technical fix,

1619
01:02:42,080 --> 01:02:44,080
and you should expect some resistance early on.

1620
01:02:44,080 --> 01:02:46,400
The best way to handle that is to celebrate early wins

1621
01:02:46,400 --> 01:02:50,160
and show exactly how relational designs saved a specific team time.

1622
01:02:50,160 --> 01:02:52,000
Invite the skeptics to your design review

1623
01:02:52,000 --> 01:02:53,760
so they can see the logic for themselves

1624
01:02:53,760 --> 01:02:56,480
and over time that resistance will turn into adoption.

1625
01:02:56,480 --> 01:02:58,720
Measuring progress.

1626
01:02:58,720 --> 01:03:01,040
You can't improve a system if you aren't measuring it.

1627
01:03:01,040 --> 01:03:02,960
Relational intelligence is either succeeding

1628
01:03:02,960 --> 01:03:05,600
or failing based on outcomes you can actually track.

1629
01:03:05,600 --> 01:03:07,760
Technical metrics are the first thing you should look at.

1630
01:03:07,760 --> 01:03:09,840
You need to track your development velocity

1631
01:03:09,840 --> 01:03:12,320
by measuring how long it takes to build a typical app

1632
01:03:12,320 --> 01:03:14,160
before you implement relational design.

1633
01:03:14,160 --> 01:03:15,920
Once you measure it again afterward,

1634
01:03:15,920 --> 01:03:19,120
the improvement becomes quantifiable and hard to argue with.

1635
01:03:19,120 --> 01:03:21,280
You'll also see a shift in code quality

1636
01:03:21,280 --> 01:03:23,760
which shows up as fewer urgent changes after a launch

1637
01:03:23,760 --> 01:03:26,240
and a massive drop in duplicate data issues.

1638
01:03:26,240 --> 01:03:28,960
Business metrics are what your stakeholders actually care about.

1639
01:03:28,960 --> 01:03:31,280
They want to see time to value user adoption rates

1640
01:03:31,280 --> 01:03:32,880
and compliance status.

1641
01:03:32,880 --> 01:03:35,200
These numbers connect your architecture directly

1642
01:03:35,200 --> 01:03:36,400
to business results.

1643
01:03:36,400 --> 01:03:37,920
When you can report that solutions built

1644
01:03:37,920 --> 01:03:40,720
on a relational design hit production 40% faster,

1645
01:03:40,720 --> 01:03:43,200
you're finally speaking the language of finance.

1646
01:03:43,200 --> 01:03:46,560
Organizational metrics tell you if the cultural shift is actually sticking.

1647
01:03:46,560 --> 01:03:47,520
Look at your architects.

1648
01:03:47,520 --> 01:03:50,400
In the early days of a COE, talented architects often leave

1649
01:03:50,400 --> 01:03:53,360
if they feel their advice is being ignored by the rest of the company.

1650
01:03:53,360 --> 01:03:56,240
If your architects are staying and taking on more responsibility,

1651
01:03:56,240 --> 01:03:58,880
it means relational thinking is becoming a reality.

1652
01:03:58,880 --> 01:04:01,200
You should also check in with your citizen developers.

1653
01:04:01,200 --> 01:04:03,360
If they tell you that building on a relational foundation

1654
01:04:03,360 --> 01:04:05,840
makes their jobs easier, then the system is working.

1655
01:04:05,840 --> 01:04:08,720
For the best results, you should measure your velocity every month

1656
01:04:08,720 --> 01:04:11,120
to get quick feedback on whether things are improving

1657
01:04:11,120 --> 01:04:12,400
or sliding backward.

1658
01:04:12,400 --> 01:04:14,160
Business outcomes change more slowly,

1659
01:04:14,160 --> 01:04:16,320
so those are better suited for quarterly reviews

1660
01:04:16,320 --> 01:04:18,960
while organizational health can be measured once a year.

1661
01:04:18,960 --> 01:04:22,400
Where you share these results is just as important as the data itself.

1662
01:04:22,400 --> 01:04:25,040
The Executive Steering Committee needs to see the financial impact,

1663
01:04:25,040 --> 01:04:28,480
while the Architecture Review Board needs to see the technical patterns.

1664
01:04:28,480 --> 01:04:30,480
Individual teams should see how their work compares

1665
01:04:30,480 --> 01:04:31,680
to the rest of the company.

1666
01:04:31,680 --> 01:04:34,800
This kind of open communication creates a natural sense of accountability.

1667
01:04:34,800 --> 01:04:37,760
When it's time to celebrate, make sure you recognize the teams

1668
01:04:37,760 --> 01:04:39,040
that are getting it right.

1669
01:04:39,040 --> 01:04:42,240
Share their success stories and be specific about the hours they saved

1670
01:04:42,240 --> 01:04:43,680
or the bugs they prevented.

1671
01:04:43,680 --> 01:04:47,120
You want to make relational thinking visible as a badge of success

1672
01:04:47,120 --> 01:04:48,800
rather than a piece of bureaucracy.

1673
01:04:48,800 --> 01:04:50,640
The final checkpoint is very straightforward.

1674
01:04:50,640 --> 01:04:52,560
Are these metrics moving in the right direction?

1675
01:04:52,560 --> 01:04:55,680
If they are, you aren't just talking about relational intelligence anymore.

1676
01:04:55,680 --> 01:04:56,720
You're actually living it.

1677
01:04:56,720 --> 01:05:01,360
Moving from grid thinking to relational intelligence is more than a technical pivot

1678
01:05:01,360 --> 01:05:03,680
because in reality, it is a career transformation.

1679
01:05:03,680 --> 01:05:05,840
You stop building isolated applications

1680
01:05:05,840 --> 01:05:08,080
and start architecting integrated systems

1681
01:05:08,080 --> 01:05:10,400
and that shift changes everything about your value.

1682
01:05:10,400 --> 01:05:13,680
Entity mapping, logic delegation and security architecture

1683
01:05:13,680 --> 01:05:15,680
are not just theoretical concepts to study.

1684
01:05:15,680 --> 01:05:19,040
These are learnable skills that separate the architects from the builders

1685
01:05:19,040 --> 01:05:20,960
and the patterns that actually scale,

1686
01:05:20,960 --> 01:05:23,840
like master data models or saga coordination

1687
01:05:23,840 --> 01:05:25,840
already exist for you to apply.

1688
01:05:25,840 --> 01:05:27,840
Your first 90 days will determine your success,

1689
01:05:27,840 --> 01:05:31,040
so you need to pick one business process and design it the right way.

1690
01:05:31,040 --> 01:05:32,320
Once you prove the model works,

1691
01:05:32,320 --> 01:05:34,320
the momentum starts to build itself.

1692
01:05:34,320 --> 01:05:36,240
The organizations that master these skills

1693
01:05:36,240 --> 01:05:39,680
will easily outpace competitors who are still relying on shortcuts.

1694
01:05:39,680 --> 01:05:41,760
This isn't just a technical advantage.

1695
01:05:41,760 --> 01:05:45,520
It is strategic positioning that creates real competitive distance.

1696
01:05:45,520 --> 01:05:46,960
This is where leadership begins.

1697
01:05:46,960 --> 01:05:48,400
It isn't about mastering buttons.

1698
01:05:48,400 --> 01:05:49,920
It's about mastering the structure.

1699
01:05:49,920 --> 01:05:53,520
Subscribe for deeper dives into Microsoft 365, Copilot and Azure.

1700
01:05:53,520 --> 01:05:54,720
Connect with me on LinkedIn

1701
01:05:54,720 --> 01:05:57,840
and let me know which topics matter most to your organization right now.

1702
01:05:57,840 --> 01:05:59,440
The foundation determines everything.