Problems, Patterns and Why Every CMS Thinks It Knows What You Need

Let’s start off with a premise –

Generally speaking, a CMS is a system to manage content that doesn’t exist yet and that it can’t know anything about at the time the CMS is designed and built.

So, Episerver and Sitecore and Drupal are all “solutions in theory,” designed and built to manage content and build websites that do not exist at that time. In their unimplemented, unplanned state, every productized CMS is theoretical. It certainly hopes that it can manage your content, but it doesn’t know this, because it knows nothing about your content.

Why am I talking about this?

Because I’ve gone on-record before as opposing the building of custom CMSs for any reason:

• Why do too many developers love to build CMS from scratch?

• Never Fall for a Custom, Hosted CMS. Ever.

And then the other day, I tweeted a screencap of two slides of a deck I use when teaching “Introduction to Content Management” in the content strategy program at FH Joanneum.

The lecture is on “Acquiring a CMS,” and it presents the four major models of how one gets a CMS. The fourth model is to “Build Your Own,” and the next slide just says “Don’t.”

Yes, this is a pithy witticism (“Thank you, I’ll be here all week, tip your server”), but is it universal? Meaning, are there some situations when you should build your own CMS? (To be fair, a few slides later I do, in fact, list some reasons when it makes sense.)

While most of the responses to this tweet were positive, someone did call me out on it. Pete Czech from NP Group wrote:

Maybe WCMS but I can point you to a ton of use cases where custom makes sense. Maybe ya need to add some context to this claim…

And I felt badly about this. Because in addition to a “pithy witticism,” it was also a gross generalization, and I hate those. My LinkedIn profile literally reads: “I believe there are very few absolutes in this industry,” yet there I was tossing one out.

And Pete isn’t wrong. There are use cases where building a custom CMS makes sense. I just think it’s exceedingly rare.

Why? Patterns.

Question: how can any product fulfill your needs when it doesn’t know you? How can a coffee maker know how you want to make coffee?

Because most everybody makes coffee the same way. Making coffee is a well-known thing – you heat water and strain it through crushed coffee beans. This general process is so common that products can be created to automate it because a manufacturer can guess with a high degree of accuracy what you want to do. There are patterns to making coffee, and a coffee maker is just a codification of those patterns.

Usage patterns have a range of variability, of course. People might make coffee a little differently. Maybe you use two scoops of grounds, and I use three. Perhaps you put hot water in the pot, and I start with cold water. But for making coffee, the range of patterns is pretty narrow, and coffee makers can handle this confined variability just fine.

Sure, some people might like a french press or a pour over (weirdos), but coffee maker manufacturers have just decided that those people are outside the range of the patterns they want to support with their product. They might try to convince those people of the advantages of adapting to the more mainstream pattern (“It’s so much easier! People won’t call you a hipster!”), but they’ve otherwise accepted that the “pattern space” their coffee maker encompasses is enough to capture the share of the market they want.

The management of content falls into patterns too.

• Consider content modeling: we generally divide out content into types, and those types have properties, and those properties have data types (ex: our news article has a publication date which is a datetime value).

• Consider approvals: they’re usually always linear, and each step can either be assigned to a single person, or a group of people, one approval from which is enough to move it to the next step (ex: we need the managing editor to approve this, then one person from Legal…)

• Consider URL management: each content object usually has am individual URL segment, which is combined with other segments based on spatial or type context (ex: the full URL of an object is the concatenation of all of its ancestors from the root object towards it)

Patterns are just problems that became so common we developed generally useful methods of solving them, to the point where those methods became accepted by the larger industry – people got sick of re-solving them, so someone rolled them together into a solution, combined it with solutions to other common problems, then bundled all that up as a commercial product. It’s kind of like evolution: some solution worked and got carried forward.

To be absurdly general: software is just a bundle of solutions to problems that people often have.

This means that no existing piece of software was created to solve your problem. How could it? When it was built, the creators didn’t know about your problem. But they knew about problems like yours, and they’re assuming that other people in the future will have the same problems, which is what rolled forward into you having a problem and this software magically solving it.

When you’re considering the “fit” between your problems and existing software, what you’re necessarily doing is forming a mental Venn diagram and determining how well the packaged software overlaps with your problem set. There are a few outcomes to this analysis, from positive to negative:

1. The system solves your exact problem, as produced. Your problem is so common as to be considered a pattern, and it’s already been addressed.

2. The system cannot solve your problem as-produced, but it could be modified or configured to solve your problem. This is where extensibility, APIs, and add-ons are helpful. More open, “platform-y” systems can pivot in various directions to solve more problems. (This is also where pure SaaS systems can be problematic.)

3. The system cannot solve your problem as-produced, but your underlying need is a little flexible, and perhaps you could modify that need a little (ex: through an organizational or process change) and then the system can solve your problem.

4. The system cannot ever solve your problem but this doesn’t matter because your problem is (a) actually not that relevant, or (b) its relative importance doesn’t rise to the level where it should outweigh the other advantages of the system.

5. The system cannot ever solve your problem, and your problem is real, relevant, and significant.

Clearly, what any vendor is trying to avoid is #5. When it comes to your problem, every vendor is going to claim their system already solves it as a pattern (#1) or can solve it with some small and routine tweaks (#2), or that your problem can be solved some other way (#3) or that it’s just not a big problem to start with (#4).

If the vendor is stuck at #5, then they have a strategic decision to make: is this problem a pattern that we expand to solve in the future? Is your pattern common enough that they need to care about it to secure future business?

The answer to this question changes over time – lots of patterns that are addressed in the current generation of products started as weird problems that became less weird as potential customers brought them up again and again, often in response to changes in their market and business environment. Being aware of these trends and making decisions about what problems are evolving into patterns is fundamentally what the discipline of “product management” is all about.

Other vendors are happy to walk at #5. They say principled things like, “We’re not trying to make everyone happy” and “We have a narrow scope,” and they just pass on the sale.

This works, to a point. But, eventually, they might find themselves walking away from too many sales, at which point they’ll expand their “pattern coverage” through new features or though an acquisition (increasingly the latter).

Which brings me back to a custom CMS. Should you do it?

My non-flippant answer is this: only if you can demonstrably prove that your usage patterns are so specific that they’re not adequately covered by existing products (and, by usage patterns, I also mean non-usage stuff, like budget, licensing, hosting, etc).

If you walk away from known solutions to patterns, you need to acknowledge that you’re losing a lot of accumulated wisdom. An existing CMS is a massive pile of experience with a UI. Most any CMS has evolved around the solving of patterns that came up again and again, to the point where bundling a solution to them was helpful.

Also worth noting is that, in the world of CMS, the word “custom” is loaded. There’s a spectrum along which a CMS can be custom. How often is something totally custom, and how often is it a custom solution built around an existing framework? I suspect the latter is far more common.

For instance, if you have some odd delivery requirements (“We want to send content to little projectors strapped to the bellies of mosquitoes!”), that doesn’t mean you have to re-invent the entire technology stack. Just because one part of your requirements falls outside any known pattern, doesn’t mean they all do.

The content delivered by those projector-laden mosquitoes is still going to have to be managed somewhere, with modeling and workflow requirements that likely fall solidly within the known pattern space. Thus, start with a headless CMS that patterns the things you do share with the rest of the world, but keeps its nose (proboscis?) out of the things you don’t.

(Speaking of headless, patterns are why I think the market for headless CMS will change remarkably as it matures. Right now, people are rolling their own delivery layers. But, eventually, they’re going to start writing their own delivery solutions over and over to the point where they think, “Hey, I’ve done this enough times that I think I know enough to turn this into a product,” and thus launch the Website Builder Era of headless CMS. How many times do you solve a problem, before you think, “Hey…I’ve seen this before. This might be a pattern!”)

(Don’t look now, but the Headless Website Builder Era might already be here: Netgen Layouts, ContentPepper, and others, I’m sure…)

So, to Pete and anyone else that was annoyed with my absolutist take on custom CMS – sure, I’ll take that criticism.

I hereby state, for the record, that there are some situations where custom solutions work, but in those situations: (1) you need to have a real outlier in terms of usage patterns, and (2) you need to understand that the “custom” parts are likely only going to be where you usage diverts from known patterns, and therefore we have to place the word “custom” on some kind of spectrum.