Introduction
The university acknowledged that we can best (or only?) meet some of the web needs by offering a second CMS platformUniversity acknowledged that a second CMS would bring considerable business benefit and indeed some web needs will only be met by this change, a significant change from the previous view that all web needs of the university should be met by SquizSquiz was the only CMS we required. As such, a selection process was added to the 2107 work programme.
A working party, comprised of staff from both ITS and the Web Team, was formed to determine the process for selecting a secondary content management system joint ITS-Web Team working party formed to selecting a secondary CMS and the associated business model. We have worked closely together rover the last six weeks, made progress where possible, and have now The team quickly agreed an evaluation process and criteria, but staff availability slowed down the selection and we have recently reached an impasse. This memo summarises the recent development and seeks clarification as to the direction we should take.
...
The working party agreed the evaluation criteria and, based on these, shortlisted the candidate CMS to Drupal and Silverstripe. We met with representatives of the companies Silverstripe (representing their own CMS) and Catalyst IT (representing Drupal). Further, we were provided access to demo versions of both CMS. A further meeting was held with experts in each CMS in the same room at the same time. This required us to draw from both the Silverstripe and Drupal teams at Catalyst to avoid the competitive tensions of two vendors in the room.
...
Discussions between Web, ITS and management identified the following requirements for the business model:
- The CMS platform must support multiple sites, where each can common or unique (within reason) modules, themes/templates, and permissions/access settings.
- The CMS platform must hosted externally and maintained by the vendor's technical staff, including updates, patching, back-ups and monitoring. As the university is in the process of moving Squiz to an externally hosted model, we wouldn't start a new secondary platform internally.
- THe CMS platform must support multiple sites, where each can common or unique (within reason) modules, themes/templates, and permissions/access settings.
- User support must be obtained through the CMS vendor or alternative channels funded by the site owners. The Web Team are stretched to support users of Squiz in their content, design and development needs and have insufficient resource to support users on another platform.
- Access to the secondary platform will be restricted, with ITS 'gate keeping' via a ticketing system. This is many different reasons:
- The resource is not free to the university so requests need to be vetted.
- Site owners wishing to use the platform would need to demonstrate capability to use the platform and/or sufficient resources to procure the necessary support.
- COMT have criteria on which sites should be on Squiz wherever possible, so might decline a request to do brand/risk management reasons.
- While support for the CMS platform will be purchased form a single supplier, every effort will be made to units to select their own model to provide the other services. This includes allowing alternative vendors/people to perform design and content work. Development of code/functionality would, as a minimum, need a code review from the hosting vendor, in order to keep the whole code base secure and performing well.
...
- $20,000 for a three-month proof of concept/trial in the first year (Ten days implementation costing $12,800, two days support and training costing $2,560, and three months hosting costing $4,500).
- $97,600 for a full year production CMS (An additional 20 days implementation costing $25,600, support for the hosting platform and CMS costing $36,000, and 12 months hosting costing $36,000).
- Extrapolated future year costs are approximately $80,000 per year.
While we haven't formally decided to procced proceed with Drupal, our assumption is that the resource costs of Silverstripe and Catalyst will be about the same.for Catalyst to work with either CMS is the same and based on publically available information Silverstripe.com charge more per hour than Catalyst.
Questions
While we can (and if we wish to proceed, should) negotiate further, this caused us to pause and consider the implications of costs of this order of magnitude. The following questions and discussion are intended to illicit management input and direction, not as the categorical answers.
...
If we have to offer the users of the secondary CMS content support (a probably scenario), then we could 'pull' this back from Catalyst and do it in-house. However, it seems foolish to try to host and support the CMS in-house, as we are trying to out-source these services for Squiz.Maybe we need to consider 'hosting' ourselves (knowing the limitations), as we at least can start moving sites of various (old) platforms onto one alternative. Maybe we have online documentation for users as a 'level 1', we internally offer level 2 and then use a vendor for level 3.
What, if anything, can we do this year, and port/forward to a future next year that has yet to be funded?
There may not be anything worth doing now with little certainty on future funding. Even if we knew we had a much less than required budget, I am unsure on the wisdom or value of moving forward this year.
Jane and Paul were unable to identify any sites that had sufficient on-going funding to risk building something this year without knowing what would happen next year.