We’ve spoken a lot on this blog about the benefits of custom CMS platforms compared to off-the-shelf software packages, mostly in top-level terms. Typically, the benefits we cover are longevity, ownership, security, and flexibility.
But digging deeper into these items, we can find even more nuanced arguments for seriously considering a custom CMS platform.
Most, if not all of our corporate/enterprise clients have very specific technology requests and requirements. The point of this post isn’t to discuss what those requests are or debate if those technology packages are the right fit for everyone, but rather to show how the custom methodology for developing your own CMS can work within the specific requirements that your organization may have.
After all, butting heads with your in-house IT team over technology requirements is rarely a battle that can be won. Many a project has collapsed at the onset over such an argument—even if other groups, such as marketing, label them as mission-critical.
In just the past few months, we’ve seen requirements from our largest customers that are all over the map: an enterprise media company with requirements to build utilizing Ruby on Rails and MySQL, or a large organization that utilizes Python with PostgresSQL. That’s in addition to the typical LAMP stacks or MongoDB that we see very often, or the ubiquitous corporate favorites, Microsoft .NET and SQL Server.
The good news is that custom CMS approaches can be built on any of those platforms and still function in a similar manner regardless of the technology stack. This is made possible by a variety of new technologies in addition to the concept of decoupling your CMS infrastructure.
At NPG, we are working aggressively to expand our core CMS backbone to work on as many tech stacks as possible with a similar UI/UX experience for the administrator on each one.
In a way, we are working to become tech-stack agnostic.
How can this be possible? The real reason is because technology today has evolved to the point that the front end and the back end of a CMS can be separated.
In the past, our use of the term “decoupled CMS” has mostly centered around separating your distribution, or front-end user experience, from the back end. Taking it a step further, it is possible to decouple your administrative interface from your back-end technology stack as well.
In fact, it is preferable.
In doing so, the back-end technology stack becomes simply an API interface, or a system that shuffles data back and forth from an administrative center. In this way, the back-end technology is irrelevant to the CMS. It need only power a rudimentary API and, depending on the project, some other functionality as well. And thankfully, new front-end technologies such as React and AngularJS make it possible for CMS platforms to be powered by these APIs while maintaining a streamlined user experience—almost an “app” type of feel.
This model represents a simple installation of a decoupled website with a CMS powered via API technology:
Now, we have simplified this concept for the purposes of this blog post and, of course, to hold some cards closer to our chests! But the top-line theory makes the debate over custom CMS platforms much easier to have.
The largest hurdle during the procurement process for many off-the-shelf CMS packages is the technology debate. Platforms such as Drupal, WordPress, and Joomla are basically non-starters for most enterprises. The security and technology requirements alone make them unacceptable for use. Despite claims from these providers like WordPress that large companies use their software, they are usually for tertiary projects or low-risk endeavors and almost never for large, public facing installations.
We have seen organizations who list LAMP as an unacceptable technology. Others just scoff at the security and unpredictability of these platforms.
Likewise, corporations have their backs against the wall when looking at enterprise-level CMS platforms from SiteCore, Adobe, Sitefinity, and the like. While these may pass some internal technology requirements, they limit flexibility, making them unacceptable to the end user, typically the marketing teams. These systems are built for the 90% of use cases, but typically, customizing them to go further than they were intended is difficult. And having anything built into the software for your needs is highly unlikely.
The bottom line is, when you are an enterprise looking at potential CMS platforms, you have to meet your internal technology requirements and your use cases and needs, which is difficult, to say the least.
In these cases, the custom CMS approach should be considered as a way to satisfy all of these requests and have more control over the process. Advancements in technology are making it possible for the back-end systems that power the API can be built by in-house developers, which is something that is appealing to almost any CTO. Likewise, developing a CMS platform that allows for cutting-edge user interfaces is now a possibility while still utilizing the technology that the internal team is used to.
This scenario is a win/win proposition for all involved.
And don’t forget that with this separation comes longevity, too. We’ve often argued that decoupled CMS platforms allow for a longer lifespan for the CMS itself. With the advent of API-driven administrative panels, your CMS can now live longer than ever before while allowing for UI/UX updates over time. The back-end “pipes” will still work the same. Again, this is something that is unthinkable with enterprise software.
The CMS industry is about to undergo a tectonic shift, much like what we have seen with front-end technologies over the past 5 years. The advent of mobile phones and tablets led to a wholesale change in the web design industry. Likewise, new technology will lead us away from the concept of integrated CMS platforms and present enterprises with new, exciting options.
The custom CMS, a concept that dates back 20 years, is about to become a breath of fresh air again. Isn’t it time your company consider the advantages?
