Redefining the Core Tech of ECM

For several months, I’ve been tinkering with an idea in my head.  I’ve watched as EMC and other large ECM vendors fell further behind in the WCM space.  For every advancement that has been made, there were losses to the market.  It is at the point that if you aren’t deploying massive websites to server farms, you wouldn’t even look at the larger vendors.image

And yet, nothing changes.  The large vendors keep taking one step for every two that the market makes.  I think there will be a change, and CMS Watch, in their excellent 2010 Predictions, made a prediction similar to my thought process:

1) Enterprise Content Management and Document Management will go their separate ways

When you read the description, it is clear that they are seeing the same things, but they appear to be throwing the emphasis in the wrong direction.

Separating WCM from ECM

If you’ve read my definition of ECM, or AIIM’s definition for that matter, you’ll notice that the focus is on the content and the business problems, but not on the specific technology.  There is no mention of Web Content Management, Collaboration, or any of the actual business solutions specifically.

Enter Gartner.  In their latest MQ, they define ECM as having six core components: Document Management, Document Imaging, Records Management, Workflow, WCM, and Document-Centric Collaboration .

I think that if an ECM vendor has the right tools in the platform, they can skip the WCM-specific offering and allow WCM systems to access the functionality through either CMIS or their vendor specific interface.  Let open source vendors, or smaller vendors with shorter release cycles, try and keep-up with the web technology.

What Do We Need From an ECM Platform?

image So, if we turn our attention away from the business solutions to what we need to support the building of those business solutions, what are we left with for the platform?  Without trying to ask for too much, here is a quick list…

  • Scale: Big or small, it just has to work for whatever volume of content I have.
  • Security: This is both Authentication and Authorization.  There doesn’t have to be Identity Management built-in, but it needs to work well with Identity Management solutions.
  • Native Content Handling: Needs to be able to recognize XML, email, HTML, images, and other formats and treat them accordingly.  For example, if it is an email, extra metadata will be captured and stored.  Content transformations fall under here.
  • Records Management: While not necessarily requiring full-blown DoD 5015.2 certification, retention, holds, and other core RM concepts are important.
  • Interoperability: This is now CMIS support as well as documented API and SOA-based interfaces to provide deep functional support.
  • Workflow: This can be as big as full-fledge BPM, but the ability to model the lifecycle of content and the processes that govern their life is important.  This means decision points, parallel flows, and loops, not just simple approval processes.
  • Basic Content Services: Versioning and all that other fun stuff that we take for granted.

This is not all-inclusive, but you get the point.  These components allow applications like Collaboration and WCM to work.

A New Prediction..

I would like to offer a modified version of the CMS Watch prediction…

Enterprise Content Management and WCM will go their separate ways.

Okay, that isn’t going to happen, but it NEEDS to happen.  Why?  Because it is distracting them from their core, which is the platform and their core applications.

I’ll take this concept and apply it to EMC’s product strategy to illustrate, but that is a separate post.

16 thoughts on “Redefining the Core Tech of ECM”

  1. Laurence:

    Partially agree and partially disagree. I agree with the overall sentiment here – but think WCM remains a part/component of ECM. As you stated, many definitions of ECM (mine included) do not mention specific technology but rather focus on functionality. ECM must provide a platform/ecosystem in which an (E)nterporse (read business) can (M)anage (read control cradle to grave) its (C)ontent (read any and all forms of information and data from paper to web pages; tacit to explicit knowledge). Thus teh abilty to control web content via a WCM tool must be part of an ECM solution. Whether that technology component need be integral/from the same tech provider of other solution components is another issue entirely and one that I believe is teh heart of your opinion – and that I DO agree with.

    Like

    • I think we are on same sides of a fuzzy line here. I think that an ECM vendor needs to be able to manage the web content. I don’t think that they should have to focus on the creation and design to be considered a valid ECM platform, as long as their are ways for WCM vendors to adequately leverage the ECM features.

      I think the integration of Drupal and Alfresco using CMIS is a nice example of this approach. Drupal is the WCM application and Alfresco is the ECM platform.

      Like

      • Peter says:

        I get the sense that you’re falling into the age old trap of equating WCM with presentation management. As has been discussed elsewhere, this is a rather myopic view that ignores entire swaths of the WCM segment (including trailblazing products such as Vignette StoryServer and Interwoven TeamSite).

        But back to your original premise, for my $0.02 worth WCM in the CPS / CMS sense is most definitely a part of ECM, as it is basically just another consumption channel for enterprise content (albeit one that has quite unique and complex requirements compared to the typically simple DM consumption use cases).

        That said there is plenty of evidence that most current ECM platforms do a poor job of supporting the specific requirements of the CPS / CMS style of web content management, and I think that’s a reflection of the fact that DM and WCM have rather different world views, and most vendors very clearly have a heritage in only one of those two camps.

        Maybe once the DM world realise that WCM is not just “document management of HTML documents” and the WCM world realises that the problems of content creation and production are equally important to the problems of high scale web based content delivery, we’ll start to see products that can genuinely lay claim to being “Enterprise” content management systems. I live in hope!

        Like

      • Peter, replying to myself so we don’t get into comment nesting hell…

        I wasn’t trying to equate WCM with presentation management, I was just grossly simplifying the issue dramatically (great link btw). EMC doesn’t manage content, it just delivers the content, while Drupal, as has been pointed out, does a full presentation management.

        Every system that users use to build their website and that is marketed as a WCM, or CMS, system has an interface with features and add-ons that are specific to web design. Template editors, navigation managers, and so forth. Be it CPS or PMS systems that you describe in your post, the ECM vendors shouldn’t be building them, at least the way they do now.

        Web Publisher is the EMC product, and it sucks. It will always be that way as long as it is coupled as part of the platform. They have a solid delivery mechanism, but that isn’t technically part of Web Publisher.

        Should an ECM system have channels to publish content, YES. Should it have mechanisms to track relationships and hierarchical designs? YES. Should it be able to natively understand XML and process referenced style sheets when needed? YES. Should it have to provide a CPS or PMS interface to be considered an ECM system? NO.

        Like

  3. John says:

    I have always thought that WCM in an ECM bundle is a bell or whistle way out of control. The notion of integration with other systems, that properly do WCM instead of half-heartedly, makes a lot more sense. To me, this seems to all be a symptom of companies reverting to making monolithic solutions instead of truly modular solutions that can integrate with other players out there — including competitors.

    Like

  4. Excellent post! And as you may well know at CMS Watch we have not covered WCM as a part of ECM for 3 years now – it is covered in its own specialist report.
    That is how buyers perceive the market (our audience) so that’s how we reflect it.

    My prediction (ooops ‘our prediction’) was that vendors that sell good old fashioned DM and Workflow will not continue to try and badge their wares ECM, they will leave that for the ‘ECM as a platform’ vendors such as EMC, Oracle and IBM…..

    Much to debate 🙂
    Best
    Alan

    Like

      • Let’s do it. Someone needs to have crack at deciding which of these acronymns needs the bullet:
        * CMS – a type of product
        * WCM – a domain
        * WCMS – a domain specific product
        * ECM – a domain
        * ECMS – a domain specific product (never heard that used)

        Should the title of an RFP be “*CM” or “*MS”? Most RFPs I see are about procuring a product, so are called “Bob’s CMS RFP”. Very rarely do a see “Bob has a Content Management problem which needs solving”.

        Like

      • CMS is fine as a term, as long as we can make people understand that there is more content out there than Web content. I was having a conversation the other day where someone asked “What other kind of content is there?” After I picked my jaw up off of the floor, I told her.

        Kill WCM. ECM is the domain/platform. CMS is a specific product. WCMS is fine I suppose, but “W” is not 100% accurate these days as you’ve mentioned.

        If I can pull WCM out of ECM, and then kill it as a term, I’ll let you take the lead in fixing the name.

        Like

  6. > Enterprise Content Management and WCM will go their separate ways.

    I only partially agree.

    Most *W*CM customers are still buying “a website” (be it a public-facing or a private-facing web site) and most of the time they only want one single system to handle all the content + composites + renderers (be it for the web or for mobile) not one back-end ECM + one front-end WCM.

    Now WCM evolved and learned, sometimes through the hard way, that a website is not only a question of CSS, transparant gif and IE/FF compatibility issues but also have to deal with some content lifecycle issues.

    If we consider ECM as a platform, more and more WCM will then stop being yet another content silo trying to rreinvent the wheel and will natively embed a “lightweight ECM platform”. The recent commoditization and standardization of ECM (mostly courtesy of CMIS and JCR + some free OSS reference implementation) should definitively help. And the JCR 2.0 nearly standardized all the ECM points you mentioned in your blog post.

    So you will soon have the Enterprise Content Platform ready WCM and the old-fashioned WCM silos. The former will ship an embedded ECM Platform by default. Like most applications are often shipped with an embedded application server or even some lightweight database.

    On the ECM Platform side you will soon have the free version vs some more powerful commercial editions (with all the DoD certification and other extras).

    Ideally speaking a WCM should be able to run on any “Content Application Server” (to use the new Alfresco term) like your servlet could run for free on Tomcat but also on WAS or Weblogic if your customer needs something more powerful. Still a lot of standardization work needed to reach this point however.

    But at least we should see more “duos” such as the Magnolia WCM which is prepackaged with Apache Jackrabbit but which customers can optionaly switch to the Day CRX ECM Platform if they need more tools/features/support.

    It will then be interesting to see how such ECM Platforms will manage potential conflicts of interests when they are still also promoting their own WCM offerings (e.g.: Day CQ vs CRX, Alfresco WCM vs new CMIS+Spring Surf Store, Exo WCM vs JBoss GateIn/CR;…).

    So ok they will go separate ways like search servers went a seperate way from WCM but are finally still prepackaged in most WCM and are still requiring some extensive level of integration work. More a kind of a new OEM relationship than a divorce.

    Cheers,
    Stéphane

    Like

    • I agree. My prediction was more focused on the ECM vendors giving-up the WCM ghost, or for analysts to stop requiring WCM applications from the ECM vendors to be considered an ECM vendor.

      A WCM system may need an ECM platform, depending on the scope/scale. However, an ECM platform should not need a WCM application to be an ECM platform.

      Like

  7. Great post indeed… I for one have been struggling trying to draw the line between ECM and WCM and its invigorating to see the agitation this subject brought about. The requirement for WCM to be visually cutting-edge is turning out to be a fairly strong requirement, naturally causing the product life cycle to roll-out WCM based apps to get much shorter when compared to ECM roll-outs. More over, the lack of standards make it all the more appealing for these paths to separate – only converge later as two mature offerings complimenting each other when the time is ready.

    Like

  8. Matty says:

    I don’t know if it’s just me or if everybody else experiencing issues with your website.
    It appears as if some of the written text within your content
    are running off the screen. Can somebody else please comment and let me know if
    this is happening to them as well? This might be a
    issue with my web browser because I’ve had this happen previously. Thanks

    Like

    • If you are referring to this site, it is likely the browser. I’m running on WordPress.com using a standard template, so special tricks on my part.

      Like

Comments are closed.