“The strategic integration project and resulting integration platform are huge enablers in our digital transformation. The platform has helped us improve governance, make better use of the data we hold across the university and improve the experiences we can offer students and our employees.
Integration debt, compounded over years.
The University of Nottingham is one of the UK's leading research universities — a Russell Group institution with more than 35,000 students and a global campus presence. But in terms of operational complexity, it functions more like a small city than an academic institution: managing catering, communication infrastructure, transport, real estate, personnel, finance, and student services across a single, deeply interconnected organisation.
The data infrastructure that supported all of this had grown tactically. Historically, integrations at UoN had used a point-to-point approach — developed in response to the immediate need for rapid delivery, rather than as part of a coherent architecture. Each integration connected two systems directly. As the number of systems grew, so did the mesh of connections between them. Over time, this became fragile: changes in one system rippled unpredictably through others, maintenance costs climbed, and deploying anything new carried genuine risk.
As system complexity grew and technical debt accrued, excess cost and risk became the defining characteristics of UoN's integration landscape. The university wanted to evolve their approach — centralising and better coordinating data within and between systems — but needed a partner who could design the right architecture, deliver it safely, and ensure the internal team could own it afterwards.
Point-to-point integrations feel fast to build. Over time, they become the most expensive infrastructure a large organisation can maintain.
Because every new connection multiplies the complexity of every existing one.
The approach
We began with an in-depth analysis of UoN's infrastructure and business and technical requirements — not to produce a report, but to understand the integration landscape well enough to make the right architectural choices. We evaluated a range of solutions available on the market, including leading iPaaS (integration platform as a service) products, before recommending Microsoft Azure as the right foundation for a cloud-native data integration platform.
Working closely with UoN's infrastructure and IT teams, we deployed Azure as the central integration layer for the university. The platform brought together Azure API Management, Service Bus, Data Factory, and Cosmos DB — a modern, event-driven architecture that could ingest, integrate, and process data from across the university's systems of record, rather than routing it through brittle bilateral connections.
We prioritised two key systems of record first, establishing proven patterns before extending the platform outward. The entire process was managed end-to-end in Azure DevOps, using Infrastructure as Code and automation principles throughout — providing the basis for rapid but safe development and testing, and allowing for increased speed of delivery without compromising security or governance.
Azure API Management
Centralised API gateway providing governed, secure access to university data across systems.
Azure Service Bus
Reliable message queuing for asynchronous integration between systems of record.
Azure Data Factory
Data pipeline orchestration for ingesting and transforming data from multiple source systems.
Cosmos DB
Globally distributed NoSQL storage providing the persistence layer for integrated data.
Azure DevOps
End-to-end delivery management using Infrastructure as Code and automated deployment pipelines.
Infrastructure as Code
Every environment defined in code — enabling safe, repeatable deployments and handover to UoN's own teams.
Building for handover, not dependency
From the outset, the engagement was designed to end with UoN in control. Architectural ownership — the ability to understand, extend, and govern the platform independently — was not an afterthought. It was built into the delivery model from day one.
Post-delivery, we continued our partnership with UoN to establish a Centre of Excellence within the university: sharing best practices, providing architectural ownership of the solution, and equipping their internal teams to take control of future integrations as they continued their transformation journey. This is the difference between delivering a platform and delivering capability. The work does not end when the code is shipped — it ends when the client no longer needs you in the room.
We're continuing to work in partnership with UoN to modernise their wider infrastructure and to design and develop new applications built on top of the integration platform we've put in place.