How many websites these days are purely content-driven?
It’s hard to justify brochureware sites. How many people do business with you just because your website looks pretty? Organisations want websites that either generate an income or reduce pressure on more costly channels, like call centres. That means transactional web applications, not just web content management.
Yet content management is still required. Whether you’re updating marketing material to support your service offering or changing form labelling and layouts to ensure fewer drop-outs on transactions, the web team still needs to be able to make content changes without having to go through a lengthy development release process.
The simplest way to achieve this is to run two web applications separately, one driven by the content management system and the other by the transactional software, like eCommerce. You get your developers to style the two applications to look the same, run from similar URLs and hope that the web app gives you enough control to alter content that it’s responsible for, such as labels on form fields. This way you can keep system integration to a minimum. There are a couple of significant disadvantages, however. Firstly, if your site needs to change globally — a change to brand or navigation, for example — you have to update both systems. Secondly, you need to design your site in such a way that you keep content and transactions separate, which is very unlikely to lead to a successful user experience.
So what are your other options? You could take content managed through the CMS and embed it in the transactional application. This means that when you have a form field to complete which needs some guidance, that guidance can come from the CMS without the user having to abandon their transaction. But this creates problems of its own. You lose some of the key benefits of the CMS: relationships are harder to maintain between pieces of content and preview becomes nearly impossible.
This is why the transactional application is often embedded in the CMS. FatWire, for example, has just launched its Web Experience Management Framework, which should make this process easier, while Terminal Four also touts its integration with external systems. Yet irrespective of the CMS you use, you’re going to face some integration problems. There’s bound to be an element of custom code, issues with assuring decent performance from both the CMS and the transactional application, and above all design difficulties ensuring that the security of the user’s transaction is maintained by the delivery layer.
Another option is portal technology. In theory, portals enable you to deliver all your web applications in an integrated fashion and what’s more, do so incrementally, adding applications without having to change the core configuration. They’re also usually pretty good at managing sessions and user credentials. Portals bring their own problems however, not least cost of delivery, increased time to develop and un-friendly URLs.
So all four approaches have positives and negatives. There’s a niche in that market somewhere for a vendor. Until someone proves they’ve filled that niche however, you’re unlikely to be able to deliver a great business-driven website using just a web content management system.
Our approach as a vendor has always been to not distinguish strongly between content management, and web application framework. CMS features are just one example of how the framework is used to provide some default features, but there are many others, like forums, or chat rooms. And other applications can be coded in seamlessly. It’s pretty much the same as a portal framework (in fact, it’s in our product name), but there are critical differences — most of these portal frameworks tend to be done in Java, by programmers who don’t understand the web well, and require complex and expensive hosting environments, hence the high integration cost, un-friendly URLs, and poor compatibility with other things (especially when it’s closed source). We (and others- we’re not unique) base everything on PHP which makes things a whole lot easier to integrate (I reckon anyone who has tried both PHP and Java coding will realise how much easier it is to work with PHP on a casual basis), and it’s the language of the web so it doesn’t require top-salary Java programmers to work with it.
I probably annoyed some people with this comment, and I know I over-generalised, but I think it still makes some important points. There’s nothing inherently wrong with portals, it’s how they are implemented. In fact, doing it without a portal is probably never going to work well, because you need the portal-like structure to encode the consistency of the system – otherwise you get a mess, or the inter-communication language is as complex and assuming than just coding as a “portlet” (or whatever you call it – we use the term “module”). Sometimes closed enterprise-thinking leads to enterprise-costs when you can do just the same thing cheaper and better by looking at PHP.
I know it sounds like it, but I don’t hate Java. It just I think is usually the wrong tool for building CMS.
Comment by Chris Graham — 14 January 2010 @ 5:02 pm
We all hate Java, sure. But a lot of us hate PHP too; maybe hate it even more. There are more modern options, you know! Not that I want to get into another stupid language flame war
As to Phillipe’s point: I’m inclined to think it’s better to use something that was actually designed to be a web framework über alles for delivery, and decouple the management stuff into a separate app. But yes, getting the integration points right can be tricky.
Comment by Michael Kowalski — 14 January 2010 @ 5:17 pm
I hate PHP a bit too, it has plenty of flaws. But where it really matters, it wins – there is far more software written in it, anyone can pick it up, you don’t need to compile anything, you don’t need to try and fathom how an application server works, it runs on virtually any server (pre-installed on hosting), there are far more programmers for it than anything else, it’s very easy to learn, you can write quick and dirty things or very sophisticated things. Nothing more modern can beat it simply because it is now the de-facto standard across the web, and I don’t think anyone can argue against that. And this is what matters when it comes to integration, what’s stable, what’s compatible, what’s easy, and what there are affordable programmers for. My point really is that I get annoyed when I see enterprisey people complain about all kinds of things that only exist because of the over-analysed and expensive environments they’ve chosen to work in.
But yes PHP sucks. It is an ugly sloppy language compared to some other options. But at the same time, that’s kind of irrelevant – a skilled programmer will work around PHP’s flaws with far greater efficiency than trying to get something written in Java.
Comment by Chris Graham — 14 January 2010 @ 6:05 pm