Should we be separating our data layer from the system that presents this data?
Then Content Management Systems (CMS) came along and allowed us to enter our data into an editor of that CMS. Then we would add some special CMS language code to display our data in our web page. Even though the data was a bit more separated and abstracted from our actual code, it was still tied very close together. If you didn’t have the CMS, you didn’t have your data either.
Now we are into 2018 and there are devices that enable us to have a presentation layer on TVs, desktops, laptops, tablets, phones, watches, chatbots, speakers that can input/output information through voice and other Internet of Things (IoT) devices. Now, instead of one system to enter data, we have many systems that we have to keep track of our data layer.
This poses a concern that companies are going to have to address. How do companies manage all theses systems with their data layer and other companies presentation systems? Are companies going to duplicate the data on their website into their mobile app as well? That means when they make an update to the data for their website they also have to update the data on their mobile application, their chatbot, or any other system that they present data on. Do companies continue down this road for all the new technologies that are coming out; tying the data directly to the system that displays this data; or is there a better solution?
A Better Solution
Think of this example. Your company has a website that has the typical about page, contact, faqs, services, an events section, and a blog that displays company news. You have all these sections displaying on your website. It’s great. But now you want to create a web app, a mobile app and a chatbot. Your web app and mobile application will share similar pages that your website has like contact information, services, information about your company, and your blog resources. Your company also wants your chatbot to have access to this same information as well as the faq section. These systems all have their own platform and editors to input this information and you end up duplicating it all. Plus, if you make a change, you have to change it in all those places.
But, by decoupling your data from the presentation system that holds this data you increase your productivity, reduce errors, and create this “one source of truth”. You could then export this data in JSON format, which can be consumed by most systems today. Your chatbot for example, can access your faqs by importing this feed. Or your web and mobile apps can consume the same JSON feed to display contact information, without you having to enter it in two places. The more data you have, the bigger this problem becomes.
There are some great systems out there right now to help solve this problem. Companies like Contentful, Prismic, Directus, Cosmic js, and Cockpit. These companies are building a separation of the data layer and presentation layer. A new type of CMS has evolved…the API-based CMS or Headless CMS.
As we continue to add new technologies and new ways to interact with companies and their data, we need new ways to manage this data across all of these systems efficiently and effectively. As a development team here at Bigfish, we are always looking for the best ways to help our clients manage their data and the best ways they can position themselves to display this data. The headless CMS seems to be a great solution to a growing data/presentation problem, and one that we will be exploring more.