Datopian Presents: Headless DMS
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.
Headless statue by Mika on Unsplash
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. CKAN, an open-source DMS, 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 ‘front end’ part of a software, the part seen by the user, and the ‘back end’, the behind-the-scenes part. The back end 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 delivering stored contents to the front end. The front end acts as a renderer, turning stored contents into a themed display (e.g. a webpage). Traditional DMSs, which contain both a front end and a back end that run in the same process, are known as monolithic DMSs.
Sometimes, software engineers choose to decouple the front end of the software (the ‘head’) from the back end (the ‘body’). There are many reasons for doing this, and these will be explored further on in this article.
You may remember the software stick-person from a previous article - here they are again, but this time they have been decoupled, leaving a headless part and a head:
DMS head
Headless DMS
Why go headless?
Datopian believes that shifting focus away from monolithic DMSs to a decoupled DMS approach could significantly benefit data-driven organisations. There are two main reasons for this.
Reason 1: Greater specialisation
Using a monolithic DMS, in which the front end and back end 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 |
|---|---|
| Front-end and back-end 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 front end means updating the back end | As updating the front-end takes much less time than updating the back-end, what should be a speedy process takes an unnecessary amount of time. |
| You can’t choose the front end | Considering that there are multiple front end frameworks out there, why not be able to choose the best one to suit your needs? |
| Heavyweight instances | Scaling through replication means replicating the whole instance, not just the front end. |
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 back end to make changes to the front end. This way, it’s easier to find developers for either end, and data portals are cheaper, faster and more flexible to build.
Reason 2: Unlimited options
Monolithic DMSs 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 back end and one front end.
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 a smartphone/smartwatch app or a website. It can’t do this with a monolithic DMS. Neither could the company suddenly decide they wanted to have one front end (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).
"One body, multiple heads" diagram by Monika Popova
Option 2: integrate data and content from multiple sources (the ‘one head, multiple bodies’ approach).
"One head, multiple bodies" diagram by Monika Popova
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, i.e. with the back end and the front end unified as one system.
Recently, however, we at Datopian have been building a decoupled head for CKAN in javascript - PortalJS. This is already in production with a number of Datopian 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 PortalJS 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 (back end) in the DMS. This is far from ideal, as CMSs are good at what they do, given their rich admin UI and 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 take the side-by-side option. This would mean having to maintain two themes and have a bifurcated user experience (and you may have to replicate things like user accounts).
