WEBVTT

1
00:00:00.120 --> 00:00:03.640
<v Speaker 1>Okay, let's unpack this. We live in a world where

2
00:00:04.040 --> 00:00:07.839
<v Speaker 1>everything I mean, from the smallest startup process right up

3
00:00:07.879 --> 00:00:11.000
<v Speaker 1>to huge global supply chains, it all runs on these

4
00:00:11.000 --> 00:00:16.079
<v Speaker 1>complex digital systems, and for business professionals, that complexity can

5
00:00:16.160 --> 00:00:19.559
<v Speaker 1>feel well, pretty overwhelming, sometimes.

6
00:00:19.120 --> 00:00:21.160
<v Speaker 2>Information overload, definitely, it's real.

7
00:00:21.359 --> 00:00:24.120
<v Speaker 1>Yeah, And what we really need is a kind of

8
00:00:24.160 --> 00:00:27.679
<v Speaker 1>systematic shortcut, almost like a blueprint, right to understand how

9
00:00:27.679 --> 00:00:33.000
<v Speaker 1>these critical digital things are dreamed up, built and managed effectively.

10
00:00:33.079 --> 00:00:35.600
<v Speaker 2>And that's exactly our mission today. We're doing a deep

11
00:00:35.640 --> 00:00:39.560
<v Speaker 2>dive into systems analysis and design, or SAD as it's

12
00:00:39.600 --> 00:00:42.799
<v Speaker 2>often called. We're pulling together insights from some really comprehensive

13
00:00:42.799 --> 00:00:45.960
<v Speaker 2>sources you shared. We want to unpack the core processes,

14
00:00:46.079 --> 00:00:48.719
<v Speaker 2>the tools analysts use, and also those big shifts you know,

15
00:00:49.039 --> 00:00:52.280
<v Speaker 2>from the old traditional ways to more agile user focus

16
00:00:52.359 --> 00:00:53.359
<v Speaker 2>methods we see now.

17
00:00:53.600 --> 00:00:56.719
<v Speaker 1>So at its heart systems analysis and design, it's the

18
00:00:56.759 --> 00:00:59.520
<v Speaker 1>process analysts use to figure out what the organization actually

19
00:00:59.520 --> 00:01:00.719
<v Speaker 1>needs exactly.

20
00:01:00.759 --> 00:01:04.799
<v Speaker 2>It's about systematically looking at how data flows in, how

21
00:01:04.840 --> 00:01:08.599
<v Speaker 2>it gets processed, where it gets stored, and what useful

22
00:01:08.640 --> 00:01:10.920
<v Speaker 2>information actually comes out the other end. The aim is

23
00:01:10.959 --> 00:01:12.120
<v Speaker 2>always improvement.

24
00:01:12.239 --> 00:01:16.719
<v Speaker 1>Analyzing designing, implementing better systems.

25
00:01:16.319 --> 00:01:20.280
<v Speaker 2>Better computerized systems. Yeah, and to really guide that whole process,

26
00:01:20.319 --> 00:01:22.280
<v Speaker 2>we kind of have to start with the let's call

27
00:01:22.319 --> 00:01:24.840
<v Speaker 2>it the foundational map for the industry.

28
00:01:24.439 --> 00:01:27.680
<v Speaker 1>Which is the classic system development life cycle STLC.

29
00:01:27.879 --> 00:01:32.400
<v Speaker 2>That's the one. Now it's often adapted or even replaced

30
00:01:32.439 --> 00:01:35.840
<v Speaker 2>by newer approaches today, but it's seven phases still give

31
00:01:35.920 --> 00:01:39.319
<v Speaker 2>us that basic structure for thinking about any major project.

32
00:01:39.400 --> 00:01:42.680
<v Speaker 1>It's basically the waterfall approach, right, you finish one step before.

33
00:01:42.439 --> 00:01:44.680
<v Speaker 2>You move on, pretty much sequential.

34
00:01:45.040 --> 00:01:50.120
<v Speaker 1>So Phase one is that critical starting point identifying problems, opportunities,

35
00:01:50.159 --> 00:01:50.799
<v Speaker 1>and objectives.

36
00:01:50.920 --> 00:01:51.200
<v Speaker 2>Yeah.

37
00:01:51.239 --> 00:01:53.599
<v Speaker 1>You just can't afford to skip this, can you, Because

38
00:01:53.799 --> 00:01:57.079
<v Speaker 1>building the perfect solution to the wrong problem, well that's

39
00:01:57.079 --> 00:01:58.319
<v Speaker 1>just wasted effort.

40
00:01:58.159 --> 00:02:02.159
<v Speaker 2>Huge waste yearsotentially. So once you've nabled the problem, you

41
00:02:02.159 --> 00:02:05.959
<v Speaker 2>move to phase two analyzing system needs. That's all about

42
00:02:06.000 --> 00:02:10.159
<v Speaker 2>gathering the nitty gritty requirements. Then phase three designing the

43
00:02:10.159 --> 00:02:13.479
<v Speaker 2>recommended system. This is the logical design part. It's not

44
00:02:13.560 --> 00:02:17.400
<v Speaker 2>just database structures, but really critical things like user procedures,

45
00:02:17.759 --> 00:02:20.199
<v Speaker 2>how people will actually do their jobs with it, and

46
00:02:20.719 --> 00:02:22.479
<v Speaker 2>the human computer interaction.

47
00:02:22.560 --> 00:02:26.439
<v Speaker 1>HgI, how the person actually interfaces with the screen, the keyboard.

48
00:02:26.080 --> 00:02:28.560
<v Speaker 2>Everything exactly, how it feels to use, and.

49
00:02:28.560 --> 00:02:31.080
<v Speaker 1>Comes the heavy lifting phases four and five. Right.

50
00:02:31.360 --> 00:02:36.400
<v Speaker 2>Phase four developing and documenting the software, coding basically and

51
00:02:36.439 --> 00:02:40.719
<v Speaker 2>writing it all down. Phase five is testing and maintaining

52
00:02:40.719 --> 00:02:43.360
<v Speaker 2>the system, finding the bugs.

53
00:02:43.080 --> 00:02:45.800
<v Speaker 1>And then finally getting it out there six and.

54
00:02:45.719 --> 00:02:49.759
<v Speaker 2>Seven implementing the system in phase six and crucially evaluating

55
00:02:49.800 --> 00:02:54.039
<v Speaker 2>its success after launch in phase seven. Did it actually work?

56
00:02:54.319 --> 00:02:56.960
<v Speaker 2>Did it solve the problem we identified back in phase one?

57
00:02:57.120 --> 00:03:00.599
<v Speaker 1>And you mentioned this sequence, this phase definition, it's really

58
00:03:00.680 --> 00:03:02.599
<v Speaker 1>important when you look at costs over time.

59
00:03:02.680 --> 00:03:05.039
<v Speaker 2>Oh, absolutely crucial, especially when you look at the project's

60
00:03:05.039 --> 00:03:08.319
<v Speaker 2>long term cost curve. A huge mistake people make is

61
00:03:08.479 --> 00:03:10.840
<v Speaker 2>underestimating the financial hit on the back end.

62
00:03:11.000 --> 00:03:12.360
<v Speaker 1>You mean after it's launched.

63
00:03:12.719 --> 00:03:16.080
<v Speaker 2>Yeah, the sources are really clear on this. The resources

64
00:03:16.120 --> 00:03:19.919
<v Speaker 2>consumed time, money, They increase dramatically over the system's life,

65
00:03:20.159 --> 00:03:21.520
<v Speaker 2>particularly maintenance.

66
00:03:21.639 --> 00:03:25.439
<v Speaker 1>So testing catches initial bugs, but what drives those big

67
00:03:25.479 --> 00:03:26.840
<v Speaker 1>cost spikes later on?

68
00:03:27.360 --> 00:03:32.039
<v Speaker 2>Major changes? Think about it. The business evolves, technology shifts,

69
00:03:32.240 --> 00:03:36.599
<v Speaker 2>new regulations come in, the system needs significant updates years

70
00:03:36.639 --> 00:03:39.639
<v Speaker 2>down the line. Wow, And if that initial analysis and

71
00:03:39.680 --> 00:03:43.120
<v Speaker 2>documentation back in phrases one, two, three, if that was sloppy,

72
00:03:43.879 --> 00:03:47.680
<v Speaker 2>fixing or changing that system later can be exponentially more expensive.

73
00:03:47.719 --> 00:03:51.479
<v Speaker 2>Good upfront analysis is like it's your insurance policy against

74
00:03:51.479 --> 00:03:52.599
<v Speaker 2>those future cost blowouts.

75
00:03:52.599 --> 00:03:55.479
<v Speaker 1>Wow. Okay, So given that huge potential future cost, it

76
00:03:55.520 --> 00:03:58.000
<v Speaker 1>makes sense that before you even start that whole cycle

77
00:03:58.360 --> 00:04:00.240
<v Speaker 1>you need to check if it's even worth doing the

78
00:04:00.280 --> 00:04:01.840
<v Speaker 1>feasibility study Exactly.

79
00:04:02.120 --> 00:04:05.120
<v Speaker 2>Any serious project needs to pass muster in three key areas.

80
00:04:05.199 --> 00:04:08.439
<v Speaker 2>It's like a quick checklist respecting your time and resources. First,

81
00:04:08.560 --> 00:04:10.680
<v Speaker 2>technical feasibility is it possible?

82
00:04:10.840 --> 00:04:12.960
<v Speaker 1>Can we actually build this with the tech we have

83
00:04:13.439 --> 00:04:15.479
<v Speaker 1>or the tech we can realistically.

84
00:04:14.840 --> 00:04:20.560
<v Speaker 2>Get precisely hardware software expertise? Is it doable? Second economic

85
00:04:20.639 --> 00:04:24.279
<v Speaker 2>feasibility the classic cost benefit analysis.

86
00:04:24.879 --> 00:04:27.839
<v Speaker 1>Do the long term gains actually outweigh the short term

87
00:04:27.879 --> 00:04:30.360
<v Speaker 1>development costs? And here we need to look beyond just

88
00:04:30.399 --> 00:04:31.360
<v Speaker 1>the obvious stuff.

89
00:04:31.399 --> 00:04:34.560
<v Speaker 2>You mean tangible versus intangible benefits exactly.

90
00:04:34.759 --> 00:04:37.600
<v Speaker 1>Tangible benefits are easy, you save money on operations, things

91
00:04:37.720 --> 00:04:40.800
<v Speaker 1>run faster, you can count it. But the intangible benefits

92
00:04:41.160 --> 00:04:44.360
<v Speaker 1>those are often the strategic game changers, like what improving

93
00:04:44.399 --> 00:04:48.279
<v Speaker 1>decision making because reports are more accurate, enhancing the company's image,

94
00:04:48.600 --> 00:04:51.959
<v Speaker 1>boosting employee morale, maybe hard to put a dollar figure on,

95
00:04:52.160 --> 00:04:53.800
<v Speaker 1>but incredibly valuable long term.

96
00:04:53.920 --> 00:04:58.439
<v Speaker 2>Okay. And the third one, the really human one, operational feasibility.

97
00:04:58.639 --> 00:05:01.519
<v Speaker 1>And this might be the most critical ch honestly, operational

98
00:05:01.519 --> 00:05:05.759
<v Speaker 1>feasibility asks will people actually use this thing effectively once

99
00:05:05.800 --> 00:05:06.519
<v Speaker 1>it's installed?

100
00:05:07.240 --> 00:05:08.560
<v Speaker 2>It all comes down to people.

101
00:05:08.480 --> 00:05:14.639
<v Speaker 1>Entirely, human resources, office politics, organizational culture acceptance. You can

102
00:05:14.680 --> 00:05:18.199
<v Speaker 1>have the most technically perfect, budget friendly system, but if

103
00:05:18.199 --> 00:05:20.360
<v Speaker 1>the people it's meant for won't adopt it or can't

104
00:05:20.439 --> 00:05:23.920
<v Speaker 1>use it properly, it's worthless. This connects back to that

105
00:05:24.040 --> 00:05:27.879
<v Speaker 1>really interesting idea from the sources about organizational metaphors. Doesn't

106
00:05:27.920 --> 00:05:29.560
<v Speaker 1>it how the company sees itself?

107
00:05:29.639 --> 00:05:34.360
<v Speaker 2>It absolutely does. Culture gets described using these implicit metaphors. Right,

108
00:05:35.000 --> 00:05:39.160
<v Speaker 2>is your place seen as a machine, a family, maybe

109
00:05:39.199 --> 00:05:42.439
<v Speaker 2>a war zone or a jungle. The success of a

110
00:05:42.480 --> 00:05:46.680
<v Speaker 2>new system hinges massively on whether it fits those unspoken

111
00:05:46.800 --> 00:05:51.040
<v Speaker 2>rules and expectations. A highly structured system might fly in

112
00:05:51.079 --> 00:05:54.240
<v Speaker 2>a machine culture, but crash and burn in a jungle

113
00:05:54.439 --> 00:05:55.959
<v Speaker 2>where everyone's fighting.

114
00:05:55.560 --> 00:05:57.920
<v Speaker 1>For resources, regardless of how well it's coded.

115
00:05:58.000 --> 00:06:00.720
<v Speaker 2>Regardless, the analyst almost needs to be an anthropopy first,

116
00:06:00.759 --> 00:06:01.480
<v Speaker 2>then an engineer.

117
00:06:01.560 --> 00:06:04.000
<v Speaker 1>That's a huge insight. Okay, okay, So let's say we've

118
00:06:04.000 --> 00:06:08.199
<v Speaker 1>passed feasibility, especially operational, we think the system will be used.

119
00:06:08.800 --> 00:06:11.480
<v Speaker 1>How do analysts then map out the logic? This is

120
00:06:11.480 --> 00:06:13.240
<v Speaker 1>where the analysis tools come in, right.

121
00:06:13.560 --> 00:06:17.480
<v Speaker 2>Let's start with the visual approach. Data flow diagrams DSDs.

122
00:06:17.040 --> 00:06:18.279
<v Speaker 1>Pictures of data moving around.

123
00:06:18.439 --> 00:06:22.480
<v Speaker 2>Essentially, Yes, they use simple symbols to graphically show data processes,

124
00:06:22.600 --> 00:06:25.439
<v Speaker 2>where data flows, and where it's stored. They chart the

125
00:06:25.480 --> 00:06:27.279
<v Speaker 2>journey of data through a business function.

126
00:06:27.560 --> 00:06:29.839
<v Speaker 1>But why draw pictures? Why don't just write it down?

127
00:06:30.000 --> 00:06:34.319
<v Speaker 2>Ah? Because DFDs force a really important separation. They let

128
00:06:34.399 --> 00:06:38.240
<v Speaker 2>the analyst define the logical system what should happen, separately

129
00:06:38.279 --> 00:06:41.560
<v Speaker 2>from the physical system what currently happens, maybe with pay

130
00:06:41.560 --> 00:06:43.040
<v Speaker 2>per forms or old software.

131
00:06:43.399 --> 00:06:45.120
<v Speaker 1>And why is that separation so vital?

132
00:06:45.319 --> 00:06:48.480
<v Speaker 2>Because if you only analyze the current physical system, you

133
00:06:48.680 --> 00:06:53.519
<v Speaker 2>risk just automating outdated or inefficient processes. DFDs help you

134
00:06:53.639 --> 00:06:57.680
<v Speaker 2>design what should be happening, not just pave the cowpaths,

135
00:06:57.720 --> 00:06:58.319
<v Speaker 2>so to speak.

136
00:06:58.439 --> 00:07:02.000
<v Speaker 1>Got it? Design the ideal flow first, and the dfd's

137
00:07:02.040 --> 00:07:05.360
<v Speaker 1>partner is the data dictionary, making sure everyone agrees.

138
00:07:05.040 --> 00:07:07.920
<v Speaker 2>On terms precisely. Think of the data dictionary as the

139
00:07:07.959 --> 00:07:11.639
<v Speaker 2>system's definitive reference guide. It collects and coordinates all the

140
00:07:11.680 --> 00:07:15.600
<v Speaker 2>specific data terms, the metadata or data about the data.

141
00:07:15.639 --> 00:07:17.800
<v Speaker 1>So customer ID needs the same thing to marketing and

142
00:07:17.800 --> 00:07:18.879
<v Speaker 1>accounting exactly.

143
00:07:18.920 --> 00:07:23.319
<v Speaker 2>That consistency is non negotiable for complex systems, no ambiguity allowed.

144
00:07:23.399 --> 00:07:25.519
<v Speaker 1>I saw a note connecting this to web systems too,

145
00:07:25.600 --> 00:07:26.639
<v Speaker 1>specifically XML.

146
00:07:27.000 --> 00:07:31.199
<v Speaker 2>Yes, it's fundamental. The data dictionary is basically the starting

147
00:07:31.240 --> 00:07:34.879
<v Speaker 2>point for creating XML schemas. XMEL is great because it

148
00:07:34.959 --> 00:07:38.800
<v Speaker 2>stores data as plaintext, independent of any specific.

149
00:07:38.399 --> 00:07:40.600
<v Speaker 1>Software, making it easy to share right.

150
00:07:40.839 --> 00:07:44.000
<v Speaker 2>And the dictionary provides the stricture rules ensuring that data

151
00:07:44.040 --> 00:07:46.800
<v Speaker 2>is consistent and can be validated easily when it's shared

152
00:07:46.839 --> 00:07:48.600
<v Speaker 2>between different systems or platforms.

153
00:07:48.639 --> 00:07:51.839
<v Speaker 1>Okay, So DFDs show the flow. Dictionaries define the terms.

154
00:07:52.160 --> 00:07:55.160
<v Speaker 1>Now what about the actual decision points in that flow?

155
00:07:55.199 --> 00:07:59.160
<v Speaker 1>How do analysts document structured decisions, the ones that are

156
00:07:59.240 --> 00:08:03.319
<v Speaker 1>rule based, no human judgment needed, like calculating a fee.

157
00:08:03.519 --> 00:08:07.240
<v Speaker 2>There are three main ways. The simplest is probably structured.

158
00:08:06.759 --> 00:08:09.240
<v Speaker 1>English sounds like coding almost It's close.

159
00:08:09.680 --> 00:08:12.720
<v Speaker 2>You use plain English, but with standardized keywords like if

160
00:08:12.839 --> 00:08:16.839
<v Speaker 2>then elsie do, while often using indentation to show the

161
00:08:16.879 --> 00:08:19.639
<v Speaker 2>logic sequence It reads a bit like pseudocode, but.

162
00:08:19.560 --> 00:08:21.680
<v Speaker 1>I imagine that gets complicated fast if you have lots

163
00:08:21.680 --> 00:08:22.759
<v Speaker 1>of interacting conditions.

164
00:08:22.800 --> 00:08:25.600
<v Speaker 2>It really can, which is why for more complex logic

165
00:08:25.680 --> 00:08:28.639
<v Speaker 2>with many combinations of conditions and actions, we turn to

166
00:08:29.000 --> 00:08:29.879
<v Speaker 2>decision tables.

167
00:08:29.920 --> 00:08:33.120
<v Speaker 1>Tables like spreadsheets.

168
00:08:32.039 --> 00:08:35.039
<v Speaker 2>Sort of, but very structured. They force you to map

169
00:08:35.080 --> 00:08:38.519
<v Speaker 2>out every single possible combination of conditions, the rules that apply,

170
00:08:38.919 --> 00:08:43.480
<v Speaker 2>and the resulting actions. It's incredibly useful for catching contradictions

171
00:08:43.519 --> 00:08:45.279
<v Speaker 2>or impossible scenarios before they get.

172
00:08:45.120 --> 00:08:47.360
<v Speaker 1>Coded, making sure all the bases are covered.

173
00:08:47.159 --> 00:08:47.879
<v Speaker 2>Every single one.

174
00:08:47.960 --> 00:08:51.240
<v Speaker 1>And the third method decision trees. How are they different?

175
00:08:51.440 --> 00:08:54.960
<v Speaker 2>Decision trees are best when the sequence of checking conditions matters.

176
00:08:55.559 --> 00:08:58.600
<v Speaker 2>The branching structure visually shows the order you ask the

177
00:08:58.720 --> 00:09:00.240
<v Speaker 2>questions or check the condition.

178
00:09:00.759 --> 00:09:03.080
<v Speaker 1>Ah, so the path matters exactly.

179
00:09:03.600 --> 00:09:06.559
<v Speaker 2>Also, if not all conditions apply to all outcomes, meaning

180
00:09:06.600 --> 00:09:09.960
<v Speaker 2>some branches and early, a tree can be much clearer

181
00:09:10.000 --> 00:09:13.039
<v Speaker 2>and less cluttered than a huge table full of not

182
00:09:13.120 --> 00:09:14.000
<v Speaker 2>applicable cells.

183
00:09:14.080 --> 00:09:17.080
<v Speaker 1>Okay, those tools sound powerful for nailing down the logic,

184
00:09:17.679 --> 00:09:20.879
<v Speaker 1>but as effective as they are, the world realized that

185
00:09:20.919 --> 00:09:24.480
<v Speaker 1>the whole step by step waterfall thing, the classic SDLC

186
00:09:24.960 --> 00:09:28.200
<v Speaker 1>could be just too slow, too rigid for businesses needing

187
00:09:28.240 --> 00:09:29.480
<v Speaker 1>constant change.

188
00:09:29.159 --> 00:09:32.000
<v Speaker 2>And that necessity really drove a huge paradigm shift in

189
00:09:32.080 --> 00:09:36.840
<v Speaker 2>software development towards modern methods that prioritize speed, flexibility, and

190
00:09:36.919 --> 00:09:40.679
<v Speaker 2>getting constant feedback from users and the business. The big

191
00:09:40.720 --> 00:09:42.600
<v Speaker 2>one here is agile modeling.

192
00:09:42.919 --> 00:09:44.879
<v Speaker 1>Agile. We hear that word a lot, we do.

193
00:09:45.039 --> 00:09:48.399
<v Speaker 2>It's really a collection of approaches, all user centered, built

194
00:09:48.399 --> 00:09:53.399
<v Speaker 2>on four core values, communication, simplicity, feedback, and courage.

195
00:09:53.519 --> 00:09:56.320
<v Speaker 1>So instead of a giant upfront plan, it works in

196
00:09:56.360 --> 00:09:57.519
<v Speaker 1>shorter cycles.

197
00:09:57.360 --> 00:10:01.519
<v Speaker 2>Exactly short development cycles often called prints, maybe two to

198
00:10:01.559 --> 00:10:05.279
<v Speaker 2>four weeks. And the plan isn't some fixed document, it's

199
00:10:05.320 --> 00:10:10.000
<v Speaker 2>a dynamic product backlog, a prioritized wishless pretty much a

200
00:10:10.080 --> 00:10:13.600
<v Speaker 2>list of features constantly reprioritized based on what brings the

201
00:10:13.600 --> 00:10:16.960
<v Speaker 2>most business value right now. Teams even use techniques like

202
00:10:17.000 --> 00:10:19.399
<v Speaker 2>scrum planning poker to estimate task effort.

203
00:10:19.480 --> 00:10:23.559
<v Speaker 1>Collaboratively planning poker sounds fun, but how do managers keep

204
00:10:23.600 --> 00:10:26.360
<v Speaker 1>track if things are changing so fast? Doesn't they get chaotic?

205
00:10:26.639 --> 00:10:29.399
<v Speaker 2>You'd think so, but it's actually quite controlled thanks to

206
00:10:29.440 --> 00:10:30.720
<v Speaker 2>tools like the burn down chart.

207
00:10:31.039 --> 00:10:31.480
<v Speaker 1>What's up?

208
00:10:31.559 --> 00:10:34.440
<v Speaker 2>It's a simple graph, really key in agile. It plots

209
00:10:34.480 --> 00:10:36.799
<v Speaker 2>the amount of work left to do, maybe in hours,

210
00:10:36.879 --> 00:10:39.279
<v Speaker 2>maybe in tasks, against the time remaining in the.

211
00:10:39.279 --> 00:10:42.039
<v Speaker 1>Sprint, so you see progress visually instantly.

212
00:10:42.279 --> 00:10:45.279
<v Speaker 2>If the line's dropping steadily, you're on track. If it

213
00:10:45.320 --> 00:10:47.840
<v Speaker 2>flattens out, the team knows immediately they need to figure

214
00:10:47.840 --> 00:10:51.639
<v Speaker 2>out what's wrong and adjust. It provides that crucial constant

215
00:10:51.720 --> 00:10:52.840
<v Speaker 2>feedback loop.

216
00:10:52.720 --> 00:10:56.080
<v Speaker 1>And that focus on feedback naturally leads to thinking more

217
00:10:56.120 --> 00:10:57.840
<v Speaker 1>about the user experience, doesn't it.

218
00:10:57.960 --> 00:11:02.440
<v Speaker 2>UX design absolutely, UX is a one is explicitly customer first.

219
00:11:02.759 --> 00:11:06.000
<v Speaker 2>It's all about observing how people actually behave when using

220
00:11:06.039 --> 00:11:09.240
<v Speaker 2>a product or service, and then designing to make that

221
00:11:09.320 --> 00:11:12.000
<v Speaker 2>experience better to boost satisfaction and loyalty.

222
00:11:12.279 --> 00:11:14.519
<v Speaker 1>And the strategy is sometimes counterintuitive.

223
00:11:14.720 --> 00:11:18.440
<v Speaker 2>It can be Prioritizing a great experience might mean not

224
00:11:18.759 --> 00:11:22.039
<v Speaker 2>maximizing profit on every single interaction because you know that

225
00:11:22.159 --> 00:11:25.360
<v Speaker 2>long term loyalty derived from a good experience is strategically

226
00:11:25.360 --> 00:11:25.879
<v Speaker 2>worth more.

227
00:11:26.279 --> 00:11:28.559
<v Speaker 1>And part of that experience today means dealing with all

228
00:11:28.600 --> 00:11:30.279
<v Speaker 1>the different devices people use. Oh.

229
00:11:30.320 --> 00:11:34.000
<v Speaker 2>Definitely, Responsive web design RWUD is a huge part of

230
00:11:34.080 --> 00:11:37.480
<v Speaker 2>modern UX. It's about making sure your website or application

231
00:11:37.679 --> 00:11:40.399
<v Speaker 2>adapts and displays content properly, no matter.

232
00:11:40.159 --> 00:11:42.799
<v Speaker 1>What device is used, phone, tablet, desktop, Right.

233
00:11:42.919 --> 00:11:46.600
<v Speaker 2>It doesn't just shrink the page. It intelligently reorganizes the

234
00:11:46.639 --> 00:11:49.000
<v Speaker 2>content to fit the screen and be easy to use

235
00:11:49.399 --> 00:11:51.200
<v Speaker 2>wherever the user happens to be.

236
00:11:51.480 --> 00:11:54.960
<v Speaker 1>Now, getting this speed, this user focus, it requires more

237
00:11:55.000 --> 00:11:57.759
<v Speaker 1>than just new tools. It needs a cultural shift too,

238
00:11:58.320 --> 00:12:00.000
<v Speaker 1>which brings us to DevOps.

239
00:12:00.320 --> 00:12:04.320
<v Speaker 2>Yeah. DevOps short for development and operations. It's really the

240
00:12:04.360 --> 00:12:07.720
<v Speaker 2>cultural shift needed to make agile work smoothly, especially in

241
00:12:07.840 --> 00:12:09.000
<v Speaker 2>larger organizations.

242
00:12:09.120 --> 00:12:10.240
<v Speaker 1>What problem does it solve?

243
00:12:10.399 --> 00:12:13.879
<v Speaker 2>It tackles that classic friction point. You have developers pushing

244
00:12:13.919 --> 00:12:17.240
<v Speaker 2>for rapid innovation, new features all the time, and you

245
00:12:17.320 --> 00:12:22.360
<v Speaker 2>have operations folks focused on keeping things stable monitoring systems. Historically,

246
00:12:22.360 --> 00:12:25.080
<v Speaker 2>they often ended up pointing fingers when something broke right.

247
00:12:25.159 --> 00:12:26.279
<v Speaker 1>Whose fault is the bug?

248
00:12:26.559 --> 00:12:29.320
<v Speaker 2>DevOps tries to break down that wall. It fosters a

249
00:12:29.360 --> 00:12:33.000
<v Speaker 2>culture where development and operations work in close collaboration, often

250
00:12:33.000 --> 00:12:37.320
<v Speaker 2>on parallel tracks. DEV focuses on rapid releases. Ops focuses

251
00:12:37.360 --> 00:12:39.759
<v Speaker 2>on continuous monitoring and maintenance.

252
00:12:39.320 --> 00:12:42.080
<v Speaker 1>Of what's live, so they work together instead of against

253
00:12:42.120 --> 00:12:42.480
<v Speaker 1>each other.

254
00:12:42.559 --> 00:12:45.440
<v Speaker 2>Yeah, that's the goal. It prevents delays caused by arguments

255
00:12:45.440 --> 00:12:49.759
<v Speaker 2>over responsibility and lets the organization innovate quickly while maintaining stability.

256
00:12:49.759 --> 00:12:50.879
<v Speaker 2>It's a cultural alignment.

257
00:12:50.919 --> 00:12:54.240
<v Speaker 1>Okay, so we have faster, user focused systems built with

258
00:12:54.440 --> 00:12:58.559
<v Speaker 1>agile and DevOps. Powerful stuff, but it only works if

259
00:12:58.559 --> 00:13:03.159
<v Speaker 1>it's reliable. Talk quality assurance. How do analysts make sure

260
00:13:03.279 --> 00:13:06.279
<v Speaker 1>qualities baked in? Especially with these faster cycles.

261
00:13:06.480 --> 00:13:09.480
<v Speaker 2>Quality can't be an afterthought. It has to be continuous.

262
00:13:10.000 --> 00:13:13.840
<v Speaker 2>One really influential idea analysts often borrow is six sigmas.

263
00:13:13.840 --> 00:13:15.799
<v Speaker 1>I've heard of that, very rigorous.

264
00:13:15.559 --> 00:13:19.440
<v Speaker 2>Incredibly, it sets an extremely high bar for quality. The

265
00:13:19.480 --> 00:13:23.120
<v Speaker 2>statistical goal is essentially to eliminate almost all defects, aiming

266
00:13:23.159 --> 00:13:26.679
<v Speaker 2>for no more than three point four defects per million opportunities.

267
00:13:26.799 --> 00:13:29.039
<v Speaker 1>Wow, And how do you catch errors before they get

268
00:13:29.039 --> 00:13:30.759
<v Speaker 1>anywhere near that stage? Peer review?

269
00:13:30.919 --> 00:13:34.600
<v Speaker 2>Yes, systematic peer review through things like structured walkthroughs. It's

270
00:13:34.639 --> 00:13:37.080
<v Speaker 2>not just casual feedback. It's a routine process.

271
00:13:37.159 --> 00:13:37.759
<v Speaker 1>How does it work.

272
00:13:37.919 --> 00:13:40.039
<v Speaker 2>You have a small team, maybe the analyst who did

273
00:13:40.080 --> 00:13:42.440
<v Speaker 2>the work, a coordinator, and a couple of peers. They

274
00:13:42.480 --> 00:13:45.840
<v Speaker 2>methodically walk through the design, the code, whatever the artifact

275
00:13:45.919 --> 00:13:49.840
<v Speaker 2>is looking for problems, catching them early, exactly, catching them

276
00:13:49.840 --> 00:13:52.480
<v Speaker 2>when they're cheap and easy to fix, not after the

277
00:13:52.480 --> 00:13:55.399
<v Speaker 2>system is deployed and a failure could be catastrophic.

278
00:13:55.840 --> 00:14:00.000
<v Speaker 1>Makes sense beyond just defects. What about managing the project

279
00:14:00.159 --> 00:14:04.600
<v Speaker 1>timeline itself, especially for really big projects. How do analysts

280
00:14:04.720 --> 00:14:05.840
<v Speaker 1>keep things on schedule?

281
00:14:06.200 --> 00:14:09.799
<v Speaker 2>For complex projects with lots of moving parts, tools like

282
00:14:09.919 --> 00:14:13.720
<v Speaker 2>per program evaluation and review technique are essential.

283
00:14:13.840 --> 00:14:14.559
<v Speaker 1>What is pro doue?

284
00:14:14.960 --> 00:14:17.559
<v Speaker 2>It helps you map out all the project activities, figure

285
00:14:17.600 --> 00:14:20.360
<v Speaker 2>out how long each will take, and understand the dependencies

286
00:14:20.360 --> 00:14:23.399
<v Speaker 2>between them. But its real power comes from identifying the

287
00:14:23.440 --> 00:14:24.120
<v Speaker 2>critical path.

288
00:14:24.279 --> 00:14:26.639
<v Speaker 1>The critical path Okay, what exactly.

289
00:14:26.279 --> 00:14:29.720
<v Speaker 2>Is that it's the longest sequence of dependent activities from

290
00:14:29.759 --> 00:14:32.240
<v Speaker 2>the start of the project to the end. Because it's

291
00:14:32.279 --> 00:14:35.480
<v Speaker 2>the longest chain, any delay in any task on that

292
00:14:35.559 --> 00:14:38.039
<v Speaker 2>path will delay the entire project's completion date.

293
00:14:38.240 --> 00:14:41.200
<v Speaker 1>Ah, so that's the chain you absolutely cannot let slip.

294
00:14:41.200 --> 00:14:43.759
<v Speaker 2>Precisely, if you lose a day on the critical path,

295
00:14:43.879 --> 00:14:46.399
<v Speaker 2>the whole project is a day late. Managers have to

296
00:14:46.399 --> 00:14:49.879
<v Speaker 2>watch those critical path tasks like hawks, sometimes even letting

297
00:14:49.919 --> 00:14:53.279
<v Speaker 2>less critical tasks slide if necessary to keep the main

298
00:14:53.360 --> 00:14:54.320
<v Speaker 2>sequence on track.

299
00:14:54.639 --> 00:14:58.720
<v Speaker 1>Okay, that's crucial for control. Finally, let's look ahead of

300
00:14:58.720 --> 00:15:03.399
<v Speaker 1>it systems are getting bigger data is exploding. What emerging

301
00:15:03.480 --> 00:15:05.720
<v Speaker 1>concepts are analysts grappling with now?

302
00:15:06.039 --> 00:15:08.399
<v Speaker 2>Two big data concepts really stand out.

303
00:15:08.519 --> 00:15:11.759
<v Speaker 1>First, data mining, digging through data for insights.

304
00:15:11.919 --> 00:15:15.960
<v Speaker 2>Basically yes, it operates on the assumption that past behavior

305
00:15:16.120 --> 00:15:19.080
<v Speaker 2>is the best predictor of future behavior. Companies use it

306
00:15:19.120 --> 00:15:23.759
<v Speaker 2>to analyze massive databases, credit card transactions, social media activity,

307
00:15:23.879 --> 00:15:24.639
<v Speaker 2>website clicks.

308
00:15:24.679 --> 00:15:26.480
<v Speaker 1>Could predict what customers will do next and.

309
00:15:26.440 --> 00:15:30.000
<v Speaker 2>Target them much more effectively, turning huge data stores into

310
00:15:30.039 --> 00:15:34.440
<v Speaker 2>potential profit by understanding patterns and predicting future purchases or

311
00:15:34.480 --> 00:15:36.360
<v Speaker 2>actions with startling accuracy.

312
00:15:36.480 --> 00:15:39.360
<v Speaker 1>And the second big one blockchains, which are more than

313
00:15:39.360 --> 00:15:41.000
<v Speaker 1>just cryptocurrency.

314
00:15:40.320 --> 00:15:44.480
<v Speaker 2>Right, oh, much more Fundamentally, a blockchain is an open,

315
00:15:44.840 --> 00:15:49.440
<v Speaker 2>unchangeable record of transactions, essentially a distributed database shared among

316
00:15:49.519 --> 00:15:50.120
<v Speaker 2>many parties.

317
00:15:50.240 --> 00:15:50.919
<v Speaker 1>What's the benefit?

318
00:15:51.200 --> 00:15:55.519
<v Speaker 2>Improve security, reduced risk, better efficiency, Think supply chains. Everyone

319
00:15:55.559 --> 00:15:58.799
<v Speaker 2>involved can see the same trusted, verified ledger of where

320
00:15:58.840 --> 00:16:02.320
<v Speaker 2>goods are, who did what? But when? No single point

321
00:16:02.320 --> 00:16:03.360
<v Speaker 2>of failure or control.

322
00:16:03.480 --> 00:16:04.840
<v Speaker 1>But there's a catch there is.

323
00:16:05.159 --> 00:16:10.039
<v Speaker 2>The biggest barrier often isn't technical, it's organizational trust. Getting

324
00:16:10.200 --> 00:16:15.120
<v Speaker 2>large organizations used to centralized control to trust and rely

325
00:16:15.320 --> 00:16:20.000
<v Speaker 2>on a decentralized, transparent shared record that requires a significant

326
00:16:20.000 --> 00:16:23.440
<v Speaker 2>shift in mindset and challenges established power structures.

327
00:16:23.480 --> 00:16:26.000
<v Speaker 1>Fascinating. Wow, Okay, that was quite a journey. We went

328
00:16:26.039 --> 00:16:30.320
<v Speaker 1>from the the rigid blue prints of the classic SELC.

329
00:16:30.320 --> 00:16:33.480
<v Speaker 2>Right through the speed and flexibility of agile and the

330
00:16:33.519 --> 00:16:35.600
<v Speaker 2>cultural shift of DevOps.

331
00:16:35.320 --> 00:16:39.080
<v Speaker 1>Touched on those deep analysis tools like DFDs and decision tables,

332
00:16:39.120 --> 00:16:39.519
<v Speaker 1>and ended.

333
00:16:39.480 --> 00:16:41.799
<v Speaker 2>Up right at the edge with data mining and blockchains.

334
00:16:42.000 --> 00:16:45.679
<v Speaker 1>It really underscores how strategic the analyst role is. Yeah,

335
00:16:45.720 --> 00:16:48.360
<v Speaker 1>you need that foundational knowledge, but also the agility to.

336
00:16:48.360 --> 00:16:52.799
<v Speaker 2>Adapt, absolutely respecting the sdlc's structure while fully embracing modern

337
00:16:52.840 --> 00:16:55.600
<v Speaker 2>speed and user focus. And we saw how quality, whether

338
00:16:55.679 --> 00:16:58.519
<v Speaker 2>through sixing the discipline or carefully managing that critical path

339
00:16:58.840 --> 00:17:00.159
<v Speaker 2>is just completely non negot.

340
00:17:00.399 --> 00:17:02.639
<v Speaker 1>And that thread running through it all, the human element

341
00:17:02.720 --> 00:17:06.039
<v Speaker 1>kept popping up, operational feasibility, Will people use it?

342
00:17:06.039 --> 00:17:09.759
<v Speaker 2>It's often the ultimate decider and that connection to organizational culture,

343
00:17:09.880 --> 00:17:13.640
<v Speaker 2>those metaphors machine family war zone.

344
00:17:13.759 --> 00:17:17.559
<v Speaker 1>It determines whether a technically perfect system actually succeeds in

345
00:17:17.559 --> 00:17:18.559
<v Speaker 1>the real world.

346
00:17:18.680 --> 00:17:22.240
<v Speaker 2>That cultural fit. Maybe that's the real critical path. Sometimes

347
00:17:22.640 --> 00:17:25.799
<v Speaker 2>a brilliant system designed for machine culture will just break.

348
00:17:26.200 --> 00:17:29.200
<v Speaker 2>If you drop it into a jungle environment, the design

349
00:17:29.279 --> 00:17:32.240
<v Speaker 2>has to mesh with those unspoken rules and expectations.

350
00:17:32.519 --> 00:17:35.440
<v Speaker 1>So here's something provocative for you, our listener, to think

351
00:17:35.480 --> 00:17:38.920
<v Speaker 1>about after this deep dive. Consider that idea of organizational

352
00:17:39.000 --> 00:17:43.359
<v Speaker 1>culture as a metaphor, which one machine family, jungle war zone,

353
00:17:43.759 --> 00:17:47.160
<v Speaker 1>something else, which one really feels like your organization? And

354
00:17:47.200 --> 00:17:50.160
<v Speaker 1>how does that unique culture shape the systems you use

355
00:17:50.200 --> 00:17:52.319
<v Speaker 1>every day or the ones you might be thinking about

356
00:17:52.319 --> 00:17:56.359
<v Speaker 1>building or adopting next. That alignment, that sweet spot between

357
00:17:56.440 --> 00:18:00.440
<v Speaker 1>the code and the culture, that's where true operational fees, ability,

358
00:18:00.799 --> 00:18:03.279
<v Speaker 1>and ultimately success is really found.

359
00:18:03.400 --> 00:18:05.720
<v Speaker 2>Great point until next time, Keep analyzing those

360
00:18:05.720 --> 00:18:07.160
<v Speaker 1>Systems and keep diving deep