One outage through three lenses: what Halo’s Service Data Model looks like in higher education

When we talk to customers about Halo’s Service Data Model (SDM), the conversation quickly gets technical. You start talking about service relationships, CMDB structures, dependencies, configuration items and access controls, and before long you’re several layers removed from the reason any of it matters.

A simpler way to explain it is to imagine that the WiFi goes down in the main university library.

A student wants to know whether IT is aware of the problem, which parts of the library are affected and when they’re likely to be able to connect again. The Service Desk needs more context. They need to know whether the problem is already being investigated, what they can tell people who contact them and whether all those reports are describing the same incident. The Networks team needs a different level of information: what has failed, what depends on it, which other services might be affected, and whether a recent change could have contributed. It’s all the same outage, supported by the same underlying data, but each group needs to see something different.

We like to describe the principle like this:

‘Model services around how they’re delivered. Present them around how they’re consumed.’

Should a university service catalogue be split into student and staff services?

A typical internal IT function may primarily support other internal employees. Universities tend to have a much broader mix of people interacting with their services: undergraduate students, postgraduates, academics, researchers, professional services staff, contractors and visitors. There may also be applicants, prospective students and other people who aren’t yet formally part of the institution but still need access to information or digital services.

Those audiences may overlap as well. An academic is a member of staff, but may spend much of their working day using teaching systems, research platforms and student administration services. A postgraduate researcher might simultaneously be a student, a researcher and an employee.

This is one reason we’re cautious about service catalogues that are structured too heavily around categories such as Student Requests and Staff Requests. There’s nothing wrong with presenting services differently to different audiences. In a university environment, that can be useful. The problem starts when the audience-facing structure becomes the service architecture underneath it.

WiFi doesn’t become a student service when a student connects to it and then turn into a staff service when a lecturer uses it five minutes later. It’s still the same connectivity service, running across the same underlying network estate. What changes is the context: who can see the information, how it’s presented, what details are useful to them and what the support team needs behind the scenes.

Halo can accommodate those different views without requiring the underlying service model to be designed around audience categories. That gives you much more freedom to model the service properly, then decide how different groups should experience it.

Lens one: the student view

Go back to our library outage. From the student’s point of view, the ideal experience is fairly straightforward.

They open the portal, status page or perhaps a virtual agent and see something along these lines:

For most students, that is enough. They can immediately see that the problem is known, whether it affects them, and when to expect another update.

They don’t need to know that LIB-DIST-SW-01 is unavailable. A topology view of switches, access points, and wireless controllers won’t help someone who simply wants to know whether they’ll be able to get online. Nor should they need to understand RADIUS or DHCP to work out whether IT has noticed the problem.

From their perspective, the service is WiFi Connectivity in the Main Library. The access point above their head is part of the technology that provides that service, not the service itself.

It sounds like a small distinction, but it affects the quality of the user experience. In large university environments, it’s surprisingly easy for technical structures to creep into the way services are presented. When that happens, the portal begins to reflect the way IT organises and supports technology rather than the way people use it.

Lens two: the Service Desk view

The Service Desk is looking at the same outage, but a student-level status message isn’t quite enough. Analysts don’t necessarily need the depth of information available to a network engineer, but they do need enough context to understand what is happening and deal with incoming contacts sensibly.

Their view might contain something like:

Now an analyst answering a call or reviewing a new ticket can immediately see that there is already a known issue. They can establish whether the person is in the affected location, associate their incident with the wider problem and give them the latest agreed update without hunting for information elsewhere.

That can prevent a familiar chain of events: another ticket gets raised, somebody sends another message to Networks, Networks confirms for the fifth time that they’re already investigating it, and several teams spend time rediscovering something the organisation already knows.

This is where the SDM goes beyond just the service catalogue. It gives customer-facing IT teams useful context around the services they support. The result can be fewer duplicate investigations, clearer communications, and a much quicker way to recognise when several apparently separate reports are symptoms of the same underlying problem.

For a university, that visibility is particularly useful because the same technical foundations often sit underneath teaching, research, administration and day-to-day campus life. A network issue that looks relatively contained from one team’s perspective may be much more significant once you understand who and what depends on it.

Lens three: the Networks team view

Network Operations needs to go further again. Their question isn’t simply whether users are having problems. They need to know what has failed and how far the consequences might spread.

The technical view could look more like this:

For the Networks team, the useful questions are now about failure, dependency and impact. They can see the component that has gone down, the infrastructure below it, the services above it and potentially anything else that shares the same dependencies.

The student and the network engineer can therefore have two different descriptions of exactly the same incident.

The student sees: WiFi Connectivity is affected in the Main Library.

Networks sees: LIB-DIST-SW-01 is unavailable and downstream wireless infrastructure is affected.

Both descriptions are useful because they answer the question that particular audience is asking.

The three views side by side

Who	What they need to know	What they see
Student	Whether IT knows about the problem, which parts of the library are affected and when they can connect again	WiFi Connectivity: service issue in the Main Library, Floors 1 to 3, with the time of the next update
Service Desk	Whether the problem is already being investigated, what to tell people who contact them and whether the reports describe the same incident	The related major incident (INC001284), 27 related user incidents, the resolver team and the latest update
Networks team	What has failed, what depends on it, which other services might be affected and whether a recent change contributed	The failed CI (LIB-DIST-SW-01), the affected switches and 34 access points, dependencies and the recent change CHG004291

Why this gets interesting in Higher Education

Universities tend to have a broad visible service estate. Teaching platforms, student administration, timetabling, identity, research systems, HR, finance, estates, collaboration tools and public-facing web services may all sit within the same overall environment.

Underneath that variety, however, you often find the same foundations appearing again and again. Identity services, network connectivity, storage, hosting, integrations and security can support dozens of apparently unrelated services.

Someone browsing a portal wants to find the thing they need quickly. Someone looking at a status page wants to understand whether the service they depend on is currently working. Someone managing the environment needs to understand how that service is built, what it depends on and what could be affected by a failure or change.

Those requirements are connected, but they aren’t interchangeable. The underlying service model can represent delivery and dependency while the user-facing experience presents those services in a way that makes sense to the individual.

That separation is useful in almost any organisation, but universities make the case especially clearly because so many overlapping audiences consume a shared technology estate.

Should each location be a separate service in Halo?

The library example raises another modelling question we come across quite often.

You could create separate records for:

• WiFi: Main Library
• WiFi: Students’ Union
• WiFi: Accommodation
• WiFi: Teaching Building A

There will be situations where that makes sense. Perhaps different locations genuinely have different ownership, technology, support arrangements or service expectations.

In many cases, though, you’ll end up with a cleaner model if the service remains WiFi Connectivity and location is treated as context around that service. The library is somewhere WiFi is consumed; it doesn’t necessarily need to become a completely different service record because of that.

You can still associate infrastructure with buildings, floors and rooms. If a switch fails in the Main Library, Halo can show that location as part of the impact. What you avoid is creating dozens of near-identical services simply so that you can tell users which building has a problem.

There’s a useful practical test here. If the locations genuinely need to be managed as different services, model them that way. If the distinction is mainly there to describe where somebody is experiencing the same service, location may be better treated as another dimension of the model.

The same model becomes useful during change

The relationships aren’t only useful once something has gone wrong.

Suppose Network Engineering plans to replace LIB-DIST-SW-01. An asset record tells them which switch they’re changing, but a service-aware model can tell them much more:

That gives Change Management a much better starting point for assessing impact. The conversation can move beyond the technical component itself to the service that relies on it, the people likely to notice the disruption, any other work happening in the same area and the communications that may be required.

The eventual message to users doesn’t need to expose any of that complexity; the outbound messaging might be as simple as:

The difficult part is rarely Halo alone

Halo can provide the structure for this kind of service model, but getting value from it depends heavily on the supporting data in the platform.

Do your user records reliably tell you who somebody is and what their relationship with the university is? Can somebody be recognised as both an employee and a postgraduate researcher? Are infrastructure assets associated accurately with physical locations? Do you know which technical CIs support which services, and who is responsible for maintaining those relationships?

Then there are questions about the data coming from other systems. HR, student records and identity platforms won’t always agree. You need to know which source is authoritative, how conflicts are handled and how quickly changes should flow through into Halo.

These aren’t simply configuration questions. They involve data ownership, governance, and how teams work together.

They’re also a good reason not to make completeness the starting objective. Few universities will get much value from spending months documenting every service, application, dependency, and CI before anybody is allowed to use the model. A more practical approach is usually to start with a manageable set of services where the relationships answer real operational questions, then improve the model as it becomes part of everyday service management.

The long-term aim is for the SDM to be something people use when managing incidents, changes and services. If it becomes a diagram created during implementation and rarely revisited, the original structure doesn’t matter, no matter how elegant it was.

One outage, three lenses

The library WiFi example works because the differences are easy to see. The student wants to understand what they’re experiencing and when they might be able to connect again. The Service Desk needs to know who is affected, whether the issue is already known and what they can tell people. Network Operations needs to understand the failure itself, the dependencies around it and what else may be affected.

The same underlying service model can support those conversations without forcing everyone to look at the same information.

For us, that’s one of the most useful ways to think about Halo’s Service Data Model in a university environment. The challenge isn’t to produce one perfect hierarchy that students, service desk analysts, platform owners and network engineers can all navigate in exactly the same way. They have different jobs to do, so they need different views.

Model services around how they’re delivered. Present them around the way they’re consumed. Then use the relationships underneath to make sure each person can see the part of the picture that helps them.

This is one of the conversations we’ll be having at Halo Connect: Higher Education in London on Thursday 26 November, with Thomas Monaghan from Halo. If your university runs Halo, or is weighing it up, you’d be welcome to join us.