As we all know, the architecture of software matters. After all, architecture is the foundation of software. How a system is built under the hood will determine how you’ll utilize the application, how it will scale to meet growing end-user demands, and how it will grow from a functionality perspective as your company’s requirements change. Architecture is important, yet many companies don’t put enough thought into understanding the way a platform works behind the scenes when evaluating content management solutions. For some, this may prove to be no issue but in many cases, the results of lackadaisical vetting can handcuff your company’s efforts in the future.
But what about in your specific case? Does the CMS architecture you choose really matter for your organization? Well, that depends on what you are trying to accomplish. If you quit on this post early, take away this one key point: the proper architecture of your content management system is highly dependent on how you plan to distribute content. This should be your primary concern in determining what package will work best for you. On a secondary level, you can dig into specific use-cases or requirements. One of the leading examples would be security, followed by scalability, performance factors, content workflows and so on.
Before I dig a bit deeper into helping you answer how important architecture of a CMS is for you, and which will make the biggest difference in your case, I want to summarize what we mean by CMS architecture and spotlight the most likely choices for the vast majority of installations.
I define CMS architecture not as the tech stack it runs on, such as .net or LAMP, but rather on how data is stored and managed in the platform and in the underlying database. So, for example, when we speak of “coupled” platforms, we are talking about platforms such as WordPress, Drupal, Sitecore and other systems that are tightly integrated into the front-end user experience. In these cases, the code that powers the back-end administrative portion is tightly coupled with the front-end user experience.
On the other hand, you have “decoupled” or “headless” systems. These platforms separate the administrative system from the front-end user display. The administrative portal may be built in a totally different tech stack vs. the front-end. The best examples of this architecture in action is the new wave of headless providers such as Contentstack, which provides a hosted CMS solution that lives totally separate from any front-end experience. Contentstack makes content available via API so you can build out any front-end experience you want, from almost any platform. The system includes a front-end administrative panel hosted and maintained by the provider.
With that architecture explained, I want to also summarize the difference between a WCMS and a CMS. I’ve written an entire post on this topic, but to quickly review, a WCMS, or Web Content Management System is entirely aimed at web content management. A straight Content Management System can handle content for use in a variety of mediums. Architecture matters, as coupled systems are married to their delivery mechanisms, whereas decoupled or headless systems have flexibility in where their content is consumed.
This is where we come back to my earlier point: the architecture that makes the most sense for you is based on how you plan to deliver content. To be helpful, let’s explain some scenarios.
Where Architecture Really Matters
As we reviewed, architecture is most important when it comes to content distribution. This is because if you have a multi-channel distribution methodology, you need to ensure that you aren’t using a CMS that was engineered to deliver to a particular medium. If you are building a content machine that will deliver content to web, mobile, and other devices, it doesn’t make sense to build your entire content management workflow around a system engineered with only the web in mind. As an example, if you are building a media distribution system with video content, you wouldn’t want to do this within WordPress and then attempt to distribute the content to a mobile app. WordPress was architected with the web solely in mind. In fact, the WordPress project is now doubling down on that direction with the introduction of Gutenberg, which is a visual content editor that is aimed squarely at web content management. While WordPress proudly boasts an API that provides access to content, they simply can’t divorce themselves from their WCMS roots.
The architecture also matters greatly in terms of the longevity and cleanliness of your web content. Digging deeper into the WordPress example, you can see that content is stored in a format that is specific to the web and to blogging (which is the origin of the WordPress system). WordPress stores “posts” and “pages” at its core, which is something specific to the web. Despite the ability to now add custom post types, which extends the capability of the platform, it still lacks in terms of clean content storage. Adding a large quantity of content to a system like this can limit your future capabilities in a few ways. First, the content is organized according to this old methodology, which assumes you are assembling just posts and pages. That restricts you a bit. Secondly, it also is storing content in a way optimized for web delivery. This means your content will have inline HTML, which will clutter the content for future usage. Decoupled and headless systems store content in a much cleaner model, meaning that you can define what content is and what it consists of, clean of any markup or other “gook” which may provide issues later.
Who does this matter to? Well, it depends on your particular organizational needs. A restaurant or other local business probably doesn’t care. They will be single-channel distributed to the web. But many other organizations should care. News and media companies should store content in as clean a fashion as possible. First, you probably distribute to multiple channels already. And secondly, you have no idea what the future will hold. It’s important to avoid future content hassles by properly storing your data today. And, it isn’t just media that should worry about content distribution. Think about e-commerce, as an example. Most people wouldn’t think about it, but e-commerce applications require clean content. A product database must be as clean as possible with data that is added, managed and stored specifically to be distributed in a multi-channel way. More and more retailers will be selling their products via other channels such as mobile applications and OTT devices. It’s essential to keep product catalogs and databases as clean as possible to prevent any issues in delivering that content across the gamut of possible devices.
Finally, there is one last area where architecture matters, and that is in the area of security. Today’s coupled CMS systems basically are exposing themselves to the world as their admin systems, including the portal itself and the logic, is attached to the front-end experience. Savvy hackers or other nefarious characters know this and are constantly working to undermine them. Decoupled platforms are great at hiding this capability, veiling the administrative portions ensuring the possibility of being compromised is greatly reduced.
Where Architecture Doesn’t Matter
Of course, to many businesses or organizations, architecture is not an immediate concern. Again, refer back to my rule: architecture matters most to those who distribute content in more complex fashion. Secondarily, if there are other concerns such as security, then architecture must be considered. But if not, well, then you have plenty of options to chose from.
Local or small businesses looking for credibility via their own website can rest assured that almost any CMS would work well. Likewise, those focused on lead generation on the web can also utilize almost any CMS that is on the market. Informational sites are typically not complex and almost any CMS is marketer-friendly at this point, so the possibilities for your company really can be whittled down to finding the solution that works best given your budget, timeframe and any other technological preferences.
Beware the Risks of Making the Wrong Decision
Before we wrap up this week's post, I want to cover the worst case scenario: what happens if you don’t make the right architecture decision. There is a good chance you probably won’t realize the mistake for a while. You’ll utilize your new system, built some content, but then the limitations will slowly start to present themselves. Maybe new opportunities to build out a mobile distribution method present themselves, or a partner is interested in ingesting your content. Perhaps your off-the-shelf system just announced a massive upgrade. Or, your business objectives change. Whatever happens, the worst case scenarios are all pretty much the same.
First, you may be forced to migrate to a new system. Content migration is a skill and discipline all of its own, and it kind of stinks. Think about moving – who wants to move? Almost no one. Packing boxes, carrying, transporting, carrying, unpacking. Content migration is directly analogous to that hassle of relocating, only it can be way worse. If you chose an architecture without planning for the future, this is a definite future risk.
Another risk is that you store your content in a manner that isn’t future-proofed. We have an entire post dedicated to this idea, but, in a nutshell, if you store data in a system that manipulates your content, you’ll be not only looking at a migration but at a large clean-up effort as well. Sometimes you can write a script which automatically cleans out this markup, other times you may be looking at (gasp) manual editing and manipulation.
Finally, one last risk is the idea of redevelopment. You could potentially run into issues where the architecture of your system prevents you from doing something so important that your only option is to start from scratch. I’ve seen this happen many times over my career. Sometimes it isn’t avoidable – it just happens in the natural course of business. But most of the time there is a warning during the initial procurement, some indicator of a weakness in the system that should be a non-starter. Pay attention to detail when choosing an architecture – it can result in a lot of stress in the future if the wrong decision is made.
Conclusion
At the end of the day, architecture matters, but it depends on your business, your use case, and your overall requirements. It’s important to know that there is no one right fit for everyone. Those that exclaim the death of WordPress are foolish, but those that say a system like that can fit every use case are even more foolish. It’s up to you to determine which works for you based on your own requirements and also based on your possibilities for the future.
