Managing Complexity in Higher Education Websites

Read one developer’s story about navigating the stormy waters of developing websites for colleges and universities for more than a decade.

The web was born in the world of higher education and research institutions. Starting first as a tool for sharing information among researchers and educators, it has expanded in the three decades to connect to practically every portion of our lives.

I wish I had thought through the implications of that evolution more deeply early in my career as I made websites for educational institutions of all sizes. I engineered projects making new sites for grade schools, high schools, small liberal arts colleges, huge state schools, medical schools and more.

At that time, in the late 2000s and early 2010s, most of these institutions felt like their web presence was out of control. The people managing the sites thought their content was inconsistent, they struggled to keep styling on brand. Even for some very large institutions, knowing how many sites they had was a surprisingly difficult question to answer.

I thought the challenge before me was a challenge of cleverness. If only I could reason deeply enough about how best to balance all of the competing interests, I could craft an elegant system and lock it into place for long-term stability. In that era, the Drupal ecosystem had numerous answers to centralizing control of multiple websites while still allowing individual academic departments to keep some level of autonomy.

We could do cookie-cutter sites with tools like Drupal Multisite, Domain Access and Organic Groups. And I tried them all. Each one took differing approaches to the same basic idea of centralizing control of functionality by making one Drupal instance pretend to be many separate websites. With the benefit of hindsight, I can more clearly see that this approach hinged on an unrealistic degree of certainty that the shape of the cookie cutter that was made during that project would continue to be the appropriate shape in the years to come.

My own novel contribution to this space was the module Organic Groups Fieldable Panel Panes. This module enabled individual academic departments (controlled via Organic Groups) to build out landing pages with Panelizeer and Fieldable Panel Panes. I felt like I was succeeding at my job by leveraging enough creativity and smarts to wire together these two independently complex module ecosystems. (Engineers are supposed to be smart, right?!) In retrospect, I can again see that wrangling this complexity at a moment in time did not necessarily serve the long-term interest well.

The web continues to change. The pressures on web teams continue to change. Of the five types of KPIs a website might have, .edu websites have at least four. A college website needs to attract the next class of freshmen. It needs to steer current students toward online learning tools. It needs to promote the results of its researchers to wider audiences. And don't forget about football ticket sales. Squeeze all of that above the fold on the homepage, please.

When I teamed up with Pantheon, I was initially skeptical of our Custom Upstreams product. It holds some centralized control for a university IT team but it fundamentally allows for more flexibility by making each child site a real, separate site. That flexibility frightened me. (What if one academic department goes rogue and off-brand?!)

Now as I approach my seven-year anniversary with Pantheon, I see that there's more to fear from a shattered cookie cutter than from a different balance of standardization and flexibility. By giving a central IT group a git-based mechanism to share code and quickly spin up new sites, Pantheon’s Custom Upstreams retains the value of low overhead. Also, giving each site its own database and deployment pipeline radically de-risks the deployment of new features. Instead of deploying an update to 1,000 sites in the same instant and praying it doesn't break them, updates can be rolled out first to one site and then the rest in increasing volume.

On the scale of the last decade, the tools for managing server-level infrastructure have gotten significantly more powerful. The patterns for making one Drupal site act as many sites was a more sensible trade-off a decade ago, when configuring many servers was relatively expensive and specialized. The container revolution and the present push toward smaller and smaller deployment artifacts make mega sites far less sensible.

After two pandemic years of no business travel, I have enjoyed getting on the road recently and hearing that these needs are just as strong now. Many higher education institutions are centuries old. They need to plan long-term. Doing that effectively means striking an intentional balance between standardization and flexibility. Too rigid and a system could crack within a few years. Too flexible and teams get tied in knots. The web presences of institutions planning on decades-long scales need to plan for long-term evolution too. They can do their best by maximizing their understanding of their long-term goals and evaluating how technology can best support those goals instead of maximizing any given technology trend du jour and backing it into purposeful usage.