Last week we attended the annual Documentum fest (still sounds better than the EMC Software Group fest). Great organization, long days and long nights. Reconnected with familiar faces.
But was there anything special to announce? Yes, there was.
First of all, there were a lot of things that we already knew:
But was there anything new to talk about? Quite a lot, in fact. Here's a quick overview of the most important newsbytes:
There wasn't a lot to announce in this field, since the platform has heavily changed with D6. D6.5 and D7 will mainly focus on new user interfaces.
There was nothing new to announce (or we might have overlooked it) in the Compliance & Archiving suite.
See you next year in Athens, giving us plenty of time to be catching up on sleep.
Although I've had my own theory about the difference between CMS and WCM for years, I've never come across any other source that clearly explains the difference between both acronyms. This has cost several business 100.000s of euros and is going to cost them several 100.000s of euros in years to come.
Not everyone will agree with this article, but a lot of users might benefit from having a clear view on the distinctions between both.
The mid 90's saw the rise of the first WCM (Web Content Management) solutions. They allowed for non-technical users to contribute content to the web via templates. Other major companies, such as Documentum and FileNet, jumped on the bandwagon around the turn of the century. These weren't native WCM solutions but, with some expansions to the core product, they could offer most of the same functionalities existing WCM players (Vignette and Interwoven) were offering. This effectively created ECM (Enterprise Content Management), as you could now manage content with a different purpose from a single repository (this must have been around 2001, the year of my first WCM implementation).
The .com-hype (and in some cases regulatory reasons) caused for a huge popularity of these WCM solutions. The hype cooled down quickly for several reasons: too costly, long implementation cycles, bad user experience, etc. This was also due to the rise of a new phenomenon: the CMS. The CMS seemed to be able to offer a set of functionalities and a user experience WCM was unable to deliver. Especially marketing and communication departments were longing for these new functionalities (let's forget about portals for the moment, what has happened to portals anyway?).
Several companies abandoned their WCM solution and shifted their attention to CMS. At a certain point in time it seemed as if every web agency, web designer and even traditional integrator had become a CMS development companies.
Former pure-WCM vendors Stellent (now taken over by Oracle) and Vignette expanded their capabilities to become ECM-platforms in an attempt to lure new customers.
But still, in several cases a CMS wasn't able to resolve the business requirements. There is a general misconception in the market (certainly the Belgian market) about the difference between WCM and CMS. CMS integrators generally don't know what a WCM is supposed to do, because their background is traditionally not in the field of ECM.
Therefore, it might be useful to clearly define both acronyms. Plenty of businesses might benefit from this, as it might help them to better evaluate and choose the solution(s) for their requirements.
There are hundreds CMS'es out there, so I'm not going to describe the characteristics of every CMS out there. The CMS Matrix has a pretty extensive list of CMSes with their functionalities, but it is still not complete... due to reasons mentioned above.
Below, I'll give a set of core differences/characteristics between/of WCM and CMS.
(These two terminologies might be useful in order to be able to interpret some of the statements below:
)
CMS:
WCM:
The answer to that question depends solely on your requirements, but nothing keeps you from implementing a combination of both. Such a combination helps you in more rapidly creating your front-end (website) and allows you to manage your pure web content via the CMS. This architecture allows your communication team to keep their hands on the CMS, while content from other business user might be delivered via the WCM system.
The image below shows what such an environment might look like:
Of course, such an architecture imposes additional technical requirements on the WCM and CMS of your choice.
Several of the WCM products have expanded their functionalities by
offering site templates, microsites, pagebuilders, blue prints, etc. in
order to reduce the time required to deploy a WCM solution. Only
one moved on to become a true WCMS, offering both WCM and CMS
capabilities (unfortunately, this is not an ECM platform).
Several of the traditional WCM vendors now also offer, via several techniques, RSS, marketing management, WYSIWYG editing.
I've seen (things you people wouldn't believe. Attack ships on fire... stop!) WCM platforms that were turned into bad CMSes with the front-end accessing the back-end. CMSes that were fitted with a repository to try multi-purpose the content.
I hope that this article might prevent such abominations in the future.
Oh, so why is CMS not ECM? It has been mentioned implicitly several times above: A CMS only manages web content.
(FYI, this site is powered by a Drupal CMS.)
*1 WYSIWYG web-editing is mimicked by some WCM platforms
*2 Sharepoint WCM can not be considered as a pure WCM, since the front-end and back-end are not techologically independent.
As you might have noticed, if you've clicked on the wiki link at the top of this page: The wiki doesn't seem to be a part of this site. Correctly so!
We've started the ECM Handbook in an effort to create a community and one central resource in relation to Enterprise Content Management. For several reasons we think the time is ripe to start building some sort of central memory of ECM. Among those there's our concern for the "ECM knowledge gap".
We can identify several causes for this knowledge gap:
We hope that the ECM Handbook can assemble functional information about each of the disciplines and on the other hand offer funtional -and technical product comparisons, thus reducing the time that should be invested in preliminary research for people looking into implementing an ECM solution and shifting the focus to the user and his needs.
It is our hope that the ECM Handbook will soon be a proper site and community in its own right. The Wiki is currently referred on our website to get it known in the community, but as you'll notice the wiki user management is not linked to the user management of this site.
On the 25th of September, Docbyte is attending the Congress Innovations@DocumentManagement. I'm giving a presentation about how you can make the best of your ECM implementation, based on the experience we have in this field.
The key reasons for ECM project failures are taken from the AIIM website. The major interesting fact about those key reasons for ECM implementation failures, is that non of these reasons are directly technology related, as many of us ECM professionals have known for quite a while.
The main reasons are related to issues about lack of knowledge, sponsorship and change management:
In regard to the above, I'd also like to discuss the knowledge gap.
There are reasons for these failures that are common with regular IT-project failures, but there are quite a few that are specific to ECM-implementations.
The subject of my presentation at the Congress is about what is needed to turn your ECM-implementation into a success, i.e. what is required to tackle the main reasons for a failure?
I'll post some more information about this subject after the congress.




Please login or register to post comments