Let's Evaluate the Current Level of Functionality

Contents

We’ve described a fair amount of functionality. Let’s take a quick timeout here to wrap up what we’ve detailed into a hypothetical CMS and then consider what that gets us.

Here’s what we’ve talked about so far, and what a theoretical system encompassing all of the discussed functionality would look like:

This is a system that incorporates every desirable feature we’ve discussed so far. What we’ve described above is a fairly competent system, and one that reflects quite a bit of what’s available in the market today. Fifteen years ago, in fact, this might have been considered advanced.

If our system only included the functionality we’ve described so far and nothing else, it would be simplistic but serviceable, and a competent integration team could use it as a fundamentally sound tool.

It’s also worth noting this: at this point, we’ve essentially just duplicated the functionality of a relational database.

This isn’t to say the work we’ve done so far has just gotten us back to the start, because remember that a CMS provides considerable functionality around content modeling. In addition to supporting a set of database-like functionality, a CMS gives you things like automatic editorial interfaces, workflow, permissions, templating, delivery, etc. It is fair to say that a CMS is a superset of database functionality – a “super database,” if you will.

We’ll discuss content services when we discuss the difference between content and everything else.

We still have a long way to ago, and a lot of advanced functionality to cover, but it’s a fair point to say that the above functionality is the “table stakes” of competent content management at the current state of the industry.

If your system cannot support almost all of the above base functionality, then it’s either behind the curve, or it’s not designed to be a general-purpose CMS.

This is item #15 in a sequence of 34 items.

You can use your left/right arrow keys or swipe left/right to navigate