Recently I wrote an article for my blog – Taking the W out of CMS – exploring content management and content delivery as separate disciplines and this is a follow up to that article.
To summarize that article – firstly, to know me professionally, is to know that when it comes to the tribes of CMS folks, I am firmly in the WCM tepee.
Secondly, I disagreed the first time this discussion rolled around, as the millennium clicked over – we were all going to use portal platforms and content management functionality would be in our application server infrastructure (we don’t and it didn’t).
Thirdly, the difference between the systems we are building for tomorrow and then – our digital engagement activities were single threaded following a website groove and the end was very much the driver for the means.
For the mainstream CMS industry it was a web site centric world and in most projects and applications the term ‘CMS’ was interchangeable with ‘WCM’. Today we have a fragmented communication channel; it’s the age of the ‘splinternet’ (in this context, a term coined by Josh Bierhoff), delivering relevant content consistently to multiple places.
This not just devices – our websites are less the single and only web destination, folks consume information about our products and services from other web destinations like Facebook and Twitter (to name two). Plus, of course the needs of customer, consumer and citizen engagement means that we can chuck in multiple touch points, in e-mail, call centres and real life.
We used to get ourselves worked up about ‘baking’ or ‘frying’ content management/delivery applications, about decoupled systems that produce pages and dynamic content – but (as I said in response to a comment on my original blog post) today’s consumer wants super dynamic content fresh caught that day, prepared their way, hot off the griddle – Teppanyaki served to share – family style.
So, we have a new level of complexity and requirements for our systems to support our digital marketers and communicators. A level of complexity of requirements that sits between our content repository and our consumer, which used to be the section of the RFP that simply said “must produce compliant HTML”.
When talking about delivery of content, this is typically where our requirement starts to gain some uniqueness between projects.
The question is, so you have your well-ordered, neatly filed, approved content – but what are you going to use it for?
A requirement for an approval process supported by workflow is fairly ubiquitous – but if you are a membership organisation that engages its audience over email or a consumer packaged goods company with fifty products and a YouTube channel – your Engagement Tier requirements are going to be quite diverse.
This diversity in requirements means two things to me.
1. As an industry we are very good at understanding, defining and capturing CMS requirements – but how are we at identifying, understanding and communicating an organisations engagement needs?
2. If there are diverse requirements, then there are different solutions – and right now it’s is a blend of dynamic web content delivery, marketing automation, campaign management, email, web analytics (etc. etc.) – There is no silver vendor bullet – no leader, no wave, no magic quadrant – its different strokes for different folks.
It’s this that I want to explore, how do we define those needs and how do we compare tools?
So, into the Engagement Tier – my colleagues here at Gilbane challenged me to draw it. Hmm.. right now it’s a box of content, a big arrow and then the consumer.
I am going to need to work on that…
