Tridion and Technical Debt

When updating Web content management (WCM) systems, the implementation team has an opportunity of paying off technical debt.


There are a few ways to improve an existing WCM, either by offering more structure, flexibility, or paradoxically a little of both. For example you can:
  • Separate code from content
  • Improve the author experience
  • Improve the design experience
  • Simplify maintenance
  • Improve the user experience
  • Improve scalability
  • Offer more options while simplifying the default choices*
*For an excellent treatment on improving the user/human experience, see Nudge: Improving Decisions about Health, Wealth, and Hapiness

Technological debt refers to design or implementation choices that have a relatively low cost up front, but cause significant issues in the future.

Tridion as a Culprit?

Could Tridion itself cause such debt? Sure. It depends on the design choices and trade-offs.

For example, implementing a mismatched BluePrint, creating confusing schema, or skipping training can wreak all sorts of short and long-term havoc with a Tridion implementation. Also, upgrading too soon or too late with any system vendor has its own trade-offs. Btw, Tridion's complex because of customer's sophisticated needs. No, I'm not being sarcastic, stop grinning. Really.

Avoiding Technological Debt

As developers we refactor code, review approach, and evaluate better implementation methods. When working on business and system requirements we balance business wants with system needs and include both user and IT perspectives. At its core, we reduce debt by planning for, anticipating, and designing for the likely-to-change  parts of our systems. Though you might smell best practices, I see practical patterns.
Easy != Simple.
Just because something has a GUI doesn't mean you don't have to perform the same due diligence. For example, although schema creation is "easy," we should apply the same rigor to avoid technological debt.  Before creating schema, be sure to understand linking propagation, the importance of author-friendly schema names, what types of fields to use, how field order impacts authors, how to properly use Categories and Keywords, BluePrinting, templates, and the difference between page metadata and page-related components.

Organizational change is so hard, some call it change leadership. But while you're investing in Tridion or any other significant implementation, it's a good opportunity to pay down technical debt. If you choose to take on technical debt, do so conscientiously in a way your team can live with.


  1. What I think is missing to Tridion to ovoid those kind of misunderstanding and technical debt, is the need of naming functionality as they should be.
    For example renaming components properly.
    I like also when you point out training. For the sake of understanding a tool you need a training even more for Tridion as you said it's complex. Without training it's extremely hard to learn how to use it. This is all about a learning curve and for some tools like Wordpress it's fast. For others like Tridion it's at least 6 months to a year (IMHO).

  2. Definitely, we shouldn't underestimate naming conventions since they impact everything from easy-to-select options to finding items.

    In terms of training, I agree it takes a slightly bigger investment than WordPress to learn, but that trade-off should be on the implementation side rather than on authors. If it takes 6 months for an author to learn how to use Tridion, double check the author, process, or implementation!


Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.