Getting your head around headless content management

The event opened with a (very) brief introduction on what a Headless CMS actually is, and a few points on why you might consider one, or in other words, why you might be attending this event! We then moved very quickly into a discussion with the panel. 

The key questions asked during the course of the conversation were:

1. What do you see as the main drivers for choosing a headless approach?
2. Can you give an example of where headless has been really effective for an organisation?
3. If an organisation was just building a website, should they consider headless?
4. What are the costs involved in headless compared with a more traditional approach?
5. Does taking a headless approach create a need for any new skills or roles within an organisation?
6. What are your predictions for the future of headless?
7. If you were going to give one piece of advice to people considering headless, what would it be? 

We then went to the audience for some questions, which covered personalisation, each vendor's key advantage over the competition, and whether this spells the end of back-end development!

The panelists

Contentful

Kentico Cloud

Acoustic

Sitecore

The video

More Q&A

We ran out of time to answer everyone's questions, but thanks to the magic of the Internet, we can continue the conversation here! I took the remaining audience questions from Slido to our panelists to see if they had any further thoughts to add, and was not disappointed! Read their thoughts below.

How about headless for small businesses or is it strictly an enterprise product? (Does Contentful, for example, plug into WordPress?)

Boris: Headless can definitely be utilised for small businesses. We have quite a few examples off small to medium sized businesses using Kentico Cloud. There is no plugin for WordPress, but any developer familiar with AJAX can pull Kentico Cloud content into your WordPress sites.

Paul: Headless tends to work better for organizations that have in-house frontend development skills, or work with an agency (like Luminary) who does. Often small businesses don't have ready access to these skillsets, so you really have to evaluate why you need headless (flexibility, scalability, agility) and if you have the right team to go that route. As for Contentful plugging into Wordpress, yes, we have customers who run them in tandem. For example, a large retailer with 400 stores has a Wordpress site that each local branch can update with local information (event calendar, regional promotions, etc), with a central Contentful backend managed at HQ that pumps "corporate" content into each of the WP sites (legal, product info, etc.). They are evaluating migrating all the sites to Contentful, but this is a familiar use case we call "pilot-in-parallel" where customers run their existing setup in parallel to Contentful while they replatform. 

Mick: Small businesses can benefit greatly from headless. Moving into an API based consumption of data and layout, this opens up more flexibility to app build technologies that can be build at a more rapid pace and deployed on more varied hosting to help reduce costs. On top of this, static site generators are now available for a lot of small business type applications, again aiming to reduce costs while also increasing performance

What is the adoption rate of headless CMS in Australia?

Mick: There is a rapid uptake of headless applications being built. CMS in general has such a long history, that headless is just a natural progression. Most popular front-end frameworks are supported, so the barrier for entry into this is very low.

Boris: We see more and more traction and we assume that headless is in the early adopter or early majority phase right now: https://kenticocloud.com/blog/state-of-headless-cms-market-2018

How do you deal with system and data fragmentation in a headless world?

Boris: This can be challenging, but if the architecture is designed appropriately we don’t see any issues you wouldn’t see otherwise in monolithic systems as there are always some integrations even with those. In general, content, assets and even configuration and other data can be stored in your headless CMS, so data fragmentation can be even lower.

What are some of the common obstacles that clients run into when migrating to a headless architecture?

Boris: SEO is a big area where additional care has to be taken during the content modelling phase as you need to account for it early on. Additionally, as already discussed during the panel event, the change of mindset to a content first one can be quite challenging at times: https://hackernoon.com/headless-cms-first-change-your-mindset-e9f6d8b6a41e

Mick: Not thoroughly thinking through their data model, and the problems they are trying to solve. It is easy to build complex applications when simpler solutions will suffice. Map and plan out the solution and data structures first, then map that into your layout requirements.

What’s next for headless CMS? Is it at the state of maturity?

Mick: Definitely not at maturity. We are seeing a convergence of artificial intelligence capabilities now forming part of headless offerings. All applications resolve around dynamic data, so to ensure that this process is as easy and efficient as possible, all while providing relevant data to the end customer, AI is helping to bridge that gap, supporting what data is returned in a more automated fashion.

Boris: I’d definitely say it’s mature enough to be considered for any type of project and scale. As mentioned above, we are probably in the early majority phase so vendors will have to scale up to provide the best customer experience for all of their customers.

Headless is not a silver bullet. What can't it do?

Boris: It’s a solution for all your content needs from the idea phase to the, production, delivery, personalisation and optimisation phases. Everything else should be handled by other best of breed solutions.

Has the rise of headless resulted in new marketplaces for heads?

Boris: Currently there isn’t a bespoke marketplace, however you’ll find plenty of “heads” on GitHub.

Mick: There are always opportunities for new markets. We see this opening up in the headless space as well. Building fully formed component and layout based frameworks are becoming more prevalent. Examples of this can be seen in the commerce space, where B2C sites are mapping directly into headless technologies. The same is happening for CMS, where SDK frameworks are being built on to support the scaffolding and easy creation of sites and applications.  

What will be the role of backend developer in headless CMS technology?

Mick: Backend developers are still required to map complex solutions, specifically around architecture. Data models also still require mapping, and depending on the headless solution technology, any customisations that are required will still typically need a backend developer to support. Heads for headless solutions aren’t tied to front-end frameworks. There is still widespread usage and offering of .NET SDK’s which is a great evolution for backend developers.

Boris: The backend developer will be still vital to connect best of breed solutions and to build your integration buss for your services if required. Custom logic might be required for some internal business processes which can’t be handled by 3rdparty services due to data sensitivity or due to your specific requirements.

Paul: One example is teams who build APIs to orchestrate different systems in their Martech stack. For example TELUS, one of Canada's largest telcos, built a Personalization API to act as middleware between Contentful + Adobe + AWS Lambda: https://www.telus.com/en/on/digital/blog/scaling-personalization-and-b-testing-telus

How would a traditional content team create, edit, and publish content in headless CMS who may not have technical skills?

Boris: Our headless CMS is built for exactly these teams. Once everything (all your channels, such as your website, app, chat) is setup you’d be working with an easy to use content production, collaboration and  delivery tool which is able to cover your content needs throughout the whole content production process. 

Paul: Some headless CMSes have a rich text editor that is great for editors who don't have technical skills (e.g. don't know Markdown, the only way to create and manage text in many headless CMSes). For example, Contentful's content editor is very familiar to editors who use traditional CMSes, with the added benefit of creating atomic, structured content on the backend for developers: https://www.contentful.com/developers/docs/concepts/rich-text/

Mick: This is largely dependent on the headless CMS system. It is pivotal when building any application with dynamic content to think of the content team. This team is the one who is working day-to-day in the system being created, so ensuring they have the most efficient and easiest data model for them is paramount. Content teams should not require technical skills, it should be intuitive for them to view a form of WYSIWYG editor, or in-line page editing experience that enhances their experience.

Can you share an example of someone getting headless wrong?

Boris: Regrettably I am not familiar with failed projects, but there have been some difficulties in the content modelling phase which once we got involved were quickly fixed. That’s why to have someone available to help you with content modelling is so important. http://bit.ly/ContentModeling

Isn't headless just the next fad (similar to front end technologies)?

Mick: Not a fad by any stretch of the imagination. Headless has been around for a long time, and has been a natural evolution into the fast changing landscape of application development and design.

Boris: We don’t think so. There is no replacement for headless as far as we can tell. I’d even argue that comparing headless with front-end technologies isn’t possible. A headless CMS is an evolution of content management systems as a whole.

Do developers need a specific skill set to work with headless CMS and if so, is there enough talent in the market to keep up with the demand?

Boris: I don’t think so. The beauty of a headless CMS is that you can use your favourite technologies and thus the developer pool compared to monolithic CMSes is much larger. 

Mick: One of the great things about headless CMS’s, is there is a variety of options available to select a technology that fits the organisation building an application or site. Front-end developers skills in JavaScript have a very low point of entry to move into a headless world, as most SDK’s support all modern day frameworks, e.g. Angular, React and Vue. This also extends to other backend languages such as .NET, PHP, Java etc.

Paul: That is the great thing with headless, it's agnostic to the frontend tech. You can use Java, .Net, Swift, JS, and any of their associated frameworks. Contentful provides SDKs for all the major languages so it's easy to get started, and with the launch of our GraphQ API, it got even easier for developers from any background to dig in.

Can we migrate some content and document types from one environment to another? e.g. Staging to production. If not, what the strategy can be?

Mick: Each headless technology supports this in various different ways. This can be from package management, serialisation techniques, data migration of databases, technology specific import/export functionality etc.

Boris: Yes, you can achieve that with our API and a built in solution is in the works and will probably be released in a couple of months.

Converting existing sites to use headless - Effort? Recommended approach?

Boris: As with any rebuild, the recommended approach depends on the project type. As mentioned during the panel, I’d strongly recommend to commence a content audit and to do a content modelling workshop to discover your content strengths and weaknesses before doing just a migration.

Mick: This can vary, largely being dependent on the existing site technology and build. We have seen existing React applications being relatively simple to port across into headless CMS based applications, as most SDK’s try to stay out of the way of the front-end technology as much as possible. With each area or component of the existing build, will need a data mapping strategy to understand what types of data and the field types required. Alongside this, determining how these components would map into page level data models, as well as re-usability and inheritance mapping is key to ensuring a smooth transition.

Is there scope for headless to revive or bring new utility to channels that may be considered outdated? Accelerated Mobile Pages and Gmail with headless as an example.

Boris: It’s possible. The beauty of headless is that you don’t have to worry about any past, present or future channels if you create a content model with highly adaptable and reusable content. Delivering that content to any channel is much easier than dealing with content only written for one channel, such as the web.

Comparing all products here today. What capabilities for personalisation and optimisation are available with headless?

Mick: Sitecore has a long history of providing personalisation, optimisation and in-built in-line page editing experience capabilities. Sitecore’s headless offering is a no-compromise solution, ensuring that all the features and functionalities of the core product are fully supported in a headless based application or site build.

Boris: There are already integrations available covering the personalisation and optimisation angle and we are adding new ones as we go: https://kenticocloud.com/integrations?categories=data_analytics___intelligence & https://kenticocloud.com/integrations?showComingSoon=true

Paul: Contentful takes a different approach than many of the more tenured vendors: we are not trying to rebuild a full solution like Adobe, but rather be laser-focused on cloud-based content management (which we call content infrastructure). We integrate with other vendors who have the same focus in their respective space.