Tridion BluePrinting Use Case

I prefer the acronym WCMS. Coming from a Web development and IT background in a healthcare-related company, "CMS" means something completely different.

Here's a use case for Blueprinting and localization for websites that need to be reviewed by external reviewers such as Centers for Medicare & Medicaid Services (CMS). I had a chance to run the scenario by Tory Johnson, a Tridion Professional Services consultant (who earlier identified better ways to use the Tridion 2011 Criteria Objects). He gave me the impression that my following setup might work (or at least confirmed I know a little bit about BluePrinting technology), but do see caveats below before trying this at home... er work.

But first some background and terminology.

Tridion BluePrinting

The Tridion BluePrint model allows developers, designers, and content owners the ability to create publications (collections of content, templates, and functionality) that share (think inheritance... sort of) content, style, or behavior. The BluePrint consists of parent and child publications where content is shared down from parent to child. BluePrinting may mean different things to technical audiences versus the business.

The Tridion localization feature is very important to BluePrinting.

Content Localization

Localization is a Tridion feature that lets you create a "one-off" version of an item, that is then shared down the BluePrint hierarchy. This item will have (almost*) the same Tridion content management identifier (tcmid), will be linked from the same components, but will no longer (automatically) share the same content from its parent publication. After localization, the item will keep its own history and can be updated independent of its parent item.

*The publication part of the 3-part ID will differ between the shared item's tcmid in different publications.

BluePrinting plus localization makes Tridion a strong fit for scenarios where you need to deliver content in multiple languages or targeted to different regions. But it's more than that, a well-designed BluePrint lets teams take the "component + component template = component presentation" concept all the way up to the publication level, where "Content Publication + Template Publication = Website Publication." Read on for an idea I worked on for a colleague (and yes, he gave me that "what?" look after we set it up).

Review Scenario

If you maintain a near-duplicate website for internal or external review, a simple solution is to simply publish content to the site. When it is approved, you can then publish this to the live site.

There's a problem, however, if you have a site that needs to be more than just website preview or user acceptance testing.

For Medicare (CMS) reviewed websites, there are restrictions on what content can be released. In this type of controlled scenario, only minor typos and select non-reviewed content are published to the Live site without CMS approval (from the technical side I'm not really sure what needs to be reviewed--the business side knows more, but this setup lets them pick-and-choose what and how things get updated).

Rather than having editors use versioning or edit history to control what gets published, a separate publication, higher in the blueprint can be used to separate the new yet-to-be-approved changes for the next iteration from the current live site.

Assuming a year-long iteration that begins in the New Year ("1/1 as a date is a hard deadline for many health or benefit-driven programs"), we start off with two publications:

• Review Website Publication, which is a parent of...
• Live Website Publication

In actuality we wouldn't use "Live" for the publication name since it might be confused with the live www. website or with the "Live" publication target (which publishes to the live www. website). Since the BluePrint is listed alphabetically, you might have names like "0035 MySuperMedicareProgram (CMS-Review)" and "040 MySuperMedicareProgram."

When the blueprint is first set up both sites are exactly the same. Review (this is not Preview) and Live have the same content shared down through the BluePrint.

1. To create the CMS Review site, everything is set up the same as the Live site and all currently Live content is published.
2. To make changes for approval for the next year, content owners determine the type of change:

New

Proposed content, new layout, and major changes can be made by first creating the proposed change (or localizing the Live Website version first if the items exist) and then publishing the changes. These new items shouldn't be published to the Live Website until approved and any localized items will keep their old approved versions unchanged regardless of how many revisions the Review Website goes through.

Fix in Both

A "must fix immediately" minor typo can be updated in the Review publication and published from Review and again in its child publication. If this typo fix applies to something that has been localized, content editors would update the Live Website localized item, then manually make the same correction to the Preview Website "proposed" item as needed.

Year-End or Approved

When CMS (Medicare) approves a change for the Review Website Publication, the content owners and their developers would:
1. publish new items that don't have shared localized versions
2. unlocalize items in the Live Website Publication, which will wipe out any localized edits and replace the items with their Medicare-approved versions
3. publish the now-matching (unlocalized) components to Live and start over with both sites matching
A content clean-up and a review of which items never received approval might also be helpful after the go-live date. :-)

Issues and Caveats

I helped set this BluePrint change in a production environment, but have not seen how it works in practical use (I've since changed teams a few times and haven't heard any issues--which strongly suggests it's not being used). The concept is sound, but I suspect there would be issues with the following.
1. Training -- when should you localize (probably everything in the Live Site at the start of the year or iteration, but always before an edit)?
2. Troubleshooting -- with content coming from two or more places, the ability to localize at different levels, and the fact that content owners sometimes forget to publish, I can imagine a few "hey, my page doesn't match my last change" type emails.
3. Support -- a Tridion BluePrint really needs to match the needs of the content. Apparently some organizations want to set up a BluePrint to match an org chart (really?), which is friendly fodder for another blog post. Like any other powerful and flexible technology, BluePrinting shouldn't be underestimated and it isn't something typical business analysts, programmers, or other support roles would understand right away. It's not quite inheritance, nor do the terms "share" and "localize" do it justice.
Watch out for confusion or misunderstandings around:
• Preview vs Review
• Tridion Publication versus Website
• The word "Publish" (component? page? .NET site?), but this isn't unique to BluePrinting!
  Terminology (feel free to point out any inconsistencies above)

If you have internal content owners publishing content for Review's Preview before it gets published to Preview's Live for CMS review of the WCMS-enabled content before it ever goes out to Live's Preview and Live's Live site, someone is bound to become confused.