Why this is an organizational problem
Universities are federations: faculties, departments, research groups, and administrative units each have budgets, schedules, and priorities. Central teams must govern the whole estate while relying on hundreds of editors who operate outside their management. Governance documents exist for this situation, but enforcement is the bottleneck—policy scales linearly with enforcement effort, and central teams lack that resource.
- 1Departmental sprawl
Departments legitimately need microsites and campaign pages. When central queues are slow, units spin up their own subsites or page-builder tools. These off-CMS sites often escape analytics, brand review, and accessibility checks, making the true estate size unknown.
- 1Brand drift
- 1Accessibility debt
Accessibility requirements (WCAG and related regulations) apply to the whole estate. Under a page-by-page model, accessibility depends on the least-trained editor's most recent edit. Auditing thousands of pages one-by-one is impractical, so accessibility problems compound until a complaint or legal notice forces remediation.
- 1The slow-page spiral
When official channels are slow, teams take shortcuts: central queues fall behind, a unit buys a landing-page tool, launches quickly, and the new page lives outside governance. Each shortcut increases sprawl, which slows the central team further, justifying more shortcuts.
Tightening governance—stricter brand rules, mandatory training, editorial boards—looks intuitive but fails because enforcement is expensive. Policies create friction without shortening the official path. If compliance remains slower than alternative routes, people will keep bypassing central systems.
A practical fix: governed components plus fast page generation
The article argues for an approach that reduces the need for enforcement by making the official path demonstrably faster and easier. Two elements matter:
- A governed component library: a single source of design and accessible components that front-end developers and editors can use. When components are centrally maintained and versioned, editors get consistent UI patterns without guessing or approximating.
- Page generation fast enough that teams don't route around it: when editors can produce production-ready pages quickly inside the governed system, the incentive to use off-CMS tools disappears.
ExperienceKit is presented as the pattern that combines those elements for Drupal estates: a governed library of components plus fast generation so local teams can publish on-brand, accessible pages inside the central infrastructure.