There is continuing debate about whether or not WordPress is a CMS, which I have participated in already. There are two things fueling the debate:
- Lots of WordPress users seem to take the attack personally. This has allowed vocal supporters to drown-out those few with rational arguments.
- The more traditional, non-web, Content Management crowd say that WordPress isn’t feature rich enough to qualify. Of course, nobody has actually provided a comprehensive definition of CMS or a list of features.
So the fight continues. While I am in no way trying to resolve the argument in this post, I am trying to solve the crux of a matter….What is a CMS?
Remember, through all of this, I love using WordPress. Trying to categorize, not demean.
Simple Answer
Tony Byrne gave a simple definition: Content Management is the management of content. Extending that, a CMS is a system that manages content.
Simple enough. We know what a System is. No debates on that term.
We have a pretty good handle on Content. There is no requirement for a CMS to manage all types of content, so a WCMS could specialize in browser-targeted content and fail at dealing with documents, video, records, or scanned images. That said, we may have to revisit content later.
So the remaining word is Manage. What does it mean to Manage a piece of content?
The WordBar
So when you want to manage a piece of content with a CMS, what do you want it to do for you?
- Store: Well, duh. Of course, you can do that with any desktop application and some disk space.
- Metadata/Properties: More complex, but important. This goes beyond author and modified date. I should be able to define custom properties. If I publish the text of a speech, I might want to store the speaker(s), date given, and location. I can do this in Word as well.
- Content Types: Let’s face it. When I edit a press release, I don’t want to deal with the property fields for a speech. I need different types to handle different fields. I have this in Word with templates.
- Security: I want to be able to secure it. Check for Word.
You know, there is a lot of things that I can do to manage content using Microsoft Office, and nobody will call it a CMS.
One thing that lots of people say in defense is that you can write/add plugins to add functionality to WordPress. You can do the same with Word. I can write some pretty complex stuff that will allow me to author and publish web content from Word using macros and add-ins. That doesn’t mean that Word is a CMS.
The most advanced out-of-the-box version of Word with all the Microsoft add-ons is still a Word Processor/Content Publisher.
So a CMS needs to clear the WordBar before we even consider evaluating it as a CMS. The type of content does not matter. A WCMS and DMS (document management system) must still Manage content.
Digging Deeper
Let’s look at some features that are pretty basic, but possibly above the WordBar. They may be implemented/named differently in different products, but the core value is important.
- Versioning: Versioning is critical. It can simple or complex, but it has to be there.
- Multi-Edit Issues: Whether there is a check-out feature or a edit resolution feature, there must be something that manages the scenario where 2 people try and edit the content at once. It doesn’t have to be great, but it needs to be acknowledged and addressed.
- Full Security: This means groups and access control lists. You need to be able to restrict access to groups of users in addition to individuals. You also need to be able to use re-usable permission sets. This also means multi-level, None-Read-Full. I’d prefer to have Write as well, but I don’t think it is necessary from a scope perspective. I just won’t use it myself.
- Lifecycle: This can be simple. There should be some way to DEFINE a simple lifecycle. Doesn’t have to be complex, linear is fine, but not all content has the same lifecycle. Any automatic lifecycle features can be defined in code, but the number of steps and name should be configurable.
- Notifications: If you the system can’t send email without writing code, forget it. I need the system to tell me when events happen, even if it is as simple as telling me my favorite piece of content has changed.
- Change Logs: I need to know what has happened. This needs to have some basic configurations so I don’t have to choose between tracking everything or nothing.
I think that will do off of the top of my head. I intentionally didn’t look at anything while writing this. If I didn’t think of it, and it is a fringe feature, probably not core.
Also, third-party plug-ins granting the feature don’t count. Extensibility in a CMS is great, but it should be a CMS before it is extended.
Content or Text?
Content is pretty simple, blobs that when viewed in their native application provide information. Some blobs, like XML and text files, you can actually breakdown into fields that are stored in a database with no loss of information or fidelity, assuming it is done correctly.
So my question is simple, what does a CMS do with your content?
Here is a simple test. If your system cannot do this with any piece of content that it claims to be able to manage, then if fails and should not be considered a CMS.
Simple. If the system deconstructs a piece of content to optimize utilization, but is unable to re-constitute it later, then it fails.
If you cannot look at it when it is in the system and tell that it is the same piece of content, then it fails.
Try it out with WordPress. If I import a Word document, which is a feature, can I then export it back later and have it retain all the same features? This includes non-date properties (after-all we can’t blame a CMS for Windows changing modified and last access dates).
If you can’t separate the content from the system, it isn’t managing that content.
Two Questions
So, is the feature list of a CMS valid? Is it complete? Does it have too much?
Second, how does WordPress, installed straight from the core download, measure up? Yes you can extend the install to be a CMS…
…but I can do that with Word.
Word of Pie 
I’d say the definition is somewhat different…
“The purpose of content management is to make content MANAGEABLE.”
Given the explosion of unstructured content, you’ll never get 100% of the way there… but there is always low-hanging-fruit, and if you can find a way to manage it, you’re doing quite well.
LikeLike
I keep wondering about how complex this seems. But isn’t it as simple as the difference between managing files and managing textual/graphics content directly? Sure there are caveats and “yeah but”s, and there for to anything. Very little is that clear cut.
In general, the argument seems to be between the people who manage files telling people who manage websites (or web content) they don’t have a real CMS, and vice versa.
The systems are different, but both groups are vying for the same term.
Call a truce, make up new terms, and go from there. Is such a thing so bad?
LikeLike
Actually, the issue is that if neither side can define the term, then neither side should be able to use it. If you can’t define the term that encapsulates your profession, then it isn’t a real profession. I’m trying to reach a consensus in the Content Management space as to what constitutes a CMS.
People have been expanding the usage of CMS for years. There reaches a point where you have to stop expanding it, define the limits, and use new terms for new products, even if they solve the same “I need a simple way to run my website” problem.
LikeLike
I am not sure that setting the bar at MS Word is a good or valid idea. You call Word a “Word Processor” – I have worked at a University which developed its own add on’s that turned Word 2003 into a fully functional “XML Structured Authoring System” – its just semantics.
So is Word plus a set of folders on a network share a CMS ? Personally I would say no, but I would say its a very simple DMS ! Very strange people who might accept Word as a HTML authoring tool may accept such a structure as a WCMS !
It’s all just semantics – but well done for pushing the debate forward as usual !
LikeLike
Incidentally, yesterday I was thinking about this: the differences between Web Content Management Systems, and Enterprise Content Management Systems.
Each one has different objectives, scenarios, although some of them may seem similar.
What most people are accustomed to see are Web Content Managed sites. WordPress, Joomla, and others, can handle Authoring, Review, Publishing in an organized and structured way. That is the most simple workflow.
That’s the principal objective of a WCMS.
If it has Versioning, then, better. If it has security, then, great, but those are not really needed for the final output: Publish web content.
An Enterprise Content Management System has very different objectives: manage unstructured content, as we all know: word processor files, spreadsheets, audio, video, pdf, scanned invoices, whatever. It has to be securable. Most enterprise documents and files are evidence of a transaction. It has to be auditable. It has to be versionable, securable. It has to be able to handle million of documents. It has to be searchable, by properties, by content.
I could continue…
So, talking about Content Management by itself is like talking about Resource Management, or any other “big concept”. We have to go deeper to really define each one, and each product will of course be different from the other, with strengths and weeknesses.
LikeLike
You’ve nicely summarised the legacy Document-Management-centric worldview that:
yet have conveniently neglected to mention that this is by no means the only (let alone the best!) definition of “content”.
In fact as soon as one steps away from document-centric use cases (web content management being but one example) one finds that alternative definitions of “content” make a lot more sense. Often these definitions re-introduce notions of structure both within and between “documents” (which no longer look anything like simple blobs).
I’ve already eaten a slice of pie on this topic (please re-read your reply and my reply to it!), so am a little disappointed to see this discussion being framed with obsolete, 1990s era definitions of the core concepts.
LikeLike
Ugh I also just noticed that I’m almost a month late in replying – I really need to find a better feed reader…
LikeLike
Relationships are important, but I was hesitant to add that to the list of requirements for a CMS. I think the ability to handle relationships or compound documents, to borrow some older DM terms, are important, but not critical to being a CMS. It may be critical to being an effective WCMS, but that is a subset of the greater whole.
Let’s say feature set “X” classifies something as a CMS. If you add a feature set “Y”, you can be a WCMS. If you add “Z” instead, you can do Records. If you add “T”, you can deal with XML. These lists are also not mutually exclusive as some features may pop-up in multiple locations.
Remember, a CMS can exist without being able to support a website. You have to separate the terminology. I wouldn’t dare define what is required to add to a CMS to make it a WCMS.
LikeLike
Simply put, documents (“files”) are not central to the WCM worldview of content but they are central to the DM worldview of content. Therefore to claim that a DM style CMS is a good starting point for a WCM is mistaken. As I mentioned in my “slice of pie” post, there are overlapping features for both use cases, but also capabilities that are core but unique to each. Therefore neither can be a predecessor or superset of the other.
This isn’t just abstract blathering on my part either – the evidence from the industry is pretty clear in this regard. Many of the vendors (notably the 300lbs DM gorilla Documentum) that started out with DM-centric solutions and organically added WCM capabilities are generally considered to be either failures or extremely weak (despite having natural advantages due to cross-sell opportunities etc.). This is not due to a lack of investment or technical know-how on the part of those vendors mind you – it’s simply that DM style CMSes are not suitable as a starting point for building a quality WCM (of course the reverse is true too, although I don’t know of any WCM vendors who’ve attempted to move into the DM space except via acquisition).
LikeLike
[Replying to myself so that I don’t get squeezed into oblivion]
Actually, I would say that the reason Documentum failed is that they could not innovate fast enough. The largest flaws were always on usability and lack of any tools. I don’t think any of the flaws were due to the underlying system, aside from the fact that it took 2-3 years to identify a feature, get it onto a roadmap, and then wait for the appropriate release.
Looking beyond my terminology, because like Brits, Aussies, and Yanks, we will always have different terms for the same things. Look at the list that I presented and tell me which of those features are not needed for a large-scale website. I’m not talking for your local non-profit that can get by with a more targetted WMS, but a larger site.
A WCMS may need more. Want to know something, so does a DMS. A good DM system must have seamless, and painless, integration with my desktop applications. It has to handle compound documents and multiple renditions of a piece of content. I didn’t list these because they aren’t core to CMS.
If you think something needs to be added to the list, let me know. I’m open. I also think that CMS should be inclusive of DM and WCM. That said, you don’t need WCMS to manage a website, thus the new category of WMS.
LikeLike