Matching Software Licensing to SDLC

Update: Thanks, Jeremy for the clarification on terms. See updates below and a new graphic to demonstrate the high-level "modularity" built into SDL Tridion.

One of the things I always wanted to get a chance to do was learn more about the Tridion templates that use template building blocks (TBBs). Originally called Tridion compound component templates (until someone must have mispronounced it in a critical sales meeting), these modular templates... I first heard of compound templates when I helped a company purchase Tridion R5.3. This modular templating approach lets template designers mix and match different pieces of re-usable functionality. This brings the modular approach full circle.

• you can re-use whole sets of functionality (Tridion BluePrinting via parent and child publications)
• you can re-use schema pieces (embeddable schema in regular schema)
• you can re-use content pieces (components on a page), and now*
• you can re-use template pieces (template building blocks in compound component templates)

*Modular templating isn't the new hotness anymore in the year 2011.

In my opinion, the hardest part about using creating re-usable classes in this "third type" of template development isn't the technology. It's getting an organization's IT operations (IT Ops) group, their development team, implementation organization, and Sales on the same page, which is far from an easy task.

Right Info. Wrong Environment.

I was once able to get my hands on a guide to setting up modular templating via .NET assemblies, but at the time, the development machine was off-limits for development. It almost sounds funny when you say it out loud, but not giving access to the DTAP servers or installing client-side software (such as an IDE) is typically a good, and common, IT practice.

This means developers using their laptops and/or virtual machines (VMs) for creating and debugging code may lack development-versions of production systems (like the Tridion Content Management Environment or CME). I'm not yet clear if remote debugging is a practical option.

Unsolicited tip: If you're considering a large software purchase for any system that includes the term "API," "IDE," and/or "Visual Studio" or "Eclipse" integration, confirm the total licensing costs and get a demo or description of how "typical development" happens with the package. Be sure to get developer-friendly licenses (especially if you have... well developers).

The Situation for Would-Be TBB Developers

A typical programmer with access to the Tridion templating objects via a complete IDE could do much to further the craft of building template building blocks. We might even get a deeper discussion of more technical questions on stackoverflow on TBB or maybe extensions.

Currently, though, we have the following:

• Atypical setup. IT Ops does not want development or client software on its servers.
• Lack of awareness. Developers may not be aware of or understand the benefit of, or even impact of not having, a Tridion CME to work with (no TBB developed as a C# assembly or no internally-developed GUI extensions, which may not be that bad)
• "Oh yeah" moments post-sale. The implementation organization consisting of technical consultants may not realize their developer counterparts don't have access to a VM of the CMS. "Oh yeah, sorry I forgot you don't have SDL Tridion on your laptop."
• Poor buyer or even Sales do not always have access to each of the above groups, nor would they readily appreciate how this impacts licensing; and if they did, it might not change any existing pricing options.

But if someone involved in the sales process for Tridion or similar software package, from whatever side, reads or remembers this...

Please consider the developer needs when selling licenses, especially if they could benefit from having the CMS available on a local development machine (or VM).

The Fifth "SDL Tridion" Environment (is not my idea... doh!)

If this is a standard practice, move along, nothing to see hear and thank you for solving this. If not, I don't have an answer (just yet), but know it's a combination of communication, sales, and oops... I should have remembered UrbanCherry already brought this topic up over a year ago! Go ahead and read through his well-reasoned evaluation and suggestion. I'll wait.

Now that you're back, and until there's an official SDL Tridion Developer Edition, I think the Tridion technical community can do three things:

1. Explain, provide examples, and demonstrate exactly what TBB developed as a C# (.NET) assembly means to Tridion (along with all the other useful things you can do including GUI extensions). The target audience is the researcher or developer considering Tridion's purchased.
2. Explain, provide examples, and demonstrate how remote debugging could be used to develop C# TBB assemblies as wells as GUI extensions without needing the CMS.
3. Love and appreciation your opportunity! Not everyone has access to play, learn, or work with very-expensive-software.

Software sellers and buyers should confirm the development process and license impact (see Nivlong's Observation of the Inverse Relationship Between Physical Size of the Software Licensing Unit and Total Cost™)  before signing the trifecta of procurement documents (statement of work, order form, and master services agreement).

Buy a good fit with room to grow because it's not about the most fully-featured software package nor even the cheapest. It's all about a well-fitted solution. Goldilocks was right to find the right-fit (except when she started breaking chairs... leave the breaking of stuff up to a qualified professional).