
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.
