By Annabel van Daalen and Rufus Pollock, with graphics by Monika Popova
In a previous article, we drew an analogy between CMS (that’s ‘content management system’) and DMS (‘data management system) to show how the two software share a similar structure. Now, in this follow-up piece, we’re going to show how DMS have always been one step ahead of the game when it comes to a novel software trend: headlessness.
Introduction
If you’ve not heard of Headless DMS before, that’s because you’re reading it here for the first time. However, while the term may be new, the concept itself is not. The open-source DMS CKAN has been operating headlessly for years - the term headlessness just didn’t exist yet. It wasn’t until CMSs began calling themselves headless that the name gained traction. Here at Datopian, though, we were working with headless software long before it became cool.
In order to understand how Headless DMS - and specifically CKAN - is significantly improving the ways in which organisations manage their data, we first need to clarify a key term: headlessness.
What does it mean for a software to be ‘headless’?
To understand headless software, we first need to know some basic information about how software is structured. In software engineering, a distinction is made between the ‘frontend’ part of a software, the part seen by the user, and the ‘backend’, the behind-the-scenes part. The backend is made up of a storage component (e.g. content repository or database), an editor (e.g. an admin user interface) and an API, which is a tool for delivery stored contents to the frontend. The frontend acts as a renderer, turning stored contents into a themed display (e.g. a webpage). Traditional DMSs, which contain both a frontend and a backend that run in the same process, are known as monolithic DMSs.
Sometimes, software engineers choose to decouple the frontend of the software (the ‘head’) from the backend (the ‘body’). There are many reasons for doing this, and these will be explored further on in the article.
You may remember the software stick-person from the precursor article - here they are again, but this time they have been decoupled, leaving a headless part and a head:
Why go headless?
Datopian believes that shifting focus away from monolithic DMS to a decoupled DMS could significantly benefit data-driven organisations. There are two main reasons for this.
Reason 1: greater specialisation
Using a monolithic DMS, in which the frontend and backend are tied together, limits the extent to which each function of the DMS can be customised. The following table demonstrates the limitations of monolithic DMSs:
| Limitation | Description |
|---|---|
| Frontend and backend development requires different programming languages | In the case of CKAN, front-end developers would have to install Python just to be able to do a small amount of HTML and CSS work. |
| Updating the frontend means updating the backend | As updating the front end takes much less time than the backend, what should be a speedy process takes an unnecessary amount of time. |
| You can’t choose the frontend | Considering there are multiple front end frameworks out there, why not be able to choose the best one to suit your needs? |
| Heavy-weight instances | Scaling through replication means replicating the whole instance, not just the frontend. |
By decoupling the head and headless part of a DMS, we can build both parts using the latest technologies and practices specialised for each purpose. It also makes life easier for data portal developers, who now don’t have to worry about tackling the backend to make changes to the frontend. This way, it’s easier to find developers for either end, and data portals are cheaper, faster and more flexible to build.
Reason 2: more options
Monolithic DMS can no longer keep up with the changing demands of users. Nowadays, users want to be able to integrate multiple sources, or push data from one database to multiple systems and devices. This is not possible with a monolithic DMS, which can only provide one backend and one frontend.
For example, imagine a company using a DMS no longer just wants to display their data through the ‘attached’ data portal, but also wants to push this data to smartphone or smartwatch apps, or a website. It can’t do this with a monolithic DMS. Neither could the company suddenly decide they wanted to have one frontend (e.g. a data portal) that integrated information from multiple sources.
Let’s look at the different options presented by decoupling in turn.
Option 1: push data from one database to multiple devices (the ‘one body, multiple heads’ approach).
Option 2: integrate data and content from multiple sources (the ‘one head, multiple bodies’ approach).
Where does CKAN fit into all of this?
We mentioned earlier that CKAN was operating headlessly before headlessness became cool. Back in 2010, CKAN was used in headless mode to build data.gov.uk. Nowadays, most of our clients use CKAN as a monolithic DMS, so with the backend and the frontend unified as one system.
Recently, however, we at Datopian have been building a decoupled head for CKAN in javascript, called frontend v2. This is already in production with a number of Datpian clients, and allows us to deliver CKAN in two pieces - the headless component and the head. We are currently working hard to make the head even better using the latest frontend technologies, React and Next.js.
From the perspective of our clients, not much has changed in terms of the way they use CKAN. However, deploying CKAN in decoupled mode improves their overall experience with the software. This is because frontend v2 makes it easier for clients to integrate content and data from both DMS and CMS for unified display via the same ‘head’. This is all made possible by CKAN’s rich API.
This is the future
As mentioned earlier, through our work on CKAN, Datopian were fine tuning their approach to headless software years before it even became cool. Thanks to recent developments in content management, we’ve now been able to give it a name: headless DMS. You heard it here first.
Technical Appendix:
There is currently no straightforward way to create unified front ends that integrate content and data. Here are some of the possible options:
- You start to develop a CMS (backend) in the DMS. This is far from ideal, as CMSs are good at what they do - they already have a rich admin UI and a good structure.
- You put the DMS in front of the CMS (i.e. replicate content into the DMS). This would mean having to replicate content into the DMS and you have to develop theming in the DMS for content.
- You put a CMS in front of the DMS. This is even worse, as data portal functionality is data focused, so you now have to replicate that functionality into the CMS.
- Or, you do side by side. This would mean having to maintain two themes and have a bifurcated user experience (and you may have to replicate things like user accounts).
Top comments (0)