Edit

By Paul Regan 30 January 19



Why content management is losing its head

Your run-of-the-mill CMS has stood still for too long and cannot cope with the new digital era. Here's why.

COPE – the content workflow principle of ‘create once publish everywhere’ – has been with us for nearly a decade. It talks of the benefits of separating how assets are stored from the way they are presented, allowing multiple instances of a product (or indeed multiple products) to be run from a single source.

Initially this was driven by any good developer’s inclination for innovation and efficient technology, but now the demand for COPE comes from end users. People want to interact with digital products using many more devices, which means brands need to consider a ‘headless’ CMS.

Headless content management is typically a back-end content store accessible via RESTful API and completely abstracted from front-end presentation. This central bucket of ‘raw’ content can be displayed across websites, apps, connected televisions, games consoles, smart watches (you get the idea) and even help manage consistent user journeys across devices.

Apart from the benefits to UX, this also brings significant back office efficiency, allowing editors and content managers more time to focus on content creation by wasting fewer hours managing parallel workstreams. Engineers can get in on this too – headless systems are a more natural bedfellow for agile working, which increases speed to market.

Edit has its roots in API-first technology that has been powering digital product in the headless manner for several years. Our flexible editorial interfaces in one case manage a single pot of content distributed across 59 different websites, bringing huge efficiency and allowing the process to be tailored to the needs of its operators.

So why do so many brands persist with inflexible legacy systems? Technical debt. We see many examples of companies building on incumbent systems to solve a problem they were never designed to address – Wordpress being contorted to run headless, Drupal running all manner of plug-ins and extensions.

Which brings us to the last of the key benefits of many headless set-ups: a microservices architecture. Working in an API-first manner often means using a collection of loosely coupled services. In the case of Edit, we have an API, our editorial interfaces, image manipulation tools and even a front-end templating layer (which, along with almost any other solution, can act as the ‘head’ to your headless Edit set up).

Apart from making Edit easier to develop, to test and to scale, this modularity future-proofs the platform by avoiding commitment to a monolith (and usually licenced) platform. It also means individual components can be upgraded or used alongside legacy technology which would otherwise be difficult to replace.

In other words if you want to run headless but think your existing CMS was standing in the way, it isn’t. Talk to us about a demo of Edit today and we’ll show you how we can help.

Edit