WEBVTT

1
00:00:00.080 --> 00:00:02.520
<v Speaker 1>Welcome back to the deep dive. If you've ever looked

2
00:00:02.520 --> 00:00:05.040
<v Speaker 1>at a big tech project and kind of wondered, how

3
00:00:05.040 --> 00:00:07.679
<v Speaker 1>do they actually go from just a vague idea to

4
00:00:08.800 --> 00:00:12.000
<v Speaker 1>working software, Well, this deep dive is definitely for you.

5
00:00:12.519 --> 00:00:16.600
<v Speaker 1>We're pulling apart the blueprint Systems Analysis and Design SAD

6
00:00:16.800 --> 00:00:22.039
<v Speaker 1>and its roadmap, the systems development life cycle or SDLC exactly.

7
00:00:22.160 --> 00:00:26.160
<v Speaker 2>And when we talk it information technology, it's really more

8
00:00:26.199 --> 00:00:28.440
<v Speaker 2>than just software, right. It's the hardware, the software, the

9
00:00:28.480 --> 00:00:32.520
<v Speaker 2>service is all working together managing information sharing it. Our

10
00:00:32.560 --> 00:00:35.719
<v Speaker 2>focus today isn't the nitty gritty coding details. It's the

11
00:00:35.759 --> 00:00:38.840
<v Speaker 2>framework itself, the thing that decides if a project sinks

12
00:00:38.880 --> 00:00:41.640
<v Speaker 2>or swims, often way before anyone writes a single line

13
00:00:41.640 --> 00:00:42.079
<v Speaker 2>of code.

14
00:00:42.119 --> 00:00:44.159
<v Speaker 1>We want to give you that shortcut to understanding the

15
00:00:44.159 --> 00:00:47.600
<v Speaker 1>big strategic choices that really impact the budget and frankly,

16
00:00:47.679 --> 00:00:49.600
<v Speaker 1>whether the systems even useful long term.

17
00:00:49.640 --> 00:00:51.960
<v Speaker 2>And we're zeroing in on those five main phases of

18
00:00:52.000 --> 00:00:57.200
<v Speaker 2>the SDLC planning, analysis, design, implementation, and then support and security.

19
00:00:57.359 --> 00:01:00.320
<v Speaker 1>We'll look at what each phase delivers and importantly, how

20
00:01:00.359 --> 00:01:03.439
<v Speaker 1>those very early decisions connect to the total cost of

21
00:01:03.439 --> 00:01:06.920
<v Speaker 1>ownership down the line. Okay, so let's lay out the

22
00:01:06.920 --> 00:01:10.079
<v Speaker 1>basic structure. First, we've got these five phases and each

23
00:01:10.120 --> 00:01:12.879
<v Speaker 1>one produces something tangible, right, a deliverable.

24
00:01:13.079 --> 00:01:16.000
<v Speaker 2>That's right. It's a formal process, a cycle. You start

25
00:01:16.040 --> 00:01:20.000
<v Speaker 2>with Phase one systems planning. The output that's the Polmary

26
00:01:20.079 --> 00:01:22.599
<v Speaker 2>investigation report, kind of the first assessment.

27
00:01:22.159 --> 00:01:23.159
<v Speaker 1>Got it initial look.

28
00:01:23.359 --> 00:01:25.840
<v Speaker 2>Then you move into Phase two systems analysis. This is

29
00:01:25.840 --> 00:01:27.400
<v Speaker 2>where you figure out what the system needs to do,

30
00:01:27.640 --> 00:01:30.079
<v Speaker 2>all captured in the system requirements document.

31
00:01:30.400 --> 00:01:33.079
<v Speaker 1>That sounds incredibly important. The requirement stock.

32
00:01:33.239 --> 00:01:35.400
<v Speaker 2>Oh, it's the absolute foundation. Everything builds on that. It

33
00:01:35.439 --> 00:01:39.079
<v Speaker 2>feeds directly into Phase three systems design. Now we're talking

34
00:01:39.120 --> 00:01:42.359
<v Speaker 2>how how's it built? The architecture databases.

35
00:01:41.879 --> 00:01:44.280
<v Speaker 1>Interphases and that's documented to YEP.

36
00:01:44.079 --> 00:01:49.920
<v Speaker 2>In the system design specification. Then Phase four is systems implementation, building, testing,

37
00:01:50.040 --> 00:01:53.519
<v Speaker 2>installing it. The deliverable is the actual functioning system. And

38
00:01:53.599 --> 00:01:58.200
<v Speaker 2>finally Phase five systems support insecurity. This is about keeping

39
00:01:58.200 --> 00:02:00.159
<v Speaker 2>it running, keeping it secure, making sure you have a

40
00:02:00.159 --> 00:02:03.120
<v Speaker 2>fully operational system for well, hopefully years.

41
00:02:03.159 --> 00:02:07.200
<v Speaker 1>Okay, so that's the framework, but within that, teams approach

42
00:02:07.239 --> 00:02:11.479
<v Speaker 1>the actual building Differently. There are what three main methodologies

43
00:02:11.680 --> 00:02:13.639
<v Speaker 1>for how they handled data and process.

44
00:02:13.919 --> 00:02:18.400
<v Speaker 2>Broadly speaking, yes. Historically the starting point was structured analysis.

45
00:02:18.879 --> 00:02:21.879
<v Speaker 2>The key thing here is processes and data treated as

46
00:02:21.919 --> 00:02:25.599
<v Speaker 2>totally separate things. You model them independently, hmmm.

47
00:02:25.879 --> 00:02:28.759
<v Speaker 1>Which feels a little unnatural. I mean, in the real world,

48
00:02:29.039 --> 00:02:31.120
<v Speaker 1>data and what you do with it seem linked.

49
00:02:31.439 --> 00:02:35.639
<v Speaker 2>Exactly. That realization led to object oriented analysis or ooh.

50
00:02:36.520 --> 00:02:39.360
<v Speaker 2>This approach bundles data and the actions on that data

51
00:02:39.400 --> 00:02:43.039
<v Speaker 2>together into these things called objects objects, right, And the

52
00:02:43.039 --> 00:02:45.680
<v Speaker 2>real power isn't just the fancy terms like objects having

53
00:02:45.719 --> 00:02:49.599
<v Speaker 2>properties or sending messages. It's about reuse. If you model say,

54
00:02:49.759 --> 00:02:53.159
<v Speaker 2>customer order as an object, you can potentially reuse that

55
00:02:53.199 --> 00:02:54.560
<v Speaker 2>whole chunk of logic elsewhere.

56
00:02:54.599 --> 00:02:56.879
<v Speaker 1>Ah. So it cuts down on future work, reduces that

57
00:02:56.960 --> 00:02:57.680
<v Speaker 1>long term.

58
00:02:57.439 --> 00:03:01.199
<v Speaker 2>Cost precisely, it helps manage complex city and can lower

59
00:03:01.280 --> 00:03:05.000
<v Speaker 2>the TCO from the start by making bits interchangeable. And

60
00:03:05.039 --> 00:03:08.280
<v Speaker 2>then there's the approach everyone's talking about now, agile methods.

61
00:03:08.159 --> 00:03:12.199
<v Speaker 1>Angel Yeah, less of a strict waterfall, more iterative exactly.

62
00:03:12.439 --> 00:03:16.199
<v Speaker 2>It uses a rapid incremental, almost spiral model. You build

63
00:03:16.240 --> 00:03:19.280
<v Speaker 2>working pieces quickly, maybe in two week sprints, and you're

64
00:03:19.319 --> 00:03:21.800
<v Speaker 2>constantly tweaking based on user feedback.

65
00:03:21.840 --> 00:03:24.919
<v Speaker 1>So the big advantage of agile is it tackles changing

66
00:03:24.960 --> 00:03:28.000
<v Speaker 1>requirements head on. It sort of expects things to change.

67
00:03:28.080 --> 00:03:30.840
<v Speaker 2>It's designed for that. It assumes the initial requirements won't

68
00:03:30.879 --> 00:03:34.479
<v Speaker 2>be perfectly stable. It builds in that flexibility, reducing the

69
00:03:34.560 --> 00:03:37.080
<v Speaker 2>risk of building something obsolete the day it launches.

70
00:03:37.400 --> 00:03:41.159
<v Speaker 1>Okay, So, whether using structured O or agile, it all

71
00:03:41.240 --> 00:03:44.080
<v Speaker 1>kicks off with the system's request. Right, someone identifies a

72
00:03:44.080 --> 00:03:45.000
<v Speaker 1>problem or a need.

73
00:03:45.240 --> 00:03:48.319
<v Speaker 2>Yes, but just saying we need a new system isn't enough.

74
00:03:48.360 --> 00:03:51.240
<v Speaker 2>You need a solid business case, the justification, why are

75
00:03:51.280 --> 00:03:51.759
<v Speaker 2>we doing this?

76
00:03:51.960 --> 00:03:54.800
<v Speaker 1>And what usually drives that request? What are the common reasons?

77
00:03:55.039 --> 00:03:58.360
<v Speaker 2>Well, they're usually about six main drivers we see. First,

78
00:03:58.599 --> 00:04:03.360
<v Speaker 2>needing stronger controls, better security, maybe compliance. Second pretty common,

79
00:04:03.520 --> 00:04:08.439
<v Speaker 2>reduce cost automation efficiency makes sense. Third, needing more information,

80
00:04:08.879 --> 00:04:13.080
<v Speaker 2>better reporting insights from managers. Fourth and fifth often relate

81
00:04:13.120 --> 00:04:18.560
<v Speaker 2>to existing systems, maybe lacking flexibility or just being difficult to.

82
00:04:18.519 --> 00:04:20.279
<v Speaker 1>Learn old clunky systems.

83
00:04:20.399 --> 00:04:23.800
<v Speaker 2>Yeah, and finally, sometimes it's needed to meet a bigger

84
00:04:23.839 --> 00:04:25.360
<v Speaker 2>strategic goal for the whole company.

85
00:04:25.600 --> 00:04:28.879
<v Speaker 1>So once you have that driver, that business case, you

86
00:04:29.000 --> 00:04:33.959
<v Speaker 1>head a crucial checkpoint, the feasibility study before spending real money.

87
00:04:33.959 --> 00:04:36.000
<v Speaker 2>Absolutely, you have check if it's even viable. We look

88
00:04:36.040 --> 00:04:40.560
<v Speaker 2>at it from four angles, operational, technical, schedule, and economic feasibility.

89
00:04:40.720 --> 00:04:44.120
<v Speaker 1>Operational feasibility, That one sounds a bit fuzzy, like will

90
00:04:44.160 --> 00:04:45.959
<v Speaker 1>people use it? How do you actually measure that? Isn't

91
00:04:46.000 --> 00:04:46.720
<v Speaker 1>it just a feeling?

92
00:04:46.839 --> 00:04:49.240
<v Speaker 2>It shouldn't be just a feeling. It needs a proper

93
00:04:49.240 --> 00:04:52.839
<v Speaker 2>assessment of the organizational culture. Will it fit how people

94
00:04:52.879 --> 00:04:56.399
<v Speaker 2>actually work? You maysure it by talking to users, looking

95
00:04:56.439 --> 00:04:58.519
<v Speaker 2>at training needs, seeing if it's too disruptive.

96
00:04:58.680 --> 00:05:01.000
<v Speaker 1>Okay, so it's about the humans definitely.

97
00:05:01.120 --> 00:05:04.360
<v Speaker 2>Technical feasibility is more straightforward. Do we have the tech,

98
00:05:04.959 --> 00:05:09.360
<v Speaker 2>the hardware, software, the right people, schedule feasibility, can we

99
00:05:09.439 --> 00:05:11.519
<v Speaker 2>realistically do it in the proposed timeframe?

100
00:05:11.600 --> 00:05:15.160
<v Speaker 1>And then the big one economic feasibility, Do the benefits

101
00:05:15.199 --> 00:05:18.519
<v Speaker 1>outweigh the costs? Which brings us straight to total cost

102
00:05:18.560 --> 00:05:19.920
<v Speaker 1>of ownership TCO.

103
00:05:20.439 --> 00:05:23.800
<v Speaker 2>TCO is absolutely central here and it's where estimates often

104
00:05:23.839 --> 00:05:27.959
<v Speaker 2>go wrong. You have to look beyond the initial purchase price.

105
00:05:27.879 --> 00:05:29.399
<v Speaker 1>Right, not just the sticker price.

106
00:05:29.519 --> 00:05:32.560
<v Speaker 2>No, you need to include the indirect costs user support,

107
00:05:32.720 --> 00:05:37.560
<v Speaker 2>ongoing training, system admin time, and critically lost productivity if

108
00:05:37.560 --> 00:05:40.319
<v Speaker 2>the system goes down or is just poorly designed. If

109
00:05:40.319 --> 00:05:43.399
<v Speaker 2>you ignore those, your economic case is basically fiction.

110
00:05:43.879 --> 00:05:46.120
<v Speaker 1>We see lots of talk about moving legacy stuff to

111
00:05:46.160 --> 00:05:48.759
<v Speaker 1>the cloud to cut TCO. Does that generally work out?

112
00:05:48.920 --> 00:05:52.319
<v Speaker 2>It often does, yeah, because you shift from big upfront

113
00:05:52.319 --> 00:05:55.399
<v Speaker 2>capital costs to ongoing operational costs pay as you go.

114
00:05:55.839 --> 00:05:58.839
<v Speaker 2>But there's a hidden TCO risk there too, vendor lock.

115
00:05:58.639 --> 00:06:01.519
<v Speaker 1>In getting stuff with one provider exactly.

116
00:06:01.720 --> 00:06:04.240
<v Speaker 2>You might save on hardware, but now you're dependent on

117
00:06:04.279 --> 00:06:07.360
<v Speaker 2>their pricing, their service levels. If you haven't planned an

118
00:06:07.360 --> 00:06:10.920
<v Speaker 2>exit strategy or maybe a multi cloud approach, those long

119
00:06:11.000 --> 00:06:13.000
<v Speaker 2>term costs could creep up unexpectedly.

120
00:06:13.279 --> 00:06:15.560
<v Speaker 1>All right, So let's say the project looks feasible. Now

121
00:06:15.600 --> 00:06:19.319
<v Speaker 1>we dive deep into analysis figuring out precisely what this

122
00:06:19.360 --> 00:06:22.279
<v Speaker 1>thing needs to do. We need good requirements.

123
00:06:22.000 --> 00:06:25.920
<v Speaker 2>And good means three things. They have to be valid,

124
00:06:26.680 --> 00:06:33.439
<v Speaker 2>actually support what the business needs, consistent, no contradictions, and complete,

125
00:06:33.720 --> 00:06:34.639
<v Speaker 2>nothing major missed.

126
00:06:34.720 --> 00:06:36.519
<v Speaker 1>Easier said than done, I imagine.

127
00:06:36.160 --> 00:06:38.480
<v Speaker 2>Oh absolutely. This is where you run into the classic

128
00:06:38.480 --> 00:06:41.480
<v Speaker 2>problem of feature creep. Requirements just keep expanding or changing

129
00:06:41.519 --> 00:06:43.959
<v Speaker 2>after you've already started building. It's probably the number one

130
00:06:44.079 --> 00:06:46.079
<v Speaker 2>killer of project schedules and budgets.

131
00:06:46.199 --> 00:06:48.879
<v Speaker 1>Feature creep. Yeah, I remember one project. The system was

132
00:06:48.879 --> 00:06:51.759
<v Speaker 1>almost done, then suddenly a senior manager decides it needs

133
00:06:51.759 --> 00:06:55.000
<v Speaker 1>to integrate with some obscure custom labeling machine no I

134
00:06:55.120 --> 00:06:55.800
<v Speaker 1>mentioned before.

135
00:06:56.079 --> 00:06:59.240
<v Speaker 2>That's a perfect painful example. It highlights why fact finding

136
00:06:59.279 --> 00:07:03.040
<v Speaker 2>is so crucial. When analysts do interviews, they can't just

137
00:07:03.120 --> 00:07:06.480
<v Speaker 2>ask what they need to ask. Why get to those

138
00:07:06.560 --> 00:07:07.560
<v Speaker 2>hidden assumptions.

139
00:07:08.480 --> 00:07:11.720
<v Speaker 1>Engaged listening is key, and sometimes you just need to

140
00:07:11.720 --> 00:07:12.680
<v Speaker 1>watch people work.

141
00:07:12.959 --> 00:07:15.399
<v Speaker 2>Observation yes, but you have to be aware of the

142
00:07:15.439 --> 00:07:19.000
<v Speaker 2>Hawthorn effect. People act differently when they know they're being watched.

143
00:07:19.120 --> 00:07:21.839
<v Speaker 1>Right, they might follow the official process perfectly for you,

144
00:07:21.879 --> 00:07:23.480
<v Speaker 1>but that's not how they usually do it.

145
00:07:23.759 --> 00:07:27.160
<v Speaker 2>Exactly, so you might need multiple observations, maybe compare the

146
00:07:27.199 --> 00:07:30.360
<v Speaker 2>official way with how things actually get done day to day.

147
00:07:30.720 --> 00:07:34.560
<v Speaker 2>We also use sampling, collecting actual documents, maybe systematically, like

148
00:07:34.680 --> 00:07:38.439
<v Speaker 2>grabbing every tenth invoice to get unbiased data and to.

149
00:07:38.439 --> 00:07:40.680
<v Speaker 1>Fight that future creep and get everyone on the same

150
00:07:40.720 --> 00:07:41.319
<v Speaker 1>page early.

151
00:07:41.399 --> 00:07:45.120
<v Speaker 2>There's JD Joint Application Development. Yeah. JD's sessions are great.

152
00:07:45.240 --> 00:07:48.680
<v Speaker 2>You lock users, managers, IT folks in a room together

153
00:07:49.000 --> 00:07:51.000
<v Speaker 2>to hammer out the requirements collaboratively.

154
00:07:51.279 --> 00:07:53.240
<v Speaker 1>The big win there is user buy in.

155
00:07:53.720 --> 00:07:57.079
<v Speaker 2>Huge win. IT fosters a real sense of user ownership.

156
00:07:57.680 --> 00:08:00.839
<v Speaker 2>If they help define the requirements, it's less likely to

157
00:08:00.920 --> 00:08:04.439
<v Speaker 2>complain or demand big changes later. It de risks the

158
00:08:04.480 --> 00:08:06.240
<v Speaker 2>whole requirements phase significantly.

159
00:08:06.360 --> 00:08:08.480
<v Speaker 1>Okay, so you gather all this info, how do you

160
00:08:08.480 --> 00:08:11.279
<v Speaker 1>make sense of it turn it into something usable for design?

161
00:08:11.399 --> 00:08:13.160
<v Speaker 1>That's where modeling comes in, right.

162
00:08:13.519 --> 00:08:16.759
<v Speaker 2>We create models. There's the logical model, that's the what

163
00:08:16.759 --> 00:08:20.199
<v Speaker 2>what functions does the system need, regardless of technology. Then

164
00:08:20.240 --> 00:08:24.000
<v Speaker 2>there's the physical model that's the how which specific software,

165
00:08:24.000 --> 00:08:25.959
<v Speaker 2>hardware networks are we using.

166
00:08:26.160 --> 00:08:29.399
<v Speaker 1>In tools like data flow diagrams help visualize that exactly.

167
00:08:29.519 --> 00:08:34.000
<v Speaker 2>Dfdes context diagrams. They map out how data moves through

168
00:08:34.039 --> 00:08:36.600
<v Speaker 2>the system, how it gets transformed. They turn those pages

169
00:08:36.639 --> 00:08:38.799
<v Speaker 2>of notes into a visual plan and architecture.

170
00:08:38.919 --> 00:08:41.559
<v Speaker 1>Moving into the design phase, now we're thinking about the

171
00:08:41.559 --> 00:08:45.240
<v Speaker 1>internal structure the data, but also how users will actually

172
00:08:45.320 --> 00:08:48.080
<v Speaker 1>interact with it. Let's start with data quality. Why is

173
00:08:48.120 --> 00:08:51.080
<v Speaker 1>having the same info in multiple places like that Mario's

174
00:08:51.120 --> 00:08:53.360
<v Speaker 1>Autoshop example such a bad idea?

175
00:08:53.519 --> 00:08:57.120
<v Speaker 2>Data redundancy. It's a recipe for disaster, basically because it

176
00:08:57.159 --> 00:09:01.000
<v Speaker 2>guarantees inconsistency. If Mario updates some mechanic's pay rate in

177
00:09:01.080 --> 00:09:03.879
<v Speaker 2>one file, but forgets the other five places it's stored.

178
00:09:03.960 --> 00:09:06.559
<v Speaker 1>Your reports are wrong, your payroll is wrong.

179
00:09:07.120 --> 00:09:12.159
<v Speaker 2>Chaos precisely. The fix is normalization. It's a technique to

180
00:09:12.159 --> 00:09:13.600
<v Speaker 2>structure your data properly.

181
00:09:13.759 --> 00:09:18.120
<v Speaker 1>Ah, normalization often gets technical fast, especially third normal form

182
00:09:18.200 --> 00:09:21.320
<v Speaker 1>three and a F. That definition, every non key field

183
00:09:21.360 --> 00:09:23.759
<v Speaker 1>depends on the key, the whole key, and nothing but

184
00:09:23.879 --> 00:09:25.240
<v Speaker 1>the key. Can you translate that?

185
00:09:25.480 --> 00:09:28.639
<v Speaker 2>Huh? Yeah, that's pure database talk. Let's simplify the core

186
00:09:28.679 --> 00:09:31.200
<v Speaker 2>idea of three and F is store each piece of

187
00:09:31.200 --> 00:09:34.440
<v Speaker 2>information once in one place. Make sure every bit of

188
00:09:34.480 --> 00:09:36.679
<v Speaker 2>data in a table is directly related only to the

189
00:09:36.720 --> 00:09:39.159
<v Speaker 2>main identifier for that table, like the customer ID or

190
00:09:39.279 --> 00:09:39.799
<v Speaker 2>order number.

191
00:09:39.960 --> 00:09:43.120
<v Speaker 1>So no repeating addresses or names all over the place exactly.

192
00:09:43.200 --> 00:09:46.639
<v Speaker 2>It eliminates those inconsistency problems and makes updating data way

193
00:09:46.679 --> 00:09:47.440
<v Speaker 2>easier and safer.

194
00:09:47.600 --> 00:09:50.519
<v Speaker 1>Okay, data storted. Now the user side, the user interface

195
00:09:50.639 --> 00:09:53.759
<v Speaker 1>or UI. IBM had that concept of a transparent interface.

196
00:09:54.080 --> 00:09:56.679
<v Speaker 2>Yeah. The idea is the user should see right through

197
00:09:56.720 --> 00:09:59.519
<v Speaker 2>the interface to their own work. The UI shouldn't get

198
00:09:59.519 --> 00:10:02.519
<v Speaker 2>in the way. To be user centered intuitive, people should

199
00:10:02.559 --> 00:10:05.879
<v Speaker 2>spend their brain power on their tasks, not fighting the software.

200
00:10:06.559 --> 00:10:09.240
<v Speaker 2>Good UI boost productivity.

201
00:10:08.679 --> 00:10:11.320
<v Speaker 1>And it helps prevent bad data getting in the whole

202
00:10:11.559 --> 00:10:14.360
<v Speaker 1>garbage in garbage out idea Gi Joe.

203
00:10:14.639 --> 00:10:19.720
<v Speaker 2>Directly good UI design enforces data quality through validation rules.

204
00:10:20.240 --> 00:10:21.919
<v Speaker 2>These are automatic.

205
00:10:21.480 --> 00:10:22.879
<v Speaker 1>Checks like what kind of checks?

206
00:10:22.960 --> 00:10:25.879
<v Speaker 2>Well, simple things like a range check making sure an

207
00:10:25.919 --> 00:10:30.639
<v Speaker 2>order quantity isn't say negative or ridiculously large, or a

208
00:10:30.720 --> 00:10:34.039
<v Speaker 2>validity check ensuring a state code entered is actually one

209
00:10:34.120 --> 00:10:37.399
<v Speaker 2>of the valid us date codes, or maybe a sequence

210
00:10:37.480 --> 00:10:38.679
<v Speaker 2>check for batch processing.

211
00:10:38.759 --> 00:10:41.960
<v Speaker 1>Little checks that make a big difference to data accuracy.

212
00:10:41.600 --> 00:10:45.240
<v Speaker 2>Huge difference. They're essential quality control built right into the design.

213
00:10:45.480 --> 00:10:49.879
<v Speaker 1>And nowadays we have to design for phones, tablets, desktops, everything.

214
00:10:50.039 --> 00:10:52.879
<v Speaker 2>That's where responsive web design is crucial. It's basically a

215
00:10:52.960 --> 00:10:55.240
<v Speaker 2>must have. Now the system has to look good and

216
00:10:55.279 --> 00:10:58.159
<v Speaker 2>work properly on any screen size. If your field texts

217
00:10:58.200 --> 00:11:00.360
<v Speaker 2>can't easily use it on their tablets, you've got a

218
00:11:00.440 --> 00:11:01.919
<v Speaker 2>usability failure right there.

219
00:11:02.120 --> 00:11:08.759
<v Speaker 1>Okay, Phase four implementation. We've planned, analyzed, designed, Now we

220
00:11:08.799 --> 00:11:11.840
<v Speaker 1>actually build it, test it and roll it out. This

221
00:11:11.919 --> 00:11:14.240
<v Speaker 1>feels like where budgets can really blow up if the

222
00:11:14.279 --> 00:11:15.440
<v Speaker 1>early work wasn't solid.

223
00:11:15.519 --> 00:11:19.360
<v Speaker 2>Oh, definitely, the quality of your requirements back in phase two,

224
00:11:19.360 --> 00:11:23.639
<v Speaker 2>directly impacts how painful and expensive testing is. Now, testing

225
00:11:23.679 --> 00:11:26.399
<v Speaker 2>isn't just one thing either. We break it down how so. Well,

226
00:11:26.399 --> 00:11:30.159
<v Speaker 2>First there's unit testing. Programmers test their own individual pieces,

227
00:11:30.200 --> 00:11:32.679
<v Speaker 2>the modules they wrote, make sure that specific.

228
00:11:32.240 --> 00:11:34.360
<v Speaker 1>Bit works okay, testing the small parts.

229
00:11:34.519 --> 00:11:38.320
<v Speaker 2>Then integration testing, does module A talk correctly to module B?

230
00:11:38.879 --> 00:11:41.639
<v Speaker 2>Do the different pieces work together as expected? Checking the

231
00:11:41.679 --> 00:11:45.279
<v Speaker 2>connections exactly? And finally system testing This is the big one.

232
00:11:45.399 --> 00:11:47.960
<v Speaker 2>Does the entire system and to end meet all those

233
00:11:48.000 --> 00:11:50.879
<v Speaker 2>requirements we define way back in the system requirements document.

234
00:11:51.039 --> 00:11:53.200
<v Speaker 1>So assuming it passes all the tests, we have to

235
00:11:53.200 --> 00:11:57.480
<v Speaker 1>actually switch it on for real users. The cutover sounds risky, It.

236
00:11:57.360 --> 00:11:59.960
<v Speaker 2>Can be very risky. Choosing the right strategy is key.

237
00:12:00.120 --> 00:12:02.679
<v Speaker 2>There are a few main ways to do it. The riskiest,

238
00:12:02.720 --> 00:12:05.080
<v Speaker 2>but fastest and cheapest is direct cutover.

239
00:12:05.360 --> 00:12:07.080
<v Speaker 1>Just flick the switch, turn off the old, turn on.

240
00:12:06.960 --> 00:12:10.279
<v Speaker 2>The new, yep, big bang. If the new system has problems,

241
00:12:10.759 --> 00:12:13.320
<v Speaker 2>well you've got a big problem. Business might grind to

242
00:12:13.360 --> 00:12:14.759
<v Speaker 2>a halt ouch.

243
00:12:15.000 --> 00:12:15.600
<v Speaker 1>What's safer?

244
00:12:15.799 --> 00:12:18.960
<v Speaker 2>A pilot implementation is safer. You roll out the new

245
00:12:19.000 --> 00:12:22.600
<v Speaker 2>system to just a small group, first, one department, maybe

246
00:12:22.600 --> 00:12:25.440
<v Speaker 2>one office, work out the kinks with them before going live.

247
00:12:25.480 --> 00:12:29.360
<v Speaker 1>Everywhere okay, minimizes the initial blast radius if something goes wrong.

248
00:12:29.480 --> 00:12:33.799
<v Speaker 2>Right, And the safest, but also the most expensive and complex, is.

249
00:12:33.759 --> 00:12:36.960
<v Speaker 1>Parallel operation running both systems at the same time.

250
00:12:36.799 --> 00:12:39.120
<v Speaker 2>For a period. Yes, you run the old and the

251
00:12:39.159 --> 00:12:42.279
<v Speaker 2>news side by side. Users might even do tasks in both.

252
00:12:42.759 --> 00:12:44.600
<v Speaker 2>If the new one fails, the old one's still there

253
00:12:44.679 --> 00:12:48.759
<v Speaker 2>running perfectly, but you're paying double the operational cost, double

254
00:12:48.759 --> 00:12:50.039
<v Speaker 2>the effort for that safety net.

255
00:12:50.080 --> 00:12:52.279
<v Speaker 1>So it's a trade off. Risk versus cost.

256
00:12:52.200 --> 00:12:55.799
<v Speaker 2>Always a trade off. In system deployment, hashtags, tag outro,

257
00:12:56.559 --> 00:13:00.000
<v Speaker 2>and that brings us eventually to Phase five support and secure.

258
00:13:00.679 --> 00:13:03.559
<v Speaker 2>The system is live, but as we talked about with TCO,

259
00:13:03.919 --> 00:13:07.120
<v Speaker 2>it's never really done, is it. The real cost unfolds

260
00:13:07.159 --> 00:13:08.759
<v Speaker 2>over years of ownership.

261
00:13:08.360 --> 00:13:11.879
<v Speaker 1>Keeping it running, keeping it relevant, which involves different kinds

262
00:13:11.919 --> 00:13:13.240
<v Speaker 1>of maintenance work exactly.

263
00:13:13.240 --> 00:13:17.039
<v Speaker 2>Their four main types you'll encounter. First is corrective maintenance.

264
00:13:17.080 --> 00:13:20.000
<v Speaker 2>That's just fixing bugs errors that pop up after launch.

265
00:13:20.080 --> 00:13:21.039
<v Speaker 1>Standard bug fixing.

266
00:13:21.200 --> 00:13:25.559
<v Speaker 2>Then there's adaptive maintenance. This is crucial adapting the system

267
00:13:25.639 --> 00:13:28.559
<v Speaker 2>because the world changed, maybe a new tax law, a

268
00:13:28.639 --> 00:13:31.240
<v Speaker 2>new regulation, a change in business partners.

269
00:13:31.440 --> 00:13:33.879
<v Speaker 1>The system has to keep up so it stays compliant

270
00:13:34.039 --> 00:13:35.000
<v Speaker 1>and useful right.

271
00:13:35.159 --> 00:13:38.799
<v Speaker 2>Third is perfective maintenance. This is about making it better,

272
00:13:38.919 --> 00:13:43.240
<v Speaker 2>more efficient, easier to use, maybe based on user feedback, tweaking.

273
00:13:42.960 --> 00:13:44.960
<v Speaker 1>It for performance, fine tuning.

274
00:13:44.679 --> 00:13:48.960
<v Speaker 2>And finally, preventive maintenance. This is proactive changing parts of

275
00:13:49.000 --> 00:13:52.279
<v Speaker 2>the system before they break, maybe updating old code, libraries

276
00:13:52.360 --> 00:13:55.440
<v Speaker 2>or infrastructure to reduce the chance of future failures.

277
00:13:55.600 --> 00:13:58.039
<v Speaker 1>And that preventive part leads us right to the big

278
00:13:58.080 --> 00:14:01.600
<v Speaker 1>ongoing challenge, doesn't it, especially now with technology moving so

279
00:14:01.799 --> 00:14:05.600
<v Speaker 1>fast agile, the cloud AI is coming.

280
00:14:06.120 --> 00:14:09.759
<v Speaker 2>It really does. It puts a constant pressure on decision makers.

281
00:14:10.039 --> 00:14:12.679
<v Speaker 2>So the final thought really for you listening, is this

282
00:14:12.759 --> 00:14:18.080
<v Speaker 2>strategic question, how do you balance spending money today on

283
00:14:18.120 --> 00:14:24.840
<v Speaker 2>that proactive preventative maintenance, updating things, simplifying things, knowing it

284
00:14:24.919 --> 00:14:27.519
<v Speaker 2>costs time and resources.

285
00:14:26.840 --> 00:14:29.759
<v Speaker 1>Now, against the risk of not doing it and facing

286
00:14:29.879 --> 00:14:33.200
<v Speaker 1>potentially much higher maybe even catastrophic it costs down the

287
00:14:33.279 --> 00:14:35.879
<v Speaker 1>road when something big breaks or the whole system needs

288
00:14:35.919 --> 00:14:37.320
<v Speaker 1>replacing because you waited too long.

289
00:14:37.440 --> 00:14:42.120
<v Speaker 2>That balancing act, weighing today's investment against tomorrow's potential disaster.

290
00:14:42.759 --> 00:14:45.799
<v Speaker 2>That's the core strategic challenge in managing systems over their life.

291
00:14:46.039 --> 00:14:49.480
<v Speaker 1>A constant calculation. This has been incredibly insightful, a really

292
00:14:49.559 --> 00:14:52.519
<v Speaker 1>clear guide through how these complex systems actually get built

293
00:14:52.519 --> 00:14:53.080
<v Speaker 1>and managed.

294
00:14:53.159 --> 00:14:55.000
<v Speaker 2>Glad to be here. It's a fascinating feel.

295
00:14:54.840 --> 00:14:57.240
<v Speaker 1>And for you, our listeners, we hope you feel better

296
00:14:57.279 --> 00:15:00.399
<v Speaker 1>equipped now to understand, maybe question, or even manage the

297
00:15:00.399 --> 00:15:04.120
<v Speaker 1>strategic thinking behind the next big IT project you encounter.

298
00:15:04.559 --> 00:15:06.200
<v Speaker 1>Join us next time on the Deep Dive