Yorkville University is a private degree-granting university headquartered in Fredericton, New Brunswick. During the late 2000s the wider Yorkville education group also operated three Toronto private colleges — Toronto Film School, RCC Institute of Technology, and the Academy of Design Toronto — under the same administration. Four schools, two provinces, two regulatory environments, and one shared student-facing technology surface that had not yet been built.
I joined as Director of Technology in 2008, with a mandate that came down to a single question: what does one coherent learning-technology stack look like when it has to serve a New Brunswick university and three Ontario private colleges at the same time, hold up to two different sets of provincial regulators, and let a student in Toronto and a student in Fredericton recognise the same institution underneath the school they actually enrolled in?
The shape of the stack
The architecture settled into three layers, each chosen because it was the right tool for what that layer actually had to do.
Moodle for online learning. Moodle was already the standard open-source learning management system for post-secondary institutions at the time, and it remains a serious answer to the post-secondary LMS question almost two decades later. It carried course delivery, discussion forums, assignment submission, gradebook, and the parts of the student-facing surface that needed to behave like a classroom. Moodle’s gravity in the higher-ed open-source community meant the platform would still be supported and improving years after the build — a real concern for an institution making a decade-scale technology bet.
WordPress for the public front ends. Each of the four schools needed its own marketing, program-information, admissions, and editorial surface — its own voice, its own program catalogue, its own intake funnels, its own communications calendar. Each school got its own WordPress install, each with a custom theme that gave the institution its own visual identity while keeping the underlying publishing rhythm consistent enough that a marketing or admissions staffer trained on one school’s site could move to another without re-learning the toolkit. WordPress in 2008 was still mostly known as a blog tool; using it as the editorial spine for four post-secondary institutions was an early bet on the platform’s institutional fit, and it aged well.
A custom Student Information System for the records spine. This was the build that didn’t have an off-the-shelf answer. Existing SIS products at the time were either over-built enterprise systems priced for state-university-scale buyers, or under-built single-school systems that couldn’t model four institutions sharing administration. The group needed admissions intake, application tracking, enrolment, registration, scheduling, transcripts, and financial-aid records to live in one system that knew the difference between a New Brunswick degree-granting institution and an Ontario private career college, because the two had to be reported to two different regulators in two different formats. Building it custom was the only way the records could actually serve both kinds of institution at the same time.
Two provinces, two regulators, one set of records
The legal layer is the part of this work that doesn’t make for a glamorous portfolio screenshot but is the part that determined most of the architectural choices. A New Brunswick degree-granting university operates under one statutory framework; an Ontario private career college operates under a different one. Student records, transcript integrity, retention periods, intake disclosures, and the reporting that goes up to each provincial regulator are not interchangeable across the two. Privacy law adds another layer underneath — federal under PIPEDA for commercial activity, with provincial privacy law in scope where applicable. The custom SIS had to know which jurisdiction each student record belonged to, what could and couldn’t flow between institutions in the same group, and how to produce the right report for the right regulator without manual reconstruction every cycle.
None of that compliance work appears as a feature in a screenshot. It appears as the absence of the problems an institution has when its records can’t answer a regulator’s question, when admissions accidentally moves data the law says it shouldn’t, or when a transcript audit reveals a gap that should never have been possible. The work was building the system so those absences stayed absent.
- Role: Director of Technology, Yorkville University (2008–2009)
- Scope: Four institutions across two provinces — Yorkville University (NB) and the three Toronto schools (Toronto Film School, RCC Institute of Technology, Academy of Design Toronto)
- The build: Moodle for online learning; WordPress per-institution for the public front ends; a custom Student Information System for admissions, registration, records, and regulatory reporting
- Team: Managed in-house technology staff and external contractors; partnered with academic, admissions, and registrar teams across the four schools
Where this pattern transfers
Any education group, hospital network, charitable umbrella, or government program that runs distinct institutions under one administrative roof has a version of this problem. Each property has its own brand, its own audience, its own intake, its own regulator. The shared infrastructure underneath has to be coherent enough that a staff member can move between properties without re-learning the toolkit, but distinct enough that each property’s audience never feels like they’re being routed into a generic shared system. The records spine has to know which property each record belongs to, which jurisdiction governs it, and which reports go out to which body on which cadence — and it has to be quiet about all of that, because the audience-facing surface should feel like the property they came for, not the umbrella.
The companion portfolio entries for the three Toronto schools — Toronto Film School, RCC Institute of Technology, and the Academy of Design Toronto — describe each institution’s WordPress front-end build inside this broader systems context.
