Feature-Driven CMS Development Part 2

In my last post I described ways to manage CMS-influenced features. Before offering a field to authors, confirm it's at the right context in the content model. Authors shouldn't need to manage fields that are always the same for a certain type of content. Also, you can manage current and future features with keywords rather than as new schema fields.

Everyone manages content. Not everyone manages the definitions.

The difference is subtle and you won't realize any technical debt until a few years with a given CMS. But a Category of boolean features beats "Yes/No" options over time for large sets of content (Categories make features searchable and extendable without schema changes).

Let's measure the impact of this and other content definition scenarios in your Content Management Organization. The use case here is whether or not you should re-use a schema (for example, "article" or "product") or look to create a one-off because it's easier for now. This also applies to adding something that probably should be "templated."

Examples include:

• positional and rendering requirements for content (e.g. a field to select a layout like 1-column or 2-column)
• a field for a site-specific feature (e.g. AddThis in the previous post)
• unstructured markup or code in CMS fields (e.g. a .NET control or Java tag)

Impact

As a content management organization, you have a better understanding than anyone else for how your websites evolve in terms of content, design, and functionality. But take a step back to consider the impact of good content architecture practices and strategy.

You wouldn't automatically duplicate database fields, create new tables, or copy existing databases for slightly different applications. Why do the same with content definitions (even if it's as simple as copying and pasting a new definition in the CMS)?

Initial investment for the new schema or schema-specific change: Free and Easy.

• Content Creation: Number of components per definition
• Development Costs: One or more new templates per definition, possibly "copy & pasted"

It's tempting to take on this technical debt by creating a "one-off" definition. It's almost zero investment in terms of development, and the initial creation of content would be the same whether you re-use and consolidate schemas or not.

Over-time, you may: Accrue Technical Debt.  

• Content Maintenance Rate: Number of edits x edits per time frame
• Technical Maintenance Costs: Increased by n schemas times m templates

It's hard to see the technical debt accrue and authors might not complain, but there are both tangible and "soft" business impacts here. Look specifically at:

• Time, training, and support for new fields (e.g. "when should I set AddThis?")
• Cost of errors seen in increased support costs and possibly decreased online credibility
• The linear overhead for each new schema or site you break from your standard definitions

This may compound as you add options in an attempt to personalize a poor content model. For example, you might consider two versions of each page for logged in or public users rather than handling changes at a component or content level. Rather than limiting changes to certain fields, this will quickly grow to four or more pages as you add more options.

At some point you may consider paying off this technical debt.

Technical "pay-off" to fix this technical debt: Initial "Mistake" + Accrual Rate x Time.

This includes work across the team. Copy & paste or merging strategies are easy to execute, but hard to fix.

• Code or manual work to un-publish, synchronize and/or "merge" content, then republish the changes
• Retraining costs for authors and developer s
• Updates to instruction materials, screenshots, and any custom training environments

Explain these trade-offs in terms of business costs and maybe full time employee (FTE) hours, preferably in a visual format.

The following hypothetical example compares a single schema versus three schemas. Both scenarios include a pair of templates per schema and separate development needs. The totals are cumulative and I chose an arbitrary 10% each for maintenance, training, and testing. Read the numbers on the left as minutes, hours, or days; easy choices today have long-term costs tomorrow.

Past Performance Can Predict Future Challenges

Also use examples from your company's history. What happened when you:

• Changed from HTML table layouts to div-based ones?
• Created a Flash-version of the site? Then later removed it?
• Addressed accessibility?
• Started your mobile approach?
• Made a recent change to unstructured (rich text) content?

Examples of technical CMS debt:

• Adding design choices to schemas that should be templated
• Treating dates and other "selectable" fields as text (what happens when an author's name or title changes?)
• Placing content-related fields at the page level or other component (which means these must always travel together)
• Choosing very implementation specific approaches, based on technologies or sites that may very well change in a year or so
• Skipping good defaults such as defaulting a folder to a specific schema
• A good default might cost seconds to set, but makes future selections cost you nothing for a given folder
• No default means authors choose for each new component in that folder (multiply the number of new components by the few seconds it takes authors to choose). This isn't much but accumulates across all folder and choices that lack a default.

Some debt is okay, maybe even good because it lets you handle the one-off, schedule-driven scenarios. But be wary of creating several thousand pieces of content or more based on a misguided content model.

In the last post in this series, we'll revisit ways to manage CMS fields in a way that scales. At some point your content model will change and evolve, it's a good idea to manage both content and definitions.