How Do You Manage Federated Higher Education Websites?
We conduct primary research for our blog posts, looking at dozens or hundreds of higher education websites to ensure that our observations are based on solid evidence. Our recent set of posts examined higher education websites and specific social media, content sharing and technology issues.
Each time we review a higher education website we encounter the issue of how the site is organised: for example, as a single site or as a federation of sites. In this post, we step back and discuss managing multiple websites informed by our earlier research findings.
We've confined our discussion to public-facing higher education sites. The rules of engagement for internal sites (including intranets) differ as these serve different user communities and sets of needs from public sites.
Early on we identified that higher education institutions use ‘gateway’ websites – with the main domain name identifier – that organise the links to related sub-sites. The sub-sites correspond to academic schools, faculties, organisational functions or even specific “projects” and services.
The sub-sites are typically identified by variants of the main domain name: e.g. sep.university.edu. The naming conventions are often cryptic and break established SEO practices. This approach is used by about 10% of the organisations we investigated. One institution had implemented two hundred (yes, n = 200) sub-sites, each of which of were partially or wholly publicly accessible.
More Than Governance
Any large website presents management or governance issues, with the issues falling into two groups: those related to content and those related to the supporting information technology infrastructure.
The content issues include, but are not limited to, broken links, stale content, maverick content that breaks house style rules, unauthorised organisational logo or branding tweaks and the difficulty of co-ordinating decentralised content creation and editing.
The infrastructure issues include juggling multiple content management systems (CMS), keeping CMS and platform software patched and updated, reliably backing up content and ensuring service continuity. Now, multiply those tasks by 200.
Campus ITS “knows” who runs public servers because ITS has to allocate reachable IP addresses and names, as well as open firewall ports. But original configurations may have been made years earlier and for different purposes - and “things change” and distributed server owners don't always inform others of changes of use.
Furthermore, every institution has its own ethos and approach to centralisation/de-centralisation. It's not right. It's not wrong. It just is.
Web governance policies give many higher education organisations the day-to-day guidance needed to run decentralised content management and offer generalised statements about supporting IT. But, the question is – even if you have the right tools to manage one site, do you have the tools to manage all of them?
Do The Right Tools For The Job Exist?
In our opinion and based on what we encounter 'in the wild', website management tools need to be able to identify all relevant sub-sites and visualise the results in ways commensurate with the scale and complexity of the implementation.
Moreover, the tools should be capable of determining and warning if sub-sites are inadvertently breaking brand, promoting competing institutions, running advertising, exposing data subject to protection or violating other guidelines. And, do this for individual sites and to allow ‘management’ to see the status over all sites within the main ‘university.edu’ domain.
These are not simple issues and we welcome discussion about any of the points we've raised. How are you tackling the problems of decentralised or federated website management?
This article is cross-posted on our LinkedIn page, where we welcome comments, questions or discussion. We encourage you to subscribe for regular updates.