Beware of Drupal for enterprise WCM

A colleague at large university asked my thoughts on using Drupal for enterprise web content management (WCM).

Drupal has its uses, but I only recommend it for point solutions or, if in large-scale use, for cookie-cutter things where all the Drupal instances are configured almost identically and share little content. I generally do not recommend it for enterprise-wide WCM.

I wrote:

Drupal is a great solution for certain purposes, but I hesitate at recommending it for an enterprise CMS. Even though some tools make it easier to manage [edit: like Aegir], Drupal “enterprise”, especially for a college campus, is still essentially flying many individual instances in parallel, so I don’t consider that a real enterprise setup. No other “enterprise” system that I am aware of is so loosely-coupled on the application layer of the service delivery stack.

You’ll find other institutions with a different perspective. I think Stanford is one. Stanford, I believe, is widely using Drupal. [edit: yes, it is: https://techcommons.stanford.edu/drupal]

The problem with their setups is to run a massive Drupal installation, your IT department’s staff commitment to web content management (WCM) will be more heavily expressed in sysadmin skillsets and FTEs than developer skillsets and FTEs. The problem there is cultural: as practitioners of stability, minimizing cost, avoiding change, etc., sysadmins are culturally much further away from web marketing than developers.

And that’s what I like about Sitecore: as a true enterprise WCM, it frees me from much of the sysadmin burden that I would bear by running gobs of parallel instances. It allows me to instead invest in developer skillets and FTEs, which in the long term helps our marketing mission.

Now, there’s also an economy of scale. At some point, you may have sufficient staff resources that it may in fact be cost-effective to go with virtually any free CMS as a base product and develop whatever you want on it.

Three general pointers:

  • Customized code that is not expressed as a formal Drupal module or theme will cause update headaches. Drupal core and the modules have frequent releases, and I recommend staying on top of them because they often contain important bug and security fixes. If you customize Drupal core or customize a module, you’ll have to re-customize it every time there’s a new release. However, if you can implement your custom code as a formal module, it is much more likely to be able to exist unchanged while other modules or Drupal core change. It’s likely, though, that you’ll need to revisit your modules on major new Drupal releases, like v7 to v8.
  • Software costs are a small part of TCO of a system. Just because the software is free does not mean you’re going to get a gigantic savings over a commercial product. That notwithstanding, there are FOSS [edit: free and open source software] tools that make a lot of sense, like, say, Firefox, Chrome, WordPress, and even Drupal for certain situations. But sometimes, FOSS tools may require more FTEs or, like I said above, FTE types that may not be the best cultural fit for marketing.
  • Generally, academic-targeted CMSes are not that good. They seem to have their rabid supporters, but my general experience is that these supporters are suffering from confirmation bias, and that these academic focused CMSes cannot compete with the big players.

Leave a Reply

Your email address will not be published.