IT Infrastructure Management and DevOps Study Notes

ITIL Service Strategy and Service Design

IT Services and Service Management

An organization uses information technology to achieve business results. A bank uses applications, databases, networks and support teams to process payments. A hospital uses them to maintain patient records and provide clinical information. The customer, however, does not usually want to purchase isolated servers, cables or administrator hours. The customer wants a dependable result: payments completed, records available or employees able to work.

An IT service is a way of delivering value to customers by helping them achieve desired outcomes without requiring them to own and manage all the specific costs and risks involved. Email illustrates this idea. A user wants to exchange messages reliably. The service provider combines mail software, identity systems, storage, networks, security, monitoring and support into one usable service. The user consumes the outcome instead of managing every component.

Service management is the set of specialized organizational capabilities used to provide value through services. It includes people, processes, information, technology, suppliers and management practices. Installing technology is only one part. The provider must also understand demand, fund the service, agree service levels, manage capacity, protect information and prepare for interruptions.

ITIL, historically expanded as Information Technology Infrastructure Library, is a widely used body of service-management guidance. The February 2026 syllabus uses the ITIL service-lifecycle vocabulary of ITIL v3 and its 2011 edition. In that version, the five lifecycle stages are:

1. Service Strategy decides which customers, outcomes and services the provider should pursue.
2. Service Design converts strategic decisions and business requirements into a complete, supportable design.
3. Service Transition builds, tests and moves new or changed services into use.
4. Service Operation delivers and supports services during daily use.
5. Continual Service Improvement (CSI) measures results and improves services and processes.

This chapter concentrates on the first two stages. Strategy asks, “What value should we create, for whom and with what investment?” Design asks, “How will the complete service meet those requirements throughout its life?”

Business need
     |
     v
Service Strategy: choose outcomes, customers and investments
     |
     v
Service Design: design service, architecture, processes and measures
     |
     v
Service Transition -> Service Operation -> Improvement feedback

ITIL Versions and Terminology

ITIL has been revised several times, and examination questions are easier to answer when the version behind a term is clear.

• ITIL v2 (early 2000s) was organized mainly around two books, Service Support and Service Delivery. It is historical.
• ITIL v3 (2007) introduced the five-stage service lifecycle described above, with one core book per stage.
• ITIL 2011 updated the v3 books without changing the five stages. It added or formalized processes such as Strategy Management for IT Services, Business Relationship Management and Design Coordination. Many people still call this edition "ITIL v3".
• ITIL 4 (2019) replaced the five lifecycle stages with the Service Value System (SVS). The SVS combines guiding principles, governance, a service value chain, practices and continual improvement. The value chain has six activities: Plan, Improve, Engage, Design and Transition, Obtain/Build, and Deliver and Support. ITIL 4 describes 34 practices instead of lifecycle processes, and it uses four dimensions of service management: organizations and people; information and technology; partners and suppliers; and value streams and processes.

The February 2026 syllabus names the lifecycle stages (Service Strategy, Service Design, Service Transition, Service Operation, CSI), so this chapter uses ITIL v3/2011 vocabulary. When a question refers to lifecycle stages, the Service Design Package, the Four Ps or provider Types I, II and III, answer in v3/2011 terms. Service Strategy and Service Design are not stage names in ITIL 4, even though many of the same activities continue as ITIL 4 practices.

Value, Outcomes, Costs and Risks

A service has value only in relation to the customer’s outcomes. An online-sales company may value a payment service because it lets customers complete orders quickly and safely. The same technical platform may have little value to an organization that does not accept online payments.

The provider must understand four connected ideas:

• An outcome is the result a stakeholder wants. “Orders can be paid online” is an outcome.
• A cost is money or another resource consumed. Hardware, licences, staff and downtime have costs.
• A risk is an uncertain event that could affect objectives. Data loss, demand spikes and supplier failure are risks.
• Value is the customer’s perception of the service’s contribution to useful outcomes, taking costs and risks into account.

The customer ultimately determines value. A technically elegant service can fail if it does not support the customer’s real work. Perception is influenced by present and past experience, competitor offerings, price, reliability and the customer’s position in its market.

Utility and Warranty

ITIL explains value through utility and warranty.

Utility is fitness for purpose: what the service does and whether that functionality supports the required outcome. A payroll service has utility if it calculates salaries, deductions and payslips correctly.

Warranty is fitness for use: assurance that the service will meet agreed conditions. It commonly concerns availability, capacity, continuity and security. The payroll service needs enough capacity at month end, must be available when payroll is processed, must protect salary data and must recover after failure.

Both are needed. A feature-rich application that is almost always unavailable has inadequate warranty. A perfectly available application that cannot produce the needed result has inadequate utility.

Resources, Capabilities and Service Assets

A service asset is any resource or capability used by a provider to deliver services. Resources are relatively direct inputs, such as infrastructure, applications, information, people and financial capital. Capabilities are the provider’s ability to coordinate and use resources, such as management, organization, processes and accumulated knowledge.

Buying another server adds a resource. Developing reliable incident response, capacity forecasting and supplier coordination builds capabilities. Competitors can often purchase similar hardware quickly; mature capabilities normally take time to develop and can become an important source of differentiation.

Customer assets also matter. A service creates value by improving the performance of the customer’s resources and capabilities. A sales application creates value only when salespeople, processes and information use it to produce business results.

Service Strategy

Service Strategy provides direction for the provider and its services. It identifies target customers, business outcomes, value propositions, constraints, investment needs and the organizational capabilities required to deliver. It prevents IT work from becoming an uncoordinated collection of technologies.

A sound strategy should answer:

• Which customers and market spaces will we serve?
• Which outcomes do those customers value?
• What services should we provide, change or retire?
• How will each service provide utility and warranty?
• What resources, capabilities, funding and relationships are required?
• How will the provider distinguish its offering from alternatives?
• What demand should be expected, and how will it affect capacity and cost?
• Who owns the decisions and results?

General Strategy and the Four Ps of Strategy

A strategy links the provider’s current position to a desired future. ITIL describes four entry points called the Four Ps of strategy:

• Perspective is the organization’s vision, values and direction. For example, a provider may aim to be the trusted supplier of highly secure financial services.
• Position is the stance taken in the market. A provider may compete through low cost, specialization, broad coverage, high utility or strong warranty.
• Plan is the coordinated path from the current state to the desired state. It assigns actions, investments, times and responsibilities.
• Pattern is the consistency visible in decisions and actions over time. Repeated investment in high availability demonstrates a high-warranty pattern.

These meanings should not be confused with the Four Ps of Service Design, which are People, Processes, Products and Partners.

Competition and Market Space

A market space is a set of business outcomes that a service provider can help customers achieve. It represents an opportunity, not merely a geographic market. “Remote employees securely access business applications” and “online buyers complete payment at any time” are examples of outcome-based market spaces.

Competition includes more than other companies. An internal IT unit may compete with outsourcing, cloud services, packaged software or the customer’s decision to do nothing. Strategic assessment examines:

• customer needs and changing preferences;
• alternative providers and substitute services;
• regulatory, security and contractual constraints;
• the provider’s distinctive resources and capabilities;
• cost structure, switching costs and barriers to entry;
• technologies and suppliers that may change the market;
• services that are valuable, profitable or difficult to replace.

Suppose an internal provider proposes a private file-sharing service. Users can already buy public cloud storage. The internal provider may choose a position based on integration with corporate identity, data-location control and tailored support. Those features matter only if they create outcomes the customers value.

Service Provider Types

ITIL identifies three provider types.

A Type I provider focuses on one unit and may understand it deeply. A Type II provider gains economies of scale by consolidating common services. A Type III provider assumes external commercial risk but can gain breadth from multiple customer types and depth from repeated delivery.

The type changes funding, contracts, competition and governance, but it does not remove the need for service management. Internal customers still require agreed value and service levels.

Customers, Users and Other Stakeholders

A customer buys or agrees the service and service-level targets. A user uses the service in daily work. They may be different people. A finance director may be the customer for payroll while employees are its users. A supplier is a third party that provides goods or services needed for delivery.

Other stakeholders include service owners, process owners, business managers, regulators, shareholders and support teams. Strategy must recognize their interests without losing focus on customer outcomes.

Service Management as a Strategic Asset

Service management becomes a strategic asset when its capabilities help the organization achieve goals in a way that is valuable and difficult to copy. Consistent processes, trusted relationships, operational knowledge and reliable measurement can make a provider more responsive and reduce cost and risk.

A provider’s service potential is its productive capacity represented by resources and capabilities. Improving monitoring, knowledge, automation and configuration control can increase this potential even when the number of servers does not change.

A service model shows how service assets interact with customer assets to create value. It describes both structure—how components fit together—and dynamics—how activities, information and resources flow.

Customer assets                 Service assets
people + process   <------>   applications + infrastructure
information                  people + suppliers + management
       \                         /
        \---- desired outcome --/

For an online admission service, customer assets include applicants, admissions staff and their procedures. Service assets include the portal, databases, payment gateway, engineers, supplier contracts and support processes. The model exposes dependencies and helps management decide where investment reduces risk or improves outcomes.

Developing a Service Strategy

Strategy development is not a one-time slogan. It is a decision process.

1. Define the market. Identify customers, business outcomes and possible market spaces.
2. Understand the customer. Learn the customer’s assets, constraints, preferences and definition of value.
3. Identify opportunities. Map outcomes to services and service assets.
4. Classify and visualize services. Create clear service models and value propositions.
5. Develop offerings. Decide the utility, warranty, service packages and target customers.
6. Develop strategic assets. Build the resources and capabilities needed to deliver repeatedly.
7. Prepare for execution. Set objectives, policies, priorities, funding and roles.
8. Measure and review. Use results, demand and customer feedback to refine decisions.

ITIL v3 groups these steps into four main Service Strategy activities, which are often examined by name:

ITIL 2011 expresses the same cycle through the Strategy Management for IT Services process: strategic assessment; strategy generation, evaluation and selection; strategy execution; and measurement and evaluation.

Objectives describe expected results; strategies describe how to reach them. A vague objective such as “improve IT” cannot guide consistent decisions. “Enable 99.9% monthly availability for online ordering before the seasonal sale” is measurable and connects to a business outcome.

Business Case, Governance and Risk

A business case justifies a significant expenditure or decision. It normally explains objectives, options, costs, benefits, risks, expected business impact and recommendations. It is a decision-support tool rather than a guarantee that benefits will occur.

Governance ensures that strategy and policy are implemented, responsibilities are defined, performance is measured and corrective action is taken. Governance decides direction and accountability; management plans and operates within that direction.

Risk management includes identifying risks, analyzing probability and impact, selecting responses and reviewing them because likelihood and impact change. For a new online service, risks might include supplier failure, insufficient capacity, data leakage and low user adoption. These affect both strategy and later design.

Service Strategy Processes

In the ITIL 2011 edition, Service Strategy contains five processes: Strategy Management for IT Services, Service Portfolio Management, Financial Management for IT Services, Demand Management and Business Relationship Management. The 2007 edition listed Strategy Generation, Service Portfolio Management, Financial Management and Demand Management, and treated the business relationship manager as a role. Service Strategy itself is a lifecycle stage, not a process.

The official scope emphasizes Service Portfolio Management, Financial Management and Demand Management. These processes interact: portfolio decisions choose services, financial management evaluates affordability, and demand management explains expected consumption.

Service Portfolio Management

The service portfolio is the complete set of services managed by a provider through their lifecycle. It contains:

• Service pipeline: proposed or developing services.
• Service catalogue: live services and services approved for deployment.
• Retired services: services no longer offered.

The catalogue is therefore a subset of the portfolio. A proposal does not become a live catalogue service merely because someone has documented it.

Service Portfolio Management ensures that the provider has the right mix of services to execute its strategy. It controls investment, examines business value and risk, and decides which services should be introduced, continued, changed or retired.

Its decision pattern is often expressed as:

1. Define: document services, business cases and required outcomes.
2. Analyze: compare value, demand, cost, risk, capability and strategic fit.
3. Approve: authorize, reject, replace or defer investment.
4. Charter: communicate the authorization and provide resources for execution.

Consider three proposals: upgrade email, create a mobile sales app and replace an obsolete backup service. Funds cannot support all three immediately. Portfolio management makes the trade-off visible. It avoids approving attractive technology without a defensible outcome and avoids keeping costly services only because they have always existed.

The service owner is accountable for a specific service throughout its lifecycle. The product manager commonly manages services and investment within the portfolio. The exact organizational titles can differ, but ownership must be clear.

Financial Management for IT Services

Financial Management provides the provider and business with financial information needed to secure funding, understand costs, forecast requirements and balance cost against quality and demand.

Its three commonly tested activities are:

• Budgeting: predicting and controlling income and expenditure for a period.
• Accounting: identifying and reporting how money was actually spent.
• Charging: billing customers for services where the organization’s policy uses charging.

Budgeting asks what the provider expects and is permitted to spend. Accounting records actual expenditure and supports comparison with the budget. Charging influences consumption and recovers costs, but not every internal provider charges business units directly.

Costs may be direct, traceable to one service, or indirect, shared across services. A dedicated database licence is a direct cost of its service; data-centre power used by many systems may require allocation. Costs may also be fixed or variable, and capital or operational, according to the accounting context.

Financial management supports decisions such as:

• Can the organization afford the required warranty?
• What is the financial effect of increased demand?
• Should a component be built, bought or outsourced?
• Does the expected benefit justify the investment and risk?
• What does each service cost across its lifecycle?

Cheap design is not always economical. Removing redundancy lowers initial cost but can increase interruption risk. Strategy and design should consider total value and lifecycle cost.

Demand Management

Service capacity cannot always be stored for later. Unused computing capacity at 2 a.m. cannot automatically satisfy a noon peak. Poorly managed demand therefore creates cost and risk: too little capacity harms service; too much wastes investment.

Demand Management understands, anticipates and influences customer demand. It works closely with capacity and financial management.

A Pattern of Business Activity (PBA) is a workload profile of one or more business activities. A PBA may describe source, frequency, volume, duration, location, performance needs, security needs and tolerance for delay. User profiles describe groups of users and their normal demand patterns.

Example: an online-learning platform has moderate use during the semester, a sharp login peak at 9 a.m., and extreme submission traffic before deadlines. “Students submit assignments” is the business activity; its volume and timing form a PBA. Designers use it to plan application capacity, network bandwidth, support staffing and continuity.

Demand can be influenced through differential pricing, appointment windows, scheduled batch jobs, quotas or incentives for off-peak use. The purpose is not to reject genuine business demand. It is to align consumption with value, capacity and cost.

Roles and Responsibilities in Service Strategy

Roles make accountability explicit. One person may hold several roles, and a role may be performed by a team, but ownership should not be vague.

A useful responsibility model is RACI:

• Responsible: performs the work.
• Accountable: owns the result and has final authority. A task should have one clear accountable role.
• Consulted: gives input through two-way communication.
• Informed: receives information through one-way communication.

From Strategy to Service Design

Strategy supplies business requirements, portfolio decisions, policies and constraints. Service Design converts them into an integrated design that can be built, operated and improved.

The most important objective of Service Design is to design new or changed services for successful introduction into the live environment. Design is broader than choosing hardware. It covers the service solution, management information, architecture, processes, measurement and suppliers.

Good design addresses current and future business requirements. A solution that works for 500 users today but cannot safely scale to the expected 5,000 users is incomplete even if its present functionality is correct.

The Five Aspects of Service Design

The five major aspects are:

1. Service solutions: functional requirements, utility, warranty, resources and capabilities for new or changed services.
2. Service management information systems and tools: especially the service portfolio and supporting management systems.
3. Technology architectures and management architectures: platforms, standards, integration and management mechanisms.
4. Processes: activities, inputs, outputs, controls, roles and interfaces needed across the lifecycle.
5. Measurement methods and metrics: how service, process, technology and value will be measured.

Designing only the application leaves major questions unanswered: Who supports it? What service level is required? What happens during a site failure? Which supplier commitments support the SLA? Which measurements reveal poor performance?

The Four Ps of Service Design

The design must balance:

• People: skills, roles, staffing, communication and organization.
• Processes: repeatable activities and controls.
• Products: technology, services, tools and management systems.
• Partners: suppliers, vendors and other external contributors.

For a secure remote-access service, purchasing a gateway addresses Products. Administrators and service-desk training address People. Access approval and incident procedures address Processes. Telecom and support contracts address Partners. Ignoring any one can cause the service to fail.

Service Design Processes

ITIL 2011 lists eight Service Design processes:

1. Design Coordination
2. Service Catalogue Management
3. Service Level Management
4. Availability Management
5. Capacity Management
6. IT Service Continuity Management
7. Information Security Management
8. Supplier Management

The 2007 edition had the same set except Design Coordination. The syllabus names Service Catalogue Management, Service Level Management, capacity, continuity and information security explicitly; availability, supplier management and design coordination are covered later in this chapter because the named processes depend on them. The Service Design Package is a document, not a process.

Service Design Package

A Service Design Package (SDP) defines all aspects of a service and its requirements through each lifecycle stage. It is produced for a new service, a major change to an existing service, or the retirement of a service. It is the principal design output handed to Service Transition.

An SDP commonly contains:

• business requirements and agreed outcomes;
• service applicability and contacts;
• functional requirements, utility and warranty;
• architecture and component designs;
• capacity, availability, continuity and security requirements;
• service-level requirements and measurement methods;
• operational, support and escalation models;
• supplier and contract requirements;
• transition, testing, deployment and acceptance plans;
• organizational readiness, skills and training needs;
• risks, assumptions and constraints;
• lifecycle plans, including improvement and retirement.

Strategy and business requirements
              |
              v
      Integrated design work
   / architecture / processes \
  / people / suppliers / metrics \
              |
              v
    Service Design Package (SDP)
              |
              v
        Service Transition

The SDP is not merely an architecture diagram. If it omits monitoring, support, continuity or acceptance criteria, transition teams may deploy a technically working service that operations cannot support.

Service Catalogue Management

The service catalogue contains accurate information about live services and those approved for deployment. Service Catalogue Management ensures that this information is created, maintained and available to authorized people.

The business service catalogue presents customer-facing information: business processes supported, service descriptions, service levels and customer contacts. The technical service catalogue records relationships with supporting services, applications, components and technical teams. Together they connect the customer view to the internal delivery view. ITIL 2011 describes the same two views as customer-facing services and supporting services.

Example:

Business service: Employee Payroll
  |- Identity and access service
  |- Payroll application service
  |- Database service
  |- Network service
  `- Backup and recovery service

This relationship helps assess impact. If the database service fails, teams can identify the customer-facing services that may be affected.

Do not confuse:

• Service portfolio: all pipeline, catalogue and retired services.
• Service catalogue: live or deployment-ready services available to customers.
• Service request catalogue: user-facing choices for standard requests, often presented through a portal.

Service Level Management

Service Level Management (SLM) negotiates, agrees, records, monitors, reports and reviews service targets. Its purpose is to ensure that current and planned services are delivered to achievable targets aligned with business need.

A Service Level Requirement (SLR) documents the customer’s required targets before agreement. A Service Level Agreement (SLA) is the documented agreement between provider and customer describing the service and targets. An Operational Level Agreement (OLA) is an agreement between internal parts of the same provider. An Underpinning Contract (UC) is a contract with an external supplier that supports delivery.

Customer SLA: payroll available 99.9% during payroll window
       |
       +-- OLA: database team recovery target
       +-- OLA: service desk response target
       `-- UC: network supplier availability commitment

OLAs and UCs must support the SLA. A customer target of four-hour restoration is not credible if a critical supplier contract permits two days.

An effective SLA uses measurable, understandable targets that reflect business outcomes. “Provide excellent performance” is ambiguous. “95% of normal transactions complete within two seconds during 08:00–20:00” is measurable, but it must also define measurement location, exclusions and reporting period.

SLM activities include understanding requirements, agreeing targets, monitoring achievement, producing reports, conducting service reviews and coordinating improvement. The process should avoid the watermelon effect: reports appear green because component targets pass, while users experience a red service. End-to-end measures matter.

Designing for Capacity Management

Capacity Management ensures that the capacity and performance of services and infrastructure meet agreed current and future needs in a cost-effective and timely manner. It balances cost against resources and supply against demand.

Its three perspectives are:

• Business capacity management: translates future business plans and demand into service and resource needs.
• Service capacity management: monitors and manages end-to-end service performance and capacity.
• Component capacity management: manages individual components such as CPU, memory, storage and network links.

The Capacity Plan documents current utilization, forecasts, constraints, options, costs and recommended actions. The Capacity Management Information System (CMIS) holds supporting data.

Example: sales predicts 40% more online orders. Business capacity management interprets the change. Service capacity management examines response time and throughput for ordering. Component capacity management examines web-server CPU, database connections and network utilization. The solution may include optimization or demand scheduling rather than simply buying hardware.

Capacity design should consider normal load, predictable peaks, growth, failure conditions and recovery activity. Redundancy can reduce available capacity during component failure, so a design sized only for normal conditions may breach its SLA precisely when resilience is needed.

IT Service Continuity Management

IT Service Continuity Management (ITSCM) manages risks that could seriously affect IT services and prepares the provider to recover agreed services within required times. It supports the organization’s wider Business Continuity Management.

The work includes:

1. Define policy, scope and responsibilities.
2. Perform Business Impact Analysis (BIA) to identify vital business functions, impacts and recovery priorities.
3. Perform a risk assessment of threats, vulnerabilities, probability and impact. The BIA asks what happens to the business if a service is lost; the risk assessment asks how likely the loss is.
4. Select continuity strategies that balance risk, recovery need and cost.
5. Develop recovery plans, procedures, contacts and technical arrangements.
6. Test, exercise, review and maintain the plans.

The Recovery Time Objective (RTO) is the target maximum time to restore a service after disruption. The Recovery Point Objective (RPO) describes the acceptable amount of data loss measured in time. If the RPO is 15 minutes, backup or replication must make it possible to recover data to a point no more than about 15 minutes before the disruption.

RTO and RPO answer different questions. A service might need restoration within four hours but tolerate only 15 minutes of data loss.

Continuity options range from manual workarounds and backups to standby sites, geographic replication and active-active service. Stronger recovery normally costs more. The BIA provides business evidence for the investment.

Plans must be tested. An untested plan may contain invalid contacts, missing credentials or unrealistic time estimates. Changes to architecture, suppliers or business priorities must be assessed for continuity impact.

Information Security in Service Design

Information Security Management aligns IT security with business requirements and maintains appropriate protection. The core objectives are commonly expressed as:

• Confidentiality: information is available only to authorized people or systems.
• Integrity: information is accurate, complete and protected from unauthorized modification.
• Availability: authorized users can access information and services when needed.
• Authenticity: identities and information sources are genuine.
• Non-repudiation: there is reliable evidence so a party cannot credibly deny an action where this property is required.

Security design starts from business risk and classification. Controls may include identity management, least privilege, encryption, logging, network segmentation, secure configuration, backup and incident response. A control is useful when it reduces relevant risk to an acceptable level without making the service unusable.

Security must be designed early. Adding authentication, audit trails or encryption after deployment can require major architectural changes. Supplier access, administrative privileges and data exchanged across interfaces also belong in the design.

The Information Security Management System (ISMS) provides policies, responsibilities, controls, risk treatment and continual review. Security requirements should appear in the SLA, SDP, supplier contracts and operating procedures where appropriate.

Related Design Concerns

Although the official bullet list emphasizes capacity, continuity and security, they depend on adjacent design concerns.

Availability Management ensures that service availability meets agreed business needs cost-effectively. It considers reliability, maintainability, serviceability, component resilience and vital business functions. Availability is not simply “server uptime”; it is the ability of the end-to-end service to perform its agreed function when required.

Supplier Management ensures suppliers and contracts support business needs and agreed service targets. It maintains supplier information, evaluates performance and aligns underpinning contracts with SLAs.

Design Coordination, added in the ITIL 2011 edition, coordinates design activities and ensures consistent, complete SDPs. It reduces the risk that separate teams design applications, networks and support processes using conflicting assumptions.

These areas illustrate why design is holistic. Capacity, availability, continuity and security can conflict. More encryption may consume processing capacity; aggressive availability may increase cost; continuity arrangements may copy sensitive information to another site. The design team must resolve these trade-offs against business priorities.

Integrated Worked Example: Online Examination Service

A training institute plans an online examination service for 2,000 candidates. Candidates must authenticate, download questions, submit answers and receive confirmation. The examination is time-bound, so late recovery has little value.

Strategy Decisions

The desired outcome is a fair examination completed within the scheduled window. Utility includes candidate registration, question delivery, timed submission and result capture. Warranty includes high availability during the exam, capacity for synchronized login, continuity, confidentiality of questions and integrity of answers.

The provider is a Type II shared service unit serving several departments. The market space is secure, large-scale digital assessment. Its position emphasizes institutional integration and strong warranty rather than the lowest price.

Portfolio management compares building the service, subscribing to an external platform and extending the learning-management system. Financial management estimates lifecycle costs, including testing, support and continuity. Demand management identifies PBAs: a sharp login peak before start, regular autosave traffic and a submission peak before the deadline.

Design Decisions

The SDP records requirements, architecture, support, testing and acceptance. The business catalogue describes the examination service; the technical catalogue links identity, database, network, monitoring and notification services.

The SLA defines the examination window, transaction-response targets, availability measurement and support response. OLAs assign identity and database recovery targets. A UC requires the Internet supplier to meet supporting availability.

Capacity design uses 2,000 candidates plus safety margin and tests login and submission peaks. Continuity design assigns an RTO short enough to resume within the exam window and an RPO small enough to protect recent answers. Security design uses role-based access, encryption, audit logging and restricted question access.

Candidates
    |
Internet and security gateway ---- monitoring
    |
Exam application cluster
    |
Database + replicated recovery copy
    |
Support processes, OLAs and supplier contracts

This example shows why the processes cannot be treated as isolated definitions. Demand affects capacity and finance. Security affects architecture. Supplier contracts affect the SLA. Continuity targets affect database and site design.

Designing a Service Step by Step

The lifecycle publications describe processes, but a beginner also needs to see how a design moves from a vague request to an operable service. The following sequence is a practical interpretation of the syllabus concepts.

Step 1: Discover the Business Requirement

Start with outcomes rather than a preferred product. “Buy a ticketing package” is a proposed solution. “Allow customers to report faults at any time and see progress without calling support” is an outcome. The second statement leaves room to compare solutions.

Questions should identify customers, users, volumes, working hours, locations, regulatory constraints, critical dates and the consequences of failure. Requirements should be prioritized. A useful scheme is must have, should have, could have and will not include now. Without prioritization, every desired feature appears equally critical and cost grows without a clear value decision.

Requirements must include warranty. A statement such as “the portal shall accept requests” covers utility but says nothing about availability, response time, recovery or protection of personal data.

Step 2: Build the Service Model and Dependencies

Designers decompose the customer-facing service into supporting services and components. They identify people, information flows, technology and suppliers. This dependency model supports impact analysis and exposes hidden assumptions.

For a ticketing portal:

Customer-facing support portal
  +-- web application and API
  +-- identity service
  +-- notification service
  +-- database and backup service
  +-- network and DNS
  +-- service desk and application support
  `-- cloud and messaging suppliers

The design should identify ownership at each level. “Infrastructure team” is often too vague to guide escalation. The required support hours and contact route also matter.

Step 3: Translate Demand into Capacity

Suppose 8,000 employees can use the portal. This does not mean 8,000 simultaneous sessions. Historical information predicts 400 requests on a normal day, 1,500 after a major outage and a peak of 100 submissions in five minutes. Test scenarios should reflect these PBAs.

A basic utilization calculation illustrates the reasoning. If one application instance safely processes 20 submissions per second and the peak forecast is 50 per second, three instances provide 60 per second of nominal capacity. That leaves little room for failure or growth. Four provide 80 per second. Designers must test rather than treat a simple division as proof because database locks, network delay and dependent services may be the actual limit.

Capacity planning decisions include scaling up a component, scaling out across instances, optimizing inefficient work, scheduling non-urgent jobs and influencing avoidable peaks. Each option has cost, resilience and operational consequences.

Step 4: Define Measurable Service Levels

Targets should describe the user-visible service and the measurement rules. Compare:

• Weak: “The portal must be highly available.”
• Better: “The portal must achieve 99.9% availability.”
• Operational: “The portal will achieve at least 99.9% availability during 06:00–23:00 each calendar month, measured by successful synthetic login and ticket-display transactions from two corporate locations, excluding agreed maintenance announced 72 hours in advance.”

The operational version defines the service window, period, measurement and exclusion. Its implications can be calculated. A 30-day month contains 720 hours. If the service were measured continuously and allowed 99.9% availability, total unavailability would be at most:

Allowed unavailability = 720 hours x (1 - 0.999)
                       = 0.72 hours
                       = 43.2 minutes

If measurement covers a smaller agreed service window, use that window rather than all calendar hours. Planned-maintenance treatment must be defined instead of silently removed from reports.

Step 5: Design Continuity and Security

The BIA identifies the impact of extended interruption. It may reveal that access to existing high-priority tickets is more urgent than reporting dashboards. Recovery can then be sequenced.

If the RTO is two hours, every dependency must support that target: infrastructure, database restoration, identity, networking, suppliers and staff mobilization. A two-hour application restart does not help if the database backup requires six hours to restore.

Security requirements are traced to risks. If tickets can contain employee information, the design may require authenticated access, least-privilege support roles, encryption in transit, audit logs, retention rules and secure removal. Each control needs an owner and a way to verify that it works.

Step 6: Design Support, Measurement and Transition

Operations needs monitoring thresholds, dashboards, diagnostic information, support procedures, escalation routes, known limitations and access to knowledge. Measurement should include technology metrics and service metrics. CPU utilization can explain a symptom, but successful ticket submission and response time describe customer experience more directly.

Transition needs test criteria, data migration, release steps, rollback, training and acceptance authority. These belong in or are referenced by the SDP. Design is complete only when the service can be transitioned and operated, not when the architecture drawing is approved.

Understanding Service-Level Relationships

Service levels form a chain of commitments. The customer-facing SLA is supported by internal OLAs and external contracts. Their measures need not be identical, but together they must make the SLA achievable.

Suppose the SLA permits two hours to restore a customer portal. The database OLA permits 90 minutes, the network OLA permits 90 minutes and the supplier contract permits four hours. Those targets are not automatically additive because recovery can occur in parallel, but the four-hour supplier commitment remains a clear risk. SLM must negotiate stronger support, redesign the dependency or agree a realistic customer target.

Service-Based, Customer-Based and Multi-Level SLAs

A service-based SLA covers one service for all customers, such as a standard corporate email SLA. It is simple but may not reflect different business needs.

A customer-based SLA covers all relevant services for one customer group, such as an agreement with the finance department covering payroll, reporting and document services. It provides a customer view but can duplicate common terms.

A multi-level SLA separates reusable terms into levels. A corporate level covers common obligations, a customer level covers one customer group and a service level covers a specific service. This can reduce duplication when managed carefully.

SLAs should not promise only what is easy for IT to measure. A report containing server uptime, number of disks and backup-job counts may still fail to show whether the business could complete transactions.

Capacity, Availability and Continuity Compared

These processes are related but answer different design questions.

High availability does not eliminate continuity planning. Redundant components handle some failures, but corruption, cyberattack, fire or design error can affect all live copies. Conversely, a recovery plan does not provide daily availability; it is invoked after disruption.

Availability terminology is often tested:

• Reliability is how long a service or component can perform without interruption.
• Maintainability is how quickly and effectively the provider can restore it.
• Serviceability is a supplier’s ability to meet contracted support and availability commitments.
• Resilience is the ability to withstand failure, often through redundancy and fault tolerance.

These properties influence availability, but none is identical to the customer’s end-to-end availability.

Information Security Decisions in Context

Security goals can conflict, so design should use risk-based decisions. Making every record available to everyone improves convenience but destroys confidentiality. Locking every record in an offline safe improves confidentiality but destroys useful availability.

Consider an employee health-benefits service:

• Confidentiality requires that employees see their own claims and authorized staff see only what their role needs.
• Integrity requires validation and audit trails for claim changes.
• Availability requires access during enrolment and claim deadlines.
• Authenticity requires confidence that users and service endpoints are genuine.
• Non-repudiation may require evidence of important approvals.

Controls are layered. Identity verification does not replace authorization. Encryption does not replace backup. Logs do not prevent every attack, but they aid detection and investigation. The design records which risk each control addresses and who maintains it.

Service Design Measurements

Measurement must be designed before operation so required data is available. ITIL commonly distinguishes:

• Technology metrics, such as CPU, memory, link errors or database latency.
• Process metrics, such as percentage of SLA reviews completed or design defects found before release.
• Service metrics, such as end-to-end availability, transaction success and user-experienced response time.

A Critical Success Factor (CSF) is something that must happen for an objective to succeed. A Key Performance Indicator (KPI) measures progress or performance related to a CSF. For example:

Objective: provide dependable online examination submission
CSF: submissions remain available during the final deadline peak
KPI: successful submissions / attempted submissions during peak period
Target: at least 99.95%

A metric becomes useful when it supports a decision. Collecting thousands of counters without ownership or thresholds increases data without necessarily increasing understanding.

Balanced measurement avoids local optimization. If support reduces call time by ending calls early, the call-duration KPI improves while customer outcomes may worsen. Combine efficiency, effectiveness and customer measures.

A Second Worked Scenario: Branch Banking Service

A bank wants a service that enables branch employees to access customer accounts and complete deposits during business hours.

Strategy Analysis

The outcome is completed branch transactions, not possession of database servers. The service’s utility includes account lookup and deposit posting. Its warranty includes availability during branch hours, response capacity on salary days, transaction integrity, confidentiality and continuity.

Demand PBAs distinguish normal branches, high-volume urban branches and month-end peaks. Portfolio management evaluates whether to improve the existing service or replace it. Financial management compares lifecycle costs and regulatory risk, not merely purchase price.

The bank uses an internal shared services unit, making it a Type II provider. External telecom and software companies remain suppliers; their involvement does not automatically make the bank’s IT unit Type III.

Design Analysis

The customer-facing SLA uses transaction success and response time. An OLA with database operations and a UC with the telecom provider support it. Capacity testing includes normal load, salary-day peak and the loss of one application node.

ITSCM assigns branch transactions a recovery priority based on BIA. The design may include a limited offline procedure so urgent deposits can be captured safely and reconciled later. Security requires authenticated staff, role-based authorization, encrypted links and tamper-evident audit logs.

The SDP describes architecture, operational monitoring, support skills, recovery, testing and acceptance. A diagram of two servers without those elements would not be an adequate service design.

Applying the Processes to a Change

Assume the bank adds biometric approval for large withdrawals. Because this is a major change, it needs an updated SDP.

1. Strategy confirms the expected outcomes: lower fraud risk and faster verification.
2. Portfolio management authorizes investment and records the changed service.
3. Financial management assesses devices, licences, support and training costs.
4. Demand management estimates verification volumes and peak periods.
5. Service Catalogue Management updates the service description and dependencies.
6. SLM agrees any changed response-time or support targets.
7. Capacity Management tests the biometric service and dependent network.
8. ITSCM decides how branches operate if verification is unavailable.
9. Information Security Management addresses biometric-data confidentiality, integrity and retention.
10. The SDP supplies Transition with test, deployment, training, rollback and acceptance information.

This flow demonstrates lifecycle integration. Strategy chooses and justifies the outcome; Design makes the change complete and operable.

Knowledge Checks with Explanations

Why is a technically successful project not necessarily a valuable service?

Technical completion proves that specified components were built. Value requires the customer to achieve desired outcomes at acceptable cost and risk. A portal delivered on time but unusable during business peaks has not delivered the required warranty.

Why keep retired services in the service portfolio?

Retired services retain historical, financial and dependency information. They help the provider understand commitments, migration and why investment ended. They are not advertised as currently available catalogue services.

Why does Demand Management belong near strategy while Capacity Management appears in design?

Demand Management identifies and influences the business consumption expected from strategic choices. Capacity Management designs and manages the resources and performance required to meet that demand. They exchange information and operate across the lifecycle; the placement emphasizes their primary concern rather than creating a wall between them.

Why can a strict SLA still produce an unhappy customer?

The agreement may measure the wrong thing, exclude critical periods or report components instead of the service. It may also omit changing customer needs. SLM therefore includes relationship, review and improvement work as well as target reporting.

Why are roles important if everyone is cooperative?

Cooperation does not settle who approves investment, accepts risk, owns a service or corrects a failed process. Clear accountability prevents gaps and conflicting decisions, especially during incidents and changes.

Common Conceptual Mistakes

• Treating value as whatever the provider says it is. The customer’s outcomes and perception determine value.
• Confusing utility with warranty. Functionality is utility; assurance about use is warranty.
• Calling every internal IT department Type I. A consolidated unit serving several business units is Type II.
• Treating the catalogue as the whole portfolio. Pipeline and retired services are also in the portfolio.
• Treating budgeting, accounting and charging as synonyms. They predict/control, record/report and bill/recover respectively.
• Assuming demand management means suppressing users. It understands and, where useful, influences demand to align value and capacity.
• Designing technology without people, processes and partners.
• Treating an SDP as only a technical specification. It contains lifecycle, service-level, operational, security, supplier and transition information.
• Assuming an SLA alone creates capability. Supporting OLAs, contracts, architecture and processes must make its targets achievable.
• Confusing capacity with availability. Capacity concerns volume and performance; availability concerns usable service when required.
• Confusing RTO with RPO. RTO concerns restoration time; RPO concerns acceptable data loss.
• Treating security as only confidentiality. Integrity and availability are also core objectives.

Key Points

• ITIL service management organizes capabilities around customer value and business outcomes.
• The syllabus uses the ITIL v3/2011 five-stage lifecycle; ITIL 4 replaced the stages with the Service Value System, value chain and practices.
• Utility is fitness for purpose; warranty is fitness for use.
• Strategy defines customers, outcomes, services, investment and differentiation.
• The Four Ps of strategy are Perspective, Position, Plan and Pattern.
• Provider Types I, II and III are internal, shared and external providers.
• The service portfolio contains the pipeline, catalogue and retired services.
• Financial Management covers budgeting, accounting and, where used, charging.
• Demand Management uses PBAs and user profiles to understand consumption.
• Service Design converts requirements into an integrated and supportable service design.
• The Four Ps of design are People, Processes, Products and Partners.
• The SDP is produced for a new service, major change or retirement and is handed to Service Transition.
• SLM aligns SLAs, OLAs and underpinning contracts with business needs.
• Capacity design, continuity and security must be integrated with architecture, processes, metrics and supplier arrangements.