April 2010
M T W T F S S
« Feb   May »
 1234
567891011
12131415161718
19202122232425
2627282930  

CMS Vendor Navel Gazing

You can either go to the church of your choice
Or you can go to Brooklyn State Hospital
You’ll find God in the church of your choice
You’ll find Woody Guthrie in the Brooklyn State Hospital
And though it’s only my opinion
I may be right or wrong
You’ll find them both
In the Grand Canyon
At sundown
- LAST THOUGHTS ON WOODY GUTHRIE

Forgive me, WordPress, for I have sinned. It’s been 8 weeks since my last blog post. And in that time many people have slandered WordPress, accusing it of not being a Web Content Management (WCM) platform at all. But that’s not important right now.

What is important is the main reason for my 8 week lapse – the arrival of my very own WCM – Willow Coco Marks, born 19 Feb and smiling ever since. So I’m now the proud owner of two darling little sproglets. And no-one would ever dare to ask me which of my children I love more. That would be horrible. It would be like asking a CMS vendor to take five super important features decide which they love the most. No-one who has seen Streep bawling her eyes out in Sophie’s Choice would go there.

So, here is the deal. I challenge any CMS vendor to rate these in order of priority:

  • Editors – A user interface that is a editor or publisher’s wet dream
  • Performance - The fastest, most stable and scalable CMS in the world
  • Features – The richest set of features any CMS could dream of offering
  • Developers – An open, standard, extensible product that makes developers salivate
  • Website – A product that can give you a kick-ass website, really really quickly

Yes, yes, yes, we know they are all important. But not equally important to you. For example, would you choose a proprietary format if it made the editor interface better? Would you add the feature the developers all want if it affected performance?

So, dear vendors, have a long hard introspective and submit your answers in the comments in the form E P F D W (assuming you like the random order I listed them in) with the first being most important and the last less important than the other four. And no, there isn’t a right answer.

Who wants to play?

  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Digg
  • LinkedIn
  • StumbleUpon
  • Technorati

23 comments to CMS Vendor Navel Gazing

  • So far we have:

    @micycle: I’d go E DWFP – but then I’m not strictly a vendor just now

    @CompoSiteC1:- D E P F W – that’s with a capital D.

  • John Goode

    @johngoode: I’m longer a member of the WCM vendor clan. The one I worked for would have voted [ E| long pause |W|F|P|D ]
    Good for take-up, but can lead to many frustrations.

    Some clients want a tactical solution [ F|W ] score highly. Others want a strategic solution [ D|P ] may well be the order of the day.

    I’d choose: [ D|W|P|FE ]

  • The answer is always, depends on the project.

    * Do you need to worry about Editors if you’ve got a centralised publishing team?
    * Performance isn’t that important if you’ve a small-scale site with relatively little content churn.
    * Who cares about Features if you’re not going to use them all?
    * Developers aren’t important if you want to off-shore (out of site, out of mind) or don’t need a site that interacts with any other systems.
    * Website is of course the ultimate objective and you want to deliver it quickly, but it shouldn’t be at the expense of achieving your other objectives.

    Of course, the reverse is also true:

    * Editors – if you don’t get this right, what are you buying the software for?
    * Performance – absolutely essential and a massive failing for many CMS projects.
    * Features – enough to enforce standards and inform new possibilities.
    * Developers – if your product isn’t extensible, your strategy will be limited.
    * Website – the core objective for your WCM.

    Glad I could help to clarify.

    • What a cop-out, dude! Put yourself in the shoes of the product architect/design authority of the hypothetical product you’ve just built. You need to make the product decisions that trade-off the different pillars. What’s the order …

    • MemSQLis a dependable and soihsitpcated database management technique that gives you different database management and SQL database recovery algorithms. is one of one of the most soihsitpcated SQL Server commands that helps you mend corrupt database. On the other hand less than some scenarios, this command fails having an mistake and are not able to mend harmed database. This behavior qualified prospects to critical details reduction and requires SQL Server recovery to become preset.

  • Have to agree with @proops it “depends” on the context, client’s business, the project, the makeup and skills of the team, who’s developing on it, who’s going to support it?

    It depends on the politics & personalities of the organisation, who is leading the charge for the CMS?

    You also have to consider risk and your plans to deal with it, what are the factors that have the highest probability and impact to derail the project?

    Performance may not be important if your traffic patterns don’t have peaks of user activity or you don’t have more than a couple of editors using the system.

    If much of the content is coming in via automated feeds you wouldn’t really care about the editorial interface. So I would suggest that there is a matrix where a particular context yields different results sets, so nobody is wrong! :)

    Where there is a devolved publishing model, complemented and supported by a small in house of project managers, web and software developers I would suggest the following results:

    1. Editors – this is the tool that they will use on daily basis, these are the guys who care about the Content and they usually outnumber and are more vocal than the
    2. Developers – looking for interesting problems to solve (opefully elegantly), next comes
    3. Website – the reason why you brought the product to support delivery channels,
    4. Performance – hardware (servers, cacheing to CDN) is so abundant and ubiquitous today that systems can be designed to scale with relative ease
    5. Features – most CMS’s now ship with a comprehensive set of features, and you would be looking at best of breed to cater for the requirements that were not being met.

    Of course the most important ingredient is the website visitor, they will drive the KPI’s management are monitoring. Fortunately we can improve their user experience to better cater for their needs. Unfortunately with the CMS you’re stuck with the UX (and content model) that you’ve purchased.

    • Et tu, @izahoor. Of course, from a customer perspective, it depends. But from a vendor (or vendor product manager) perspective, it’s doesn’t. They have one product, one roadmap and one architectural vision. They need priorities. So forget the customers for now and stick your neck out :-)

  • Have to respectively disagree with Phillipe and Zahoor – all of those “depends” comes down to CMS customer “choice” rather CMS vendor priority. Welcome to my opinion :) P D W E F

    1. Performance – this is your foundation, and I include Reliability and Consistency, as well as Authoring and Publishing interfaces in determining this as choice number one. It affects *everything* else. This is not solely about Power. Would you put an underperforming Formula 1 engine in a lawnmower? Or a high performance two stroke? The choice for a CMS vendor here is what size project do they wish to cater for. The choice for the CMS customer is to not choose one below their requirements! Poor performance does not give any confidence that any of the other choices can be delivered to any satisfaction.

    2. Developers – Unless your CMS is Perfect, it better cater towards developers. Basically – any flaws, holes, missing features or just the fact that no two set of requirmeents are the same means that there will be bespoke work to be done. Make this painful for developers and prepare to be saddled with few to little choices in everything below. Developers come after Performance only because Developers can’t improve Performance – not without rewriting the CMS anyways…

    3. Website – Our end purpose. Remember, we are supposed to be making this *easier* not *harder* :)

    4. Editors – Editors are very important, so why down at #4? Well, if you put them above performance, their editing interface can be impaired – no matter how good the UI is. If you put them above developers, then the supplied interface better be Perfect. Again, a customer may choose a CMS whose editor interface suits (or more likely mostly suits) their needs, but a CMS vendor would have more difficulty creating an interface that is Perfect for one let alone all of their clients’ needs… I did consider putting Editors above Website – but then I had to consider that – we need to create a Website, and, most likely the Editor interface will also be a Website – and therefore anything that restricts our ability to create a killer Website more than likely will restrict our ability to create a killer Editor interface too…

    5. Features – the easy one to place! Features are nice, especially standardised ones, but again, the chances of all of your requirements being met and in the way you want them to be met means that you are looking at custom development again, which means we are covered by #2! This really is just a nice to have, perhaps as examples of Developer API :)

    Disclaimer: I’m a developer :)

  • The order I would choose:

    P E D W F

    1. Performance – a system’s up-time and the delivery of up to 1 billion PIs per day in a dynamic environment is mission critical to our customers, so naturally we take maintaining this level of performance very seriously.
    2. Editors – a website can only be successful if editors can do their jobs well. Power and flexibility to shape and optimize the editorial process is essential.
    3. Developers – in an enterprise environment, each web project is a tailor-made solution where a WCMS is a strategic infrastructural decision. For this reason, the WCMS needs to be very flexible, minimize proprietary expertise, while still being sufficiently stable in order to protect initial investment.
    4. Website – a quick start is perfect! But only if it does not limit future developments and strategies (see 3.). With the right architecture it’s not an either/or decision.
    5. Features – are important, which is self-evident for a comprehensive product suite. However, no set of features will ever be complete and no two customers will ever have the same feature requirements.

  • Hi Jon,

    Good to see you back and on fine form – congratulations I think you have created a perpetual motion CMS conversation machine – this deserves to run and run.

    I also think this could also be the Myers-Briggs test of the CMS profession, I can see people introducing themselves at events – “Hi, I’m a D|W|P|F|E” :-)

    Me, I’m errmm.. P (using Adrian’s definition).. then err.. it goes a bit hazy.

    I started to explain, then my comment got way longer than your post and that seemed rude. So I wrote this blog post.

    Before you say it, yes, yes I know, I too am a cop out.

    Ian

  • Peter Monks

    My goodness! I haven’t seen this much dithering since I last tried to surf pr0n on an EGA-equipped PC! Seriously people – @McBoof was asking for an opinion and all he’s gotten is a lot of umming and aahing!

    Well the blathering stops here: If the product is a CPS, then the priorities are EDPFW. If the product is a PMS, then the priorities are WPFDE. It’s not entirely surprising to me that those two use cases are (almost) the inverse of each other – I think there are *drastically* different priorities for a production / authoring system vs a presentation / delivery system.

  • Once again, the prawn-consuming Monks sees through my plan. This is exactly the point. I think we should first try to classify the products based on these priorities, and then use this to decide if they’re a CMS/WCM/CPS/PMS/other. For example, how about these as starters:

    WordPress – WDEPF
    OTEX/Vignette VCM – PFDEW
    EPiServer – EWDPF
    PHP (yes, the language) – DWPFE

    • Peter Monks

      Here’s my take on a selection of WCMSes I’m (in some cases only vaguely) familiar with:

      1. OTEX/VIGN VCM – EFDPW
      2. OTEX/VIGN Dynamic Portal – WDEFP
      3. AU.L/IWOV TeamSite – EPFDW
      4. Alfresco WCM – DEPFW
      5. Drupal – WDFPE (F ranks high due to community contributed modules)
      6. WordPress – WEDFP (ditto)
      7. Non-Java portal-like WCMSes (PHPNuke, DotNetNuke, and friends) – DWFPE (ditto)
      8. JSR-168 portal servers – DWPFE (some minor variation between specific products, but most fit this general pattern. Also interesting to note that JSR-168 failed to produce the plethora of community developed modules / portlets that Drupal et al achieved – evidence in support of the idea that in practice specifications tend to result in lowest common denominators? A topic for another day…)
      9. Hosted WCMSes (Clickability et al) – WPEFD (with some flipping of F and D)
      10. MVC frameworks (Struts, SpringMVC, Tapestry, Django, Ruby on Rails, Lift etc. etc. ad nauseam) – DPWEF
      • Peter Monks

        PS. These ratings reflect my opinion of these products as they currently are, not necessarily as their vendors intend them to be.

      • My ratings reflect my view of what the product designers intended the product to be, not as they currently are. A great case in point is me putting the P first for the VCM, while you’ve got it at the back. Vignette has put a huge amount of effort into their extremely complex J2E creating. It’s meant to be the most stable and fastest thing out there. You can just the success of this by the fact Mr Monks has put the P for Vignette near the end.

        P.S. @pmonks – Do you actually like the editorial interface for the VCM? V7? V8?

    • Peter Monks

      Also, would it make sense to post a followup blog with a matrix showing where various WCMSes end up getting placed? I think this discussion will uncover some interesting patterns and a visual representation will more readily show that.

  • Jon, suggest you bring post-it notes and a marker to next Last Thursday. Let’s see some self-labelling! Hm, might even be a party game in it.

  • Regarding our earlier conversation on Twitter – got the completely unofficial word from Fatwire today – they are PDFEW. Although, I think it was a close thing between F, E & W.

    Cheers,

    Ian

  • Plone is IMO: D|E|P|F|W (Other Plone people will probably disagree with me. We are a diverse group)

    Plone is about the people. The community is longevity. All the other factors can be gradually improved when you gather awesome developers with shared goals and collaboration. Software can be written again – but only as long as you have momentum behind it (be that from community strentgh or money).

  • In an effort to avoid all navel-gazing and fence-sitting, here’s what you should look for if you want a successful web CMS implementation:

    * Performance
    * Website
    * Editors
    * Developers
    * Features

    No expansion required.

  • In a 2.0 world every users is becoming an editor. I must then say that I prefer a vertical separation of Platforms with Products on top rather than an horizontal division from CPS to PMS. Needs of Developers (Content Platform) are not the same than the ones of Practitioners (Content-enable Products/Applications). New generation of Content Systems are now splitting-up their CMS offerings trough a better distinguo of the Platform/Product division (think of SP2010 as a Platform (SP2010 Foundation) vs SP2010 as a Product or Day CRX as a Platform vs Day CQ as a Product, etc…).

    This would rather generate the following matricial split:

    +———————+——-+——–+
    | | CPS | PMS |
    +———————+——-+——–+
    |Content Platforms | D | D P |
    +———————+——-+——–+
    |Content Products | E F | U W |
    ‘———————+——-+——–+

    U = Users 2.0 but could become E

    More you are looking after a High-end offering, clearer the matrix will be declined in different lines of products. On the low-end market segment everything is still heavily-coupled but content platform commoditization is ramping.

    P.S: Where is Jahia? Somewhere in transition to a better Platform + Products split-up… ;-)

  • Useful info. Lucky me I found your website unintentionally, and I’m surprised why this
    accident did not came about earlier! I bookmarked it.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>