Peter Marsh

A long time ago, while Betamax battled VHS for videotape supremacy, another war broke out among suppliers of content management systems for publishers. Back then, we didn't even call them content management systems. Integrating text and graphics was still a pipe dream for most in the mid 1970s, so people referred to these things as text processing systems, or editorial systems, or sometimes simply, databases.

Digital Equipment Corp. won the early platform battles. Vendors like Atex, CSI, Harris and Hendrix/Hastech developed text-processing systems based on DEC minicomputers. These systems were designed to help journalists, editors and production people automate the whole collaborative workflow process for publishing newspapers, magazines and trade journals.

Two-party system

Along came System Integrators Inc. in 1979, bringing to the publishing market a text-processing system based on fault-tolerant computers from a company called Tandem. The minicomputer duopoly war was on. The Tandem platform was appealing to publishers because of its fully redundant “NonStop” architecture. This meant, in theory, that an SII system powering a 24/7/365 news operation would never go down. One-hundred percent uptime. During sales presentations, SII would demonstrate how an engineer could swap out a printed circuit board in a Tandem computer while it was still running, and the users wouldn’t lose even one keystroke. Journalists, editors and IT people loved it.

Of course, this platform war quickly became more than just a two-party contest. Companies like Digital Technology International (DTI) latched on to the industry’s preference for a newsroom system that could operate continuously with no single point of failure. Using Sun Microsystems hardware and UNIX-based software, DTI developed an editorial platform that boasted complete fault tolerance due to its resilient dual-server architecture. DTI was also one of the first industry suppliers to offer publishers the choice of running on either Sun/UNIX or Windows NT servers.

A new platform war

While other vendors continued to develop content management solutions based on server technologies from companies like Data General, Unisys, IBM and others, another revolution was happening directly on the front lines — the users’ desktops.

People in all industries, and across all walks of life, were choosing between Microsoft Windows personal computers and Apple Macintoshes. It was 1984, and the PC vs. Mac microcomputer war officially began. Existing content management vendors re-architected their systems to take advantage of these desktop platforms. Dumb terminals were replaced with PC or Mac workstations. Several upstart companies entered the fray with content management systems that relied on souped-up PC or Mac computers as their back-end servers.

Companies like Saxotech, Miles 33 and Dewar brought to market PC-based content management solutions using Windows PCs as editorial workstations and NT machines as servers. Baseview, P-Ink, Quark and others countered with systems that were entirely Mac-based.

One of the most revolutionary — but unfortunately, least successful — content management solutions to emerge from this era was the Information International TECS/2 system. Originally built by the Morris Newspaper Group, TECS/2 was a PC-based editorial system designed around the Proteon token ring network. The idea was that the server could never go down because there was no server. Each journalist’s stories were automatically backed up on another PC somewhere on the network. If that journalist’s PC failed for any reason, he or she could find the backup copies on another PC on the network. Locating these backup stories turned out to be one of the biggest challenges, along with the Christmas-light effect that often occurred when one node on the token ring network went down.

Nevertheless, during this desktop era, our digital democracy continued to flourish. Publishers had the freedom to choose a content management system that fit their business needs as well as their microcomputer platform preferences.

Flash forward to the web

The rules changed again around the turn of the century with the advent of web content management technology. Companies like Vignette, Interwoven, Polopoly, Ektron and others developed proprietary systems that enabled publishers to manage the presentation and delivery of content on their websites.

Back then, these systems were typically interfaced with a publisher’s editorial CMS to exchange content between online and print channels. Most of these solutions were installed on-premise in a company’s computer room or data center, but some — like Clickability — were hosted using early software-as-a-service models.

A few publishers, hearkening back to the days of Morris, decided to build their own platforms. The Ellington system is one example. Developed by the Lawrence (Kansas) Journal-World for its own internal web content management needs, Ellington was spun off into a separate division called Mediaphormedia, which provided sales, support and services to other publishers looking for a platform built specifically for news media companies.

Proprietary eventually gave way to open-source technology, and a new platform duopoly ensued. Publishers now had two basic choices: buy a purpose-built CMS solution where the vendor is responsible for creating, modifying, managing and expanding the source code, or select an open-source system where the source code can be inspected, modified and enhanced by the vendor and/or by the publisher’s in-house development team.

The open-source option grew in popularity over the past decade or so, thanks largely to the extensibility of these platforms and the global community of developers constantly enriching the source code to add new functionality. Favored open-source content management solutions included WordPress, Drupal, Joomla, TYPO3, Magento and many others. Of these, WordPress and Drupal quickly emerged as the preferred platforms of choice among news media publishers.

With WordPress, a publisher gets a web content management platform that’s quick to install, easy to learn and straightforward to manage. WordPress also has market share on its side, powering over 30 percent of the world’s websites. Drupal-based systems can be more complex to implement, but this complexity often translates into greater configurability for large, multi-site environments. In addition, the launch of Drupal 8 gives Drupal the edge when it comes to website cybersecurity protection, data breach detection and real-time reporting.

Coupled, decoupled and headless CMS

But wait, there’s one more thing to consider. In the democratic world of web content management platforms, publishers can now choose between three deployment options. With a traditional or coupled digital CMS architecture, the back end is tightly linked (or coupled) to the front end. Content is created, managed, and stored on the system’s back end. Website design, applications and other digital assets are also stored on the back end. Journalists write and publish on the same back end that website visitors are viewing. The front end in a coupled CMS environment is mainly responsible for presentation — i.e. displaying published content on the site’s HTML web pages.

By contrast, a decoupled CMS architecture separates (or decouples) the back-end database from the front-end presentation layer into two separate components. Content creation and storage are managed in the back end, while content delivery and presentation are managed in the front end. With a decoupled architecture, journalists create and edit content in the back end, just as they would in a coupled CMS. The difference here is that a decoupled architecture takes advantage of web services and APIs (application program interfaces) to deliver this content to any front-end web design on any device and any digital channel.

For publishers that want to build or integrate their own front ends, the headless CMS option is often most attractive. A headless architecture is akin to the decoupled model, as both consist of a content management and storage back end where content is delivered from the database through an API.

The main difference lies in the presentation layer. A headless CMS can connect to any publishing front end, meaning content can be delivered to any device or digital channel. In effect, it’s the Independent Party of the CMS deployment triopoly. Because content is not bound to a predetermined user interface, a headless CMS allows the same content to be published independently to a website, an app, a wearable device or any device connected via the Internet of Things (IoT).

So many options, so little time!

The point is, news publishers today have more content platform choices than ever before. This is vitally important to an industry craving a technology solution that gives journalists and editors a single view and a single point of access to all content. In the old days, this simply meant text. But now it means articles, archives, graphics, images, video, audio and all social media assets delivered to almost any Internet-connected device imaginable.

Content will always reign supreme. But, the platform on which it runs will remain a democratic process where freedom of the press meets freedom of choice.

Peter Marsh is vice president of marketing at Newscycle Solutions, a provider of content management, advertising and subscription management solutions for news media companies.

(0) comments

Welcome to the discussion.

Keep it Clean. Please avoid obscene, vulgar, lewd, racist or sexually-oriented language.
PLEASE TURN OFF YOUR CAPS LOCK.
Don't Threaten. Threats of harming another person will not be tolerated.
Be Truthful. Don't knowingly lie about anyone or anything.
Be Nice. No racism, sexism or any sort of -ism that is degrading to another person.
Be Proactive. Use the 'Report' link on each comment to let us know of abusive posts.
Share with Us. We'd love to hear eyewitness accounts, the history behind an article.