How the CMS Fails Marketing

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 reporting, email 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]