Why the CMS Industry is Due for Disruption

By Pete Czech

p>I’ve been pontificating on the state of the CMS industry for quite some time now. It’s a complicated and convoluted space, with the term “CMS” meaning different things to different people.

The industry’s biggest players and open-source projects haven’t done a good job describing what these platforms do and what they are designed for. The number of acronyms circling around can easily confuse even seasoned software veterans.

Furthermore, for a technology category, the CMS space is based on technology and concepts that are old—and getting older.

Add in the difficulty of acquiring CMS development and implementation services, where the battle between onshore and offshore resources continues to muddy the waters for potential clients both from a capabilities and cost perspective. One could say it has never been more difficult for customers to figure out what they should look for in a CMS solution and implementation partner.

I believe quite strongly that the space is due for interruption—but by whom and when is anyone’s guess.

Lately, I’ve been thinking more and more about the possibility that it won’t be just one company that interrupts and disrupts the way we do things, but a movement in general.

Perhaps it will happen via a coalition or grassroots campaign to redefine what it is we are seeking to accomplish as an industry and as service providers.

This movement must be based on a few core principles:

  • Content management systems must be content-first;
  • “CMS” doesn’t mean distribution to the Web exclusively—it must allow for other outputs as well by separating content management from display technologies;
  • We must be focused and dedicated to the cause of security and the safety of our CMS applications.

In this post, I am going to expand upon why the industry desperately needs to be disrupted and explore some potential ideas for the future.

Content Management Isn’t Going Away

This is a no brainer. There will always be a need for content management. The economy is information-based, and content will always be generated and added regardless of industry or economic conditions. As long as there are people to consume content, there will be a need for content creators and systems to facilitate the creation, organization, and distribution of said content.

Furthermore, content distribution isn’t cut-and-dry and won’t get easier to manage in the future. Administrators will need systems that can make the management process simpler and more streamlined.

As such, if the need will never dissolve, why are we allowing the industry to make such a mess of something so important? Why is technological advancement in the content management space so far behind in a medium that is consistently expanding and enhancing its front-end user experience?

I think one reason is that our industry is now inundated with too many “experts”—and I use that term loosely. The CMS category is being flooded with developers and strategists that really have no idea what they are trying to accomplish and continue to spread off-the-shelf solutions based on outdated architecture.

The fix is for the industry to come to know and accept that content management is here to stay and the scenarios that we are tasked to address are complex. There are no simple fixes and no one-size-fits-all solutions. We must stop trying to mold clients into the methodologies that are available, but rather mold technology to fix their problems.

Software Providers and Projects Are Lying To You (Sorry!)

One of the major problems that exist today are the promises being made by software providers and other developers. I include everyone from enterprise CMS manufacturers to open-source projects in this category.

Displaying content on the Web and on other media isn’t easy. These large-scale software packages are not going to do 100% of what you want them to do—it simply isn’t possible. They are built for the masses, for the most common use cases. Eventually, almost every customer will find that their needs are not being met.

Sure, each platform promises extensibility and flexibility. Many have plugins, extensions, or modules you can “drop in” to extend functionality. But in reality, those are flooded with technical debt and under no centralized control in terms of coding quality or performance.

The truth is that to get 100% of what you want, you MUST consider custom-built solutions—at least for the front-end experience of your site.

We’ll talk more about this in a bit when we discuss the ideal architecture for your CMS. But for now, it’s important that the industry is interrupted by someone willing to admit that any product or project created for the masses will never do everything you need it to do.

Another area of concern is the lack of transparency regarding ongoing costs. I blame two things for the commoditization of CMS services.

First, the “free” nature of open-source platforms. Customers are now being conditioned to believe that their website should always be a low-cost investment with no ongoing expenses. But even the chief advocate for the freeware philosophy, WordPress, charges many thousands of dollars for maintenance of their own platform in enterprise environments (Read our post about this here.)

This lack of clarity in terms of cost and budgeting is resulting in sticker shock for clients who deploy these solutions cheaply, only to continue spending money for updates, upgrades, and security monitoring.

The second issue that has affected the quality of the industry is the amount of offshore resources that can quickly spin out CMS installations for very low margins. This has put pressure on consultancies onshore by either taking business away from them or marginalizing the value of a complicated task.

I’m always shocked that people spend hundreds of thousands of dollars on office build-outs and then send their corporate website to India or China for $10,000.

Something isn’t right…

Old Theories, Old Architecture

The CMS industry today is addicted to muddying the waters between what a CMS and WCMS is (if you are confused, read this post).

We’ve talked a lot about CMS architecture, how all of these parts work together, and what the CMS of the future looks like. Today’s most popular platforms are still web-centric, treating web delivery as the only content delivery platform that matters.

The truth is that for any content creator, whether you are developing text, audio, or video content, distribution must be more than just for the Web. There are a variety of devices and channels where you can distribute content for consumption and monetization. Yet today’s most popular platforms are still web-centric, coupling their content management capabilities with web-specific display!

Now, the entire idea of headless or decoupled architecture isn’t new—it’s actually rather old. But it must make a comeback, and all indications are that it finally is.

New SaaS-driven content management tools are now coming online, and even the monolithic platforms such as WordPress and Drupal now include APIs as part of their installation.

In those cases, it’s too little too late, as the CMSs themselves are web-centric. Why decouple a system created for the Web anyway?

This architecture problem is inevitably going to lead to a massive overhaul of the existing systems available today. There simply isn’t any way to avoid this reality—the architecture must be caught up and everyone will have to realize that web delivery is just one of many ways of doing business.

The world is moving towards portable data, transmittable via API and consumed in many mediums. Systems that integrate HTML into content (such as WordPress, Drupal, and most enterprise platforms) are putting their customers in jeopardy when it comes to future content portability.

Display Technology Has Changed

I often say that back-end technology moves slow and front-end technology moves fast. For the most part, this is true.

The most popular development languages and techniques on the server side or back end of applications is similar today to what it was 15 years ago. PHP is 20 years old and powers the most popular frameworks in use today.

Looking at this chart of framework usage, you can see that many of the frameworks that are back-end-centric are based on technology that’s been around for quite some time: Ruby, Laravel, CodeIgniter, Symfony, and CakePHP as an example.

But interestingly enough, some of the technologies on that list are new, and for the most part, they are identified as being front-end platforms. React, AngularJS, Ember.js, and other front-end frameworks are redefining how applications work today—and this definitely includes CMS technologies.

Without diving too much into details of software architecture, I can describe at a top level how these new frameworks function.

In the past, web applications were built by developing code that was executed on the server and output into HTML. That is what is called a “scripting language.” PHP, which powers WordPress, Drupal, Magento, Joomla, and many other platforms, functions in this manner.

When a webpage is requested, PHP takes the variables of interest to the request, generates HTML on the fly, and that is then transmitted to the client or end user.  This architecture requires everything to be tightly coupled together; front-end code and back-end code live in the same environment and are tightly integrated.

Today’s new technology works much differently.

Instead of coupling together the end-user code with back-end function, modern frameworks simply request data from a centralized location and then work to parse and display that data on the fly. Most of the time, this happens via an API, or a system to transmit and share data from one system to another. This is actually a much more efficient system in that the back end and front end have separated powers, meaning that each can function as an independent unit.

The benefits of that architecture are massive for an enterprise environment. Imagine your next CMS rollout lasting you many years to come. How is this possible? Simply put, because separating content management technology—which should iterate at a slower pace than front-end technology—from the user experience will mean the system will have its own lifespan and development cycle.

This also means that as front-end technologies come and go, you will be able to count on a dependable, stable base framework powering your CMS.

If you wanted to get even deeper into what is possible, imagine your CMS not changing at its core, but redesigning the user interface every few years as new requirements emerge. This is also possible because even the CMS interface itself can be decoupled from the core logic of the system.

Try doing that with any system off-the-shelf today!

Distribution Methodology Has Changed

Another area where the CMS industry is not capable of keeping up is content distribution.

When today’s popular platforms were architected, there was no thought put into external content delivery with the exception of RSS/XML feeds. And those were pretty much just methods to deliver content to other web properties or readers, not necessarily true content distribution.

Today’s content creators are tasked with deploying content across a vast stream of channels, including many different devices, partners, and social networks. This is most prevalent in video distribution.

The below model is a representation of the available distribution channels for online video publishers today:

As you can tell, video content can be distributed from a centralized content management system to the Web, partner companies, OTT devices, social networks, and even live broadcast.

At first glance, this seems easy. A WordPress developer would say that they can simply spin out new feeds to populate each channel. What they won’t tell you is what we’ve already said above: WordPress is made for web content, not for something specific like video.

Even creating custom content types to store video in WordPress won’t give you the ability to create custom rules for distribution to all of these channels and methods.

The same idea applies to audio content and in some cases, text as well. Smart publishers are now realizing that distributing pure content without the unnecessary web-specific markup is essential to monetizing their content effectively.

And this will only continue as more and more devices come online for consuming content as a whole. Content management must revert back to a simplistic model of adding, editing, and deleting content—not trying to be all things to all people, which is a good segue to my next point…

Security: A New Essential Component Everyone Ignores

WordPress is in use by 59% of websites where we can determine what CMS they are utilizing, which translates to 28% of the web in its entirety.

Yet despite this level of popularity, it also has almost 8,000 known vulnerabilities!

This, in addition to its vast library of plugins and themes (which are not certified by any central authority), makes WordPress the most vulnerable platform in mass use on the Web today.

I take no pleasure in picking on WordPress so much. It’s a viable platform for some uses. The issue I take is the infiltration of WordPress into enterprise environments where its ability to wreak havoc will eventually result in negative consequences for many a web administrator or CMO.

Simply put: To install WordPress on the enterprise level is a total disregard of potential security concerns.

Luckily, security is easily addressed with the proper architecture. Headless or decoupled systems are much easier to secure, as the CMS can be easily locked down from a network perspective. Since the website front-end lives elsewhere, this separation allows for administrators to sleep better knowing that their CMS is locked to intruders.

It’s Time to Embrace Simplicity: A “Pure” Content-Driven CMS

As I said earlier, interruption can happen two ways.

First, a company can come with a solution that changes the world. I’m unsure how this would happen in content management, as each scenario is different and every project has its own unique requirements. One universal system is pretty much how we got into this mess in the first place.

But the second way is by the industry adopting a new philosophy. And that philosophy should be to simplify content management in such a way that new CMS installations are truly content-first.

I’ve been a fan of simplistic content management for many years. If you’ve had an introductory call with me, you’ve heard me say that the best CMS simply adds, edits, and deletes content. The industry has to start welcoming that idea back into the fold by separating content management and display/distribution configuration.

The first step is by changing architecture to embrace the decoupled, headless methodology. Even if you are 100% web-driven, it is smart to consider this approach.

We’re not saying that you need two systems—one for content and one for website configuration. We’re simply saying your next CMS should architect those items separately.

At NPG, we’ve married these two components into a single interface for content administration—and we’ve taken great pains to keep it simple. Our new base CMS platform includes content management tools, or a place to simply define, add, edit and delete content. Then we have components that manage display and manipulation, either for web, API, or other distribution methods.

For web display, we focus on the philosophy of modular design, which utilizes parts of a website that pull in content via a series of logical requests. It’s easy to administrate, simple to learn, and best of all, it preserves the integrity of content for any future uses that may be required.

So What Are We Waiting For?

Honestly, I’m unsure what we are waiting for. The space is desperately in need of disruption in the form of redefinition.

Surely, over time this redefinition will happen—the situation will become dire enough and the masses will catch onto new trends that will right the ship.

The question is, how many more cycles of CMS implementation and redevelopment can we take before the industry as a whole starts to address the major problems that we are facing?

Get in Touch

In the past, we have addressed many of the important reasons to take website accessibility seriously.

Get In Touch