Some of the benefits of using a proper CMS are obvious. However many benefits are hidden, particularly those which are only felt when things go badly wrong.
Security
The “Site Admin” link to the right of this article is protected by a user ID and password. You could easily point a brute-force tool at it to discover a password, or find some other vulnerability with the application. (Try this and I’ll break your legs) Once you’re in, you could make defamatory posts as the site editor, or worse, you could gain administrative access to the system.
An Enterprise CMS is a back-office system, situated behind a firewall. While this does not afford full protection, it is an extra layer of defence which is maintained and monitored by a security team.
Audit Trail
With a complex site with multiple editors working on many different site components, if something goes wrong you need to find out what, why, when and by whom.
Every activity is logged in an Enterprise CMS like TeamSite.
Production Load
CMS systems provide mechanisms for transforming content before publication, such as changing the size of images to suit the web. This takes processor load, and it must not be done on a production environment. You want to reserve as much of the production load as you can for your site visitors, to run code exclusively for them. The work of content manipulation belongs in the back office.
Resilience
If the server running this site fails, I’ve lost my blog. I wouldn’t lose sleep over it. If parts of your production environment die, you’re fucked. You’ve lost every change made since your last backup.
Using a CMS, your up-to-date content will be safe, ready to publish immediately to a new environment.
Versioning
WordPress is pretty good at vertical versioning, I’m impressed.
A CMS keeps a version history of everything you do with every file. You can revert a file to a previous version (vertical roll back), or revert everything back to how it was at a certain time (horizontal roll back). For organisations in the financial sector, this is a regulatory requirement. However it’s still important to keep a full history of valuable content, even if you’re not forced to do so.
Development Effort
It would be very foolish to develop CMS functionality within every web application. It’s very similar to the age-old argument of bespoke vs. off-the-shelf software. I understand that project sponsors are tempted to demand that their project is delivered exactly how they want. However projects are far more expensive to develop and support if they do not share common infrastructure and code.
Release Process
Software is always buggy. Despite vigorous testing it inevitable that some bugs will be discovered after a system goes into production.
Changes to the CMS can be done much more flexibly when it runs as a back office system. This is not to say it should not be tested vigorously and released properly, but fixes to content bugs can be done much quicker. This is why we separate web content from application code. Sites usually require fixes to content to be released in much shorter cycles than application code releases allow.
Multiple Interfaces
Projects should have as few interfaces for content creation as possible. Additional interfaces cause additional errors, and cost more to develop, support, document and train users.
Workflow
The archetypal CMS workflow is an approval process. This is vital for many enterprises, particularly in regulated environments such as the Legal, Financial and Gaming sectors. However in the Media world, “workflow” conjures the image of a Soviet Bloc beaurocrat coldly controlling a production line, a factory that churns out worthless components only to be melted down to feed raw materials into the same factory.
Workflow is not just about approval, endlessly clicking meaningless steps. It is one of the most important tools you can use to customise CMS behaviour, to automate tasks tailored to your specific needs. It’s the killer component of a CMS, setting it far apart from blogging tools.
There are more arguments. But these terms are just as tedious as “workflow”: governance, brand protection, deployment architectures… I’ll spare you details, and I’ll spare you any more of my laboured, cold war metaphors.
Recent Comments