- About
- Services
- Solutions
- Portfolio
- Contact
- Blogs
Just caught a glimpse of this article by Erin Griffiths of AdWeek, which was published on August 9th. Take a look and come on back for some of my thoughts:
First off, while I found Erin's article entertaining and correct in a few places, she is misinformed in many places, and sensationalist in others. I don't know whether Erin is posting her article on the old Nielsen Business Media customized implementation of TeamSite which delivered 'baked' XML content to a custom-written content-delivery application (CDA), or if she is now using whatever new CMS that her company quickly implemented after the e5 Media (Prometheus) acquisition, but she may be speaking with bias in her distaste for CMS technologies, which may color her ability to report.
There are amazing success stories in CMS all throughout the world, and not just on any one product or another (be it open-source or proprietary). Let me be more specific on my concerns with her article, as well as point out some reasons why companies fail in Web content management system implementations (as well as virtually any kind of technology implementation, frankly):
1. Companies more often than not fail at functional requirements elicitation and documentation. Organizations still don't have the internal capabilities to map the 'what' they need to the 'how' they'll build it. This includes taking those requirements, creating a traceability matrix and test plan to support testing, then getting industry-strength quality assurance protocols in place so that you can chase out inevitable bugs in ANY software you implement, not just Web content management. The point is to get your requirements right at the get-go so that you don't have to fix major ideation problems later on.
2. Customize a solution like CMS? Remember the old saying, 'do what you love, outsource the rest?" Why would any media or publishing company have the hubris to think they can build a custom solution by throwing a few dozen 'bodies' - developers, however good they are -- and after some period of development come up with a scalable solution? Granted, a number of these companies started years ago while there were so few choices in the market that were scalable and extensible. But in 2011? Sheer madness. And yet, several of the largest publishers in the world are doing just that as I write this. To me that is more about ego than anything.
3. Implementing an open-source CMS but hacking core? That is suicide. The Onion can say all they want about Drupal 4.7, for instance, but they need to come clean on the fact that they modified this VERY outdated version of Drupal software for their needs and didn't contribute back when they had a chance to influence the future of Drupal for the sake of their company and the rest of the World. They got what they paid for - Drupal moved on and they were left with their hacks. This wasn't a lesson in scalability, it was a lesson in messing with core code but not giving back to a community that is about contribution.
4. Scalability: What I think Erin and most non-technical writers fail to realize is that the scalability issue is often less about the product OR the underlying technology, and more about how the system architecture has been planned and implemented. Whether you're using PHP, Python, Ruby on Rails, Java, .NET or whatever technology, the issue is what your architecture team knows about how to set up your technology to support your volumetric needs. Those kinds of resources are very much worth big salaries, which probably should be paid in gold these days. Show me a critic of any PHP-backed site and I'll show you some platforms that service hundreds of millions of users daily built on the LAMP stack.
5. Staying current: You know its really easy to criticize Vignette, which probably did all it could to kill itself back about 10 years ago when it went from version 6 TCL to v7 Java/J2EE. However, if you're running VCM v6 in 2011, do you really think you have a right to complain about how much it sucks when considering you have gotten your return on investment already about 7 years ago? I'm not saying OpenText's Web Experience Management platform (formerly VCM) is terrific or flawed - I'm just saying that if you have a platform that can sustain 180 million page views in a day and that product was built in 1996-1999 timeframe, thats a pretty impressive feat by those engineers -- and YES, it is going to be VERY outdated in functionality.
6. Fringe products: I'm always slightly scared when I hear C-level technologists at media companies declare a brand new Web content management technology as the unequivocal winner in the CMS wars, then proceed to rip out and replace whatever incumbent system was there with this new technology darling. I don't mean to discourage innovation, since that is what my career has always been about and always will be. However, I've seen dozens of products that were labelled as the next big thing in Web CMS that are now dead and gone, or marginalized at best. Anybody remember Krang? That was going to be the de facto standard in Web CMS for publishers back at the turn of the millenium. How about EZ Publish - still alive and kicking -- I was told back in 2007 by a global CTO of a major media company that Drupal didn't have a chance and that EZ Publish was going to be the standard in Web CMS of the future.
In these past 20 years I've heard that about a lot of products. My advice is to stick with the top few that are widely adopted and accepted, are within your price range, and whose underlying technology is supportable by your existing staff resources. The rest you should leave for your R&D activities and NOT for your live primary production systems that you use to communicate with your customers.
At the end of the day, companies spent millions on Web CMS back in the 90's. Most companies felt they got ripped off, whether they bought Interwoven TeamSite or Vignette "StoryServer" or any of the others of that day. The reason solutions like Drupal and WordPress became so popular is the price tag for open-source was so attractive. But many of those companies still have the same procedures for implementing any software, and the results are often not that good because frankly, management doesn't always know what they're doing, so they just keep throwing the bodies at the problem. Those C-level technical executives seem to look like geniuses when they get low cost bodies from other countries, but they often just keep digging their companies deeper into the abyss of poorly implemented software.
With regard to Conde Nast's decision to go with Communique, which Erin cites in her article, we'll be watching that decision closely at DPCI. We implemented CQ a few years ago, prior to Adobe's acquisition. We didn't continue the relationship with Day at the time since we didn't think they could scale to meet the needs of the US market. However I always felt that they would be a terrific acquisition target (secretly hoping it wouldn't be one of the ECM holding companies that would suck the innovation out of the product line). Now that Adobe has acquired Day, we're leveraging our decade-long relationship with that terrific company to get back up to speed with the Communique product line.
I'm fascinated by the integration opportunities of Adobe CQ with the Adobe Creative Suite, with Adobe's BI unit (Omniture), with CQ DAM, with LiveCycle, and other Adobe products. If that company can get all those business units talking and working together, they could have an immensely powerful platform on their hands. It will be indeed be interesting to see how Conde ports away from TeamSite, which they spent so many years customizing to meet their needs.
Posted at 11:26 pm by Joseph Bachana