We in IT are aware that some of the terms we use to describe our services can be full of jargon and many well be verging on incomprehensible for someone outside of IT. Therefore, we have put together this glossary of IT terms which are used to describe the Service Management activities that IT undertakes to make what we do, and the processes we follow, a little easier for people outside of IT to understand. As such, we will aim to update this document as our services develop so that our customers across the university can always understand the approaches that we take and the processes that we follow to maintain the services that you rely upon.
IT distinguishes between Incidents (unplanned service interruptions or reductions in the performance of an IT service) and Requests (customer requests that do not represent a service disruption, such as a password reset). Service interruptions are handled through Incident Management, and Service Requests through Request Fulfilment. See knowledge base article KB0012925 for information
Incident Management aims to manage the lifecycle of all Incidents from them first being reported through to their eventual resolution. The primary objective of this process is to return the IT service to users and to its normal state as quickly as possible.
The Incident Management process can be triggered in various ways: A user, customer or supplier may report an issue, IT technical staff may notice a (potential or actual) failure, or an Incident may be raised automatically by an event monitoring system.
All Incidents will be logged by IT as Incident Records in ServiceNow, where their status can be tracked, and a complete historical record can be maintained. The initial categorisation and prioritisation of Incidents is a critical step for determining how the Incident should be handled and how much time is available for its resolution. The system’s Service Level will also help to clarify these prioritisation and categorisation decisions.
If ‘First Line Support’ (the IT Service Desk) is unable to resolve an Incident, it must be escalated to an appropriate specialist support group in ‘Second Line Support’ (normally a team in Application Support). Then, if required, Second Level Support may in turn involve external parties such as suppliers and vendors or a specialist internal team within IT (this is known as ‘Third Line Support’) in resolving the Incident.
IT has defined a special process for dealing with Major Incidents (emergencies that affect business-critical services and require immediate attention). Major Incidents typically require the establishment of a temporary Major Incident Team to identify and implement the resolution.
The responsibility of First Line Support is to register and classify received Incidents and to undertake an immediate effort to resolve the issue and/or to restore a failed IT service as quickly as possible as well as providing workarounds.
If no straightforward solution can be achieved, First Line Support will transfer the Incident to Second Line Support (essentially the expert technical support groups).
First Line Support also processes Service Requests and keeps users informed about their Incidents' status at agreed intervals.
At the university, First Line Support is provided by the IT Service Desk.
Second Line Support takes over Incidents which cannot be solved immediately by the First Line Support team (the IT Service Desk).
If necessary, Second Level Support will request support from elsewhere such as from another IT team or from a third-party application provider of from a software or hardware manufacturer.
The aim remains to resolve the IT issue and/or to restore a failed IT Service as quickly as possible or provide an adequate workaround.
If a workaround is provided but further investigations are required to fully understand the root cause and potential fixes, then Second Line Support may close the incident and open a Problem to allow further examination of the underlying issue.
Third Line Support is typically provided by third-party application providers or by hardware or software manufacturers.
However, at Leeds this Third Line Support may well be provided by another IT team (such as the Server Team, the Storage Team or by Application Development).
The services of Third Line Support are often requested by Second Line Support if required for solving an Incident however Second Level Support retain ownership of the Incident and are responsible for coordinating the responses to the customers and all suppliers.
The aim is to resolve the IT issue and/or to restore a failed IT Service as quickly as possible, or to provide an adequate workaround.
The aim with Request Fulfilment is to fulfil Service Requests, which in most cases are minor (or standard) Changes - e.g. requests to change a password or requests for information.
At the university, many Service Requests will be fulfilled by First Level Support (i.e. the Service Desk) while others will be completed by Second Level Support. See knowledge base article KB0012925 for information.
A Problem can be defined as the underlying cause of one or more Incidents. The cause is not usually known at the point a Problem is created.
Problem Management seeks to manage the full lifecycle of all Problems. The primary objectives of this process are to prevent Incidents from happening in the first place, and to minimize the impact of incidents that cannot be prevented. In some cases, here at the university, a persistent issue exists which can generate significant numbers of incidents, either within a short timeframe or over an extended period. Problem Management in IT allocates dedicated time to identifying the cause and resolving these underlying Problems, thus improving the service for customers, and reducing support overheads for the long-term.
For Cloud Hosted services, Problem Management would normally be delivered in partnership with the vendor but the relationship between First and Second Level Support and Problem management is key to spotting patterns and trends in Incident frequency so underlying Problems can be recognised.
The aim of Knowledge Management is to gather, analyse, store, and share knowledge and information within an organisation. The primary purpose of this is to improve efficiency by making it as simple as possible to locate and make use of knowledge about IT systems and processes.
At the university, this involves the maintenance of a public-facing knowledge base but also keeping a knowledge base of key information for use by IT staff for resolving Incidents, delivering Service Requests and many other activities.
The purpose of the capacity and performance management is to ensure that services achieve agreed and expected performance, satisfying current and future demand in a cost-effective way.
Capacity and performance management includes the following activities:
When services are running on a cloud service such as AWS, Azure, or Google, it changes the approach to capacity and performance management significantly in that the flexibility of what the cloud provider can offer reduces the need for upfront modelling and allows the adjustment of allocated resources based on actual service operation rather than ‘theoretical future peak’ use.
This activity is sometimes termed Event Management which is a slightly unhelpful term for the concept of monitoring the way a service is running and the different factors which might impact on the smooth running of the service. The Event Management process aims to filter and categorize any change of state (or ‘Event’) that impacts on a live service in order to decide on appropriate actions - if required. The term Event has also come to be used as IT shorthand for any alert or notification created by an IT service.
There is no significant change in the requirement for Service Monitoring for cloud hosted services but how the monitoring is provided could be different (for example, the third-party vendor may well provide their own monitoring tools).
IT will produce a plan to define the frequency and scope of preventative maintenance for the key applications and infrastructure components that we have agreed to support.
The Continual Service Improvement (CSI) process uses methods from quality management to learn from past successes and failures to help continually improve the effectiveness and efficiency of all elements of a service.
At Leeds, this role is usually the responsibility of Application Support and both Maintenance and CSI are usually combined into a single annual plan with regular reviews.
There is no expectation that ongoing maintenance or the CSI process will differ significantly for cloud hosted services although the vendor may take a more prominent role in the process (managed overall by IT Application Support).
The purpose of Service Availability Management is to ensure that services deliver the agreed levels of availability to meet the needs of customers and users.
By ‘availability’ we mean the ability of an IT service to perform what it is designed to do when required. In the simplest terms, the availability of a service depends on how frequently the service fails, and how quickly it recovers after a failure.
It should be noted that cloud hosted services can often provide higher levels of availability than locally hosted services. But the principles behind availability management for these services should remain the same.
The aim of Compliance Management is to ensure that all IT services, processes, and systems comply with both the university policies and procedures and any legal or regulatory requirements.
At the university we expect this to be managed via a Compliance Check which will review the accessibility, security, and potential vulnerability of the IT service.
‘Accessibility’ refers to ensuring that websites and applications can be used by as many people as possible. It involves ensuring that the content and the design of the service is clear and simple enough so that most people can use it without needing to adapt, while supporting those who have different needs.
Cyber security is the practice of defending computers, servers, mobile devices, electronic systems, networks, and data from malicious attacks. In this context, the focus is on Application security and keeping the services IT looks after free from threats. A compromised application could provide access to the data its designed to protect. Successful security begins in the design stage, well before a program or device is deployed. The Compliance Check envisages a regular review to confirm that security measures and procedures are still in line with perceptions of risk from the business side and to verify if those measures and procedures are regularly maintained and tested.
‘Vulnerability’ is a concept which is closely aligned to cyber security. A vulnerability check refers to a process which identifies flaws or weaknesses in system security procedures, design, implementation, or internal controls that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the university’s security policy.
At the university, the Compliance Check with be conducted by one of the Primary contacts of the service working closely with the IT Security Team.
The purpose of Service Continuity and Risk Management is to manage the risks that could seriously impact an IT service. This process seeks to ensure that minimum agreed Service Levels can always be maintained by reducing the risk from potential disaster events to an acceptable level and planning for the swift recovery of the IT service.
The intention here is to the manage the risks that could seriously impact IT services by lowering the risk from disaster events to an acceptable level and by planning for the swift recovery of IT services should a disaster event occur.
The IT Service Continuity plan is informed by the priorities and requirements defined by the university as part of their Business Continuity Strategy.
It is likely that IT Service Continuity Management would largely be handled by a third-party vendor in case of a Cloud Hosted service. However, IT would still need to provide service continuity in relation to ensuring reliable access to their web-based service.
A Change can be defined as the addition, modification, or removal of anything that could impact on IT services. The scope includes upgrades, migrations, and a huge range of other changes to IT architecture, processes, tools, and documentation.
Change Management seeks to minimize the risk associated with these changes – especially in relation to the liver service. Its primary objective is to authorise and enable useful Changes to be made, with minimum disruption to IT services and to block or challenge potentially damaging changes.
IT has a well-established Change Management process headed up by a weekly Change Advisory Board consisting of senior and expert IT staff. Therefore, while Changes relating to your service would be initiated and coordinated by the key service contacts, those staff would be supported by the whole IT Change Management infrastructure and process.
With a Cloud Hosted service, it may be that IT might be limited in the control that it has in the timing or approach to some changes. In this case the key role would be to work with the third-party vendor and stakeholders to minimise risk – but the change management process would still be required.
The purpose of Release & Deployment Management is to plan, schedule and control the release of new or updated services or service components to both test and live environments. The primary goal of this process is to ensure that the live services are protected when changes are released into the live environment.
This is a developing area of IT service provision, but it is closely aligned with Change Management and would form part of the overall IT Change Management process.
With cloud-hosted services there might be some limitations on the control that IT has over the process. But a full understanding of the risks of undertaking such changes along with appropriate mitigation of those changes would still be essential.
Effective testing should ensure that deployed Releases and the resulting services meet customer expectations and verifies that IT operations is able to fully support the new service.
This activity is again, closely aligned with Change Management and while requests for the testing of new functionality or architecture would be coordinated by the key service contacts, this activity be either handled via a dedicated Test team within IT or by the key services contacts working in partnership with users of the service.
The need for testing would not necessarily depend on whether it was a locally hosted service or Cloud Hosted though if it were the latter then the testing activity may take place in partnership with the third-party provider.
IT services deal with stakeholders in almost every process and these business stakeholders have a legitimate interest in the reliability and management of the service. IT enables engagement with the business through the organisation of regular Service Review meetings. These will be organised at different intervals based on the Service Level of the supported service and with the agreement of the business representatives.
These meetings will help to:
The objective of this activity is to ensure that all contracts with suppliers fully support the needs of the business. This process is also responsible for making sure that all suppliers meet their contractual commitments.
To support this activity, IT employs an IT Contract Manager and has also provided specialist training for all its key service contacts. The aim is to put in place regular Supplier and Contract Reviews with the vendor and key stakeholders to ensure that the current contract meets our requirements and also that the supplier is fulfilling their obligations.
For Cloud Hosted applications, there is no real difference in the need to ensure that contracts with third-party suppliers meet the needs of the university and are being delivered effectively.