You don’t really want a CMS

Customers often come to us with a requirement that they need a CMS (Content Management System) to drive their website. When we explore this a bit more, we’re generally able to re-express this requirement such that the customer would like the ability for non-technical people to be able to manage content on their website.

Depending on the specifics around this need, we’ve found more often than not that a CMS isn’t the right solution.

You probably want a CMF

A CMF (Content Management Framework) is a slightly different way to deliver content management capability in a web application.

In a traditional CMS setup (the likes of Sitecore, Drupal, and Adobe CQ) all of the functionality of the website is generally built inside the CMS. And it turns out that while these CMS systems do the content management stuff pretty well (though in the case of Drupal we might dispute even that), what they don’t do is provide a particularly productive platform on which to build rich customer-facing functionality.

The Content Management Framework approach takes the opposite approach: start with a web framework that is built for delivering rich customer-facing functionality quickly, and then plug in the required content management capability on top of this.

Built for purpose, not from the ground up

Using a CMF shouldn’t mean reinventing the wheel. By having the building blocks in place, a developer should be able to implement the required content management capability in just a few lines of configuration – but having a solid framework to fall back on when more bespoke needs arise.

In our experience, we’ve found pre-packaged CMS platforms tend to fall down when more bespoke needs become apparent. If the needs aren’t catered for out the box (and even if these needs are apparently catered for now, one should bear in mind how often requirements can change and be added during the life of a software product), developing more custom functionality often proves complex and costly.

We’ve often seen procurement processes where every currently conceivable content management capability is listed as a requirement (even where there’s no immediate need), with a view to ensuring the platform that is chosen provides this capability out of the box. This route fails for a couple of reasons: firstly, people are rubbish at predicting the future. Your requirements in two years time almost certainly do not fit neatly in to everything you’ve managed to list down today. And secondly, you’re likely to be missing the most important requirement, and that is to choose a software platform that is designed to adapt to change.

A better user experience

We see feature-rich pre-packaged CMS platforms as victims of the 80/20 rule: whereby only a small subset of the functionality is actually required on any particular project. What this can often lead to is a hard-to-comprehend user experience for those using the CMS, where too many options and features that aren’t used get in the way and provide confusion.

The CMF approach, by nature of delivering a tailored set of functionality, also provides an equally tailored user experience.

An architectural decision

For a platform of any significant scale, there is usually a significant benefit in dividing the functions of the system in to discrete services (ala Service Oriented Architecture or Microservices).

Compared to the big-box-of-everything route that you almost always end up with by pursuing a monolithic CMS platform, this approach provides much stronger future proofing by allowing you to replace smaller components as they reach their end of life and move away from the traditional throw it all away cycle every 5 years.

For just about every requirement we’ve seen, when we’ve interrogated them hard enough, we’ve discovered that the longer term needs are better served by first choosing a strong framework on which to build the application, and then plugging in content management capability that does just that: content management.

About the Author