SDL Tridion Troubles

By | March 28, 2011

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.

7 thoughts on “SDL Tridion Troubles

  1. John Winter

    Great follow up post.

    I agree with the satisfaction regarding fixing the unfix-able in terms of blueprinting structure. Last year I write a tool that migrates content and dependencies from one publication to another in order to fix a terribly implemented BP structure. I think I was happier with the result than the client!

  2. Nuno Linhares

    Good stuff Albert. Don’t take me wrong, I love my job. From where I see it, I would much rather have people do things right and not need me – or you or Dominic Cronin or Ingmar and oh so many others – to come in and fix what could and should have been done right from the beginning.


  3. Marjolein Mosmans

    It is nice to be a consultant who can help customers with their Tridion implementation from the start till the end and beyond.
    And as Nuno says: you, Dominic, Ingmar and skilled other consultants are there to help!
    It’s too bad that implementing Tridion is a project that is almost everywhere underestimated with regard to (organizational) resources and impact.
    But leaving a happy customer in the end after completing a successful implementation is indeed a great experience.

  4. Alvin Reyes

    Ah, validation for the “sanity check,” thank you, Albert! Excellent post.

    I typically run blueprint changes by at least two developers and an analyst, manager, and/or the users. I’ll tap the Tridion World community for constructive feedback as well. I was thinking I just like talking to people about Tridion, but the process and consensus gained by it make a difference.

    We’ve documented everything from how-to (dev setup and user) guides, to rationale for how we set up permissions, to a list of customizations and blueprint decisions. It comes in handy with changes–new staff, new technology, new projects, or an upgrade to the CMS itself.

  5. Henk-Jan castermans

    Very usefull. We’re migrating to Tridion 2009. You talked about disabling “publish propagation” in your “Publishing queue traffic jam”-topic. Where can I find this option?

  6. Albert Post author

    Hello Henk-Jan,

    You need to disable it using the eventsystem. The howto is on the SDL Tridion forum.

    btw seems a long time ago since we were colleagues…


Leave a Reply to Albert Cancel reply

Your email address will not be published. Required fields are marked *