ITIL and the Operational Side of DevOps

This session has two halves. The first half recaps what was covered in the first session — how DevOps reshapes each phase of the software development life cycle, why the waterfall model still survives, and what Agile is really about. The second half goes deeper into the operational side: ITIL, the framework of best practices that tells a service industry how to run its IT services. ITIL was left out of the first session because of time constraints, so it gets the full treatment here, including a long look at service level agreements and a complete walkthrough of the five ITIL phases using a house-building example.

By the end of this session you should be able to answer four questions. What changes in each SDLC phase when a team works in a DevOps way? When is the old waterfall model still the right choice, and what does Agile actually change? What are the five ITIL phases, and what does each one contribute to running an IT service? And how do the agreements — the SLA, the OLA, and the UC — fit together so that a promise made to a customer is a promise the organization can keep? The session closes with the real-world evidence for ITIL and a first look at how DevOps plans to combine the development and operation teams that ITIL keeps separate.

2.1 SDLC Phases Through a DevOps Lens

The software development life cycle (SDLC) has six classic phases: requirement analysis, design, development, testing, release, and maintenance. The first session looked at what DevOps changes in each of them. The core pattern running through all the changes is the same: go from big-bang, one-time activities to small, frequent, feedback-driven ones. In the traditional way of working, requirements were gathered once at the start, the whole system was built in one long stretch, testing happened at the end, and the finished product was handed over in a single big release. DevOps takes each of those phases and asks the same question: can we do this more often, in smaller pieces, and with a faster loop between doing, checking, and learning?

2.1.1 Requirement Analysis and Design: Iterative and Minimal

For requirement analysis, DevOps suggests an iterative way of gathering requirements. You should not collect the full set of requirements in one phase and consider it done. Requirements come in incrementally, and each round of feedback refines them. In practice this means the team starts with the few requirements it is most confident about, builds something, shows it, and lets what it learns shape the next round of requirements. The list is never "complete" in the traditional sense — it is a living list that grows and changes as understanding grows.

The design phase follows the same spirit: design around a minimal viable product (MVP), then move slowly and steadily toward the complete goal in iterative steps. The MVP idea means you build the smallest version that delivers value, ship it, learn, and expand. A useful everyday picture: think of crossing a muddy field. The first trip creates a rough path — that is the MVP. You walk it, see where it sinks and where it holds, and only then pave the parts people actually use. If you had poured a concrete road in one direction and the field turned out to lead somewhere else, the concrete would be wasted. The MVP is the cheap path that tells you where the expensive road belongs.

2.1.2 Development: Early Feedback and Modular Code

The development phase changes in two ways. First, involve the stakeholders, the business team, and customers early in development so you get feedback early. The working mantra for the development phase is "deliver early and deliver often." Early delivery means early feedback, and early feedback means you can act before the cost of a mistake explodes.

Second, keep the code modular. Modularity is a daily need. When your code is modular, every change and every enhancement is easy to grab: you can adopt the change and integrate the new code with the old code. A change touches one small, self-contained piece instead of rippling through a giant monolith. There is a second benefit too — if someone new joins the team, modular code is much easier for them to understand than a bulky single file running to 5,000 or 6,000 lines, which is genuinely tricky to crack. A 6,000-line file means a newcomer must hold the whole file in their head at once; ten 600-line modules let them understand one piece at a time, in the same way a book is easier to read as chapters than as one unbroken wall of text.

2.1.3 Testing: Continuous and Automated

DevOps identified that testing should be continuous. Wherever you can, accommodate automation. All the testing phases you planned for your project — integration testing, system testing, acceptance testing, capacity testing, whatever you have — should run continuously, and the tests should be triggered automatically by your continuous integration (CI) server. No one waits for a tester to remember to click "run." The pipeline does it.

2.1.4 Release: Delivery, Deployment, and Release

"Deliver often and deliver early" does not mean pushing code to your own internal servers. When the professor says deliver early and often, the target is the production environment — not staging, not pre-production, not a capacity-testing server. The code goes to production as often as possible so the end customer can test it live and give feedback, and so features reach the market early. Code that sits on an internal staging server generates no market value and no customer feedback; only code the customer can actually touch earns either. This leads to a careful three-way distinction that keeps confusing people:

So you can deploy without releasing, and you can deliver without deploying. The feature is only "released" when the customer can actually use it. Three examples make the boundary concrete. Your team delivers when it moves the build into the staging environment for a final test round — the code is somewhere internal, but no customer can see it. Your team deploys when it puts the new version into production on Friday night — the code is now running on production servers, yet if the feature is switched off behind a configuration flag, customers still cannot use it, so it is not released. Only when you flip that flag and the feature becomes visible to customers is the release complete. Getting these three words mixed up is one of the most common mistakes in this course, and it is worth memorizing them cold.

2.1.5 Maintenance: Corrective, Adaptive, and Proactive

Maintenance comes in two kinds. The first corrects the system — if bugs exist in the existing system, you correct them. The second evolves the system — you enhance your product by adding features. Even with full automation, maintenance can never be completely avoided: the code you write is written by the manual logic of employees, so problems and issues will still come across. Automation removes the predictable human slips — forgetting to run a test, misapplying a config change — but it cannot remove the fact that a human designed the logic, and new logic always carries new risks. What DevOps changes is the attitude. Instead of being reactive, be proactive. Set up continuous monitoring so the system identifies a problem and fixes it before the problem ever reaches the customer. The system should catch it first. The exact phrases used in class for the two maintenance types are "correct you" and "evolve with you," which is a handy memory hook: maintenance either fixes what is broken or grows the product, and in both cases the monitoring should be watching for trouble before the customer reports it.

2.2 The Waterfall Model Today

The first session covered the waterfall model in detail: its advantages, its drawbacks, and the amendments made to it over time. The important conclusion for the exam: waterfall is not dead. A couple of organizations still adopt it, and there are two clear situations where it is the right call. The waterfall model works by converting the software development life cycle into a strict sequence of phases — requirements, design, development, testing, release — where each phase finishes before the next one starts, like water falling from one shelf of a staircase to the next. Its famous weakness is that feedback only arrives at the end, when the whole product is assembled. Its hidden strength is that a sequential flow is simple to plan, simple to budget, and simple to audit. The two situations below are where that strength outweighs the weakness.

2.2.1 Hybrid Waterfall-Agile

The hybrid way works like this: the organization follows agile scrum for the iterative, incremental approach, but once a sprint starts, they follow the waterfall model inside that sprint to implement it. The sprint becomes their complete goal. The reasoning: if the problem is known and the team is completely aware of the technologies involved, they can commit to the waterfall sequence for one sprint, finish it, then do the same for the next sprint. This hybrid pattern is what many organizations opt for.

2.2.2 Where Waterfall Still Wins

Manufacturing and similar domains still follow waterfall because their problem statements are clear. Take a car as an example: the variations are only in car size, body, paint, and chassis. They are sure how to create a car. The industry also works across multiple sites and cannot be co-located in one location; the project size itself is large. In that case waterfall is the best fit because requirements are stable, the budget and schedule are fixed and known, and there are no extra costs. Converting the SDLC into sequential phases is all waterfall asks for. You do not need to hire a scrum master, hire a product owner, or give training to scrum teams — nothing of that sort is required.

Real-world: this is why regulated, hardware-heavy industries (manufacturing, construction) stay with sequential delivery while software teams move to iterative delivery. Bridges and aircraft cannot be "shipped and fixed after feedback" the way a web app can — the requirements are fixed by physics and regulation, and the cost of a late rework is enormous, so the predictable sequential plan wins.

When to pick which: choose waterfall (or a waterfall-inside-a-sprint hybrid) when the problem and the technologies are well known and the requirements are stable; choose agile when the market is uncertain and the team needs customer feedback to steer the product.

2.3 Agile: Breaking the Wall Between Teams

If waterfall still works in places, why did Agile exist at all? The motivation is the wall between the business side — the customer and stakeholders — and the development team. In traditional delivery, the business hands a requirement document over the wall, the development team builds in isolation for months, and the first real conversation happens at delivery time — which is also the moment the business discovers whether the team built the right thing. Agile reorganizes the work so that conversation happens constantly instead of once.

2.3.1 Why Agile Exists

Agile exists to break that wall and to increase productivity by getting feedback in an interactive, incremental way, working with speed. It minimizes the fear between teams: you get feedback early from the customer, and if you need anything, you can reach out to the customer directly. Working iteratively and incrementally lets you get feedback wherever you need it, and that is what minimizes risk. Picture the wall again: on one side the business, on the other the developers, and every question, doubt, or wrong guess has to travel over the top — slowly, formally, and late. Agile removes the wall, so a developer who is unsure about a requirement asks the customer that same day, and a customer who sees a wrong feature says so after the first iteration instead of after the final delivery. Each small iteration becomes a checkpoint where the two sides re-align, which is why risk shrinks even though the pace is fast.

2.3.2 The Agile Values

Agile's main agenda is that every iteration or every increment should deliver working software. In the words of the four values, Agile focuses on:

• Working software over comprehensive documentation
• Customer collaboration over giving more time to contract negotiation
• Responding to change over strictly following a plan

The values are not a rejection of the things on the right — documentation, contracts, and plans all still exist — they are a statement of what gets priority when the two sides conflict. The fourth value of the manifesto, "individuals and interactions over processes and tools," was covered in the first session together with the agile roles, and the same priority logic applies: the people doing the work matter more than the process machinery around them.

The value of the correction is easy to miss: "responding to change over following a plan" reads, on the surface, as permission to wing it. The professor's point is that the plan remains the team's skeleton — the sprint backlog, the iteration goals, the release timeline — but it is a skeleton that can bend. If the customer's need shifts, the team's job is to change the plan to fit the need, not to defend the old plan.

2.3.3 The Methodologies Ahead

The upcoming sessions will cover these methodologies in depth: Scrum, XP (extreme programming), TDD (test-driven development), and BDD (behavior-driven development), among the others on the list. The full list of methodologies mentioned for the coming sessions is Scrum, XP (extreme programming), TDD (test-driven development), BDD (behavior-driven development), and FDD (feature-driven development). To keep them apart, hold one line for each: Scrum organizes the work into fixed-length sprints with roles like the scrum master and the product owner; XP (extreme programming) is a set of engineering practices such as pair programming and frequent small releases; TDD (test-driven development) writes a failing test before the code so the test drives the implementation; BDD (behavior-driven development) phrases the tests as customer-visible behaviors — given, when, then; and FDD (feature-driven development) plans and builds the system feature by feature. The first session also covered the roles of Agile, and ended with a YouTube link that students were asked to watch before this session. Later sessions will pick these up again, so treat this section as the foundation, not the whole story.

2.4 ITIL: A Framework of Best Practices

The main topic of this session is ITIL — the Information Technology Infrastructure Library. It is called a library because it is a set of books, or publications. ITIL is a framework of best practices for delivering IT service. The best practices are written into publications, one per phase, and out of those best practices the industry picks whatever suits it to run a smooth operational method. The word "framework" matters: ITIL does not dictate one rigid procedure that every company must copy in full. It offers a shelf of proven practices, and each organization selects the ones that fit its own services, customers, and constraints — the same way a real library lends you only the books you need, not the whole building.

2.4.1 What ITIL Is

ITIL is the framework of best practices behind IT service management (ITSM) — the ITIL processes within IT service management. It ensures that IT services are provided in a focused, client-friendly, and cost-optimized manner. Take a service industry as an example: the company wants to give more focused service, the service should be client friendly, and the delivery should be cost-optimized so that revenue is generated. ITIL is the systematic approach that makes that possible.

A useful piece of history: ITIL began as a standardization effort started by the government of the United Kingdom in the 1980s, when large public-sector organizations realized that IT departments were reinventing the same operational procedures independently of each other. Writing the good habits down once — instead of rediscovering them in every new organization — is the entire spirit of the library.

2.4.2 What ITIL Gives a Business

The systematic approach of ITIL helps businesses in several connected ways. It manages risk well. It strengthens the relations between the service industry and its end customer. It creates cost-effective practices and makes revenue out of them. It builds a stable IT environment. And once you achieve all of that, the business is allowed to grow, scale, and move through change. The list is a chain rather than five separate prizes: risk management keeps surprises small, stable environments make delivery predictable, predictable delivery builds customer trust, and trust plus cost control is what lets the business take on growth without breaking what already works. A business cannot scale confidently on top of an unstable IT environment — the growth step only becomes safe after the first four links are in place.

2.4.3 The Five Phases at a Glance

ITIL has five phases, each backed by its own book of best practices:

One structural note: all five phases contain processes, but only one phase contains functions — service operation. That distinction (process vs function) matters for understanding what service operation does. A process is a sequence of activities that turns inputs into outputs — handle a ticket, fix an outage, approve a change. A function is a standing team or unit with a job to do — the service desk, the technical support team. Every phase runs processes; service operation additionally has the teams that staff them.

2.5 Service Strategy

Service strategy is where the industry decides what it wants to be and what services to offer. It is organized around the four P's, and it contains four processes. Strategy is the "before anything else" phase: it sets the vision and the direction, and every later phase — design, transition, operation, improvement — works within the choices made here. A useful way to hold the phase in mind: strategy decides where the organization wants to be, honestly measures where it currently is, and chooses the path between the two.

2.5.1 The Four P's

Position is the "what is our advantage" question; plan is the "what exactly will we do" question; pattern is the "how do we execute cleanly" question. The four P's form a natural order. Perspective names the destination: what the industry wants this service to be. Position looks sideways at the market: the same service idea exists in several competitive service industries, and the organization must say what add-on its version brings to the customer — faster response, better price, a feature nobody else has. Plan turns the vision and the add-on into a concrete list: the activities and tasks that have to run. Pattern governs the way those tasks are executed — the policies and standards that keep the execution smooth, consistent, and repeatable, so the plan is not reinvented differently every time it runs.

2.5.2 Demand, Portfolio, Money, and Relationships

Service strategy contains four processes. Demand management means identifying what the current demand is in the market, grabbing that demand, and converting it into a service. It covers what the customer needs right now and what the customer might ask for — everything about the current market demand. If customers are asking for faster invoice processing today and for analytics tomorrow, demand management is the process that hears both requests, sizes them, and decides which one deserves a service. It is the listening process of strategy.

Service portfolio management keeps a portfolio of every service the industry provides to all its different customers. The portfolio holds three kinds of services: retired services (expired, no longer activated, nobody uses them anymore), active services, and planned or upcoming services. The reason to keep the portfolio is that from past and existing services you can generate ideas — combine one or two services and make a new service out of them. The portfolio is the strategy phase's memory: it records what the industry has done, does, and intends to do, and that full picture is the raw material for new service ideas. A retired service is not wasted history — it is a proven building block that can be combined with a live one.

Financial management comes in before you implement a service. The industry has to validate that the service is financially suitable: does the company have a good enough amount of cost for implementing this service, will the service generate revenue, and is it strategically suitable for the industry? All of that analysis happens in financial management. It is the gatekeeper that asks three questions about every proposed service: can we afford it, will it pay for itself, and does it fit the strategy? A service that fails any of the three is redesigned or dropped before a single server is bought.

Business relationship management (BRM) is the fourth process. Every service industry has a BRM role. When industry XYZ gives service to customer company ABC, ABC becomes the customer, and one person is dedicated to ABC. That person's job is to keenly observe how the customer works and uses the tools and technology, and to identify what the customer will need in the future. BRM does two things at once: it identifies new service needs, and it keeps the current relationship strong. The dedicated person acts as the customer's voice inside the service industry: because they watch how ABC actually works, they can spot a future need before ABC itself files a request — and because ABC knows one person owns its relationship, the day-to-day contact stays smooth.

2.6 Service Design

Service design is where the service itself is designed along with the agreements that govern it. Its lead process is service level management, which the professor spent the most time on — a signal that it is a high-value topic. If strategy answers "why should this service exist," design answers "what exactly is the service, and what exactly will we promise about it?" The promise is the delicate part, because a promise signed too loosely leaves the customer unprotected, and a promise signed too ambitiously guarantees a penalty later. The design phase exists to make the promise both strong and honest.

2.6.1 Service Level Management and the SLA

In service level management, the service industry finalizes the SLA — the service level agreement. The SLA is the agreement signed between the provider and the customer about completing tasks within agreed timeframes. Every ticket has an SLA: within a defined timeframe, you as the service industry have to respond to the customer. SLAs get defined in many ways. A typical example: within 30 minutes of a ticket being raised, the customer gets a notification or acknowledgement that the ticket has been received. After that, within a minimum of two to three hours, the problem is identified along with the possible remedies — there can be multiple remedies. Then, over the next three hours, the solutions become available.

The key word in the definition is "agreed": an SLA is not a one-way guarantee the provider dreams up. It is negotiated and signed by both sides, and every later dispute about response speed is settled by looking at the signed agreement.

2.6.2 OLA and UC: The Two Ingredients of an SLA

An SLA is always a combination of two other agreements: the OLA and the UC.

The OLA is the operational level agreement — the internal agreement. For one service, several different teams inside the same organization may be working: one team looks after the database part, another works on one feature of the service. If something goes wrong, you are dependent on those different internal teams. The OLA fixes how much time each internal team will need to respond, fix something, or give a solution for any problem or issue. It is an internal SLA, an agreement between the internal teams.

The UC is the underpinning contract — the agreement signed with providers, also called vendors or suppliers. The service industry often buys part of the capability from a third party: infrastructure, storage, database support. The UC fixes the vendor's timelines for those parts. The terminology to remember: the service industry gives the SLA to the customer, the service industry has the OLA internally, and the UC is with the vendors.

2.6.3 Worked Example: The Failed Disk

Here is the full scenario the professor used to show why the UC has to be part of the SLA. You are a service industry and you provide a service to customer ABC. For storage you acquire disk storage from a storage vendor. One of the disks the vendor provided fails. Since that disk failed, a performance issue shows up in your service. The customer ABC raises a ticket: sometimes the service completes in about two minutes, and sometimes there is a lag and the response time goes to six to seven minutes.

As an operational or maintenance team member, you start identifying where the problem is — looking at the logs and the events that happened. From the logs you see a delay in the response. You conclude the problem is with the hardware. (The professor's honest aside: it is not easy to identify the problem, sometimes it takes a huge amount of time.) Say you identify a failed disk, and the storage device is not in India — it is outside the country. Now you have to reach out to the vendor: "this is what the disk is, it failed." The vendor goes and replaces the disk with a working disk, and that is how you restore the service.

2.6.4 The Rest of Service Design

The remaining service design processes, briefly but completely:

• Supplier management (also called vendor management): manage and maintain all the information about vendors — the contract, the contract negotiation, when the service is going to end, whether to renew it, and when the renewal is due.
• Capacity management: if a thousand end users access the service at the same time, how much capacity do you need? And as the number of end users grows, how do you scale the capacity up, and how do you downgrade it again when demand drops, to manage the cost for the customer?
• Availability management: this is where the nines come in. Organizations commit that the service will be available for 99.9 percent, or 99.99 percent, and a few organizations commit to 99.999 percent. The availability percentage is the promise.

• Continuity management: since no industry accepts 100 percent — they say 99.9 or 99, whatever suits them — there is still a chance of failure in that small remaining slice. If the service goes down, how much time does your team need to make the service up and continue? That process, including how you manage the penalty and accommodate the customer, is continuity management. Two numbers steer it: the RTO (recovery time objective), the maximum time the service may stay down after a failure, and the RPO (recovery point objective), the maximum amount of recent data the organization is willing to lose. A backup taken every hour means at most one hour of data loss — an RPO of one hour; a recovery plan that restores service in ten minutes has an RTO of ten minutes.
• Information security management: the customer is god for any service industry, and you do not want to leak their information to the market. This process guarantees that the data coming from the customer stays confidential, that integrity is intact, and that no unauthorized user can access the service. Three properties, three promises: confidentiality (only the customer and the authorized provider see the data), integrity (the data is not altered by accident or attack), and access control (no unauthorized user can reach the service). The professor's way of saying it — treat the customer like god, never leak their information to the market — is the attitude the process is built to enforce.
• Service catalog management: the service catalog is a subset of the service portfolio. The portfolio lists everything the industry can provide; the catalog holds only the services designated for one particular customer. For customer ABC, the catalog shows all the services being provided to ABC. The portfolio is the full shelf; the catalog is the single customer's shopping list — ABC should see only what ABC is entitled to, not the industry's entire portfolio.
• Design coordination: the best practices for coordinating among all the processes of service design while you are actually designing the service.

2.6.5 The SLA, Re-explained

Later in the session, a student asked to hear the SLA explanation again, and the professor re-explained it — which is the clearest version of all. When any industry provides a service to a customer, the service can be anything: a product, database management, managing their infrastructure. They need to agree on an SLA: if some issue or problem comes up in the service, if there is a ticket, what timeline have you agreed to mitigate that issue, or to give a remedy or solution for that issue raised by the customer. The SLA should always be calculated by considering both the OLA and the UC: the internal teams' response times (how long the network team takes for a network issue, how long the database expert needs to correct a database schema, how long the development team needs to produce a patch solution), plus the vendor's timelines for the parts the vendor owns (how long the third-party vendor needs to identify and resolve a hardware problem).

2.7 Service Transition

Service transition is the planning phase — what activities have to be completed to finish the service and make it available to the customer, essentially pushing it into the production environment. Between design (where the service is drawn) and operation (where it runs day to day) stands all the work of actually getting it live: scheduling the change, preparing the environments, checking the new version is fit to use, and making sure the knowledge needed to run it exists. Strategy and design answer "what," transition answers "how do we get it there safely."

2.7.1 Change Management and Zero Downtime

Change management manages and controls the life cycle of changes by making sure a change does not impact the availability of the current service.

The professor's example: you provide a service where report generation happens for one customer at a time. You want to enhance it so that 10 people can download the report at the same time. To enhance something you have to change your code, and that change becomes the upgrade of your service.

2.7.2 Assets, Configuration, Validation, and Knowledge

Asset and configuration management maintains the assets and their respective configuration settings. An asset is a piece of the system, and its configuration is exactly how that asset must be set up.

Service validation and testing makes sure, before pushing to production, that the service has quality — that it is fit to be used by the customer. This is the design phase's promise being checked against reality: the service must not only work on a developer's machine, but work in a production-like environment with real configurations and real integrations.

Release and deployment management maintains and manages the deployment strategies: looking at the cost, which strategy should be managed, and how to get zero downtime. The strategies your team must adhere to live here. This is where the release patterns come in — redeploying the previous known-good version to roll back, running blue-green pairs so the switch is a router flip, or rolling a canary out to a small user group first. Each strategy trades cost against speed and risk, and release and deployment management is the place where that trade is decided in advance rather than improvised on release day.

Evaluation evaluates your infrastructure monitoring, your service activities, and all your asset configurations, making sure everything is intact. After a transition, the service must be confirmed whole: monitoring is in place, activities behave, and every asset still matches its recorded configuration.

Knowledge management stores the knowledge of all past and current services. The professor's line of reasoning: whenever we do something we learn from our own mistakes. If you made a mistake while implementing one service, you can store the details — what the mistake was, how you accommodated it, what risk was identified, what mitigation the team applied. Stored and accessible at the organizational level, that knowledge lets other services be designed and delivered in a better way. Real-world: this is the principle behind runbooks and post-incident reviews, where the organization's past failures become the training data for future operations. A runbook is the written version of "the last time this failed, here is what we did"; a post-incident review is the meeting where the mistake becomes that written knowledge. The service that fails twice because the first failure was never recorded is paying for the absence of knowledge management.

2.8 Service Operation

Service operation is what runs after the service is deployed — the day-to-day operations. It is the only phase with functions; it also has five processes. Every ticket, every login, every slow afternoon and every fire drill happens here. If service transition is the handover ceremony, service operation is the marriage that follows — the long-term, undramatic, endlessly repeated work of keeping the promise made in the SLA.

2.8.1 The Processes

Event management manages and maintains the track of all events. An event is everything: if somebody logs in by giving a user ID and credential and clicking the login button, that is an event; report generation is an event. Any input given by your customer to your service becomes an event. Even the normal flow is an event. Event management does not wait for trouble — it records the service's whole life: successful logins, failed logins, report runs, configuration changes. A stream of normal events is the baseline; a deviation from that baseline is what deserves attention.

Incident management handles things that go wrong. If the login happened but was not successful — even though the user ID and password were correct — there was a problem: the service did not respond the way it has to. That is an incident. Incident management tracks all the incidents: what happened, how the solution was provided, and how the root cause analysis is done. The word "even though" matters here: the user did everything right and the service still failed to respond as it should — the login event occurred, but the service did not deliver the login outcome, and that gap between event and expected outcome is exactly what makes an incident.

Problem management wants to minimize the frequency of incidents and the impact of each incident. When a problem is known — the root cause analysis is done and documented — a team member can immediately access that problem and look for the mitigation or solution and implement it. So the contrast to keep straight: an incident is the single failure event; the problem is the underlying cause, and fixing the problem is what cuts the frequency and impact of future incidents.

Request fulfillment covers things the customer requests that are not incidents. Changing a password is a request, not an incident. Modern systems are designed intelligently: you get a button or a link to click to change the password yourself, instead of raising a ticket or asking the service provider to do it. Request fulfillment is about fulfilling those self-service requests. The test for "request, not incident": nothing is broken — the customer simply wants the service to do something normal for them, like reset a password or provision access to a tool.

Access management controls who can access what. A service provides multiple access levels tied to roles and responsibilities: an admin role, a user role, and a super admin role, among others. Access management decides which role gets which accessibility — an end user should not be able to access the code or the admin parts like changing the layout or changing inventory in the application. Role-based access is the practical answer to "who can do what": the user role sees the product, the admin role changes content, the super admin role changes the system itself, and access management keeps each person locked to the narrowest role that does their job.

The chain to remember: events are the stream, incidents are the exceptions in the stream, and problems are the reasons the exceptions keep happening. You fix incidents to restore service today; you fix problems to make the incidents stop.

2.8.2 The Functions: Service Desk and the Support Tiers

Service operation has three functions that keep the operation part running smoothly. The service desk is the L1 support. Nowadays the service desk has been minimized as much as possible by introducing bots. If you have a small issue you log in, the chat box pops up, and the bot responds: "if you have a problem in logging in, do this, do this, and it will reset." Everyone wants a quick solution, so you no longer wait on a call until an expert talks to you.

Technical management is the next tier. If the service desk could not identify the issue and provide a solution, it escalates to the technical management team. If even that team cannot manage, it goes to application management — the L1, L2, L3 support chain in action. Real-world: this escalation ladder is exactly how modern IT help desks work, with self-service bots absorbing the first wave of simple issues. Each tier is a filter: L1 (the service desk and its bots) handles the frequent, simple, well-known cases; L2 (technical management) handles issues that need deeper technical knowledge of the infrastructure; L3 (application management) handles the hardest cases that reach into the application code itself. An issue climbs the ladder only when the tier below cannot resolve it, which is what keeps the most expensive experts working on the smallest number of tickets.

2.9 Continual Service Improvement

The fifth phase of ITIL is continual service improvement (CSI). It exists to make sure the industry keeps improving its processes so it can reach its vision and mission. Where the other phases deliver a state (designed, deployed, running), CSI delivers a motion: the service and its processes getting measurably better, cycle after cycle, without a finishing line.

2.9.1 Continual, Not Continuous

The word choice matters. It is continual, not continuous. Continual means stepwise improvement — you improve process efficiency step by step. Continuous improvement, by contrast, would mean the end goal is achieved in a single instance. ITIL is firmly on the continual side: the end goal never arrives in one shot; you keep climbing. The two words look almost identical and describe completely different behaviors. "Continuous" suggests one smooth run straight to the destination — as if a process could be fixed perfectly in a single pass. "Continual" describes what real organizations can actually do: take a step, measure the result, take another step. Each step is complete in itself, and the destination keeps moving, because the vision and mission of the industry evolve too. That is why the phase is called continual service improvement, and why any exam answer should use that exact word.

2.9.2 The Marathon Analogy

The professor's analogy: say you want to participate in a marathon and you are totally new to running. You need to practice. Your mission is to participate in the marathon. Initially your goal is modest — one kilometer completed in 30 minutes. Once you reach that, you improve your running stats: now complete one kilometer in 20 minutes, then in 15 minutes. Once you finish one kilometer in 15 minutes, you judge yourself ready to achieve the mission and participate in the marathon. It is an ongoing process: you have to keep improving your process so you can achieve the mission and vision of your industry. That is why continual service improvement is the fifth phase — it never ends.

The same shape applies to an IT service: the improvement goal this quarter might be "resolve 90 percent of tickets within the SLA," and once that is measured and achieved, the goal tightens to 95 percent, then to 99 percent. The systematic version of this is the seven-step improvement process used in CSI: define what should be measured, measure it (establishing a baseline), process and analyze the data, present the findings, and implement corrective actions — then loop back and measure again to see whether the step actually improved the process. What the marathon and the seven steps share is the engine of improvement: set a step, measure the baseline, act, and re-measure.

2.10 The House-Building Walkthrough

The clearest way to see all five ITIL phases working together is the house-building example: a walkthrough that maps ITIL to building a new house.

2.10.1 Strategy and Design of the House

"I want to build a new house" is the service strategy — your thought about what you want to achieve. All strategical decisions in an IT organization are strategy: the vision and mission of the organization are its strategy, and how to achieve the goal is all strategical decisions. The walkthrough's example: an organization wants to be listed among the Fortune 500. That ambition is its strategy. Notice how much is already decided in that single sentence: the organization will be large, visible, and financially strong — every later design and operation choice is steered by that ambition, exactly as "I want a big house with a garden" steers everything from the foundation to the furniture.

The house plan, or blueprint, is the service design. Service design talks about the money needed to build the house, the availability of land, the timelines of completion, and the suppliers providing raw materials for construction. Design is where the plan and the budget meet. The blueprint is not the house — it is the agreement about the house before anyone pours concrete: what it will cost, on which land, by when, and from which suppliers the bricks and cement come. An IT service design does the same: the service's capabilities, its budget, its delivery timeline, and its vendors, all fixed on paper before the transition phase starts.

2.10.2 Building and Living in the House

Service transition is more about project management. In the house example, the builder is the project manager; the person funding the construction is the sponsor. The key components of transition: the builder has the knowledge of building a house; the change is constructing a new building; you maintain all required assets; you plan the construction duration and provide support as appropriate. The completion of the house construction is release management, and finally you evaluate the construction efficiency. Each transition concept maps one-to-one: the builder's expertise is the knowledge management of the project, the construction itself is the change, the materials and equipment are the assets, the schedule is the transition plan, and the day the family receives the keys is the release.

Service operation talks about day-to-day operations — buying household articles and living in the house. This is the phase most people are familiar with: incident, problem, event, service request, and access management. The walkthrough's image: "oh no, the kitchen is on fire" — that is an incident. "I don't know what to do" — "not to worry, I know what to do; we can call 9-1-1 and they will be able to help us out." All your day-in, day-out activities fall under service operations in IT: handling all tickets, monitoring the environment, restoring incidents. The kitchen fire is a perfect incident because it is a sudden failure to respond as expected — the kitchen was supposed to cook, not burn — and the call to 9-1-1 is the incident response: an agreed, known procedure that restores safety, the everyday equivalent of an escalation to the right team.

2.10.3 Improving the House

Continual service improvement means being clear about the term continual and not continuous: stepwise improvement of process efficiency, as opposed to continuous improvement where the end goal is achieved in a single instance. In the house, the household articles you upgrade as and when there is a new technology release — new features, a more user-friendly interface — are all continual improvements. The house gets better in steps, not in one shot. The kettle is replaced when a safer model appears, the lighting when a smarter one arrives, the doorbell when a video version is released — each replacement is a small, complete step, and none of them waits for "the perfect house" to be designed from scratch. That is continual improvement with a roof over its head.

2.11 ITIL: A Process, Not a Project

Two quick questions near the end of the discussion settled what kind of thing ITIL is and where it applies. The first question is about time — does ITIL end? The second is about scope — where does ITIL belong? Both answers are simple, and both are easy to get wrong on an exam.

2.11.1 The Project-or-Process Question

Asked whether ITIL is a project or a process, the professor answered without hesitation: it is a process. There is no fixed end date. A process is an ongoing thing — you are improving yourself. A project, by contrast, has the basic characteristics of a start date and a proper end date. ITIL has neither; it runs as long as the organization does.

When to call something which: if the work ends when a deliverable is handed over, it is a project; if the work must continue as long as the organization exists, it is a process — and running and improving IT services is squarely the second kind.

2.11.2 ITIL's Scope: Beyond Support Projects

The second question was whether ITIL can be applied only in a support or maintenance project. The answer is no — ITIL's scope is bigger than that. Even a product company, which has a product to sell to the market, needs an operational practice to manage the operation part of that product.

A related clarification came out of the same discussion. In the development phase you apply a development method — Agile. For the operational phase you follow ITIL. In the transition and planning phase, which is project management activity, you can apply any development method: waterfall, spiral, or agile scrum — whatever you want. All the other ITIL processes are relevant to the operational side. And here is the gap the professor flagged: there was no scope where we could combine the development team and the operation team and understand the working life cycle together — the operational team has a different goal than the development team, and that barrier existed. Bridging that barrier is exactly what the next sessions on DevOps are for. The three-way map to keep: development runs on Agile, transition runs on project management (any method you choose), and operation runs on ITIL — and the missing bridge between development and operation is the subject DevOps was born to build.

2.12 ITIL in the Real World, and What Comes Next

2.12.1 The Reported Business Benefits

The benefits of ITIL are documented in an industry report that lists case studies from real companies that adopted the framework:

These are the numbers to remember: 500 million dollars over four years, 40 percent fewer outages, 92 percent fewer critical incidents. They are also a reminder that ITIL is not academic — it is measured in money and downtime at companies of this scale. Two of the three results are literally dollars (the Procter & Gamble savings and the Nationwide return on investment), and the third is a count of business-critical incidents — which, at Capital One's scale, is also money, because every business-critical incident costs revenue and trust. When a framework can be summed up as "half a billion saved, nearly half the outages gone, nine in ten critical incidents eliminated," it stops being theory and becomes an investment decision.

2.12.2 SRE and the Road to DevOps

With the operational side now covered, the professor set up the bridge to DevOps by contrasting it with SRE. If you automate all your operations — all the phases of your operations — while keeping the maintenance or operation part of your service segregated from development, that is SRE (site reliability engineering). DevOps does not want to segregate. DevOps wants to combine your operation and your development. That single contrast — segregate-and-automate versus combine-and-collaborate — is the summary of why SRE and DevOps, close as they sound, are different moves.

Both SRE and DevOps accept that operations must be automated — nobody wants humans clicking through repetitive production tasks. The disagreement is about the boundary: SRE keeps the automated operation world as a separate discipline, engineered with software-engineering rigor; DevOps removes the boundary itself, so the team that builds the service also owns running it. The plan for the coming sessions: understand the development side, understand the operational side, and then discuss DevOps — with this session's ITIL content as the operational half of that picture.

Exam Guidance Summary

• Quizzes: after every tutorial session, a quiz opens and stays open for 24 hours. The quiz is purely MCQ. Once you start an attempt, it is time-bound: you must finish in 30 minutes. A request to extend the window to at least 48 hours for working professionals was raised and taken up with the operations team; watch the announcements for the final decision.
• Evaluation plan: a single consolidated document listing every evaluation component with dates and timelines is being created and will be announced on the learning portal. This is the authoritative calendar for quiz dates and assignment dates.
• Previous year question paper: it will be uploaded to the portal. Before the mid-semester exam, the session will spare 15 to 20 minutes to walk through the questions and the expected outcomes, so students know what to expect. This is done for every batch.
• Study resources: the textbook and reference books are listed in the course handout. For anyone who wants to scale further, more book names are available on request. Session recordings are available for anyone who misses a session, and the recordings also serve as the reference for assignment topics.
• Assignment scope: assignment topics come from what has been discussed in the sessions — review the material covered so far, with the recordings as backup.
• Course structure: the course runs 16 contact sessions plus 4 tutorial sessions. The tutorial sessions are industry-expert talks on the DevOps tool chain, CI/CD pipeline, GitHub, and Scrum, and each one is followed by its quiz.
• What to review before the exam: the delivery / deployment / release distinction, the waterfall-versus-agile reasoning, the agile values, the five ITIL phases, the four P's of service strategy, the service design processes, SLA = OLA + UC with its worked example, the nines (99.9, 99.99, 99.999 percent), event versus incident versus problem, the functions of service operation, continual (not continuous) improvement, and the reported ITIL benefits.

Key Industry Applications

• Real-world: DevOps-style delivery gets features into production frequently so customers test live and give feedback early; this is the pattern behind the release practices of modern software companies.
• Real-world: the hybrid waterfall-agile model — agile scrum for planning, waterfall inside each sprint — is what many organizations actually run in practice.
• Real-world: manufacturing and hardware industries (the car example) still run waterfall because requirements are stable, sites are distributed, and sequential phases cost nothing extra.
• Real-world: ITIL is used by service industries worldwide; the documented benefits include Procter & Gamble saving about 500 million dollars over four years, Nationwide Insurance cutting system outages by 40 percent, and Capital One reducing business-critical incidents by 92 percent over two years.
• Real-world: service level agreements with concrete numbers — a 30-minute acknowledgement, two to three hours to identify a problem and remedies, three more hours to solutions — are exactly how real ticket systems quote response commitments.
• Real-world: underpinning contracts with storage and infrastructure vendors cover third-party hardware replacement time, as in the failed-disk example, so the vendor's delay never becomes the customer's penalty.
• Real-world: availability commitments are quoted in nines — 99.9, 99.99, and up to 99.999 percent for the most demanding services.
• Real-world: service desks now rely on chat bots and self-service (the password-change button, the login-reset bot) so L1 support absorbs simple requests before escalation to L2 technical management and L3 application management.
• Real-world: knowledge management turns past mistakes into organization-wide runbooks so future services are designed better — the same idea behind post-incident reviews and documented root cause analyses.
• Real-world: ITIL applies to product companies too, not just support providers — any company selling a product needs an operational method for running it.
• Real-world: the distinction between SRE (automating segregated operations) and DevOps (combining development and operations) frames how modern organizations choose their reliability strategy.
• Real-world: the tutorial sessions connect directly to the industry tool chain — DevOps tooling, CI/CD pipelines, GitHub, and Scrum — as taught by industry experts.