It’s a slippery slope, with potholes, rusty nails, and a sundry of other snags ready to pull you into CMS bliss or hell. Truth is, there’s no perfect match. Even when strategically aligning your team and goals within a framework for decision making, there’s somewhat of an art to the selection of what fits and what does not.
Having recently launched a couple of new community websites, I find myself reflecting on the pains of the past when watching and assisting people we work with as they begin deploying their content. Jeremiah wrote this timely post making a call out for the peeps in his community to share horror stories as well as share their ideas for future-proofing their CMS systems. So, while I had CMS on the brain, Jeremiah’s post inspired me to go with this one…
Generally (very generally) there are two big camps you might find yourself in when evaluating your approach to a Content Management System for your organization. We could split this beyond just two camps, but I think we generally do a pretty bad job in our industry of simplifying things, so I’m trying to simplify. The two camps I am referring to are:
- Open Source CMS
- Enterprise-Class Package
This consideration is where the first big mistakes are made. I find myself in a lot of discussions where the words “Open” and “Source” conjure up a few preconceived notions. Let’s address some of those with respect to the first one of our camps:
Open Source is not limited to the Linux, Apache, MySQL, PHP stuff that we keep hearing about. There are plenty of open source applications out there that are even of the Microsoft variety. That’s right, I just used the “M” word. There are many who are already squarely locked into a Microsoft infrastructure and there’s no getting around using something that will integrate well with their existing enterprise systems. And, that’s perfectly fine. There are solutions available such as DotNetNuke, Rainbow and Umbraco.
If you’re in the Open Source camp, Microsoft technology lies beneath a number of options that might fit within your technology stack. If your search moves you away from the Microsoft technology set (for reasons such as cost, integration or consistency with your enterprise road map), you may be in the confusing space where the lines blur between countless Web 2.0 applications. Danger ahead! Some of these applications can, and very well may be, like heroin — One of the great things about all of the applications you may find yourself looking at is how these low cost, easy to build, sexy looking applications satisfied some immediate needs, and even helped build amazing communities to boot. In many ways, these applications helped to build working business cases for companies to think in a more sophisticated way in how they engage their communities. So, what’s the problem with all of these shiny, bright colored applications? Nothing at all — They have helped to democratize (oh my gawd, I can’t believe I just used the most overused phrase on the web) the way we think about the web… about igniting communities and stimulating many millions of conversations. While so many of these applications satisfy the urge to be more socially compliant, they are fundamentally split from the business models of many online commerce models. In the plain-est possible speak, these are the applications that excited and inspired us about the power of going social… they validated the concept and value of community… and now corporate officers are taking it seriously — really seriously. What does that mean? We now have challenges on our hands of integrating these applications into the enterprise. We’re going from a bunch of successful experiments to a market who takes this seriously and now wants it to fit inside their enterprise.
So — When picking a winner, some of the old methods still apply. Evaluating your solution and applying just any Web 2.0 approach is a “top down” way of thinking. Don’t get me wrong, I love the bling, bling social stuff… but it’s generally “bottom up” thinking that goes the long haul.
In the past, we have referred to Drupal VS WordPress. Reason for the comparison, is that WordPress is arguably a killer solution for a specific thing. If you want to build a great blog and have the ability to add bling, then it’s awesome. You can even use it for light weight content management. But, the mindset of WordPress is all about blogging — social — community. Drupal comes from a Content Management mindset. Even the tone and content created by the community is different in tone and approach than your typical community building solution. It’s got more of a content management flavor to it. Within the last few releases, Drupal has asserted itself as a CMS solution with an appetite to add community everywhere.
Drupal VS WordPress is a good comparison to make a simple point…although it’s shallow in the bigger picture of what’s really available and completely bypasses the important part of picking a winner — the process of picking.
If your enterprise is not ready to go enterprise yet, then you’ve got to be careful and not shortcut the process. Here are a few things to remember as you stand on the edge of what could be a very important decision. Even if you don’t plan to be at your organization after another year or two, someone will need to pick up where you left off. Here are some things to consider:
- Think down the road of what the options could possibly be based on the IT roadmap.
- Devour information about your systems, communities and other nodes on your enterprise’s system.
- Involve your IT organization and push hard on integration points.
- Even if it’s an experiment, can you or your IT peeps be nifty with migration regarding your chosen platform?
- Understand the goals and objectives well enough to build a framework for decision making. Before you know it, you and your team will be adding hundreds of wishlist items to your next release. Have a framework for prioritizing and planning each one before you end up in CMS bloat.
- If you follow an enterprise route for scalability purposes, remember that you will eventually run into cost and feature challenges (to name a few). Pound for pound, applications like SharePoint do not have the nifty Web 2.0 features built in yet (operative word, “yet”), but they will. You will be faced with lots of those “customize now - or wait” questions.
- Identify the DNA of your solution. Is it really a community center, an extranet, an intranet, a marketing brochure, or all of the above?
- Make sure your solution allows you to customize to your liking, and allows your orgainzation to rapidly learn how to easily publish content. Chances are, you’re not going to be granted a “call center for my new CMS” budget, so you’ll want to keep fielding the training calls to a minimum.
Going forward, we’ll try to share more about what we are finding. We’ll try extra hard to use plain speak (please let us know if we are being bone heads and pushing the tech talk). The big take-away is however, that jumping into what looks like shallow water can result in jumping right off the continental shelf. The most successful implementations we have seen always occur when the right planning is put in place. It’s never time ill spent.
