Rationality in CMS implementation planning

A few weeks ago, my 14-year-old daughter had a weekend volleyball tournament. We were issued wristbands to get into the venue. On the third day, she forgot her wristband. The woman guarding the door wouldn’t let her in.

I pleaded her case: “She’s a teenage girl. She’s in uniform. She has her bag with all the gear to play.”

The response: “Anyone could dress up like that to get in for free.”

Um, what?

I allowed discretion to my annoyance, but what I wanted to do was ask the woman:

“Who would actually do that!? What teenage girl in the world would find a uniform matching a registered team, then dress up in it, and carry a bag of gear, solely to avoid a $10 fee to get in on the last day of a tournament? And assuming this happens on some rare occasion, does it possibly happen enough that this is a situation we have to be actively guarding against? Are there not other, more important things we could be doing?”

I had nothing against this woman personally—she was just doing her job. But this is what I call “majoring in the minors.” She expended a lot of effort to prevent what I can only assume is fairly non-existent threat. The entire thing just stank of inefficiency. Couldn’t this energy have been better applied somewhere else?

Any project—be it a volleyball tournament or a CMS implementation—has a variety of work items into which we can invest effort. All work items are not created equal. The mark of experience in any arena is someone who can judge which work items are worth the effort.

I feel like we’ve lost this when it comes to content management. We’re pursuing management strategies for content and elements that are simply not providing any benefit. As an industry, we need to become more rational about our CMS planning, and how and what content we decide to bring under management. We need to break free of the idea that everything needs to be managed by the same system.

Pace layers and content velocity

Last year, I read a book called How Buildings Learn: What Happens After They’re Built. It was a fascinating review of how buildings change over time. You might not automatically realize it, but buildings evolve and grow throughout their lives. A building that’s demolished in exactly the same state as it was built is rare. Over time, a building is re-modeled, re-arranged, expanded, and improved in response to the requirements and conditions of its tenants.

One of the concepts in the book is the idea of “pace layering.” Architect Frank Duffy articulated the fact that different classes of objects in a building move at different speeds. He claimed there are six “layers” that move at different “paces.”

They are:

• Site: the ground the building sits on
• Structure: the foundation and structural components
• Skin: the outer surface or facade
• Services: the underlying electrical, plumbing, and HVAC
• Space: the interior walls and the spaces they create
• Stuff: the furniture and other fixtures

These require different levels of effort to change. If you want to rearrange your office (“stuff”), you maybe just need a co-worker with a strong back. If you want to rearrange the very ground the building is built on (“site”), you need an earth-mover.

Additionally, changing the more base layers brings different risks than the more superficial layers. If there’s a glare on your desk in its new location, just move it back. However, if you don’t understand how erosion or drainage might affect your building, then step away from from the bulldozer.

In fact, the first two layers—site and structure—are generally considered unchangeable after construction. Re-pouring a foundation after a building is sitting on it is probably a good way to destroy the building, or—at the very least—your bank account.

Layers three through six are far less (wait for it…) set in stone. Buildings get new siding or facades every couple decades (“skin”), the average life of a furnace might be 15 years (“services”), interior walls get rearranged every couple of years (“space”), and sometimes furniture changes weekly (“stuff”).

We automatically accept that these changes will be managed differently. We don’t call a contractor to move a desk. We don’t call a friend to re-pour the foundation. Somewhere in the middle, we have a variety of roles to help us—we have a handyman to help us with the HVAC, an interior decorator and carpenter to help us re-arrange the walls, etc.

Content in a website isn’t much different. All content is not equal—it changes at different speeds and requires different levels of effort. Your company logo is quite a different animal than your newsfeed. You might publish news releases multiple times a week on short notice in response to quickly-changing events. Your corporate logo, on the other hand, is deeply tied into your brand identity. Some companies have had the same logo for over a century, and it’s not likely to change anytime soon.

We can give this characteristic of content a name: “content velocity.” This encompasses two things:

1. How often content changes, be it weekly, yearly, or never.
2. How much lead time an editor would have to make a change.

News releases have a high velocity on both counts, and your corporate logo is on the other extreme. You may find out the CEO resigned 10 minutes ago, and you have to have a news release out in the next half hour. On the other hand, a brand identity change happens twice a decade and you can see it coming a long ways off.

Why do we try to manage these things in the same way? Differing velocities allow for differing management strategies.

Managing for velocity

We can manage our content using different methods of varying immediacy and sophistication. Too often, we try to manage these types of content using the same processes, paradigms, and tools.

Consider:

• Content can be managed real-time out of the CMS itself. Indeed, this is what we think of when we plan or envision a CMS implementation.
• Content can be “static,” from the file system. Compared to a high-end CMS implementation, this can seem almost archaic.
• Content can be sourced from some other system—a dedicated system for managing content, an RSS feed, a SQL database, etc.
• Content can be hard-coded into a template that’s otherwise used to render content out of the CMS.

Any one of these achieves the same end: content delivered to the end user. Where they differ is in effort required to implement, and effort required to manage. In general, those two variables are inverse—it’s awful easy to just copy and reference an image on the file system, but changing it involves access to the server and pushing files around.

Let’s go back to the construction analogy and How Buildings Learn to point out that the walls of a building are not created equal. There are interior walls that are meant only to partition spaces. Then there are load-bearing walls, which both partition spaces and perform the not inconsequential task of holding the roof up. You can move partition walls yourself—get a sledgehammer and just go nuts. But load-bearing walls can’t be touched without calling a contractor, getting a permit, etc.

Where the load-bearing walls are placed in a building will vastly affect how that building can morph and change in response to the needs of its owner. Some buildings are gloriously flexible, while others have walls and pillars that have to stay where they are, under threat of structural collapse. When an architect designs a building, they make design decisions about where these load-bearing walls are placed. These designs can reverberate decades later when someone attempts to change the building.

The same can be said of a content management implementation. Partition walls are content that is “editorially sourced,” which means it’s content that an editor can create, change, or delete at will. If an editor wants something new and different, they can grab a sledgehammer and go nuts.

Load-bearing walls are content, settings, and functionality that are “development sourced,” which means they are something that a developer put in place at the code level. Most of the structural, layout HTML is development sourced. The search box and text on the search button are usually development sourced. The CSS and layout styles are usually development sourced.

These items are load bearing. If an editor wants to change these things, they need to call a developer and endure the ensuing cost and complication.

So, why don’t we just editorially source everything? Should we, as developers, seek to allow every single last text string, HTML tag, and CSS rule to be modifiable by editors? Well, no. Few buildings are made of purely partition walls. Some walls have to hold up the roof.

Items are development sources for multiple reasons:

• Time and expense—Allowing editorial sourcing for every last scrap of content is expensive. It takes time and budget to do this implementation.
• Complication and instability—Development-sourced content is usually more stable. A logo read from the same place on the file system every time has much smaller opening for error than a logo managed by editors and read out of the CMS. Editors make mistakes. Systems malfunction. Sometimes, the increased control comes with a decrease in stability. Many an editor has inadvertently deleted or changed something that was load-bearing, usually to disastrous effect.
• Training—Lower velocity content is changed less often. An editorial process that happens rarely is one that editors are far less likely to remember when they actually need to do it. Training issues on something an editor does twice a week are rare because the process gets ingrained in the editor’s memory. Employee turnover being what it is, content that has a velocity approaching zero might never be changed by the same person twice, which means that process will always begin with a phone call that starts, “I don’t remember how to do this …” Your CMS has become a support call generator.

The decision of when to source something editorially or developmentally should always be based around ROI. If you have to spend five hours implementing management around the company logo, are you likely to get those five hours back? How many times does that logo have to change before the organization has saved enough from the management tools to cover the cost of the original implementation of them?

Fact: there is some content where management provides no ROI, or even negative ROI. When you consider the total costs to implement it, manage permissions around it, create workflow for it, guard against stability issues caused by it, fix those issues when they occur, and train editors how to manage it, there is absolutely content that actually costs money to bring under management.

Fighting irrational uniformity

What we’re fighting here is an irrational drive for uniformity. CMS customers generally want all their stuff in the same place. There’s an implicit—and sometimes explicit—desire for uniform management of all content. We pursue “single sourcing” and “vertical integration” of all our content. Vendors fuel this by claiming they have the “one tool for all our content needs.” We view software as our savior—all we need is a better technology platform, and all our problems will be solved.

Any deviance from this dream is considered a weakness. You can’t manage everything from the same CMS? Well [scoff], clearly either the tool or the implementation was flawed and has fallen short of the goal. In most implementations, this is accepted with muted resignation and the background hope that we can bring that content under management eventually—we pursue a White Whale of “completeness” that we’re not likely to ever catch.

(It’s worth noting that this state of affairs is perpetuated by both vendors and integrators. Both of them want to maximize their revenue per project. So a vendor is going to build as many tools as it can and encourage complete dependence on them, and an integrator is going to content manage everything to burn hours and pump up their invoices.)

We have to start drawing a balance between these two opposing forces: the ideal of giving editors total control, and the investment, complication, and instability introduced by doing so. In some cases, the ROI just isn’t there, and projects get bogged down in technical problems around content that isn’t benefiting much from increased management. Every implementation decision should start around the idea of whether content of Type X even needs to be managed in the first place.

Decisions like this are invariably dependent with what ongoing relationship an editorial team will have with a development team post-launch. If there will be none—meaning the editors will be completely on their own post-launch—that will drive a completely different set of decision criteria. But I’d wager this situation is not common, and certainly not desirable. What would be more efficient is for an active development relationship around the principle that the initial implementation can be “light” and intended to manage high-velocity content, with access to a responsive development team for lower-velocity content.

For example, let’s say our project is a microsite for a new product line. In examining the content, we find that our goal is to provide some background information around the product, and have a series of updates about its progress that will be displayed in a feed and emailed to people who sign up for them.

Consider velocity: the background information about the product is “slower” than the news updates. Not only is there less of it overall, but changes to the core purpose of the product could be seen much further off than an update around when the product will ship.

This is clearly pace-layering. The newsfeed is moving at a much faster pace than the more static marketing information. Do we need to manage them the same way?

Traditionally, we’d stand up an entire content-managed website for something like this. But what if we critically examined the content and decided a templated site from a static site generator (Wyam, for example) was enough for most of it?

The news updates could be externally sourced—edited and managed in a cloud solution like Contentful or Gather Content or even Office 365 (via Interchange or any number of other abstraction layers), then pulled into the site through RSS (we could even do this in JavaScript, avoiding server-side development entirely). If we decide later that Page X needs more management tools, we can cross that bridge when we come to it, because we’re going to maintain an active, responsive relationship with the development team.

The result would be a faster, more responsive development project with fewer deployment and stability issues. No, we didn’t content manage everything, but what if we stopped looking at that as a shortcoming and started considering it a strength? We spent less time and budget on content that simply didn’t need full management. The variability and velocity of the newsfeed is the main purpose of the website, and that’s where we put the majority of our time, budget, and effort. We didn’t major in the minors, we majored in the majors—we spent money where we needed it, at the greatest benefit.

With the current crop of static site generators and cloud CMS tools, the initial implementation of this site is drastically reduced. Editors certainly have less control, but this is a balance which, carefully considered, would have more benefits than drawbacks.

Rational decision factors

In practice, we need to interrogate our wireframes with rational circumspection, avoid an irrational belief that content not in our CMS is somehow an implementation failure, and set expectations to this effect in our editors. We don’t have to be perfectly uniform. Heterogeneous content management is not an error condition.

When evaluating a particular element and deciding how to manage it, here are some questions we should ask:

• How often will this content change? Indeed, will it ever change? A lot of effort has been put into managing content that isn’t likely to ever change. Are we solving a problem that doesn’t actually exist?
• How much advance notice will editors have of this change? Enabling real-time content management can involve implementation expense. Content that offers a long lead-time on changes can perhaps be moved to a different management paradigm that has less implementation time and costs.
• How much of an outlier will the management process around this content be? Will it roughly match the process editors use on everything else, allowing them to use the same mental model and training? Or will it be an outlier, requiring them to re-learn each time?
• Is this something an editor should change on their own? Are you going to have to lock the content down to a very small subset of editors to guard against mishaps? Or even allow access only to developers who (ironically) use the CMS to make the change?
• Can editors perform an end-to-end change of this content on their own? If a webform talks to some server-side process, can an editor even make a change without a developer having to match that with a code change? If so, then what’s the value of editorially-sourcing the form in the first place?
• Should we developmentally-source this content? Would it be so bad to have a static asset on the file system for media that isn’t likely to change much?
• Should we externally source this content? If our editors know Sharepoint, could we just let them manage news items there and pull them into an otherwise static site via an API call? (Even some programming logic can be externally-sourced: consider InRule, a business rules engine.)
• What relationship will editors have with their development team post-launch? In exchange for a lighter initial build, would it be worth it to increase the intimacy and immediacy of this relationship to allow development-sourcing for some content that we’d be otherwise inclined to editorially-source?

The answers to these questions will never be uniform. They’re very contextual, depending on factors like the skill of the editorial team, the long-term plan for the site, the ongoing relationship with the development team, etc.

What these questions offer is perspective. If nothing else, they’ll guard against knee-jerk reactions with are ultimately not advantageous for our projects.

In writing this, I’m not trying to roll back or minimize the wonderful advances we’ve made in content management over the last decade. But I am trying to fight back against the idea that a CMS is, in itself, the savior of every project.

You do not need to surrender your entire project to a CMS and go to heroic measures to shoehorn everything into it. We need to start evaluating content in terms of ROM—Return on Management. What is the cost of managing Element X or Content Type X or Function X, and ask ourselves if that’s the highest and best use of that time, budget, and skillset.

Additionally, we need to avoid irrational uniformity. Something is not necessarily “better” because we managed to wrap a CMS around it. If you free yourself of the confines of a single CMS, you might find that heterogeneous content management can open up broad possibilities for integration and rapid development. The future is likely more distributed than monolithic.

If all you have is a hammer, pretty much everything looks like a nail. Next time, let’s dig a little deeper into our toolbox before taking that first swing.