Secondary CMS one pager

Owned by Paul Seiler (Unlicensed)
Last updated: Mar 23, 2017
4 min read

Introduction

The University 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 Squiz was the only CMS we required. As such, a selection process was added to the 2107 work programme.

A joint ITS-Web Team working party formed to selecting a secondary CMS and the associated business model. 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.

Selection of a CMS

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.

The Web Team has a slight preference for Drupal over Silverstripe, for reasons of functionality (the existing extensions better cover our full range of needs), risk mitigation (Drupal has a sizable market share in higher education worldwide, greater compatibility with other higher-education software and larger developer support, albeit Silverstripe is well supported in Wellington) and the relationship with key staff (the Drupal lead understood our needs better).

Business model and pricing

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.
  • 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.

Indicative pricing from Catalyst IT to meet such requirements, whichever CMS we selected, was considerably higher than we expected:

  • $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 proceed with Drupal, the costs 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.

What sites would we move/work on first, given the uncertainty of future funding?

It is extremely difficult to start work on moving any site to the secondary CMS without the security of ongoing funding. We weren't envisaging the first year as a poof of concept, but as starting with small steps. No site owner would want us work with us when the site might be unsupported after the first few months. We don't believe there is a need to trial the secondary CMS, as we are confident that it can do what we require. 

Will an 'outsourced' model work?

The Web Team doubt that we will be able to maintain a 'hands off' approach as and when things start to go wrong, and also because some of the site we want on that platform are really those that we should be supporting (i.e. it is core business). This is definitely true from a content perspective, as the sites we see as benefiting from a different CMS are not fringe or 'outer-orbit'. Even development-wise, we will want to use/tune/extend it, together with the vendor.

The secondary CMS would still be a valuable addition to the available tools, but the core team will require new capability and capacity to support it.

Are there different support models that could have cheaper costs?

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. 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.