Why “WEM” Worries Me
“WEM” is the newest thing in content management. It stands for “Web Experience Management,” and I first heard it from FatWire emails I seem to get every week or so.
RSG makes the point that this goes beyond content management, and you need to be a bit skeptical about that.
The services that make up the “E” part have been around for a long time, including: analytics, multi-variate testing, landing page management, CRM integration, personalization, template management, social functionality, and so on. So, we are witnessing a natural progression and not something drastically new. The big difference now is that – while these features tended to come separately in the past – the trend now is to more tightly integrate them with traditional WCM services. In many cases, these additional features are natively provided by WCM vendors themselves as part of a larger package.
Here’s what the problem boils down to:
Your WCM vendor may not be the right supplier for the varied services they are peddling today. Template management, native to your WCM tool? That’s a good candidate. Blogs and wikis? Maybe. Testing and analytics? Probably not.
This has always frustrated me. I feel like CMS vendors push too far sometimes, into things that aren’t content management-related. This is fine so long as those things float on top of the CMS, elegantly, and orthogonally.
I look at content management in three levels:
Repository, Repository, Repository (it’s so important, it’s worth saying three times…): This is the most critical layer. If your repository sucks, then your system sucks, period. (See “Give Me My Friggin’ Content! Or, why methods that start with Get’ are a good thing”)
Content Management Services: These are all the things that make it a CMS and not just a database: versioning, permissions, template management, workflow, etc.
Ancillary or Value-Add Services: These are the nice-to-have things like A/B testing, analytics, social networking, and all the other “E” stuff in WEM.
Where I really start to worry is when a vendor concentrates on #3 when #1 and #2 suck. And then they invariably start pursuing #3 relentlessly, piling half-baked feature upon half-assed feature onto a crappy repository that’s just barely acceptable as it is.
Vendors can lose sight of their foundations, and start making all sorts of assumptions about what their customers want, to the detriment of what their customers really need when it comes time to do the scary integration tango.
Man, I hate that. You have no business building a penthouse when the foundation is crumbling. Make sure you can walk before you run. Before you embark on the Uber-Craptastic Feature X, ask yourself, “Do we have any business writing this? Are our foundations solid enough that we can steal time for this?”
But they still do it. Why? Because the glamour and gloss of the penthouse hides the boring, mundane reality of the foundation. People never ask to see the foundation in a walk-through. They just get blinded by the penthouse, which the vendor is only too eager to show them in some rigged-up demo that looks fantastic for 10 minutes but probably has very little to do with what the customer actually needs out of their CMS.
Before I get too pissed off, I’ll stop, and ask you to read these two other posts:
[…] software that skimps on architecture for the sake of functionality. It’s software that focuses on superficial widgets that play really well in a 10-minute demo, but that very, very few people actually use. Meanwhile, the underlying architecture of the system is crap.
Architecture and Functionality in Content Management
As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything. But give me nothing but a pile of sand and a toothbrush, and I’m pretty much screwed.