Contented Management laughing buddha logo

Contented Management

Contented Management

Setting standards

CMS vendors are under constant pressure to improve their products. They add features their competitors lack (or that are perceived as lacking in their own product), provide what they hope will be prettier and more intuitive administration interfaces and increasingly integrate with other applications.

Increasingly we see vendors trying to make their products meet industry-defined standards. This could be CMIS, ECM maturity, or feature tables that are readily comparable.

But how do these standards help you as a buyer or end-user of the CMS? A multi-lingual installation package or a product rated as highly mature do not guarantee a successful solution to your content management requirements. I applaud the vendors who are trying to improve the technology, but I don’t think the analysts and architects would be doing their clients a good service by telling them that these standards somehow make the products better.

As a client selecting or supporting your content management software, you need to think about the tasks that are most critical (e.g. must run on my infrastructure) and most frequent. If your CMS is easy to install but you can’t tell when content you’ve published will go live, you have a really serious problem. If your workflow requirements can’t be met, it doesn’t matter if the content sits in a JCR-compliant repository.

You need to focus on your own day-to-day needs, not on the industry telling you what a great product it offers. Set your own standards and be sceptical about other people’s.

Philippe Parker on | 31 March 2009 | Tweet this |

Contented Management

Are open standards by-passing enterprise implementations?

A significant challenge for medium to large organisations is managing the exchange of information between all the applications. This might mean having a common login for your users across all your websites, or being able to display different content depending on a visitor’s geographic location.Ordinarily, the approach has been to create complex integrations of content management systems with user directories (LDAP), web services and portals to expose information from back-end systems in a standardised way.The single biggest issue with this approach is cost. You need sufficient kit to ensure scalable dynamic delivery of the applications, licences for all the software involved and significant design and implementation time. You always hit hurdles during the project as you discover data models weren’t quite what you expected, or your LDAP directory has been customised to hold data slightly differently, or you can’t get one portlet to communicate with another… It’s time-consuming and often frustrating.

Once you complete integration to all your applications, they appear as a common platform for everyone interacting with your services. Except that people don’t use the internet to interact just with your services. They want to check their email, spend time on their networking sites, shop… why should they have to go to your site just to get hold of information that should be available anywhere?

Who buys a washing machine by going to the Hotpoint site? They go to a price comparison site or a reliable distributor first. You should be able to syndicate your content any partner site. And when I’ve remembered my login to all your services, wouldn’t it be good to have the same username and password across all these partner sites? For example, you login to check your current account balance, and it’s the same login to check your mortgage status with another bank!

All right, you can retain login credentials in your browser, in a particularly insecure way. And why would you expect Barclay’s and Abbey to share login credentials? Because it’s what customers need.

We’re seeing the emergence now of true data portability. Increasingly, large web organisations (Google, Facebook, LinkedIn, Flickr) are subscribing to a model of open standards for information exchange that mean you’ll be able to enter your information once and choose which data you share with which websites. Consider OpenID which already provides single sign-on across many sites on the web. This is exactly what many enterprises are struggling to achieve across applications which they actually own!

So what does this emerging approach mean for enterprise implementations? It means you need to question the value of creating complex data integrations. Service oriented architecture through a portal is no longer the only method for integrating your systems, so you need to conduct some due diligence to satisfy this kind of expenditure.

Data portability is, of course, no panacea. Standards are still emerging. But if you’re going to jump on a web services bandwagon, it’s probably a good idea to be on the same train as Google and other leading web presences.

Philippe Parker on | 16 January 2008 | Tweet this |