When the University of Toronto’s Temerty Faculty of Medicine needed to create dozens of websites, Foster stepped up.
Background
When one University of Toronto Temerty Faculty of Medicine site became a group of three—and then 20—the Temerty Faculty of Medicine called on Foster to help tame the beast. What we developed ended up reimagining what Drupal could do, simplifying our client’s work and greatly magnifying their impact.
The University of Toronto’s Faculty of Medicine is one of the oldest in North America, first created when the School of Medicine was founded in 1843.
It’s also one of the largest, with approximately 9,000 faculty and staff, 7,000 learners, nine fully affiliated hospitals, and scores of other care sites.
However—from a Web perspective at least—the most important figure is 50, the number of separate departments, Research Centres, and other units that comprise the Temerty Faculty of Medicine.
You need an organization of that complexity to train doctors, of course. But as our client at the Temerty Faculty of Medicine came to discover—when those separate areas each want a website, complexity can be a killer.
The University of Toronto’s Temerty Faculty of Medicine is one of the oldest in North America, first created when the School of Medicine was founded in 1843.
The Challenge
Initially, the Temerty Faculty of Medicine needed only to revamp their flagship website, a task they handled ably.
And when the Graduate Program and Physician Assistant Program—which had previously been integrated into the main website—needed to be spun out, the answer seemed simple. Using the main site as a template, the Temerty Faculty of Medicine created two clones and allowed the programs to customize as they saw fit.
That’s when the trouble began. Our client quickly realized that three custom sites meant three times the maintenance and support, so they asked us for help. We had built the initial flagship site, so we were happy to be tackling this new challenge.
Once we had the lay of the land, the solution was clear.
We built a Drupal Distribution, a full copy of all the Drupal code that powered the Temerty Faculty of Medicine’s site. We also set up a Custom Upstream, a Pantheon product that acts as a scaffold on which anyone of any skill level can build a new website.
This combination enabled our client to launch new Department websites with little more than a click. Each new site would share the same features but remain independent of the others. In other words, if one site crashed, the others would stay online. Sites might have shared features, but they certainly didn’t share risk.
Crucially, the sites would also share the same changes and updates. So eventually, with some work to remake the two spinoff sites into proper “children” of the Distribution, it became easier for our client to maintain all three.
That is until the collection of three Department websites had become 20—at which point they understandably handed maintenance off to us.
The Solution
Supporting the nearly two dozen sites was simple enough: push security updates to the Distribution, then—one at a time—cascade those updates to each of the sites, checking that everything still worked as expected, and then deploying each site.
“Simple” didn’t mean “quick,” however. Eventually, the sheer amount of time consumed by even a small update drove us to look for a different solution.
That’s when we created Webpac, a custom “next-level” Distribution that was key to the Temerty Faculty of Medicine’s continued ability to roll out websites.
Where a Distribution full of pre-assembled “bundles” of features had represented a leap forward from vanilla Drupal, Webpac was a similar leap again.
In a Webpac Distribution, a core group of features would roll out automatically to every new site. However, site owners could also choose from optional pre-approved, pre-coded features that they could enable or disable with the click of a mouse.
Suddenly, if a particular Department wanted a new feature—professor biographies, for example—getting it was as simple as pushing a button.
Two basic rules governed Webpac.
First, no new website could auto-install a feature that hadn’t already been tested and made available to every other site.
And second, if one or more Departments did need a new feature, they could get it by paying to have it created, tested, and made available to all the others.
In this way, we were able to maintain the integrity of the Webpac Distribution, reduce maintenance, and ensure that Webpac would continue to power each new site added to the fold.
The Foster Difference
As it turned out, Webpac couldn’t have come at a better time: in 2018, we learned that our client’s (by then) 35+ Temerty Faculty of Medicine sites needed to move off Drupal 7 because of that platform’s end-of-life announcement.
Worse, because Drupal 8 would be built on an entirely new codebase, we would have to remake Webpac before we could use it to upgrade the Faculty’s websites.
Fortunately, as much work as that was, it was still infinitely more manageable than rebuilding the sites from scratch.
Webpac 2 was born, and over the intervening months, we relaunched every site, plus another ten that were created net-new. Thanks to Webpac 2, our client now manages 45 sites with only a team of two staff members, neither one a web developer or IT expert.
We think that fact speaks directly to what we were trying to create with Webpac—a simple way for anyone with any skill level to spin out websites.
What’s more, the principles behind Webpac 2 could be easily used to roll out sites other Faculties at the University of Toronto, or even for other universities. Corporate customers with multiple regional sites could also benefit greatly from a Webpac-style Distribution.
Webpac represents nothing less than the ability to scale digital assets without multiplying costs—an advantage that we’re excited to bring to others in the future.
Thanks to Webpac 2, our client now manages 45 sites with only a team of two staff members, neither one a web developer or IT expert.
Related Articles
