SDL Tridion Troubles

This post is a Response to “Rants on Tridion Implementations” which I ran into on my Sunday evening round of blog reading. In this post Nuno L rants about the burden of fixing broken Tridion implementations. We seem to be in the same business and I would like to share my perspective on this subject. I strongly diasgree with “my job is not always an easy or necessarily happy one”. In addition  when I (please read the rant of Nuno first) walk into a project it means your Tridion Troubles are over. I love to fix things that are broken or find a solution to problems other people have given up on. To see despair turn to optimism and see smiles on the customers face always makes me feel happy with my job. Though I have to admit I find that the best part of fixing the impossible is the bragging rights afterwards.

In the language debate I would like to make a stand for reduction in the number of languages/technologies needed to implement Tridion. The cost of maintaining different development environments alone should be enough reason to want to limit the number of languages and technologies.

That said I would also like to vent about the most unintelligible Tridion troubles I have come across:

Blueprinting Mayhem

I agree with Nuno that blueprinting is usually the source of the most costly of Tridion Troubles. It is a very powerful instrument, however as with operating any power tool, it should be used with caution and handled by a skilled craftsman. On one of my bigger projects I came across a blueprint which defied the most basic of information management principles. The problems caused by not following basic guidelines for data design could not be managed by the implemention partner. The project was halted and lawyers were already circling the remnants of the project. Luckily some of my Deloitte colleagues who were engaged on another project at the client) picked up on it and brought it to our attention. Luckily both parties agreed the legal option would be less fruitful then giving a colleague and me a chance to sort out the mess and get all project members facing in the right direction. I succeeded in finding solutions to the “impossible-to-fix” problems and directed the programmers in order to get the website up and running.

However the fundamental problem, of the sub-par blueprint, eventually had to be solved and cost the client a substantial sum. This could have been avoided if the blueprint architect, or anybody in the project team for that matter, had followed a basic data modelling course where you are taught the reasons behind normalizing data models. I am not saying you should normalize the complete data model, however you should understand that creating and maintaining 20+ copies of the same data might prove troublesome.

Publishing queue traffic jam

The latest client that banged on my door had recently upgraded to SDL Tridion 2009. They told me they had always had problems with slow publishing performance. Unfortunately by the time they found me it had escalated to a point where the queue was backed up so badly that it was becoming unusable and even the CIO had spent time writing a memo on the subject. There were three external parties involved in hosting, maintaining/upgrading and extending their CMS, none of them were able to find the source of the problem (and pointed at each other).

The problem in the end was quite simple: Someone forgot to disable publish propagation and nobody seemed to have noticed. The clients estimate was that it had always been enabled during the 3 years the CMS had been in production. It took me 3 days to review their systems and fix their most urgent problem (no that’s not bragging). During the next meeting the client confidently asked me whether they now had the fastest publishing Tridion CMS. Despair turned to optimism in a very short time. Unfortunately, my typical Dutch frankness spoiled the mood, I disappointed them by telling their setup did not come close.

Final Thoughts

A Tridion blueprint is designed at a very early state in the product life cycle and is the most important factor in the success of the Tridion CMS. There are always alternative blueprints possible, make sure you evaluate the pro’s and cons, discuss them with stakeholders on a level they can understand and capture these thoughts in writing. Never make the mistake of designing a blueprint without a solid business and technological sanity check.

When running into any Tridion trouble always check all angles: Hardware, custom software, Tridion software, DB and content manager workflow. Try to resist the urge to blame somebody else. If you still find yourself unable to fix the problem you are welcome to send me an e-mail using the contact form. I am always looking for a bigger challenge.