IT Operations, Service Management and Governance

Introduction and Context

Modern organisations depend on information technology not merely as an administrative support function but as an operating platform for finance, manufacturing, health care, education, commerce and public services. A failed identity service can prevent employees from working; a poorly governed cloud contract can expose sensitive information; and inadequate capacity planning can make a successful digital product unusable during peak demand. IT operations, service management and governance provide the disciplines needed to deliver reliable technology, control risk and align technology investment with organisational purpose.

IT operations concerns the day-to-day running of infrastructure, applications, networks, platforms, facilities and support processes. IT service management (ITSM) organises these activities around services and customer outcomes. Governance establishes direction, accountability, oversight and assurance. These areas overlap but are not identical: operations executes and maintains; service management designs and improves service delivery; governance evaluates whether technology is being directed and controlled responsibly.

This chapter uses ITIL concepts for service management and COBIT concepts for governance. They should be treated as complementary bodies of guidance rather than as competing software products or rigid recipes. ITIL is strongly concerned with the management of services and value co-creation, whereas COBIT provides a governance and management framework for enterprise information and technology.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the relationship between IT operations, ITSM and IT governance.
2. Apply ITIL concepts to incidents, problems, changes, service levels and continual improvement.
3. Describe how COBIT separates governance from management and supports control objectives.
4. Manage assets, configurations, capacity, availability, suppliers and compliance.
5. Select meaningful technology performance indicators and interpret service-level data.
6. Evaluate controls, risks, ethical responsibilities and emerging operational technologies.

1. A Service-Based View of Information Technology

A service is a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks. For example, an online learning service enables students to access content and submit assessments. The service is more than a server: it includes software, networks, identity management, support, data, security, procedures and supplier relationships.

Important ITSM terms include:

• Customer: the person or organisation that defines service requirements and is accountable for outcomes.
• User: the person who uses the service.
• Sponsor: the person who authorises the budget for the service.
• Service provider: the internal IT department, external supplier or shared service organisation delivering the service.
• Utility: what the service does; it must be fit for purpose.
• Warranty: assurance that the service will be available, secure, sufficiently capacitated and continuous; it must be fit for use.
• Value: the perceived benefits, usefulness and importance of a service, considered with its costs and risks.

A service catalogue communicates available services, eligibility, service hours, request routes, service levels and charges where applicable. A service portfolio is broader: it includes proposed, current and retired services. The portfolio supports investment decisions, while the catalogue supports customer understanding and operational delivery.

2. ITIL Service Management Concepts

ITIL 4 presents a service value system (SVS), which explains how an organisation’s components and activities work together to facilitate value creation. Its major elements are guiding principles, governance, the service value chain, practices and continual improvement.

2.1 Guiding Principles

The guiding principles are general recommendations rather than mandatory procedures:

1. Focus on value: relate every activity to outcomes that matter to stakeholders.
2. Start where you are: assess existing capability before discarding it.
3. Progress iteratively with feedback: deliver manageable improvements and learn from results.
4. Collaborate and promote visibility: make work, dependencies and decisions understandable.
5. Think and work holistically: consider people, processes, technology, suppliers and information together.
6. Keep it simple and practical: remove unnecessary steps and controls.
7. Optimise and automate: improve the workflow before automating it, and use automation where it reduces error or delay.

The principles require judgement. For example, “keep it simple” does not justify eliminating segregation of duties from a high-risk financial change. Simplicity must be balanced with risk, regulation and resilience.

2.2 The Service Value Chain

The service value chain contains six interconnected activities:

A value stream selects and combines these activities for a particular demand. An access-request value stream might engage the user, plan the approval route, obtain account information, deliver the access change and improve the process using performance data.

2.3 ITIL Practices Relevant to Operations

Incident management restores normal service operation as quickly as possible and minimises adverse impact. An incident is an unplanned interruption or reduction in service quality. Incident management is not primarily concerned with finding the underlying cause; that is the role of problem management.

Problem management reduces the likelihood and impact of incidents by identifying actual or potential causes. A known error is a problem that has been analysed but not necessarily permanently resolved. A workaround reduces impact while a permanent fix is developed.

Change enablement maximises successful changes by assessing risk, authorising changes and managing schedules. Standard changes are low-risk, repeatable and pre-authorised. Normal changes require assessment and authorisation. Emergency changes are implemented urgently under an adapted approval process; “emergency” must not become a shortcut for poor planning.

Service request management handles predefined, user-initiated requests such as password resets, software installation or access to an approved application. Requests should be distinguished from incidents so that performance, workflows and approvals remain clear.

Service desk is the entry point and coordinating function for users. It records demand, communicates status, performs initial diagnosis and routes work to appropriate teams.

Monitoring and event management observes services and components, detects significant changes of state and determines appropriate responses. An event is a detectable occurrence; not every event is an incident.

Release management makes new or changed services and features available for use, while deployment management moves components into environments. Separating these concepts helps organisations coordinate business readiness, communications and technical movement.

Configuration management ensures that accurate and reliable information about configuration items (CIs) is available when and where needed. A CI may be a server, application, database, contract, cloud resource, network device or service documentation. A configuration management database (CMDB) stores relationship information, but a CMDB is useful only when its data is accurate, governed and connected to operational work.

Service level management sets clear, business-based targets and monitors performance against agreements. It should avoid measuring technical activity that has no meaningful relationship to customer outcomes.

Information security management, availability management, capacity and performance management, supplier management, IT asset management and continuity management connect operational practice to risk, resilience and financial stewardship.

3. Service Levels and Performance Measurement

A service-level agreement (SLA) is a documented agreement between a service provider and a customer describing services and targets. Supporting agreements may exist between internal teams, and underpinning contracts may exist with external suppliers. An SLA should define scope, service hours, measurement method, exclusions, responsibilities, reporting, escalation and review arrangements.

Common measures include availability, response time, resolution time, transaction latency, request fulfilment time, recovery objectives and customer experience. A target should be operationally meaningful. “99.9% availability” without a measurement window, exclusions or service boundary is incomplete.

Availability for a period can be expressed as:

Here, agreed service time and unavailable time must use the same unit, such as minutes. The calculation assumes that downtime is defined consistently and that maintenance exclusions are agreed in advance. Availability is not the same as reliability: a service may have many short interruptions but still achieve high availability.

For a 30-day month with 43,200 agreed minutes and 50 minutes of measured unavailability:

The result should be reported with the measurement method, not as an isolated percentage.

Mean time to repair (MTTR) is commonly calculated as:

Mean time between failures (MTBF), when failure and restoration data are defined consistently, is:

These averages can conceal extreme cases. Percentiles, such as the 95th-percentile response time, are often more informative for user experience. Metrics should be interpreted together: reducing MTTR by repeatedly applying risky emergency changes may improve one measure while increasing future incidents.

A service-level objective (SLO) is a target, such as 99.95% monthly availability. An error budget is the permitted unreliability implied by the SLO. If the SLO is 99.95%, the monthly error-budget fraction is 0.05%. For 43,200 minutes, the budget is:

This approach can guide release decisions, but it is appropriate only when service boundaries, measurement and customer impact are clearly defined.

4. COBIT and IT Governance

Governance answers questions such as: Are stakeholder needs evaluated? Are direction and priorities established? Is performance and compliance monitored? Management plans, builds, runs and monitors activities in accordance with that direction.

COBIT 2019 provides a framework for the governance and management of enterprise information and technology. Its governance system includes components such as processes, organisational structures, information, people and competencies, policies and procedures, culture and behaviour, and services, infrastructure and applications.

COBIT distinguishes five governance objectives in the Evaluate, Direct and Monitor (EDM) domain:

• EDM01: Ensured governance framework setting and maintenance.
• EDM02: Ensured benefits delivery.
• EDM03: Ensured risk optimisation.
• EDM04: Ensured resource optimisation.
• EDM05: Ensured stakeholder engagement.

Management objectives are grouped into Align, Plan and Organise (APO); Build, Acquire and Implement (BAI); Deliver, Service and Support (DSS); and Monitor, Evaluate and Assess (MEA). The framework supports design of a governance system appropriate to enterprise strategy, risk profile, regulatory environment, sourcing model and technology adoption.

A capability assessment considers whether a process achieves its purpose in a consistent and managed way. Capability ratings should be supported by evidence, not claimed merely because a policy exists. Evidence may include approved records, system logs, access reviews, test results, incident trends, supplier reports and internal audit findings.

COBIT and ITIL can be integrated. For example, COBIT may establish governance expectations for service performance, risk and compliance; ITIL practices may provide the operational methods for incident, change, service-level and continual-improvement management. Neither framework removes the need for professional judgement.

5. IT Asset and Configuration Management

IT asset management manages the lifecycle of assets to maximise value, control cost and risk, and support decision-making. Asset records may include ownership, location, acquisition cost, licence terms, warranty, depreciation information, disposal status and security classification. Assets include hardware, software licences, cloud subscriptions, intellectual property and sometimes data-related resources.

Configuration management focuses on the attributes and relationships needed to manage services. Asset and configuration records overlap but have different purposes. A laptop may be an asset requiring lifecycle and licence control; it is also a CI if its relationship to a user, endpoint-management service and security policy is operationally important.

A practical configuration management system should define:

• CI classes and naming conventions;
• ownership and data custodianship;
• authorised sources of discovery data;
• relationship types and service maps;
• update triggers, reconciliation rules and review frequency;
• access controls and retention requirements;
• quality measures such as completeness, accuracy and timeliness.

Configuration data should support impact analysis. Before changing a database server, the organisation should identify dependent applications, business services, support teams, suppliers, recovery arrangements and maintenance constraints. Automated discovery can improve accuracy, but it cannot reliably infer every business dependency or ownership relationship.

6. Capacity, Availability and Continuity

Capacity and performance management ensures that services have sufficient resources to meet current and expected demand at acceptable cost. It considers business capacity, service capacity and component capacity. Demand may be forecast using historical trends, planned campaigns, seasonal patterns, product growth and workload characteristics.

A simple utilisation measure is:

The formula is meaningful only when “used” and “available” are defined for the same resource and interval. High utilisation is not automatically efficient: systems may need headroom for bursts, failover and maintenance. Conversely, excessive idle capacity may indicate avoidable cost.

Queueing effects mean that response time can deteriorate sharply as a resource approaches saturation. Therefore, capacity decisions should consider latency, throughput, concurrency, bottlenecks and resilience rather than a single utilisation threshold.

Availability management designs and monitors the ability to perform when required. It includes redundancy, fault detection, maintenance, failover, recovery and testing. Continuity management addresses how services will be sustained or recovered after disruptive events. Two important business requirements are:

• Recovery time objective (RTO): the targeted maximum time to restore a service after disruption.
• Recovery point objective (RPO): the maximum tolerable period of data loss measured in time.

An RPO of 15 minutes does not mean that every recovery will lose exactly 15 minutes; it states the tolerated recovery-point requirement. Objectives must be feasible, funded and tested. A backup that has never been restored is not reliable evidence of recoverability.

7. Supplier and Vendor Management

Organisations increasingly depend on cloud providers, software publishers, telecommunications carriers, managed service providers and specialist contractors. Supplier management should address due diligence, service scope, performance, financial stability, security, data location, subcontractors, intellectual property, audit rights, incident notification, exit assistance and termination.

A vendor risk assessment should be proportional to criticality. A supplier supporting a public website may require different controls from a provider processing health records or operating payment infrastructure. Contractual service credits may compensate financially, but they do not necessarily compensate for reputational harm, regulatory exposure or safety consequences.

Effective vendor governance includes named owners, periodic service reviews, evidence-based scorecards, risk registers, renewal decisions and tested exit plans. Multi-sourcing can reduce concentration risk but may increase integration complexity and accountability gaps. “Cloud” transfers some operational responsibilities to a provider; it does not transfer the customer’s accountability for appropriate configuration, access control, data governance or legal compliance.

8. Controls, Compliance and Ethical Governance

An IT control is a policy, procedure, technical mechanism or organisational practice designed to manage risk. Controls may be:

• Preventive, such as least-privilege access and segregation of duties;
• Detective, such as log monitoring and vulnerability scanning;
• Corrective, such as recovery procedures and remediation;
• Directive, such as policies, standards and training.

A control objective describes the desired condition. A control activity describes how it is achieved. Evidence demonstrates whether it operated effectively. For example, the objective may be that privileged access is authorised and reviewed. Activities may include approval workflow, multifactor authentication, session logging and quarterly access recertification. Evidence includes approvals, system configuration and review records.

Compliance is broader than passing an audit. Organisations may need to address data-protection law, sector regulation, contractual obligations, records retention, accessibility, intellectual-property law and cybersecurity requirements. Legal requirements vary by jurisdiction; therefore, local legal and regulatory advice is necessary.

Ethical governance requires consideration of affected stakeholders, not merely formal compliance. IT leaders should address privacy, accessibility, algorithmic bias, surveillance, environmental impact, workforce displacement, responsible disclosure and unequal access. Automated decision systems require documented purpose, data governance, human oversight, testing for discriminatory outcomes and a route for appeal. Generative AI used in operations should be governed for confidentiality, accuracy, intellectual-property risk, prompt injection, hallucination and accountability. Automation must preserve meaningful human control over high-impact decisions.

9. Continual Improvement and Technology Performance

Continual improvement is a structured, evidence-based activity rather than an occasional project. A useful improvement register records the opportunity, baseline, desired outcome, owner, priority, resources, dependencies, measures and review date. The improvement cycle may be expressed as:

1. Identify the vision and improvement opportunity.
2. Establish the current state using evidence.
3. Define measurable objectives.
4. Plan and implement a limited intervention.
5. Measure results and unintended effects.
6. Standardise successful changes and repeat the cycle.

A balanced technology scorecard may include customer outcomes, operational reliability, security and compliance, delivery flow, workforce capability, supplier performance and cost. Metrics should have clear definitions, owners and decision thresholds. Goodhart’s law warns that when a measure becomes a target, it can cease to be a good measure. For example, rewarding teams solely for closing tickets may encourage premature closure rather than durable resolution.

A mature performance system combines leading indicators, such as overdue patches, failed changes and capacity headroom, with lagging indicators, such as outages, breaches and customer complaints. Trend analysis is generally more useful than a single month’s result.

10. Integrated Operating Model

An effective operating model connects governance, service design and operational execution. Governance establishes risk appetite, priorities and accountability. Service management translates these into service requirements, practices and agreements. Operations implements, monitors and improves the technical environment. Feedback from users, incidents, audits and performance data returns to governance and planning.

The operating model should define roles clearly. A service owner is accountable for the end-to-end service; a process owner is accountable for process effectiveness; a technical owner manages a component or platform; a risk owner accepts or treats risk; and an auditor provides independent assurance. These roles may be performed by different people, especially where segregation of duties is required.

A RACI matrix can clarify whether a role is Responsible for performing work, Accountable for the result, Consulted before action or Informed afterward. It should not be used to distribute accountability so widely that nobody owns the outcome.

11. Illustrative Case: Meridian Polytechnic Digital Learning Service

Background. Meridian Polytechnic, an illustrative institution, operates a digital learning service used by 18,000 students. During assessment periods, students experience slow logins, delayed file uploads and inconsistent support responses. The institution uses several cloud suppliers and has an incomplete CMDB.

Problem. Availability is reported as 99.8%, but students continue to experience serious disruption. Investigation shows that the measure excludes some identity-provider failures and scheduled maintenance. Incidents are frequently closed as “user error,” while recurring storage and authentication problems are not linked to problem records. Vendor responsibilities are unclear.

Analysis. The service owner maps the end-to-end service: identity, network, learning application, storage, notification service, service desk and suppliers. The team defines the service boundary and agreed service time. It distinguishes incidents, service requests and problems, then identifies authentication as a common dependency. Capacity analysis shows that storage throughput, rather than total storage volume, is the peak-period bottleneck. A supplier review finds that the contract has response targets but no effective recovery evidence or exit assistance.

Approach. The institution establishes a service-level agreement based on student-facing outcomes, with separate objectives for login success, upload latency, incident response and availability. It creates a minimum viable service map in the CMDB, assigns service and CI owners, and introduces a normal change schedule before assessment periods. The supplier contract is revised to require incident notification, security evidence, recovery testing and clear data-export procedures. A problem record is opened for recurring authentication failures. Capacity tests are conducted using representative peak workloads, and an error-budget approach is used to decide whether nonessential releases should proceed during the assessment window.

Outcome. In the following assessment period, authentication incidents fall, peak upload performance improves and support communications become more consistent. Reported availability decreases initially because previously excluded failures are now measured, but the metric becomes more credible. Governance committees receive a dashboard showing customer impact, supplier performance, change success, unresolved risks and improvement progress.

Learning points. The case demonstrates that a high headline availability figure can conceal poor service experience; that service mapping must cross organisational boundaries; that supplier governance is part of service management; and that accurate measurement may initially make performance appear worse while improving decision quality.

12. Challenges and Limitations

Frameworks can create bureaucracy when organisations implement terminology without understanding outcomes. Excessive approval boards delay low-risk changes, while weak controls expose critical services. CMDB programmes often fail when data ownership and use cases are not defined. SLAs may encourage negotiation over percentages rather than genuine customer value. Averages can hide vulnerable user groups and short but damaging interruptions. Outsourcing can create accountability gaps, and automation can amplify an incorrect process at high speed.

Frameworks also reflect assumptions that must be adapted. Agile product teams, platform engineering, DevOps and cloud-native architectures may release frequently and manage infrastructure as code. Traditional annual planning and manual change gates may be unsuitable, but the underlying needs—risk assessment, traceability, testing, separation of duties where necessary and recoverability—remain. The appropriate response is risk-based control design, not the removal of governance.

13. Best-Practice Checklist

A professionally managed IT environment should:

• define services in terms of customer and organisational outcomes;
• assign accountable service, process, risk and supplier owners;
• maintain trustworthy asset and configuration information;
• use measurable, agreed and transparent service levels;
• separate incidents, problems, requests, changes and releases;
• test capacity, continuity, backups and recovery;
• assess supplier concentration, security and exit risk;
• design preventive, detective and corrective controls;
• protect privacy, accessibility, confidentiality and human oversight;
• combine leading and lagging indicators;
• review trends and unintended consequences;
• improve iteratively using evidence and stakeholder feedback.

Chapter Summary

IT operations runs technology environments, IT service management organises technology around valuable and reliable services, and governance provides direction, accountability and assurance. ITIL contributes a service value system, guiding principles, value-chain activities and operational practices such as incident, problem, change, configuration, service-level, capacity and supplier management. COBIT contributes an enterprise governance and management perspective, distinguishing Evaluate, Direct and Monitor governance from management domains such as Align, Plan and Organise; Build, Acquire and Implement; Deliver, Service and Support; and Monitor, Evaluate and Assess.

Effective service management depends on clear service boundaries, trustworthy measurements, accountable ownership and continual improvement. Availability, MTTR, capacity utilisation and error budgets are useful only when definitions, units, assumptions and business effects are understood. Asset and configuration information supports impact analysis; continuity requires feasible and tested RTO and RPO objectives; and supplier management must address both performance and exit risk. Controls should be risk-based and supported by evidence. Ethical and regulatory governance extends beyond compliance to privacy, accessibility, fairness, security and responsible use of automation and AI.

Key Terms

Service management: A set of organisational capabilities for enabling value through services.

IT operations: The activities that run, monitor, maintain and support technology environments.

Governance: Direction, oversight and accountability for achieving objectives and managing risk.

ITIL: A body of guidance for managing IT-enabled services and co-creating value.

COBIT: A framework for governing and managing enterprise information and technology.

Service value system: ITIL’s model connecting principles, governance, value-chain activities, practices and improvement.

Service-level agreement: A documented agreement defining a service and measurable commitments.

Availability: The ability of a service to perform its agreed function when required.

Incident: An unplanned interruption or reduction in service quality.

Problem: A cause, or potential cause, of one or more incidents.

Change enablement: Practice for assessing, authorising and managing changes.

Configuration item: A component that must be managed to deliver an IT service.

CMDB: A repository of configuration information and relationships.

IT asset management: Management of asset value, cost, risk and lifecycle.

RTO: Target time for restoring a service after disruption.

RPO: Maximum tolerable period of data loss measured in time.

Control objective: The desired condition that a control is intended to achieve.

Error budget: The unreliability permitted by a service-level objective.

Service owner: The person accountable for an end-to-end service.

Continual improvement: Repeated evidence-based activity to improve services, practices and outcomes.

Review Questions

Short Answer Questions

1. Distinguish IT operations, IT service management and IT governance.
2. What is the difference between an incident and a problem?
3. Explain the distinction between utility and warranty.
4. Define RTO and RPO.
5. Why must an SLA specify its measurement method and boundary?

Long Answer Questions

1. Explain the ITIL service value system and discuss how its elements support value co-creation.
2. Compare ITIL and COBIT in terms of purpose, scope and practical use in an organisation.
3. Describe how asset management and configuration management complement one another.
4. Discuss the design of a risk-based supplier-management process for a critical cloud service.
5. Explain how controls, compliance, ethics and continual improvement should interact in IT governance.

Analytical / Application Questions

1. A service has 43,200 agreed minutes in a month and 70 minutes of measured downtime. Calculate its availability and explain two limitations of interpreting the result alone.
2. A university’s login service meets its availability target but has severe failures during examination periods. Propose a service-management investigation, including metrics, configuration information, capacity analysis and supplier questions.
3. An organisation wants to automate approval of high-risk production changes using AI. Evaluate the proposal using ITIL, COBIT, control, security, ethical and accountability considerations.

Multiple Choice Questions with Answers

Question 1

Which ITIL practice is primarily responsible for restoring normal service operation as quickly as possible?

A. Problem management

B. Incident management

C. Supplier management

D. Portfolio management

Correct Answer: B. Incident management

Question 2

Which COBIT governance domain includes evaluating, directing and monitoring?

A. EDM

B. APO

C. BAI

D. DSS

Correct Answer: A. EDM

Question 3

A service has 10,000 agreed minutes and 25 minutes of unavailability. What is its availability approximately?

A. 99.25%

B. 99.50%

C. 99.75%

D. 99.975%

Correct Answer: C. 99.75%

Question 4

What is the principal purpose of a CMDB?

A. To replace all monitoring tools

B. To store configuration information and relationships useful for service management

C. To approve every financial transaction

D. To calculate employee salaries

Correct Answer: B. To store configuration information and relationships useful for service management

Question 5

Which statement best describes an RPO?

A. The maximum acceptable time to restore a service

B. The maximum tolerable period of data loss measured in time

C. The average time to resolve an incident

D. The percentage of service availability required

Correct Answer: B. The maximum tolerable period of data loss measured in time

Question 6

Which change is normally low-risk, repeatable and pre-authorised?

A. Emergency change

B. Major change

C. Standard change

D. Unassessed change

Correct Answer: C. Standard change

Question 7

A control that identifies unauthorised access through log analysis is primarily what type of control?

A. Preventive

B. Detective

C. Directive

D. Compensating only

Correct Answer: B. Detective

Question 8

Why can a high average availability percentage be misleading?

A. Availability cannot be measured in minutes

B. It may conceal short, frequent or user-critical interruptions and unclear exclusions

C. Availability is always identical to reliability

D. Availability applies only to hardware

Correct Answer: B. It may conceal short, frequent or user-critical interruptions and unclear exclusions

Question 9

Which role is accountable for the end-to-end performance and outcomes of a service?

A. Service owner

B. Incident caller

C. Auditor only

D. Change implementer only

Correct Answer: A. Service owner

Question 10

An organisation has an SLO of 99.9% over 10,000 minutes. What is the implied error budget?

A. 1 minute

B. 10 minutes

C. 99 minutes

D. 999 minutes

Correct Answer: B. 10 minutes