In the late 1990s the CMS invaders deployed their systems at large corporations, as managing web pages using HTML editors wasn’t scalable and non-technical folks needed to publish. In many cases after the invader left, the company’s business teams and technical web teams were stuck cleaning, fixing, enhancing, for years to come.
Unplugging web publishing systems (and community platforms) ain’t easy.
Publishing from Word Docs, ouch.
I was a web manager at a very large corporations, as such, I was the business sponsor for the website, and therefore the tools that were used to publish the website. Often, in most cases, I inherited a legacy CMS system, one that I did not choose, the underpinning structure of the site revolved around it, documents, navigation, ability to edit pages, and look and feel.
This was one of the worst implementations of CMS systems I’d ever seen, the idea was for non-technical people to edit the webpages, so the system would have the ability to check out a ‘word doc template’ filled with macros, publishers could edit the word doc, check it back into the system and a new webpage would appear. fail.
The templates were so complicated as users had to be trained on how to use the word docs, understand the styles, and all the nuances associated with the code. The linking structure linked to a primary key for a document, which also caused confusion. That’s just the publishing process, it gets worse.
The Pains of Content and Structure Coupled
The site was unfortunately designed so the structure would for the most part, remain constant. The structure of the site, and the content were coupled together, and that’s a major problem. As the site would grow and more pages were added to the taxonomy, the system became more and more inflexible. The developers had a very complicated way of managing the pages, the changes took a few days to work as the underlying code had to be changed. The simplest of web changes that you would expected to see from a web CMS system required ongoing developer support –not content changes at the business level.
I’m not going to mention the name of the CMS vendor who provided this less than stellar tool, as I believe the deployment of the system was to blame from the in house technical group –all of which happened before I got there. Whew, I feel better, that’s been pent up inside of me for a few years now.
Thinking forward: Community Systems of today, to be legacy systems tomorrow
As we deploy community solutions that have social media features, are we thinking about in a few years how these legacy systems will be inflexible, don’t talk to our other systems, cobbled together application ware that we loosely couple with our other customer facing web systems?
I also know of many business groups that are deploying community software, often by ‘notifying’ IT that they are doing it, sometimes without thinking about the long term implications of these systems not being able to migrate, talk, or share data with other websites. In many cases, the business sponsor will move on to another role, job, or company, leaving the archaic community platform in the hands of the next web strategist.
Two questions for you:
1) I’d love to hear from you about your CMS horror stories, feel free to leave a comment below, go ahead, vent away.
2) Are you deploying a community platform for your web strategy at your company? What are you doing to plan for the long term 5+ years impacts of this system in regards to the rest of the enterprise web strategy?
I agree with the majority of the comments above, in particular the point about CMS’ being largely a Faustian bargain.
I’m based in Japan, and in addition to the points above, I think the biggest problem with the implication of CMS systems here is that they’re implemented as the solution to give internal types control, well before they know what they’re going to do with the site. Ultimately, most CMS systems fix designs in a manner that doesn’t allow for robustness and scalability (plus a lot of the sites look really bad), resulting in systems that simply become glorified (and expensive) news update mechanisms.
We’ve had some luck in building some AJAX based custom CMS systems for sites we manage internally (with experienced developers, editors and programmers), but even they require constant enhancements in the face of the changing nature of social computing. After all, if we could see the future clearly we wouldn’t be congregating here, would we?
All in all a good topic. If at the end of this you come across some examples of good robust systems and cases that have worked (especially in a global setting), that would be great.
Also very timely for me. I’ve just started a new job, managing a website that at present is 7500+ .asp files stored in a shared drive. The number of PDFs on the site is in five figures. There’s no CMS and whilst the site holds its shape, it’s not sustainable.
There’s no doubt we could do a better job of matching content with customers, and a CMS is a potential part of that solution. I’ve only every worked with bespoke solutions (mixed success), with all this bad blood around about CMSs, the inflexibility, the difficulty in specifying a solution that’ll work in the mid-to-long-term etc etc I find myself paralysed and unable to take action confidently.
I’d be interested in some of the open questions you think I should be asking of myself and the team that may help determine what type of approach to content management is suitable for my organisation (a non-US Govt department). Thanks.
This is quite a timely discussion. The CMS landscape is quite crowded and determining what will be the best for your organization is a challenge. On that thought (re: the post by kenobi), anyone have any feedback regarding the main Enterprise class offerings out there (Documentum, IBM Workplace, TeamSite, Oracle UCM, RedDot, Vignette, etc.)?
I am investigating what could serve as a true robust foundational layer for an extremely large, complicated and distributed web presence. It needs to handle pretty much anything we could throw at it… 🙂
Thanks,
Jeff