That Should be in the Product!

Alex Klock, of Razor Mediator fame, presented his work on Content Bloom's Alchemy GUI extension framework at this year's SDL Tridion Community Award (MVP) retreat (2014 video). As the community releases, and even re-releases, SDL Web (Tridion) extensions, some might ask, "why isn't that already in the product?"

There are a lot of business decisions from legacy requirements, to market desires, to customer needs, to an entire development process that drive what's actually in the box. I can't speak for what's in Tridion today (maybe tomorrow), but I respect the history (and love the product!).

But since I'm joining the Product Management, making it fair game to ask, let's explore some ways to evaluate product suggestions by looking at BluePrinting and Content Management System (CMS) development.

The following diagram has a Y-axis for Publications (roughly SDL Web-managed sites) and an X-axis for CMS environments. DTAP refers to the CMS environments of Dev, Test, Acceptance, and Production. Combining the varations give us this table and a graphic:

Publication (site) variation	DTAP variation	Example
Different per publication	Different per CMS environment	Site system settings
Different per publication	Same across CMS environments	Language Codes
Same across publications	Different per CMS environment	CMS Instance configuration
Same across publication	Same across CMS environments	Organization-specific settings

Notice a few patterns in this matrix:

• Content manager, "single source," and some developer-related settings tend to be the same across environments. Building blocks like Schemas, Component Templates, and Components for headers and footers are also consistent across the DTAP environments.
• Delivery-side configuration varies between sites or Publications, though many need values for Language Code or Site URL.
• Settings that vary across both DTAP and Publications start to multiply. It might help to have easier ways to manage the delivery-side topology of a given DTAP environment (that's a hint).

Plotting various managed elements, including configuration in Tridion Component or Metadata, creates a snapshot of a given organization. Add a Z-axis to represent different customers and you can evaluate when something applies universally, in which contexts.

For example, if all customers used certain Publication Metadata fields with the same options (e.g. language codes in the format of xx-YY where xx is language and YY is Country/Region) across all their environments, it would make sense to add "language code" as a Publication product feature, rather than an implementation option.

Before wanting something in the product, you want to be aware of how it will function across websites and DTAP environments. Adding additional dimensions such as "type of user" or "size of implementation" can further help analyze a request for "productization."

For a given Alchemy 4 Tridion module (or any extended SDL Web functionality), considering who needs what functionality and where (in which publications/environments) helps address "why something isn't in the product" and maybe even "when" something will be. Even knowing all of this still leaves the interesting question of if we should put something in the product (and even who's the right people to build some functionality, but that's a different post).

With the "coding" part of the retreat done, I want to say thank you to Alex, Content Bloom, and the SDL Web MVP participants. Community contributions (and use) can highlight what features are important to you, your colleagues, and customers. I've been a fan since I joined the community and will continue to support your efforts in whatever role I play.

Everyone else, have your GUI extension developers or consultants check out Alchemy 4 Tridion as Alex and Content Bloom introduce this framework to the community!