jump to navigation

CMS and All That…. July 14, 2006

Posted by poseidongroove in brand, CMS, eWorkPlace, Java, Joomla, Web Culture, Weblogs, Work.
1 comment so far

I’ve been very busy in the last month. I’m architecting a new web platform for a medium-large UK organisation.

I’ve done a lot of Content Management System rescue engagements in my time. Like customers implementing CMS as a silver bullet that will solve every problem conceivable. In my experience, this is never the case. It always depends on the customer. If you’re a medium to large business. You will need more than a CMS to fully engage with customers across multiple touch points.

If you’ve got a really good web application for managing relationships etc you can get by for a little while. Problem starts if you really want to do A/B campaign splits and really test customer life-cycles or user segmentation. Personalising user experience occurs in two ways what you accurately inferred about a customer and what they told you about themselves. In most cases, you’ll get the latter with a CMS !

I thought about writing this post because, after several years of people buying content management systems. If we exclude open source offerings such as Mambo or Joomla which are not really enterprise scale CMS. I feel most CMS vendors always think all presentation logic and meta-data should be coupled into the CMS. Whatever happened to Portals and Commerce Engines. Are you sure you really want to be making Web Services calls to build dynamic content in each JSP or ASP Page ?
I know JSRs are really difficult to follow and hardly anyone is implementing JSR 170 correctly. I still think CMS vendors do themselves serious disservice if they keep selling their solutions as one stop shop for everything from integration to back-end system, personalisation, etc.

If you’re in the market buying a CMS, ensure decoupled delivery is the default mode you engage with the vendor. Meaning you deliver content into a Content Repository for example, a database schema for a dynamic JSP/ASP whatever to use jsp tags to look-up the data and render it using an ORM.
Effectively, you’ve exposed all the meta-data for any degree of personalisation you might want. If however, the html, stylised content, tags and content items are all locked in deadly embrace in jsp pages. I really feel sorry for you and your company. You really ought to start again.

Effectively, there is no decent means other than the CMS of doing personalisation campaign management analytics whatever. Please don’t come and tell me I should be making SOAP/WSDL calls to a CMS repository. You don’t need to do that. Just bung it in a database schema bodytext, headline and all and off you go. Use an Object Relational Mapper with caching capability to retrieve the data into your dynamic JSP/ASP pages.

Remember, the CMS will need to notify your Object Relational Mapper of additions or changes to the content items. You can still carry on deploying static content to your Webserver document root. It’s better there. Except, the CMS or Portal provides decent full-text search of documents such as pdf. Don’t waste your time putting them in a CMS.

Two of the vendors we saw delivered a decoupled implementation. They know who they are and I really appreciate their effort. For us and the vendors, it means if we decide to buy an eCRM Platform or Personalisation engine none of the new vendors can turn round and tell us we’ve never integrated with that CMS before. I’ll just give them the reference implementation to use. Saves everyone a lot of time. (This is a MacDonald’s tip for you).

One of the best CMS implementations I’ve worked on that still does that to date is Den Norske Bank, Vital and Postbanken in Norway with Guray Sen & Razorfish. Same parent company different trading divisions, same database schema all very dynamic way before anyone thought of JSR 170. It’s called common sense and flexibility meaning you can localise to whatever language since all content is dynamic.

Given this frustration of mine, I seriously recommend if you’re in the market for a CMS, tell all the vendors to deliver a decoupled delivery implementation of the content items into a Tomcat or JBoss reference implementation using hibernate and a decent set of taglibs to retrieve an array of news-feed and a detail news item page from a MySQL database. See below for an example schema.

What you’re doing is building flexibility into your content architecture. All data should be available for creating a 360 Degree View of the relationship with your customer where-ever it lives.
More importantly, if you’re using a personalisation engine or campaign management platform with your web application, you’re now in a position to really personalise the user experience and create effective campaigns that really affect your audience. Even better let the user liven up their interaction with your site as they wish e.g. Playing with the colour scheme or delivering relevant news-feed based on item-Types such as football assuming you categorise your content repository.

Finally, the demands of participative architecture (AKA Web 2.0) means delivering an online experience that has stick-ability is a serious challenge going forward.

CMS vendors really need to be careful with the messages they’re sending out when selling their solution. I came away from this excerise feeling all CMS tools are actually, the same. The difference now is in usability. If you’re doing due dilligence means you need to ensure you get what you want and what the users want !!!

ContentSchema

Context of Use for Dynamic Languages April 30, 2006

Posted by poseidongroove in Chaos, CMS, Joomla, PHP, Python, REST, RUBY, SOA, Social Software, Web Services, Weblogs.
2 comments

The last few weeks have been quiet on the blog but very busy for me workwise. I had a few customer projects to put into production and also complete hand over. Last Friday was my last day at Consider Solutions. Been fun working amongst friends the last 3.5 years or so. Will miss you guys.

I’ve started up a project with some friends; I’ll share details of what we’re doing on the blog in due course. You get to a crucial age when you feel I really want to make the difference in your own little way. I’m @ that stage right now.

This post been nagging away in my mind for several weeks, Richard Veryard blogged about it a few weeks ago The Lightweight Enterprise. I’d already written up a draft on my stolen laptop.

We have two camps in application development today, the dynamic scripting languages camp and the enterprise class application development camp. Without Dynamic Languages like PHP, Ruby and Python, we probably will not have the amount of innovation we have on the web today. Just think for a moment, WordPress and Typepad are both written in PHP so they’re enterprise class content management systems are they not? On the other hand Enterprise IT is slow cumbersome, standards obsessed, reflective and worse stifles innovation. We’re so full of contempt for Dynamic Languages because we think we can’t control it. I’m transitioning between these two camps all the time, until I discovered the Power of PHP and Ruby I was an enterprise bigot. Now, I have a more pragmatic view about all things software related. I’ve always used Jython for light coupling, PHP and Ruby are simply awesome!

I’m building our company website in Joomla at the moment, I’ve used Documentum, Media surface and Interwoven Teamsite. Joomla and Mambo are more elegant and easier to use. Besides, you can create enterprise grade websites in these tools even if I hate to admit it. Better still, they’re free, loads of free templates available for them. So where does this leave our bigoted view of superiority of so called Enterprise Grade Architecture/Software? Maybe locked into a bitter fight for deals with fortune 500 companies. Leaving the door open for mass market adoption of so called open source alternatives.

I think what So Called Enterprise Software vendors need to do is recognise that you can’t stifle innovation for long. I think the best way of opening up Enterprise Applications and Architecture to participation is to recognise a context of use for Dynamic Languages.

For example, if all application server vendors, enterprise service bus and BizTalk(Whatever MSOFT App Server is called), have out of the box Runtime support for as many scripting/dynamic languages as possible, you then empower developers to use whatever tools are available to develop rich web applications. All these bigoted views we have about what language is better will cease. Who cares what language, who cares if you use REST or SOA? As long as end users adopt the application and it scales, that’s all that matters. It really isn’t that hard to do this. My last project used Jython referencing Java APIs provided by the platform.

If you’re in a big enterprise, turning your nose up at Dynamic languages, you do so at your peril, you’ll be out of a job soon believe me. The world of software will start to revolve around free software and software as service in less time than you imagine. Only the vendors that tolerate innovation and open up their platforms will survive this shake out.

If you’re in a command and control enterprise, your developers are all spending their spare time getting up to speed with Ruby and PHP. Yet when they come into work you say thou shalt only use Java or C#. You’d better smell the coffee before it’s too late.

How about developing reusable services/components that can be used by all languages using REST?

If you Mr/Mrs Enterprise follow this approach you can then force your software vendor to provide a runtime environment for scripting languages. It then becomes easy to loosely couple services in your enterprise and harness available skills to build any application.

The question of scale will disappear why? If you use REST to couple a PHP based application front end to a backend SAP, BEA or Siebel CRM everyone is a winner, the application scales (hardware is cheap with dual core and virtual servers, you get more from your CPU investments) structured languages and dynamic languages bigot let’s all get together and make the end users happy. That’s our job!