Best Practices? Let's Talk Best Patterns.

I hear requests for "Tridion [industry] best practices" at least monthly in both internal and external discussion. Implementers ask for them, colleagues forward emails about them, and trainees ponder what constitutes a best practice.

The answer unfortunately, in characteristic consulting fashion, is "it depends." The best practice depends on your environment and business needs. Lets see how context impacts:

• Why we want best practices
• Tridion best practices
• The discussion on Tridion patterns

Why Best Practices?

Easy. We want to know the biggest issues we'll face implementing feature XYZ.

• What have others done to get XYZ?
• How should we build XYZ?
• What are the typical "newbie" mistakes with XYZ?

Lots of time, trials, and tribulations produce such practices. So they're invaluable but not without context. A misguided focus on best practices distracts you from understanding your particular needs. Yes, we have to think and I know sometimes its a pain in the ass, hence the term analyze (Ooh, did you get that? Nevermind. Move along to the examples).

Tridion Best Practice Examples

In order to apply to everyone, the ultimate practices are so generic, bland, and boring they approach becoming platitudes such as "use a content management system to manage your content." You might hear best practices familiar to any non-trivial system:

• Don't hard-code values.
• Use naming conventions and standards.
• Build so that the likely-to-change parts are easy to change.
• Separate concerns.

My favorite is "the best practice is one that works" ("Knew Know", multiple citations circa 2000-something up to this post and beyond). But let's add some Tridion-specific detail.

• Don't hard-code Tridion Content Manager Identifiers (tcm ids) when possible. Actually, never! Well, except maybe in questions to make it clear what you're doing, but even then someone's going to copy your code... See? Best Practice discovery isn't simple.
• Use friendly names for author-facing items such as templates and schema but geek-out with your favorite naming conventions for developer-specific items such as embeddable schema.
• Build for change by using configurable system components, source control for assemblies, and extensions, not customization. Place template-related content in components to avoid needing to localize templates for, well... content differences.
• Separate concerns by using a tiered architecture; managing content, design, and pages in different publications; and having content management and delivery in different environments.

You should also reveal the "we could build it this or that way, but won't" options. Let's make sure the system works, but just because you can do it a certain way doesn't mean you should, it depends on... let's say it again, context.

The Difference between Best Practices and Best Patterns

These "who, what, where, when, how, and why" questions challenge notions of simple best practices.

• Who is the customer and its industry, goals, and strategy?
• What is the Content author approach, experience, and familiarity with content management?
• Where does this affect the BluePrint Requirements, for example website, handheld mobile, tablet device, fridge, car, internet-enabled clothing?
• When will internal, external, temporary, and yet-to-be acquired resources be available and what is their familiarity with all of the above and with Tridion
• How do Technology and standards apply such as Operating Systems, databases, .NET, Java, (X)HTML x.0, etc?
• Why this question? What's the context?

For example, we might suggest the Core Service over the Business Connector as a best practice, but this assumes:

• Customer has SDL Tridion 2011 and is willing to build/buy and support such an implementation.
• The use case isn't better handled by Content authors, possibly as manual one-time changes.
• The approach handles the BluePrint Requirements.
• Implementation team is familiar with the API and will build in a way the customer can maintain and live with.
• Customer and implementation has access to the appropriate Technology, licenses, and software.
• And since there are (more than) seven places to affect content, we have to make sure a "Core Service" need is not better met through templating, event system, workflow, content porting, and/or other extension.

See? Context matters.

A recent customer asked me for a breakdown of the pros and cons of such practices. It can't simply be "what's the best way," but what's the best way for my scenario? What's the best fit?

Best Practice + Why + Trade-offs = Design Patterns

This is where patterns help. If you're new to software design patterns, I recommend Head First Design Patterns (one of the crazy-looking, brain-friendly purple O'Reily books). It's a fascinating read so far with lots of "a ha" moments for me. "Ooh, I didn't realize factory and decorator pattern had names."

To get Tridion-specific patterns hire a an SDL Web Content Management consultant of course!</plug> Actually, this is something the Tridion technical community has been evolving for years. To address context, do continue to share your thoughts on not just best practices, but include the why's and trade-offs. It doesn't matter if we actually use the term design patterns, in the end it has to work for customers and implementers.

Get inspired by design approaches and implementation examples from around the Tridion web.

• Patterns in Strategy. Minimize Localization Approach is a best practice/approach/pattern tidbit that reflects  "Señor Strategist" Garrido nuanced and sophisticated Tridion understanding.
• Implementation Patterns. See The Tridion Practice Cookbook for code smelling of something delicious. Its problem-solution format and experienced chefs make it a go-to resource.
• Customer, Community, and Other Good Stuff from That Community Webinar-ing Tridion Autodidact
• MVC Pattern. A MVC pattern framework with Tridion (DD4T) with example from Albert Romkes.

tl;dr version:

Tridion Best Practices are useless without context. Instead, let's talk Tridion patterns. What that means exactly is evolving; however, we've already started.