WEBVTT 1 00:00:00.120 --> 00:00:04.040 Have you ever found yourself feeling well stuck caught between 2 00:00:04.240 --> 00:00:07.759 two really powerful forces in the IT world, Like, on 3 00:00:07.759 --> 00:00:11.160 one side, you're pushing hard for that lightning fast delivery, 4 00:00:11.240 --> 00:00:13.560 you know, the agility of a startup, but then on 5 00:00:13.599 --> 00:00:17.160 the other you're grappling with these established processes and let's 6 00:00:17.160 --> 00:00:19.960 face it, the absolute need for stability and control. 7 00:00:20.079 --> 00:00:21.800 It's a real tension, isn't it a common one? 8 00:00:21.879 --> 00:00:25.399 Exactly? It feels fundamental. Well, you are definitely not alone 9 00:00:25.399 --> 00:00:28.120 if you feel that. We've got a fascinating deep dive 10 00:00:28.160 --> 00:00:32.520 for you today exploring exactly how to reconcile that tension. 11 00:00:33.039 --> 00:00:37.039 We're diving right into the intersection of ITYL and debops. Yeah, 12 00:00:37.119 --> 00:00:41.679 our focus today is based on Abynav Krishna Kaiser's insightful book, 13 00:00:41.960 --> 00:00:44.200 Reinventing IYLE in the Age of Debops. 14 00:00:44.280 --> 00:00:47.079 That's right, And our mission here really is to unpack 15 00:00:47.439 --> 00:00:50.960 how these two powerful approaches, which let's be honest, often 16 00:00:51.000 --> 00:00:53.719 seem like they're contrasting. Yeah, how they can not just 17 00:00:53.840 --> 00:00:56.799 coexist but actually thrive together. Think of it as a 18 00:00:56.840 --> 00:01:01.280 shortcut maybe to understanding this critical evolution in IT service management. 19 00:01:01.679 --> 00:01:05.319 We want to explore those perceived conflicts sure, but more 20 00:01:05.319 --> 00:01:10.719 importantly reveal some innovative techniques to make processes genuinely agile 21 00:01:10.799 --> 00:01:13.560 and relevant for today. So you get the clarity you 22 00:01:13.640 --> 00:01:17.200 need to navigate this landscape without feeling overwhelmed. 23 00:01:17.519 --> 00:01:20.000 Okay, so let's start there. Then let's unpack this apparent 24 00:01:20.000 --> 00:01:22.879 clash because yeah, on the surface, they can really seem 25 00:01:22.959 --> 00:01:28.079 like oil and water. So on one side we have DevOps. Now, 26 00:01:28.079 --> 00:01:30.120 most of you listening are probably familiar with the push 27 00:01:30.159 --> 00:01:33.439 for DevOps. It was borne out of this craving for 28 00:01:33.640 --> 00:01:39.359 fast turnarounds, solving those painful agility problems and really dramatically 29 00:01:39.359 --> 00:01:42.400 increase in productivity and quality and software delivery. 30 00:01:42.680 --> 00:01:44.480 And it's fundamentally cultural, wouldn't you say? 31 00:01:44.480 --> 00:01:48.000 Oh? Absolutely, it's a cultural transformation, a powerful union of 32 00:01:48.040 --> 00:01:51.599 development and operations teams. We saw it evolve clearly from 33 00:01:51.599 --> 00:01:55.079 that old sequential waterfall model, which oh man felt like 34 00:01:55.120 --> 00:01:58.840 trying to build a skyscraper without seeing the blueprint for months. Yeah, 35 00:01:58.959 --> 00:02:00.920 to the agile manifest show back in two thousand and one, 36 00:02:00.920 --> 00:02:06.159 which really emphasized fluidity and small, manageable iterations at its core. 37 00:02:06.319 --> 00:02:11.800 DevOps kind of lives by that Calmo's acronym culture automation, lean, measurement, 38 00:02:12.039 --> 00:02:12.639 and sharing. 39 00:02:12.960 --> 00:02:16.360 And culture's key, Like Peter Drucker said, culture eats strategy for. 40 00:02:16.319 --> 00:02:20.639 Breakfast exactly, and DevOps it's truly about overhauling behavior, changing 41 00:02:20.680 --> 00:02:23.039 how people work together. And just to give you a 42 00:02:23.080 --> 00:02:26.639 sense of the sheer speed and scale DevOps enables, think 43 00:02:26.639 --> 00:02:31.400 about Amazon back in twenty eleven, over one thousand deployments 44 00:02:31.680 --> 00:02:34.039 per hour per hour. That's not just faster. That's a 45 00:02:34.039 --> 00:02:35.199 different galaxy of speed. 46 00:02:35.319 --> 00:02:38.280 It really is. And what's fascinating is contrasting that with 47 00:02:38.360 --> 00:02:41.800 the other side of this perceived divide. It TEL now 48 00:02:41.919 --> 00:02:45.199 many listeners will know, IDEL is the backbone for traditional 49 00:02:45.199 --> 00:02:47.960 IT service management. It was really established in that earlier 50 00:02:48.000 --> 00:02:50.520 waterfall era where stability and control were. 51 00:02:50.400 --> 00:02:53.159 Absolutely paramount, right, the focus was different totally. 52 00:02:53.919 --> 00:02:58.599 Eyetel is fundamentally service centric. Its official definition emphasizes delivering 53 00:02:58.680 --> 00:03:02.199 value to customers by facililitating outcomes they want without them 54 00:03:02.240 --> 00:03:05.919 awning the specific costs and risks, and the framework itself 55 00:03:05.960 --> 00:03:08.879 is structured around a service life cycle with five sequential 56 00:03:08.919 --> 00:03:14.240 phases service strategy, service design, service transitions, service operation, and 57 00:03:14.319 --> 00:03:17.000 continual service improvement. You have to go through them in 58 00:03:17.080 --> 00:03:20.879 order sequentially. Yeah, and crucially for our discussion today, ITIL 59 00:03:20.960 --> 00:03:25.479 defines functions, which are essentially specialized teams like networking or 60 00:03:25.599 --> 00:03:30.240 Java teams. These often maybe inavertently create those silos we 61 00:03:30.280 --> 00:03:33.800 hear so much about. And it defines processes, these very structured, 62 00:03:33.919 --> 00:03:39.560 predictable sequences designed for control and stability. Inputs triggers, outputs, 63 00:03:40.199 --> 00:03:40.800 very defined. 64 00:03:41.159 --> 00:03:43.800 Okay, so we've got these two powerhouses, but they seem 65 00:03:43.800 --> 00:03:46.840 built on different foundations. So what happens when they collide 66 00:03:46.879 --> 00:03:49.479 in an organization? The book points out some big ticket 67 00:03:49.520 --> 00:03:52.080 conflicts things many of us have probably felt. First That 68 00:03:52.199 --> 00:03:54.120 core difference sequential versus concurrent. 69 00:03:54.159 --> 00:03:55.000 Yeah, that's a big one. 70 00:03:55.120 --> 00:03:59.319 Idle strictly sequential phases, you must finish strategy before design, 71 00:03:59.719 --> 00:04:02.319 design before build. That can feel like hitting a concrete 72 00:04:02.360 --> 00:04:03.919 wall when you're trying to move fast. 73 00:04:04.000 --> 00:04:10.479 Right, Absolutely, While DevOps is inherently anti sequential, it's iterative, 74 00:04:10.960 --> 00:04:13.960 expects output almost right away, often in parallel. 75 00:04:14.039 --> 00:04:16.759 Yeah, it's like building a house floor by floor versus 76 00:04:16.839 --> 00:04:19.360 I don't know, starting the plumbing while the foundation's still setting. 77 00:04:19.560 --> 00:04:23.360 It's a different mindset completely. Then there's batch sizes. Idle 78 00:04:23.399 --> 00:04:26.199 often leads to one big piece of delivery after a 79 00:04:26.240 --> 00:04:29.160 really long cycle, and we all know how risky that. 80 00:04:29.079 --> 00:04:31.360 Can be huge risk. If it fails, it fails big. 81 00:04:31.600 --> 00:04:35.439 Whereas DevOps champions small batches sprints. The whole idea is 82 00:04:35.439 --> 00:04:39.240 to reduce that risk and allow for quick, continuous changes. 83 00:04:38.920 --> 00:04:44.360 Delivering value incrementally. It's like small gifts daily versus one giant, 84 00:04:44.480 --> 00:04:45.720 risky present once a year. 85 00:04:45.800 --> 00:04:50.639 Good analogy, and Third, feedback, IDLE traditionally formalizes feedback way 86 00:04:50.680 --> 00:04:52.759 at the end in continual service. 87 00:04:52.480 --> 00:04:55.279 Improvement, often too late to make meaningful changes to what 88 00:04:55.439 --> 00:04:56.720 was just delivered right. 89 00:04:57.480 --> 00:05:01.319 DevOps, though, demands rapid feedback every step of the way, 90 00:05:01.800 --> 00:05:06.839 constant tests demos, often within those tight two week sprint cycles. 91 00:05:06.879 --> 00:05:08.759 You're getting feedback almost constantly. 92 00:05:08.800 --> 00:05:11.800 Then we have the silo culture versus the single team 93 00:05:12.000 --> 00:05:17.120 aisle's functional silos, just by their nature create boundaries and handoffs. 94 00:05:16.879 --> 00:05:20.000 Which leads to delays, misunderstandings. 95 00:05:20.040 --> 00:05:25.199 Exactly dev ups pushes for that one team, one software approach. 96 00:05:25.920 --> 00:05:29.199 Tear down the walls, remove the confusion, the miscommunication, the 97 00:05:30.240 --> 00:05:31.720 mistrust between dev and. 98 00:05:31.680 --> 00:05:33.680 OX, get everyone pulling in the same direction. 99 00:05:33.800 --> 00:05:37.839 And finally, there's this perception that well continuous deployment makes 100 00:05:37.879 --> 00:05:41.720 release management irrelevant because changes just go street to production 101 00:05:41.800 --> 00:05:44.600 without all the traditional heavy governance steps, right, Like. 102 00:05:44.560 --> 00:05:46.959 The need for a formal release team just vanishes. 103 00:05:47.120 --> 00:05:47.279 Yeah. 104 00:05:47.319 --> 00:05:49.279 We'll dig into whether that's actually true later. 105 00:05:49.439 --> 00:05:51.000 Yeah, that's a really interesting point. 106 00:05:51.120 --> 00:05:53.680 But you know, despite these apparent conflicts, and they are 107 00:05:53.759 --> 00:05:57.279 real conflicts in many places. Yeah, the core argument in 108 00:05:57.360 --> 00:05:59.680 the book and what we're seeing in practice is that 109 00:05:59.720 --> 00:06:03.720 it PO can adapt, It really can't. DevOps isn't necessarily 110 00:06:03.800 --> 00:06:07.199 about throwing out decades of ityl learning. It's more about 111 00:06:07.480 --> 00:06:10.480 creating a union of mindsets. 112 00:06:10.560 --> 00:06:12.079 A union of mindsets, I like that. 113 00:06:12.199 --> 00:06:15.680 Yeah, adapting the framework to the digital age, taking the 114 00:06:15.720 --> 00:06:19.399 best of iipel's governance and stability, but supercharging it with 115 00:06:19.519 --> 00:06:21.160 devops' speed and agility. 116 00:06:21.319 --> 00:06:22.879 Okay, so how do we actually do that? This is 117 00:06:22.920 --> 00:06:25.720 where it gets really interesting, right, because the key to 118 00:06:25.800 --> 00:06:29.439 bridging this divide seems to lie in three common elements 119 00:06:29.480 --> 00:06:34.319 that enable that DevOps cultural change, people, process, and technology 120 00:06:34.439 --> 00:06:38.879 a classic triad exactly. Let's start with people, specifically, those 121 00:06:38.920 --> 00:06:44.000 team structures. Traditionally, itol functions group specialists, technical management, application 122 00:06:44.120 --> 00:06:47.879 management into separate silos that often created those us versus 123 00:06:47.879 --> 00:06:51.160 them dynamics. We just talked about walls between teams, but 124 00:06:51.240 --> 00:06:54.079 in a DevOps world, the shift is towards building teams 125 00:06:54.240 --> 00:06:58.000 around an application. You bring all the necessary roles developers, testers, 126 00:06:58.040 --> 00:06:59.879 opspos into a single. 127 00:06:59.600 --> 00:07:01.720 Team, one team responsible and to. 128 00:07:01.800 --> 00:07:05.680 End right, this team becomes the Alpha and Omega, as 129 00:07:05.680 --> 00:07:09.199 the book puts it, for both developing and maintaining that application, and. 130 00:07:09.160 --> 00:07:14.959 That structure naturally fosters a flat hierarchy. Shared responsibility replaces 131 00:07:14.959 --> 00:07:17.800 those old many hierarchies within silos. 132 00:07:17.319 --> 00:07:20.160 Which fundamentally removes a lot of the conflicts of interest, 133 00:07:20.199 --> 00:07:23.560 doesn't it No more pointing fingers down the line precisely. 134 00:07:23.680 --> 00:07:26.879 And this model also brings in key agile roles. You've 135 00:07:26.879 --> 00:07:28.160 got the product owner. 136 00:07:28.000 --> 00:07:29.720 The customer's voice, and the team. 137 00:07:29.680 --> 00:07:34.680 Exactly embedded in the team providing constant feedback, steering the 138 00:07:34.759 --> 00:07:36.879 direction based on business value. 139 00:07:37.000 --> 00:07:37.879 And the scrum master. 140 00:07:38.120 --> 00:07:40.959 Yeah, the scrum master acting more like a servant leader 141 00:07:41.000 --> 00:07:44.319 whose main job is clearing away impediments, helping the team 142 00:07:44.399 --> 00:07:45.879 focus purely on delivery. 143 00:07:46.160 --> 00:07:49.079 So it's not just changing job titles. It's a really 144 00:07:49.160 --> 00:07:52.319 profound shift in accountability and how people collaborate. 145 00:07:52.519 --> 00:07:55.040 Absolutely, and once you have the right people in these 146 00:07:55.079 --> 00:07:57.600 new collaborative structures. The next question is, well, how do 147 00:07:57.600 --> 00:08:01.480 we orchestrate their work efficiently that brings us squarely to 148 00:08:01.560 --> 00:08:05.639 process or what the book calls Agile integration. DevOps introduces 149 00:08:05.639 --> 00:08:09.639 some specific processes on top of basic Agile methods to 150 00:08:09.800 --> 00:08:14.120 really accelerate delivery. First, you've got continuous integration or CI. 151 00:08:14.879 --> 00:08:17.439 This is where developers merge their code changes back into 152 00:08:17.439 --> 00:08:20.319 the main branch frequently, often multiple. 153 00:08:19.959 --> 00:08:22.480 Times a day, and the key is automation right totally. 154 00:08:22.759 --> 00:08:26.199 These integrations are immediately verified by automated builds and tests. 155 00:08:26.519 --> 00:08:30.959 It drastically minimizes conflicts and catches errors super early. Think 156 00:08:31.000 --> 00:08:33.919 of it like a constant automated sanity check for the codebase. 157 00:08:34.039 --> 00:08:35.759 Okay, CI, then what Then? 158 00:08:35.799 --> 00:08:39.519 You have continuous delivery CD. This means that every change 159 00:08:39.519 --> 00:08:43.320 that passes all the automated tests is automatically pushed to 160 00:08:43.399 --> 00:08:47.000 a staging or pre production environment. The binaries are qualified 161 00:08:47.039 --> 00:08:48.480 for production deployment. 162 00:08:48.399 --> 00:08:50.960 Qualified, but not necessarily deployed yet exactly. 163 00:08:51.000 --> 00:08:53.639 The actual deployment to production still needs a manual trigger, 164 00:08:53.679 --> 00:08:56.600 a human decision. But your software is always ready to 165 00:08:56.639 --> 00:08:59.360 go live. It's sitting in a launch pad button ready. 166 00:08:59.200 --> 00:09:01.639 Got it ready? But waiting for the go ahead. 167 00:09:01.600 --> 00:09:06.000 Right, and then finally there's continuous deployment. This takes continuous 168 00:09:06.039 --> 00:09:09.440 delivery one step further. Every change that passes all the 169 00:09:09.519 --> 00:09:13.679 tests is not just qualified, it's automatically deployed all the 170 00:09:13.679 --> 00:09:14.279 way to production. 171 00:09:14.639 --> 00:09:16.840 Whoa, so the button press is automated too. 172 00:09:17.080 --> 00:09:21.559 Essentially, Yes, every successful build automatically goes live. That really 173 00:09:21.559 --> 00:09:24.879 pushes the envelope on speed and requires a huge amount 174 00:09:24.919 --> 00:09:27.519 of trust in your automation and testing. Wow. 175 00:09:27.639 --> 00:09:31.559 Okay, that distinction between continuous delivery ready to deploy and 176 00:09:31.600 --> 00:09:35.000 continuous deployment actually is deployed automatically. That seems crucial. Yeah, 177 00:09:35.120 --> 00:09:36.799 defines the level of automation. 178 00:09:36.559 --> 00:09:38.720 And well trust, it really does. 179 00:09:38.879 --> 00:09:43.200 And these processes ci CD they obviously rely heavily on 180 00:09:43.279 --> 00:09:45.399 technology automation tools. 181 00:09:45.559 --> 00:09:47.120 Yeah, the third piece of the triad. 182 00:09:47.159 --> 00:09:50.440 The book rightly emphasizes that technology is often seen as 183 00:09:50.480 --> 00:09:53.600 the most important bit for getting those rapid results. 184 00:09:53.279 --> 00:09:54.200 Because it's tangible. 185 00:09:54.240 --> 00:09:56.960 You can buy a tool, right, But as you said earlier, 186 00:09:57.080 --> 00:09:59.960 it's pretty useless without the right people and processes where 187 00:10:00.200 --> 00:10:00.600 and sync. 188 00:10:00.720 --> 00:10:04.440 Absolutely, but the tech has been a massive enabler. Automation 189 00:10:04.519 --> 00:10:07.639 has completely changed the game for infrastructure. 190 00:10:07.200 --> 00:10:09.240 Like infrastructure as code. 191 00:10:09.039 --> 00:10:12.240 Exactly, instead of manually building servers over weeks, you can 192 00:10:12.279 --> 00:10:15.679 spin up complex environments from code in minutes than cloud 193 00:10:15.720 --> 00:10:21.159 platforms aws, Azure, Google Compute Engine. They make this dynamic 194 00:10:21.200 --> 00:10:22.679 provisioning possible. 195 00:10:22.279 --> 00:10:24.639 So no more waiting weeks for a server hopefully not. 196 00:10:25.200 --> 00:10:27.600 And then there are specific tools for different parts of 197 00:10:27.639 --> 00:10:31.399 the pipeline. Distributed version control like GIT is huge. It 198 00:10:31.440 --> 00:10:35.000 provides that safety net for rapid changes, letting teams experiment 199 00:10:35.039 --> 00:10:39.399 collaboratively in ways older systems like SVN just couldn't handle easily. 200 00:10:39.480 --> 00:10:41.360 Branching is so much easier. 201 00:10:41.200 --> 00:10:44.279 Much easier. Then you have orchestrators like Jenkins or Bamboo. 202 00:10:44.440 --> 00:10:48.320 They're not just scheduling tasks, they're codifying your entire release pipeline, 203 00:10:48.399 --> 00:10:53.600 turning complex manual handoffs into predictable, repeatable, transparent. 204 00:10:53.000 --> 00:10:55.559 Workflows, making the process visible. 205 00:10:55.279 --> 00:10:59.399 Visible and automated configuration management tools like Puppet and Chef 206 00:10:59.480 --> 00:11:04.519 automates server setups, application can figs ensuring consistency everywhere. No 207 00:11:04.639 --> 00:11:05.440 more works on my. 208 00:11:05.440 --> 00:11:07.759 Machine, huh, We've all heard that one in. 209 00:11:07.840 --> 00:11:11.679 Automated testing tools like Selenium or Cucumber provide those crucial 210 00:11:11.759 --> 00:11:16.679 quality checks, ensuring speed doesn't rex stability quality gates exactly. 211 00:11:17.039 --> 00:11:20.840 And one more important distinction the book makes artifact repositories. 212 00:11:21.840 --> 00:11:25.879 These store the machine readable binaries, the deployable units. They're 213 00:11:25.919 --> 00:11:29.360 distinct from source code repositories, which hold the human readable 214 00:11:29.399 --> 00:11:33.440 code and scripts. Both are critical, but for different stages. Right, 215 00:11:33.480 --> 00:11:35.840 one holds the recipe, the other holds the baked cake, 216 00:11:35.919 --> 00:11:40.000 ready to deliver perfect analogy precisely. So to really see 217 00:11:40.000 --> 00:11:42.399 this union of mindsets in action, we need to get 218 00:11:42.440 --> 00:11:45.799 a bit more granular. Now, let's zoom in on how 219 00:11:45.879 --> 00:11:50.200 some of idyl's most critical processes are being fundamentally reinvented 220 00:11:50.559 --> 00:11:52.840 when you infuse them with these DevOps principles. 221 00:11:52.879 --> 00:11:54.639 Okay, yeah, let's do that. Where should we start. How 222 00:11:54.679 --> 00:11:57.159 about service transition, managing changes in assets? 223 00:11:57.200 --> 00:12:01.799 Good place. So change management in idle definistion is the addition, removal, 224 00:12:01.919 --> 00:12:04.440 or modification of anything that could have an effect on 225 00:12:04.480 --> 00:12:07.320 it services. Historically, it acted as. 226 00:12:07.240 --> 00:12:11.600 A gatekeeper and often felt, let's be honest, pretty rigid bureaucratic. 227 00:12:12.200 --> 00:12:14.440 Lots of approvals, cab meetings. 228 00:12:14.799 --> 00:12:17.720 It could definitely slow things down. But here's where the 229 00:12:17.759 --> 00:12:22.000 book offers a really a potentially game changing insight. It 230 00:12:22.039 --> 00:12:24.600 talks about maximum agility with standard changes. 231 00:12:24.639 --> 00:12:27.000 Standard changes, Okay, what does that mean in this context? 232 00:12:27.080 --> 00:12:32.519 It's about intelligently segmenting your change workload. The analysis suggests 233 00:12:32.519 --> 00:12:36.200 that a huge chunk, maybe sixty seventy percent of all 234 00:12:36.279 --> 00:12:40.320 changes are actually low risk, low impact and highly repeatable. 235 00:12:40.600 --> 00:12:42.519 Think patching minor can figure up dates. 236 00:12:42.519 --> 00:12:44.120 May think you do all the time, exactly. 237 00:12:44.440 --> 00:12:48.159 So the idea is identify these, define them clearly, test 238 00:12:48.200 --> 00:12:50.879 the process thoroughly, and then preapprove. 239 00:12:50.399 --> 00:12:53.320 Them preapproved so they bypass the usual CAD. 240 00:12:53.240 --> 00:12:56.759 For the most part. Yes, they bypass multiple time consuming 241 00:12:56.759 --> 00:13:00.960 approval steps. This significantly boost productivity and lets the change 242 00:13:00.960 --> 00:13:04.519 management process focus its energy on the truly complex, high 243 00:13:04.600 --> 00:13:05.200 risk changes. 244 00:13:05.320 --> 00:13:08.200 That makes a lot of sense, freeing up cognitive load exactly. 245 00:13:08.600 --> 00:13:11.279 The book even mentions an anecdote and organization saved over 246 00:13:11.320 --> 00:13:15.200 half a million dollars annually just by properly implementing standard changes. 247 00:13:15.440 --> 00:13:18.080 Wow, but how do you build the trust needed for 248 00:13:18.120 --> 00:13:21.240 that pre approval? Doesn't it still feel risky to some 249 00:13:21.320 --> 00:13:22.120 parts of the business. 250 00:13:22.240 --> 00:13:25.600 Oh? Absolutely, it requires a cultural shift towards trust, yes, 251 00:13:25.919 --> 00:13:29.639 but also really robust automation and monitoring to prove that 252 00:13:29.679 --> 00:13:33.120 these standard changes truly are low risk and well tested, 253 00:13:34.200 --> 00:13:37.440 And it's not about abandoning governance entirely. It's about shifting 254 00:13:37.519 --> 00:13:38.399 where you apply it. 255 00:13:38.480 --> 00:13:41.440 Okay, So how does that work with continuous delivery or deployment. 256 00:13:41.759 --> 00:13:44.919 Well, with continuous delivery, where there's still a manual trigger 257 00:13:44.919 --> 00:13:47.600 for production, you might still have a COIB approval for 258 00:13:47.639 --> 00:13:52.639 that specific deployment. But with continuous deployment, where everything is automated, yea, 259 00:13:53.120 --> 00:13:56.759 the change Advisory Board often shifts its focus. Instead of 260 00:13:56.799 --> 00:14:00.159 approving individual deployments, they approve the pipeline itself. If the 261 00:14:00.200 --> 00:14:03.360 whole automated process, the testing and the quality gates. Once 262 00:14:03.360 --> 00:14:06.879 the pipeline is trusted, it can run, allowing multiple daily 263 00:14:06.879 --> 00:14:09.919 deployments without individual cab blessings for each one. 264 00:14:10.120 --> 00:14:13.799 So the governance moves upstream to the process itself exactly Now. 265 00:14:14.000 --> 00:14:19.360 Still within service transition, there's Service Asset and Configuration Management sacm. 266 00:14:18.879 --> 00:14:23.440 AH, the CMDB, the heart of service management. Some call it. 267 00:14:23.440 --> 00:14:27.320 It is the configuration management database, tracking all those configuration 268 00:14:27.399 --> 00:14:31.320 items cis and their relationships. In the old world, it 269 00:14:31.360 --> 00:14:35.039 could sometimes feel like a static inventory, maybe only updated quarterly, 270 00:14:35.120 --> 00:14:38.720 a bit dusty sometimes, but in a DevOps world. The 271 00:14:38.720 --> 00:14:42.480 CMDB isn't just for auditing production anymore. It becomes critical 272 00:14:42.559 --> 00:14:46.679 for dynamic environment provisioning, spinning up test environments that mirror 273 00:14:46.679 --> 00:14:50.879 production accurately. It's vital for rapid impact assessment. If this 274 00:14:50.960 --> 00:14:54.600 component changes, what else is effected across all environments and 275 00:14:54.639 --> 00:14:58.360 managing dependencies. Knowing application B relies on service C. 276 00:14:58.639 --> 00:15:01.639 So it becomes a living map integrated into the workflow. 277 00:15:01.279 --> 00:15:06.200 Precisely and alongside the CMDB, the Source Code Repository SCR 278 00:15:06.360 --> 00:15:09.279 like it becomes that single source of truth for all 279 00:15:09.360 --> 00:15:13.440 the code, the infrastructure scripts, the configuration files. It enables collaboration, 280 00:15:13.600 --> 00:15:16.639 tracks every change, and provides that safety net for experimentation. 281 00:15:16.720 --> 00:15:20.000 Okay, so the CMDB and SCR become active, vital parts 282 00:15:20.039 --> 00:15:22.519 of the pipeline, not just after the fact records. That's 283 00:15:22.519 --> 00:15:25.519 a big shift, huge shift, all right, Moving on from transition, 284 00:15:25.639 --> 00:15:28.440 what about service operation keeping the lights on, keeping things 285 00:15:28.519 --> 00:15:30.679 running smoothly. Let's talk incident management. 286 00:15:30.799 --> 00:15:34.919 Okay. Itill's goal here as simple, restore service to its 287 00:15:34.960 --> 00:15:36.399 normal state as quickly as. 288 00:15:36.240 --> 00:15:38.440 Possible, minimize the disruption. Right. 289 00:15:38.639 --> 00:15:44.840 The typical flow is identify the incident users, calling monitoring tools, 290 00:15:44.879 --> 00:15:49.559 firing it staff noticing, then analysis, maybe escalation L one 291 00:15:49.519 --> 00:15:51.320 to L two L three. 292 00:15:51.360 --> 00:15:53.879 The usual path. How does DevOps change that? 293 00:15:54.080 --> 00:15:57.159 What's really transformative here is that the DevOps team itself 294 00:15:57.399 --> 00:16:00.679 often acts as L three support for incidents related to 295 00:16:00.720 --> 00:16:02.679 their applications, code or recent changes. 296 00:16:02.879 --> 00:16:05.399 So the people who wrote the code are fixing it directly. 297 00:16:05.559 --> 00:16:09.120 Often yes, the resolving incidents in parallel with their development work. 298 00:16:09.279 --> 00:16:11.960 They might pull the production codebase onto a separate branch, 299 00:16:12.440 --> 00:16:15.080 diagnose the issue, fix it, test it, and deploy the 300 00:16:15.080 --> 00:16:17.480 fix rapidly through the same automated pipeline. 301 00:16:17.519 --> 00:16:21.960 Wow. Their intimate knowledge must lead to much faster resolution. 302 00:16:21.639 --> 00:16:25.639 Times, incredibly faster. Usually it's like having the architect in 303 00:16:25.679 --> 00:16:28.840 the builder on site immediately when a pipe bursts, instead 304 00:16:28.840 --> 00:16:31.360 of calling a separate maintenance hotline and waiting. Yeah. 305 00:16:31.440 --> 00:16:34.759 Makes sense, But even with that speed, some idel disciplines still. 306 00:16:34.559 --> 00:16:38.559 Matter, right absolutely. Even though the pace is fast, itil's 307 00:16:38.679 --> 00:16:42.279 robust knowledge management process is still vital, capturing learnings from 308 00:16:42.320 --> 00:16:47.000 incidents quickly making them searchable. That, coupled with good configuration 309 00:16:47.080 --> 00:16:50.399 management data from the CMDB, is crucial for quick analysis 310 00:16:50.440 --> 00:16:53.120 and effective resolution. You don't want to solve the same 311 00:16:53.120 --> 00:16:54.159 problem twice. 312 00:16:53.919 --> 00:16:57.240 So capture the knowledge, use the CMDB for context. 313 00:16:56.919 --> 00:17:01.440 Got it and related to incidents. But distinct is problem. 314 00:17:01.120 --> 00:17:04.000 Management ah, the detective work exactly. 315 00:17:04.279 --> 00:17:07.799 This is the investigation unit, the CSI of IT service management. 316 00:17:08.279 --> 00:17:11.240 Its role isn't just to fix the immediate disruption that's 317 00:17:11.319 --> 00:17:14.240 incident management, but to find the underlying cause of one 318 00:17:14.359 --> 00:17:16.599 or more incidents to prevent them from happening again. 319 00:17:16.839 --> 00:17:22.559 So differentiating is key incident disruption, problem root cause precisely. 320 00:17:22.839 --> 00:17:25.960 Example, the application crashes frequently, that's a series of incidents. 321 00:17:26.240 --> 00:17:28.920 The unknown bug causing the crashes, that's the problem. It's 322 00:17:28.960 --> 00:17:32.079 the difference between constantly mopping up a leak versus finding 323 00:17:32.160 --> 00:17:33.880 and fixing the leaky pipe. 324 00:17:33.920 --> 00:17:35.920 Okay, and ITIL has techniques for this. 325 00:17:36.279 --> 00:17:39.319 Yes, things like the five Y technique just keep asking 326 00:17:39.359 --> 00:17:42.440 why until you get to the route, or the Ishikawa 327 00:17:42.559 --> 00:17:46.680 diagram the fishbone diagram to map out potential causes. These 328 00:17:46.720 --> 00:17:48.079 are still incredibly useful. 329 00:17:48.559 --> 00:17:51.000 So how does problem management fit into the fast pace 330 00:17:51.039 --> 00:17:51.680 of dubops. 331 00:17:51.839 --> 00:17:56.079 Well, things like unresolvable defects those bugs found during development 332 00:17:56.119 --> 00:17:59.079 that maybe have minimal impact but still need a proper fix. 333 00:17:59.119 --> 00:18:03.319 Eventually they become direct inputs to the problem management process. 334 00:18:04.200 --> 00:18:06.920 The problem manager, who might be part of a shared 335 00:18:06.960 --> 00:18:10.640 services team or even embedded within larger DevOps teams, works 336 00:18:10.640 --> 00:18:13.920 to prioritize these problems. The resolution then gets fed back 337 00:18:13.920 --> 00:18:16.519 into the development backlog, planned into sprints. 338 00:18:16.720 --> 00:18:19.240 Ah, so the fix becomes a work item for the 339 00:18:19.279 --> 00:18:19.960 DevOps team. 340 00:18:20.079 --> 00:18:24.200 Exactly. The solution is developed, tested through the CICD pipeline, 341 00:18:24.359 --> 00:18:27.599 and deployed like any other feature or fix, ensuring permanent 342 00:18:27.599 --> 00:18:29.000 solutions are rolled out efficiently. 343 00:18:29.079 --> 00:18:31.799 Okay, that integration makes sense, and that leads us nicely 344 00:18:31.839 --> 00:18:35.200 to release management, actually delivering these changes and fixes with 345 00:18:35.319 --> 00:18:36.359 speed and control. 346 00:18:36.559 --> 00:18:40.319 Right ITIL traditionally defined releases as a collection of changes, 347 00:18:40.720 --> 00:18:43.839 often bundled into release units or release. 348 00:18:43.599 --> 00:18:45.920 Packages, and deployment approach is varied. 349 00:18:46.039 --> 00:18:48.319 Yeah, you had the big bang, everything goes out at once, 350 00:18:48.720 --> 00:18:51.519 high risk, high reward. Maybe be risk definitely or the 351 00:18:51.559 --> 00:18:54.519 phased approach, which is much more common now deploying to 352 00:18:54.599 --> 00:18:58.880 specific regions or user groups in stages. Think about how 353 00:18:58.920 --> 00:18:59.960 iOS updates roll out. 354 00:19:00.319 --> 00:19:02.839 Yeah, not everyone gets it on day one exactly. 355 00:19:03.319 --> 00:19:06.920 That phased approach is great for managing risk, learning quickly 356 00:19:06.960 --> 00:19:10.279 from a smaller group, and minimizing the blast radius if 357 00:19:10.279 --> 00:19:11.240 something does go wrong. 358 00:19:11.400 --> 00:19:15.039 So how does this look in DevOps? Releases still exist, right, Oh. 359 00:19:15.000 --> 00:19:19.119 Yes, but release management becomes much more iterative. For longer 360 00:19:19.160 --> 00:19:23.160 projects or coordinated releases across multiple teams. You often see 361 00:19:23.200 --> 00:19:28.440 planning done through agile release trains arts, a concept from 362 00:19:28.440 --> 00:19:29.920 the scaled agile framework. 363 00:19:30.039 --> 00:19:32.559 Okay, but here's another one of those provocative points from 364 00:19:32.559 --> 00:19:37.079 the source material. Automation has simply killed the release management 365 00:19:37.119 --> 00:19:38.559 team for the repetitive stuff. 366 00:19:38.640 --> 00:19:41.160 Uh. Yeah, that's a bold statement, but there's truth to it. 367 00:19:41.319 --> 00:19:45.400 So if the machines handle the gruntwork, the building, the testing, 368 00:19:46.440 --> 00:19:48.839 the deploying, what's left for humans and release management. 369 00:19:49.079 --> 00:19:52.559 It's the cognitive work, the planning, the strategic thinking, the 370 00:19:52.680 --> 00:19:57.319 risk assessment, coordinating dependencies between teams, the final GONA GO reviews, 371 00:19:57.640 --> 00:20:01.799 the communication, the post release and analysis. These things still 372 00:20:01.839 --> 00:20:06.359 absolutely require human intelligence and judgment. Automation handles the how 373 00:20:06.640 --> 00:20:08.440 humans focus on the what, why, and when. 374 00:20:08.720 --> 00:20:12.160 So the role evolves, it doesn't necessarily disappear. It becomes 375 00:20:12.160 --> 00:20:13.720 more strategic, exactly. 376 00:20:13.720 --> 00:20:17.519 It's a powerful shift in focus. And this transformation also 377 00:20:17.640 --> 00:20:22.000 brings deployment strategies like blue Green deployment to the forefront. 378 00:20:22.200 --> 00:20:23.880 AH blue Green explain that quickly. 379 00:20:23.960 --> 00:20:27.519 Sure, it's a fantastic way to achieve deployments with effectively 380 00:20:27.680 --> 00:20:32.839 zero downtime. You run two identical production environments in parallel. 381 00:20:33.160 --> 00:20:34.240 Let's call them blue and green. 382 00:20:34.359 --> 00:20:35.799 Okay, two identical setups. 383 00:20:35.880 --> 00:20:39.240 Right, one say, Blue is live serving all your user traffic, 384 00:20:39.599 --> 00:20:42.880 the other, Green is idle or passive. You deploy your 385 00:20:42.880 --> 00:20:44.039 new release to the green. 386 00:20:43.880 --> 00:20:46.480 Environment while Blue is still running the old version exactly. 387 00:20:46.720 --> 00:20:50.759 You can then thoroughly test Green smoke tests, integration tests, 388 00:20:51.079 --> 00:20:53.519 maybe even route some internal traffic to it. Once you're 389 00:20:53.519 --> 00:20:57.319 completely confident, you flip the switch. You redirect all the 390 00:20:57.400 --> 00:21:00.359 live traffic from Blue to Green. Green is now live 391 00:21:00.759 --> 00:21:03.599 serving the new version. Blue is now idle and becomes 392 00:21:03.640 --> 00:21:07.160 your rollback environment if needed, or the staging area for 393 00:21:07.200 --> 00:21:07.920 the next release. 394 00:21:08.279 --> 00:21:12.640 Slick like having a standby runway, always ready for takeoff. 395 00:21:13.200 --> 00:21:14.640 Continuous availability. 396 00:21:14.759 --> 00:21:15.359 That's the goal. 397 00:21:15.559 --> 00:21:18.559 And this brings us to another really significant role transformation 398 00:21:18.640 --> 00:21:22.480 mentioned in the book, the product owners. They're emerging as 399 00:21:22.960 --> 00:21:24.640 the new release managers. 400 00:21:25.079 --> 00:21:26.279 That's a fascinating point. 401 00:21:26.319 --> 00:21:29.799