Ask why a university's public website, faculty-profile directory, IT service desk, and staff insurance system don't share a login, and the honest answer is rarely technical. It's procurement history: the website was bought by the communications office in one year, the service desk by IT in another, insurance by HR in a third — each a reasonable decision in isolation, each optimized only for the office that bought it.
The cost shows up as everyone else's problem
A new hire needs five separate accounts before their first week is over. A faculty-promotion request has to be manually re-entered into three systems because none of them share a schema. An IT ticket about a broken insurance login goes to the help desk, which has no visibility into the insurance system and can only forward it — to an office that may not answer for days.
Nobody who felt this pain was the one who could fix it
The communications office that bought the website has no reason to think about service-desk integration. IT, which feels the support burden of five disconnected logins, wasn't the one purchasing insurance software. The fragmentation is rational at each individual purchase decision and irrational in aggregate — which is exactly the kind of problem that never gets fixed by any one department acting alone.
What "integrated" actually has to mean
Not a single monolithic app — that just recreates the same problem with one vendor instead of five. What actually closes the gap is one identity layer every system sits behind, so a promotion request, a service ticket, and an insurance record are three views of the same person rather than three unrelated accounts that happen to share a name. Everything else — website, faculty directory, ticketing, insurance — can stay logically separate underneath, as long as none of them ask a student or staff member to log in twice.
We built exactly this for a public university: one SSO behind five previously disconnected systems. The write-up, with real numbers, is in our Lorestan University case study.
