How the CMS Fails Marketing

December 11, 2012
It's time to rethink our approach to how we manage the content lifecycle.

The so-called modern web Content Management System (CMS) has outlasted its utility and is failing content marketers. And still, it is one of the most important tools that we at Digett leverage on behalf of our enterprise clients in the deployment of systems to store and display content to an audience in the form of a website.

Considered in isolation, the CMS does a fine job of this. But this constrained store-and-display scenario represents a diminishing slice of the expanding role that content plays in good marketing. To evaluate the effectiveness of the CMS from a higher vantage point, a picture emerges of widely-used toolsets that put too much downward pressure on marketing ROI.

It has become clear to me that we need to seriously rethink how we solve many of the challenges posed by content marketing.

Three Big Problems with the Web CMS

As content gains prominence, the tightly-coupled nature of enterprise systems like Drupal, for example—which attempt to address a full breadth of challenges related to the content lifecycle—becomes burdensome, inefficient and ineffective:

  • burdensome because we get stuck with huge applications to maintain
  • inefficient because replacing any part of these systems often means replacing the whole thing
  • ineffective because developer attention is spread thinly and unevenly across thousands of requirements.

How We Got Here

I think it is useful to recognize that we got here for good reasons. The web evolved, after all, into the most important communication medium of our time almost overnight. To address this growing demand to publish content, we have developed dozens of programming languages and web technologies to solve specific problems as they arise. To make it easier for the non-techie to take more control of the publishing function, for example, we devised simple tools to achieve this.

These were the earliest iterations of the CMS. All hands have been on deck to focus on these challenges, and look how far we've come! But somewhere along the line we crossed a couple notable thresholds.

  1. The CMS evolved to fulfill roles that would best be divided among multiple applications.
  2. Content became useful in more ways than our inflexible and bloated CMS architectures can keep up with.

To suggest that any one user type is the "most important" serves to help illustrate the challenge of treating content management as one to be solved by a single application. The fact is, by the way, that the most important user of a website is its intended audience. But even if we allow ourselves to shift our focus off the audience onto users that "work with content"—as does the referenced article—we are still talking about a wide range of roles: content strategists, authors, editors, reviewers, content administrators, web publishers, curators, and any number of possible "wholesale" consumers of content who need or want access to it for a purpose such as pushing it through another channel.

Each of these functions has its own unique set of challenges and requirements, and in some cases the needs and interfaces related to one function look nothing like those related to another.

Today's CMS has grown up as a one-tool-does-all approach to getting content onto the web and managing its lifecycle. We have WordPress, Drupal and Joomla (among many others), each of which increases in size and complexity with each version release.

It's not hard to see why this happens. Consider, for example, that a website is no longer something we view only from a desktop computer, but from mobile devices of all shapes and sizes. Consider that a website needs to leverage or at least play nicely with social media outposts.

These are just a couple requirements among many that demand new and more capabilities, and too frequently these capabilities become the responsibility of the CMS. This leads to bloated software that is less effective than it should be and more expensive to maintain.

Nowhere does this growing complexity result in more pain than with the never-ending and expensive two- to three-year cycle of upgrading a website to a new version of its underlying CMS platform. We do these upgrades to be able to stay current with security patches and, less often, to benefit from a new feature or two that the previous CMS version does not support.

How wasteful that we discard the result of previous website-building efforts every few years and replace it with the result of an entirely new website-building effort! Is there really justifiable value generated by this ever-repeating exercise?

How to Build a Better CMS

What we need is a more role-centric approach, applying best practices learned over decades in the software development industry, separating distinct groups of requirements into highly-tailored components, each designed for a specific role. Allowing these applications to interoperate would be well-defined interfaces that hide the complexity of what happens under the hood and make it feasible for developers to evolve and improve individual components of the content support ecosystem without worry of breaking it.

At its center would be a flexible and logically-designed content store that provides multiple methods for getting content in and out, as well as the means to effectively catalog it. Contrast this with the CMS database of today, which has become a tangle of unrecognizable labels and table structures and offers a poor foundation on which to build robust content applications.

Relegate the assembly and packaging of content into pages for viewing on different devices to a lighter-weight application that does only that. Give authors tools that streamline their own processes, which somewhere integrate with those of the content marketer who manages the production of those authors in the context of an editorial calendar.

There are hints of this type of modular approach just about everywhere you look. Drupal itself is a fabulously-architected wonder that goes further than probably any other comparable system to modularize its functions. Those who work with me know I'm a Drupal fan.

But I don't like telling my clients to budget for an expensive upgrade every three or four years on top of the significant ongoing cost of keeping the system patched. I don't think it should be that way, and right now I do not know of a better alternative.

I'd like to see the CMS go the way of SaaS, and believe at some point we'll see a tipping point toward that destiny. We see pieces of this already, and have for some time, in companies providing functions like data collection and reportingemail services, and social media integration. And there are some legitimate offerings for CMS SaaS, my long-time favorite being Squarespace.

But one of the very first frames of the video overview for Squarespace starts out by promoting its biggest weakness: "Everything you need to create an exceptional website."

Not that this might not be a legitimate approach if I'm going after the low-budget audience, mind you, but this won't fly for the enterprise. Any given enterprise is going to have its own unique set of needs that a one-size-fits-all solution cannot accommodate.

A Call For a More Sustainable Approach

In the end I'm looking for a better system, or ecosystem, to employ and leverage in the pursuit of helping my clients acquire, engage and retain customers through content marketing.

Additionally I want a more sustainable website solution; one that puts an end to the madness of explaining to my clients that shelling out $20-$30K or more every other year for a CMS upgrade is the norm, even while the old one seems to work just fine. It should not be the norm, and I know there has to be a better way.

Getting there will take time, but here’s hoping we can start a dialog to evoke change in that direction.  

[Image: opensourceway]

Comments

Hey great article! It really

Hey great article! It really makes me think about where content management systems are going.

Recently, I am trying to educate people running Drupal 6 that it is soon approaching end of life/support. It's a scary task and I feel your pain! We are already starting to see issues with Drupal 6 not running properly with PHP 5.4. We have recommended that people hold off any major changes to Drupal 6, and invest in Drupal 7 or 8.

I tend to agree with you on a lot of things, but software is always going to be this way. As always, people don't like to hear they have to spend more money on technology. The reality is that computers double in speed every 2 years...so... guess what that means. Yup, new and improved software is released every couple of years or sooner. In turn this requires more complex CMS and web systems. Website marketing people can stay in the stone ages, or embrace the change.

For this reason, I don’t really see the CMS as failing marketing, but rather drastically helping it (At a cost of course). Without modern CMS we wouldn’t have great tools such as Google Search. When was the last time you looked up how to do something at the library in one of those book things? The real goal of marketing is communicating the value of a product or service to customers. - taken from Wikipedia (I found it on Google!). Drupal does this, and it does it well. Drupal 7 does it even better of course , because it’s newer.

If people don’t want to accept change and invest in technology, it is pretty clear on what happens. Dinosaurs will die. They may be happier for not having upgraded but ignorance is bliss. If the website maintenance costs are outweighing ROI, then this is a separate issue. SaaS creates it's own set of major issues and simply hides costs.

I recently came across this article from the founder of Drupal. http://buytaert.net/the-drupal-mood-cycle . It describes the migration path between Drupal versions in a totally unfortunate but realistic/accurate way! Drupal end users are screaming! I am also screaming! (About my blackberry which is now a brick). Everyone is screaming!

Wes

"To suggest that any one user

"To suggest that any one user type is the 'most important' serves to help illustrate the challenge of treating content management as one to be solved by a single application"

I think that you are taking Thomas' article too literally. No one is suggesting that we ignore the final audience. But I think we can all agree that content is king. By giving more attention to your content creators they can spend more time crafting the content rather than fighting the interface and fighting the workflow that doesn't mirror internal processes.

"Nowhere does this growing complexity result in more pain than with the never-ending and expensive two- to three-year cycle of upgrading a website to a new version of its underlying CMS platform."

While things are unique for every site and every dev shop, rarely do we encounter this situation. Our clients are looking to completely revamp their sites every ~3 years to freshen the design, re-brand, and update the IA to better reflect their evolving organization. Ideally these sorts of things would happen ongoing, but most of the organizations that we work with don't have the internal bandwidth to be constantly iterating.

For those sites that do hit the security deadline before they want a total site refresh, upgrading to the newest version is probably not what they need. Keep in mind that:
- Most security announcements won't apply to this site.
- Most of those that do are only exploitable by trusted users.
- Those that remain will be _far_ cheaper to fix on an individual basis than the 20k-30k to completely upgrade.

Wes, thanks for the

Wes, thanks for the thoughtful reply. You make the valid argument that the CMS *helps* marketing. I just wonder if we couldn't provide more help by de-coupling the major CMS functions and possibly avoiding the pain associated with complete rebuilds every few years. Also, not sure your brief analysis of SaaS is fair or accurate. If SaaS simply hides costs, then I don't think we would be witnessing the mass shift that's occurring. Digett, for example, has significantly more capabilities thanks to innovative cloud-based services (Google Drive, Vocalocity, and SEOMoz, to name a few), and in each of these cases our costs are lower than what we dealt with before they came along. Thanks for sharing Dries' article, an interesting macro look at the upgrade cycle of Drupal. Cheers!

Dave, thanks. You're right, I

Dave, thanks. You're right, I may have come across as picking on Thomas, and that's a little unfair out of context. Honestly, though, I do feel like sometimes developers focus on their most direct clients (the users of the system) at the expense of the end goals. At Digett we are often in the position of developing (and executing) our clients' marketing programs. We are usually judged on the results of that, so we really do have to put first priority on the clients' audience. Still, I don't disagree... content is king, and if we can make systems that are easier for content managers to leverage, that benefits everybody.

Our clients are looking to completely revamp their sites every ~3 years to freshen the design, re-brand, and update the IA to better reflect their evolving organization.

Yes, that's not an uncommon scenario for us, too. What really bugs me, though, is that in addition to revamping visual and information design, we sometimes have to tackle, for example, a complete migration of content. I don't see the value in that, nor in re-customizing the administrative aspects, such as node add/edit forms. I wish we could figure out how to separate the things that *should* change from the things that should not, and avoid the cost associated with the latter.

It's true that in the PHP

It's true that in the PHP world - which this article focuses on - the norm is to use one of a handful of bloated, one-size-fits all package CMSes. Back in the day, there were hundreds of CMS contenders in the PHP arena; at least today, only a few have survived to maturity (with Drupal being the most mature and the most extensible PHP CMS available, in my opinion).

However, if you look outside of PHP, you'll see that others have already developed a good ecosystem of modular, interchangeable components. I also do a fair bit of Python web dev, and in Python land, the norm is to develop a re-usable component as a stand-alone piece of code, which is managed in its own space (most commonly as a GitHub repo), and which can easily be added as a dependency of other projects using pip (and preferably also listed in a package index such as PyPI).

Python also has its monolithic CMS bogey-men, such as Django, Plone, and TurboGears. But the norm is for devs to make their bits of code available to the world as stand-alone projects, rather than as Django apps or similar.

I know that in other languages, such as Ruby and Node.js, the independent-components-not-CMS-modules approach is also the norm.

We're starting to see this pattern become more mainstream and understood in the PHP world, with Symfony2 components, Composer, Packagist, etc. However, it's still early days.

Jeremy, thank you. You have

Jeremy, thank you. You have definitely educated me somewhat. I wonder if you could point me toward some examples of CMS-related python components?