Erosion From Below: The Long-Term Price of an Insufficient CMS Platform

August 12, 2011 | John Berndt


Imagine this scenario: a large organization with a high-content website is contemplating a redesign, under what feels like very substantial time-to-market pressure. The newly hired director of marketing, perhaps a talented and charismatic person coming from a smaller organization, is rather horrified to discover the announced twelve-month roadmap to get to a new website: pick a strong CMS, architect the new user experience in the CMS, discuss governance and back-end concerns, implement, test, train and migrate tons of content.

Likewise, this director of marketing senses that organization leadership is similarly concerned about the timeline, and perhaps even more concerned about the half-million dollar price tag of the project. Only the two people who have been managing the site and a few people in I.T. who will have to support the system are really loyal to the project as it stands. The new director of marketing senses an opportunity.

“This is ridiculous,” he/she says, “I can get up a great site in WordPress (or substitute Drupal or Joomla) in three months, and then we’ll be able to get to market quicker. It will also be easier to use. We’ll have all of the same features, and we will barely need to involve I.T. at all. And changing the site structure will be easy, too!”

The words ring out with horror-movie reverberation: everyone at the conference room table is shocked, but also at a loss for words. The CEO smiles and nods. A decisive chess move has been made, and in many cases, no amount of well-reasoned arguments will reverse its effects. The Pandora’s Box of the “no-time, no-cost, super-flexible website project” has been opened, and it will be very difficult to get it shut again.


Time rolls on, and the director of marketing is proved right, if only for the moment.

Launching with a nice design and 50% of its previous content, a new site does indeed show up in three months. Business division owners are pleased with the very fast speed of their content updates, and training of new users is extremely short. The new site is shiny and new with a nice design, and it is a big win for the director of marketing, and a big loss politically for I.T., reinforcing the growing sense that I.T. “doesn’t get it” and only lives to slow things down and create problems.

The two people managing the site grudgingly have to admit that “a lot” of problems have been solved, and wonder if their previous position was off-base. The director of marketing gets a promotion and then, to everyone’s surprise, takes a job at another company within a year, getting a raise in the process. * The site is left to his/her successor.


Within a year and half, the awful cracks begin to show. Sections of the site that were complex had been scaled down for launch; users are increasingly complaining about usability in those sections as well as problems with overall usability and search. Management has now noticed that the site doesn’t have any “related links” like those of their competitors, or the ones they do are old or inappropriate, and wonders why. As content and the desire for complexity grows the web team finds themselves more and more violently at odds with the software as they try to manage large amounts of content in a simple directory structure with no automation. Schemes are floated to graft complicated search technologies onto the site to make up for the lack of automation, but the cost, complexity, and supportability make these ideas seem dubious.

Then something bigger happens—the request comes to support the new Apple Smart Shoe screen at 200 X 300 pixels—and it simply can’t be done. Management feels this should be no problem; after all, “everyone else is doing it.” The recriminations begin, and I.T. is asked why in the world they ever allowed this mess to happen—perhaps they are even told that “everyone uses WordPress so it must be possible.” They and their content manager counterparts are stunned—and they try to point their finger at the person who caused the problem. But that person is, often, already gone and the conversation is moot. They can only reboot the initial project, with less money now, and more time pressure.


It’s true that WordPress, Drupal, Joomla, Expression Engine, and the lower-end of the commercial CMS market do tend to get better ever year, and become an ever more appropriate choice for ever larger sites as the years go by. However, this is very much a matter of degree, and there is a ton of wreckage in the road. Organizations that bet on the inexpensive, fast underdog, only to come out of the race with something that barely limps along and that slows the growth of web strategy by entire years. This blog entry is designed to inoculate folks against such an inappropriate decision—and to provide a counter-balance to the naturally optimistic hoards of loyalists that these less robust systems have. They are, after all, justifiably excited that their systems can manage a large site AT ALL, and generally have not been through the ringer of trying to manage a large site with an inappropriately small tool over the course of years. It’s just not who they tend to be.

Here is why this problem exists.

Websites, especially large ones, inherently live in that gray space between marketing (with its concerns over features, flexibility, and time-to-market), and I.T. (with its concerns over sustainability, skill-sets, and security). There is also a third set of imperatives that neither marketing nor I.T. is usually unfamiliar with—roughly “the needs of people managing and changing large, high content websites over time.”

These needs go far beyond just picking features and getting things done quickly (marketing) or picking and supporting the right technology stack (I.T.). Rather, they are directly related to a whole series of subtle decisions about what platform to choose and how a CMS implementation is architected to support different types of user experience and content, while supporting strong usability and flexibility on the back-end.

Examples of these sorts of considerations:

  • Content type definition—how content is internally structured in the CMS

  • Site folder configuration—how the site is set up, and relates to navigation

  • Metadata taxonomy—behind-the-scenes categorization

  • Template strategy—how templates and elements are re-used in the site

  • Abstract, flexible templates and frameworks—fancier, designer-friendly templates

  • User model—how users exist in the system, and how they relate to content

  • Localization—relationships among different language and culture versions

  • Personalization—how content and users are qualified for personalization

Each of these considerations have to be architected, and then carefully implemented in a CMS platform that is sophisticated enough to support them. The discipline involved flies in the face of time-to-market changeability, because it is the attempt to build a system that will, with a single major purchase, support the very wide-range of user experience and features that marketing will need down the line. It is also a discipline that often will be relatively alien to I.T., who is unlikely to have all of the skills and perspective to create the most appropriate, well-designed architectures for content through the CMS. (Not too surprisingly, that’s where firms like ours, TBG (The Berndt Group), come in.)

This perspective and discipline are likely to come from the outside of an organization, not driven by the current imperatives of either Marketing or I.T. because the underlying problem—how to best manipulate and transform large amounts of content over a long time horizon—is not really one that either group already deals with day-to-day. Parts of the problem emerge on either side, as both frustration with rigidities of poorly-engineered systems by feature-conscious marketers, or as frustrations with implementations that are too “loose and groovy” for I.T. staff to support over changing regimes of editors—especially when those editors are trying to implement a new feature, page design, or integration and can’t because the existing system’s data structures are too insubstantial.

At the end of the day, tempting as it is for an organization to go for the quick-and-dirty, it is a choice that simply pushes the real issues of web content down the road by several years, to a time when they will be even more pressing and harder to address in an appropriate time frame. In the meantime, opportunities for better user experience and true (albeit not immediate or unlimited) flexibility are lost by virtue of this decision, slowing down effective web strategy. At the end of the day, the only real way through this debacle is to engage with the real issues of structured content, pick a real platform, and start the effort to build the system that will be sustainable long-term—usually working with qualified specialists that can lead the process.

Anything less (WordPress and Drupal fans’ opinions aside) is likely to be a source of regrets for everyone in a larger organization… except that director of marketing who got his/her gold star and already moved on to the next place, where he/she can do it all again!**

*Let me emphasize that I have nothing against directors of marketing; some of the best people have that job description, and would never let something like this happen to their organization.

**No, really.

About the Author

John Berndt

I'm CEO of TBG and I've been thinking about the Web in creative ways since the year it began.

Leave A Reply

comments powered by Disqus