For the past few months we have been investigating whether Drupal might be a suitable CMS for our university's web presence. Several people in the university already use Drupal for smaller sites and we use it ourselves in that way. It is popular and highly flexible. It has been used for a number of highly visible sites around the world and so would likely handle the number of page hits that our central web site receives.
The big question for us was whether the large number of modules that are available for Drupal could be managed in a consistent way across our large, devolved, institution. The university has over 500 people who can edit some part or other of our central web site and we need mechanisms for managing this access. We want to be able to share information between different parts of this distributed information architecture, a requirement that is very different from running a more centralised operation.
Meanwhile, Drupal modules are written and maintained by a large, devolved, open-source development community. This can make the system very flexible and responsive but can also lead to inconsistencies between modules. Security fixes can sometimes be bundled in with upgrades to functionality, which can make maintenance more complicated than a system provided be a central vendor. We needed to understand how to engage with the Drupal community and how to manage an installation to provide the rock-solid service the university's users require.
We do use other open source software, such as Apache and Linux, for some of our core systems. Those are rather different in character to Drupal - from our point of view, they could as well be a commercial product. We download them, install them and patch them; we don't modify them or configure them from a range of different options. Drupal will be a different experience. The nearest we have come to this so far is probably the Moodle virtual learning environment.
I'd pleased to say that our investigation was successful. The project team wrote a detailed report which was presented to the governance group, who gave their blessing to this initiative. We are now progressing to the next stage, drawing up a detailed business case and implementation plan.
The big question for us was whether the large number of modules that are available for Drupal could be managed in a consistent way across our large, devolved, institution. The university has over 500 people who can edit some part or other of our central web site and we need mechanisms for managing this access. We want to be able to share information between different parts of this distributed information architecture, a requirement that is very different from running a more centralised operation.
Meanwhile, Drupal modules are written and maintained by a large, devolved, open-source development community. This can make the system very flexible and responsive but can also lead to inconsistencies between modules. Security fixes can sometimes be bundled in with upgrades to functionality, which can make maintenance more complicated than a system provided be a central vendor. We needed to understand how to engage with the Drupal community and how to manage an installation to provide the rock-solid service the university's users require.
We do use other open source software, such as Apache and Linux, for some of our core systems. Those are rather different in character to Drupal - from our point of view, they could as well be a commercial product. We download them, install them and patch them; we don't modify them or configure them from a range of different options. Drupal will be a different experience. The nearest we have come to this so far is probably the Moodle virtual learning environment.
I'd pleased to say that our investigation was successful. The project team wrote a detailed report which was presented to the governance group, who gave their blessing to this initiative. We are now progressing to the next stage, drawing up a detailed business case and implementation plan.
Comments