Contented Management laughing buddha logo

Contented Management

Contented Management

When WCM isn’t enough

Orange and blue liquid forms in a glass

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.

Philippe Parker on , | 14 January 2010

Contented Management

The future of the web is JavaScript

O'Reilly JavaScript textbook

The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.

Philippe Parker on , | 11 December 2009

Contented Management

Stand and deliver

Adriaan Bloem points to the downtime on Oracle’s website following its acquistion of Sun as an indicator that dynamic delivery is generally unsatisfactory. Certainly that website looked like it needed a decent application server on Monday. I wonder where they could get one.

The static vs. dynamic delivery debate is specific to the kind of content you’re producing. Generally, dynamic delivery is well-suited to:

  1. Time-critical content, such as news or user-generated content.
  2. Content that requires lots of automatic relationships and “see also” type links, including product catalogues. This is easier to generate through dynamic queries than it is through a complex relational static publishing model. This is a particular strength of Vignette.
  3. Segmentation and personalistion of content; a strength of FatWire. It can be really hard to deliver content aimed at specific users if you deploy static publishing, although SDL-Tridion has a go by implementing custom server tags into the application server layer.

More generally, you need to weigh up whether you need a dynamic model because you’re publishing lots of content that needs to be up to date, or a static model because you want to guarantee that the content will continue to be served. Either way, you need to be sure that you can change or remove content quickly as well as publish it, and you should follow best practice for delivery performance:

  1. Ensure caching is in place and decent parameters are set; use a CDN if you have a global audience or lots of very large media files.
  2. Optimise your images, CSS and JavaScript and try not to have too many of these being called from a single page.
  3. Use compression techniques, such as GZIP delivery.
  4. Ensure your CMS gives you a tool to purge your cache when you need to.

If Oracle are really concerned about their own website performance, expect them to buy Akamai some time soon.

Philippe Parker on , , , , | 22 April 2009

Contented Management

More enterprise myths

It’s true to say that enterprise is a loaded word: it means a lot more to some than to others. We have enterprise content management (ECM), enterprise search, enterprise portals, enterprise resource planning… People like Nicholas Carr have been railing against these all-encompassing applications for years now, questioning how applications that cost so much to install and configure can deliver tangible business benefit, particularly compared to smaller, more targeted systems. The Gilbane Group on the other hand dislike the term enterprise because they believe it’s pure marketing spiel, particularly in the case of content management where few vendors offer the full range of content management products.

It is of course possible to go to a single supplier and get the full WCM, DM, RM, DAM, JCR and IDM gamut of acronyms. The leaders are IBM and Oracle, but Day, Vignette and Open Text all have products covering the main functionality. You have to take care of course that just because the products are owned by the same company and are labelled as a single product family, this does not mean that they can actually talk to each other. Many is the client persuaded to implement a product portfolio from off the shelf, only to spend months and hundreds of thousands on systems integration.

Leaving aside the truth that vendors relate and the more palpable realities their clients are faced with, ask yourself this: why would you need an enterprise application for content management anyway?

Enterprise means not simply across your whole organisation but unique to your organisation. Your ECM will be different to someone else’s, with different security privileges, workflow, storage and retrieval requirements.

Except it’s not.

What you’re trying to do in your organisation is being attempted in every other organisation of a similar scale or vertical. All your competitors, all your partners, all your suppliers and clients will need to control their information and distribute it to the right people. And they want to do it in similar ways, which is why all these vendors are able to sell their content management technologies to so many clients. The thing is, if your requirements aren’t unique, do you need a system that’s unique?

Of course you don’t.

People like Andrew McAfee and JP Rangaswami have been using and writing about disruptive technologies for years. Technologies like wikis, blogs and tagging are disruptive because they upset standard business models and processes where you procure a single technology and then tell everyone how to use it. Under the disruptive model, you let people use a set of tools the way they find most productive. You can add anything to a wiki without it going through workflow, you use blogs instead of email, you use tags instead of a taxonomy. Depending on where you look, these technologies have been more or less successful.

But for me the issue is that it’s not blogs and wikis that are disruptive, it’s the enterprise technologies themselves. Why do organisations feel the need to procure these tools that few people know how to implement and even fewer know how to use? Why not just pick a few technologies that are out there already? The procurement and implementation of these systems actually disrupts the things your organisation is good at, often having a greater negative impact than the business benefits the system will eventually entail. Yes, an enterprise system gives you one butt to kick, but you still have to do some butt-kicking.
For example, why set up a massive LDAP directory that a bunch of systems administrators need to maintain, when you can use OpenID? If you used this to authenticate people, they can use the same username and password for their social life as their daily business. Isn’t this simpler for everyone? Why set up project team servers? Just let each project team set up a blogger account with a new blog for each project and restrict who can view it. They can use the same email address for their email, calendar, and even documents. And those documents could be shared as a wiki. Some of these technologies will work better than others, and there are of course security implications.

Your organisation does not need to control technology, it needs to exploit it. So before you procure a new CMS ask yourself:

  • Am I trying to do something that is already being done by some of my staff using existing tools?
  • Why can’t I extend those tools to support my business?
  • Do I really want to manage a new supplier, a new project and on-going support?

Isn’t it easier to view web technologies as a facility your enterprise makes use of, like roads or a rail system? Let your employees make their own way to work, don’t go out and buy a bus to round them all up in.

Philippe Parker on , , , , | 20 March 2008

Contented Management

Suitable content for a CMS

One of the biggest challenges for organisations with complex web architectures, particularly those trying to implement SOA, is deciding just what is appropriate for a content management system and what goes into AN Other application. Oscar Berg has had a stab, but I thought I’d try to give a few guidelines.

An indication that a project may be a good fit is if it meets any of these criteria:

  • Written (as opposed to numerical) content to be published within or outside the organisation and administered through a web browser.
  • Documents to be published internally or externally.
  • Digital assets used in conjunction with web or document publishing.
  • Information aggregated from other sources that subsequently needs to be edited by staff before it is published to an internal or external website.

An indication of a poor fit would be a project with the following requirements:

  • Structured numerical databases: this is more appropriate to a bespoke database application.
  • Draft, unpublished information that belongs to an individual, rather than to the organisation: this can be achieved with a file server.
  • Loose, collaboratively-created content, such as blogs, discussion forums and wikis, that don’t require peer review. This content is usually best managed through dedicated collaboration technologies.
  • Aggregated content that can be presented “live” on websites without editorial intervention. This can be achieved through a portal or an application server.
  • Integration of back-end applications to be presented through a common, browser-based interface. This can be achieved through a portal.
  • Archiving records to less expensive data allocations based on frequency of access or age of assets. This is a feature of a more advanced records management system.
  • eCommerce sites requiring automated cross-sell functionality.

There are some grey areas which might combine a CMS with another technology:

  • “Advanced” personalisation, where a website has to remember who you are while you’re on the website and deliver different content to you based on your profile. This is pretty straightforward in a CMS when applied to the homepage using cookies, but anything beyond this requirement is going to be complex to implement, particularly if your CMS is stateless.
  • Streaming media will require an additional dedicated server.
  • Single sign-on functionality would benefit from an identity management tool.
  • Web-based applications such as polls that need to be included on a website but are unlikely to be managed through the CMS.
Philippe Parker on 29 October 2007

Contented Management

Solid architectural foundations

I confess, I’m a sceptic when it comes to architects, for two main reasons.

1. What qualifies someone to be an architect in the first place?

If you meet an architect in the construction world, you know they’ll have studied the minutiae of building design for many years. But if you meet a user experience architect, an information architect, a system architect, or indeed an enterprise architect, what qualifies them for that role? How do you know if they’re any good?

There are some recognised models for “enterprise architecture”, provided by the Zachman Instititute for Framework Advancement or The Open Group Architecture Framework, but these don’t actually tell you whether your architect is sufficiently clued up about your CMS publishing model that s/he can get it to work with a proprietary HR system.

2. What use is someone who designs your project then walks away from it when you actually start implementation?

I think I’d like to be a project architect. I could come up with all the tasks, dependencies and deliverables to design a project, then hand it over to someone else and say “deliver that”. I’d know what all the tasks are likely to be, identify risks, assumptions and approach, but someone else could own delivery post initiation / inception. Anything goes wrong, it’s not my fault: I told you how to do it, so if the project goes wrong then it must be your fault.

It’s just the same for development. How many projects have you seen where the technical architect needs to be called in to resolve an issue because the development team couldn’t apply the technical design?

These days, Service Orientation is the order of the day, which makes having an architect a prerequisite for any web CMS project. So how do I overcome my scepticism and define what an architect should do and if they’re any good or not?

Pranshu Jain provides some insights into what you should expect from your architect: fundamentally the role is about picking the technologies that enable the business to meet its objectives. But this approach has led to some organisations having less technical architects who understand what various software packages do, but who don’t understand the in depth technical details of how the architectural components relate. This spells project disaster.

So my message to architects out there is get your hands dirty. Get involved in the project development and take ownership if things start to go wrong. It will help you to design better systems in future.

And my message to project sponsors and managers is that if you’re recruiting an architect and they don’t know what a reverse proxy is, they’re not going to be much use to you.

Philippe Parker on 8 October 2007