SDL Tridion. Bottom-Up or Top-Down?

A few customers have asked me about the trade-offs between SDL Tridion implementation approaches.

Typically you design SDL Tridion implementation top-down but build bottom-up. Sometimes it makes sense to reverse the process.

Implementing SDL Tridion is rarely an either/or situation. I've typically seen a mix of approaches depending on the circumstances. Let's review the typical approach then consider the opposite: a top-down build followed by a bottom-up design.

We Define Top-Down

The SDL Tridion functional design typically starts with the client's business and website requirements. Using Information Architecture, we review website specs (e.g. wire frames, comps, or mock-ups) and analyze them for Page and Content Types (i.e. Component Presentations).

We then define a Functional Design that includes, among other things:

1. Presentations: Page and Component Templates as well as Template Building Blocks (TBBs)
2. Definitions: Schemas and Keywords
3. Organization: Folders and Structure Group as well as Categories

We Can Build Bottom-Up

Given a Functional Design, we can build a SDL Tridion implementation from the Bottom-Up. We reverse the list above and create the following.

1. Organization: Folders, Structure Groups, and Categories
2. Definitions: Schemas, Keywords, and optionally Components
3. Presentations: Page and Component Templates as well as TBBs

Though these lists simplify reality a bit, the order matters because of Building Block dependencies. Though you could do things out-of-order by creating Component without Categories or making pages without Component Presentations, the point is to understand the impact of such dependencies on your implementation, design, and code.

...Or You Can Build Top-Down

You might have seen a video showing how you can quickly create a Layout Template Building Block even before creating Component Templates, Components, and Schemas. This copy & paste approach mimics the design process.

1. Presentation design starts with the final markup pasted into, or uploaded via WebDAV as, layout TBBs. You can quickly create Component Presentations, not worrying what will be componentized or templated just yet.
2. Add Definitions only as needed, perhaps hard-coding markup in templates or in one-field "code" components. 
3. Organize as you proceed, assuming flat organizational items and text fields over Categories until more refined requirements dictate otherwise.

This approach requires iteration and small changes as you go. It makes sense when you know what you're doing on a small project or template with limited time. You understand requirements will change and will accommodate accordingly. I've seen this work with:

• An Experienced Team. You or the team has SDL Tridion and system design experience. You understand the dependencies and know how to synchronize components manually or with code.
• A Small Implementation. The implementation is a small one-off page or mini-site and will use existing approaches in an existing implementation, possibly with the same schemas, TBBs, and other items.
• Limited Time. You need managed content quickly for a proof-of-concept, a demonstration, or to prove a colleague wrong. :-)
• Clear Requirements or Requirements Not Required. You have wireframes and possibly markup already defined and a clear idea of CMS approach. Paradoxically this approach applies to teams more interested in "Tridionizing" a site than the actual requirements.

I've personally seen Top-Down Tridion development* work for in-place implementations. For example, given a known (rendering framework) format (e.g. a specific set of HTML, XML, or JSON), you can start with the desired output, then work backwards to the Component Presentations, Component Templates, and Schemas, and Components. This is harder if the format is unknown.

Former colleague Jeff Vaccaro once asked me about such in-place implementations. "Why did we have Tridion make an XML page here for these home page alerts, which differs from the rest of the implementation?" I explained that I didn't own the home page alerts .NET code and "preferred an in-place replacement rather than forcing a change to existing code."

*I've heard "Tridion developer" used to describe Technical consultants and contractors, but I prefer to save the phrase for those that create Tridion code (e.g. Peter or Mr. P).

Cons to a Top-Down Tridion Build

Top-Down development is fast and flexible, but can get sloppy with redundant work and missed requirements, especially when done in parallel with little communication. For example you might be tempted to copy and paste each Web page into a Page layout Template Building Block and end up with a Page Template for every Page. "Hidden" requirements such as analytics or SEO details are easier to miss.

Be sure to set realistic expectations with this approach; the website will seem to work with Tridion right away, but you're not done until the content is actually manage-able.

Published from Tridion != Tridion Managed

Recommendations

Run your SDL Tridion implementations in a way that fits your team, software development life cycle, and technology. The copy/paste top-down approach is a typical part of implementations (I see it most with Component Templates), but consider the following.

• Manage expectations. If possible, consider removing hard-coded image references and actual content from page layout logic. The client and team will be less likely to assume you're further along than you are. Broken or placeholder images and Lorem Ipsum are your friends.
• Communicate and identify shared elements and logic. You can hold off on designing them right away, but at least identify who will work on them. For example templates may all need the same approach for analytics, navigation, and shared elements. Report any "global" items to the team you come across (e.g. "I have link requirement that I think applies to everyone").
• Get consensus on connecting interfaces, formats, and approaches. Creating a dozen Component Templates based on tentative markup creates a lot of rework when you have multiple last-minute changes along the way.
• Though seemingly related, don't confuse the fast and flexible Top-Down Approach with agile. Because SDL Tridion separates content management from content delivery, you could still follow agile's tenants for iterative development, collaborative design, and ready-for-release check-ins and builds where you build bottom-up, top-down, or sideways.

If you're new to Tridion or find the requirements change faster than you can create schemas and templates, consider having those responsible for the changes own the corresponding building blocks. Given a little training and maybe some "change leadership," designers could update layout TBBs, developers can create CMS-side code and code TBBs, and the right people can create keywords, components, and pages. Groundbreaking, I know.

Regardless of approach you'll hopefully end up with managed content.

Got thoughts on agile development with Tridion or the Building Block dependencies? Leave a comment, or better yet, share in a blog post. I'd love to hear about your experiences with the tried-and-true approaches as well as the cutting edge in implementations.