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:
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.
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:
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.
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.)
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.
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.
The system cannot ever solve your problem, and your problem is real, relevant, and significant.