There are hundreds of factors that can play into your choice of a good CMS (most of which have nothing to do with the technology). In this post however, we’re going to look at that choice purely from a technological perspective by reviewing the internals of a CMS (Content Management System) to see which one […]
There are hundreds of factors that can play into your choice of a good CMS (most of which have nothing to do with the technology). In this post however, we’re going to look at that choice purely from a technological perspective by reviewing the internals of a CMS (Content Management System) to see which one looks the best from the outside-in. This may be a bit academic but there can be real business value behind some of these considerations.
Now don’t let this question fool you. The specific language in which the CMS is implemented is the least significant reason  you should or should not choose one. Instead, you should really be asking yourself:
Do you have developers that can create custom content for your CMS in the implementation language?
Very rarely will you have a CMS that, out-of-the-box, will host all the types of content (let’s call them capabilities) that you want. If your business deals with less than trivial capabilities, such as text, images, videos, audio, and documents, chances are you’re going to need to create a new capability that is unique to your line of work. This means you’re going to need a developer or development team to create that new capability. Not only that, but you’ll also probably realize that you need to make changes to that capability as your business requirements evolve. So yes, now you have a piece of software that will need to be maintained by a developer.
One of the pitfalls of adopting a CMS is that you lose some of the control over your application. If there is a bug or piece of functionality that you would like added, you must either wait for it to be developed or do it yourself. If the CMS is open source, you have the power to add new features and fix bugs that you’ve identified on your own. Granted, you may introduce bugs of your own, but you won’t have to worry about the core team’s development cycle. On the other hand, you will want to understand how easy it is for developers to make changes or fix bugs. A good indicator can be seen in the activity in GitHub, BitBucket, or whatever service the open source CMS hosts their code on. If the CMS has an active open source developer community with a lot of pull requests, it’s a good (not great) indicator of whether that CMS is designed for developer modification.
This will play a large part in the CMS operational cost, and which CMS’s are lagging technologically due to custom web applications.
Some CMS’s are “on-prem” only. This means that you must have a physical server, ensure its security, power supply, networking, upgrade its operating system, etc. This can be a HUGE cost, not to mention an additional headache for your IT team since you’re now responsible for maintaining not just the content of the CMS, but also the physical server that it’s hosted on.
One thing that you’re going to want to look for is whether a cloud provider has a CMS that can be easily spun-up on the cloud. In Microsoft’s Azure, they offer CMSs such as dotnetNuke, Umbraco or Orchard instances that can be started at the push of the button. This takes away from the cost of managing a system.
Even MORE advanced are CMSs taking advantage of Serverless Functions. They dramatically reduce the operational cost of a system, however, very few CMSs are implemented like JAMStack or KISTUI. These are very cutting edge, so I wouldn’t recommend them as of this writing, but they hold a lot of promise in the future.
The more complex business problems you’re trying to solve with a CMS, the more likely you’re going to need to develop custom content. My last point was that customized content functionality and bug fixes are now the software that your business must maintain. It will evolve as your business evolves, and requirements will most likely need to be added.
As with all good software: custom content, functionality and bug fixes must be tested in a place that is NOT production! You will likely need a staging environment to test the new content types on. This also requires that you have equivalent environments for upstream and downstream systems.
Additionally, you’ll want a CMS that is very easy to package, deploy and upgrade. We at Excella aim for a continuous integration/deployment approach that requires an automated build pipeline. This will automatically deploy changes from the various environments to your system as well as run automated tests against your custom content.
How easy the CMS is packaged and deployed to its hosting environment plays a huge part in keeping your system up to date with the latest content that you need.
This can be made easier by containerizing your CMS, but that also requires a savvy IT staff that knows how to do such things.
In summary, when choosing a CMS from a technical standpoint, you just need to ask yourself:
How good is your IT staff?
The biggest pitfall that I see with clients is that they think that by adopting a CMS, they reduce the need for IT staff and eliminates the need for developers. However, as we learned from this post, a CMS project is just another IT project. There are many hidden costs to adopting a CMS, and some CMS projects end up with higher development and operational costs than a custom-built web application. With these tips, however, you should at least be able to find what best suits your IT department.