The Drive Towards Headless - Digital Trends

A couple of years ago, I talked about web content management and experience delivery in the digital age. I discussed briefly broad level about delivering fine tuned user experiences across multiple applications through different integration patterns with WCMs and enterprise systems.

Ref: Web Content Delivery in the Digital Age. Part 1 and Part 2

Since then,I've had the chance to delve deep into headless CMS needs and capabilities, as well as continue to track industry trends, in particular ceaseless proliferation of digital devices and the opportunity and challenges it presents.

Adobe too have evolved their capabilities with new variations and enhancements to their fragment based content approach.

It's time to check-in on the

• How drive towards headless is shaping up,
• What are the lessons to learn in this space
• How is the industry responding

The Evolution - The Rise of the CDO

5 - 10 years ago, the company website was just a small transit stop for customers in their journey to interact in the real world with the organisation and do business.

In recent years this dynamic has shifted considerably towards favouring all interactions and transactions through web enabled devices.

Customers today are spoilt for choice they can access information, conduct transactions from almost any connected device , smart phones, fitness trackers, appliances, cars and the like. They've figured out how to make their digital lives seamless and expect no less from the companies whose services they avail.

Formal systems for document and records management are still critical underpinnings for business, but 'legacy tech' just can't keep up with such needs of agility. Combine that with the fact that organisations grow both organically and inorganically over time, acquiring different systems , processes and stakeholders all operating at different speeds, and you have an extremely challenging situation.

This gave rise to the CDO - Chief Digital Officer - having flavours of CMO, CTO, CIO , to chart a future in the wild wild world of digital and to help build experience platforms that can surface up critical information for consumers at the right time regardless of the medium

The Shift to Headless

Implementations like multi geo websites across 90 countries , supported by 100s of cross-geo authors, supporting a mixture of inherited and localised content are , dare I say it, standard today. Technology has caught up to the point where such scale and associated flexibility is pretty much expected.

However, today , we're taking a step back and addressing a fundamental shift in understanding what content and experiences are actually are. There is an increasing need to allow management of content as core building blocks , that can be managed in real time, independently syndicated, and assembled into tailored experiences where-ever, when-ever.

The need of a new mindset

Crucially, this problem is not going to be addressed simply by a technology solution - There is a need for an organisation to re-think , re-align and even re-build its information, experiences and content process in the manner.

i.e. To be able to take all information about all its services , normalise it and break it down into immutable building blocks, maintained in a content or repository , which when assembled on demand , give rise to experiences relevant for a channel.

The content repository would be maintained as a pseudo System of Record for all Systems of Engagement and we'd have to have a new role - Experience Authors - i.e. one step above raw content authors that would facilitate how the individual building blocks combine to create a great experience.

Such a capability would not be limited to authored experiences either. The repository would almost invariably have to be exposed through APIs, allowing same level of recombination to consuming apps and thus allowing systems in realtime to dictate the kind of experiences they need.

This, if done end to end across experience as well as transactional processes it may even allow for the capability to bring new products to the market much much faster

Imagine, for a customer of a bank, being able to build their own home-loan, just as they are able to build their own pizza !!!

Also, that last line should have given you a hint - this mindset is not completely new or hidden, it is very much prevalent in other industries to a degree at least for product based processes in retail and consumer telecom, albeit in a limited context

Standard vs Headless

Many organisations are heavily invested into content management systems and are keen to tap into the headless trends - however, trying to fit an existing tech into a new paradigm can be tricky and costly if we don't consider the core differences and strengths of each.

Standard CMS

It is the master of the user experience, and owns the look & feel, the copy, as well as the functionality of what is delivered to the end user. In general , users directly access the CMS as the first point of contact.

Design Considerations

• Type of Payload:A web page with all the bells and whistles - heavy HTML / XML markup , CSS, JS associated links. Heavy to large payload >350KB
• Best Fit: Experiences consumed through a web browser directly e.g. Brochure ware sites, static sites, ecommerce portals, transactional sites, SPAs hosted within the CMS etc.
• Poor Fit: Business logic heavy apps with little content management needs, experiences needed through other channels e.g. ATMs, smart watches etc
• Tech Considerations :Standard web request / response patterns , infrastructure considerations ( e.g. CDN , WAF ) , Browser compatibility , CX design, UX / UI build etc

Headless CMS

A CMS without the responsibility of owning the end user experience. It typically provides content to be rendered by the consuming app or channel. JSON is typically a common format for payload delivery but can pretty much be anything based on needs.

The consuming app / channel is responsible for validating the payload, and rendering it appropriately for the end user , implementing any business logic it needs to.

Design Considerations

• Type of Payload: A content feed - typically JSON - small size and broken up into components. Should be limited to few KBs to 100Kb max
• Best Fit: Experiences consumed through digital devices and across channels , including providing content to SPAs, digital watches, virtual assistants, mobile apps etc
• Poor Fit: Delivering traditional websites / microsites

Tech Considerations

• A metadata driven content and experiences repository / dictionary
• APIs that inform the consuming channel of available affordances
• Styling prompts / metadata in the payload to guide consuming channel
• Level of coupling - Loose - just raw payload no styling / Tight- stylised HTML fragments that drop right into visual design of consuming applications
• Link processing / management as headless CMS may be a few layers below the consuming app, but may still deliver links in the payload
• Costs can increase if you also need to build for the consuming application to render the final experience

Which one wins ?

Both! - Based on your need

Based on my experience - shifting gears and going full headless may not be needed.

Significant investments made into mainstream standard experience platforms that power flagship websites of major organisations are not suddenly made redundant.

Try delivering a full website , with complex navigation structure that have a high degree of WYSIWYG type of content management requirements through a headless CMS - you may end up paying quite a bit more than you bargained for.

At the same time, if you need to provide an experience to multiple departments, based on a single source of truth for experiences, then building a separate websites , catering to different authoring needs, look and feel rendering, design and branding etc - may become too expensive - try the headless route and have each department own the rendering of that experience.

What is necessary is to establish a road-map and maturity curve for organisations for at least

1. Omni Channel Experience Strategy
2. Experience / Content Repository

And then based on the above, chart their paths ahead adopt different suitable patterns for suitable use cases.

Adobe's response to Headless

Of late, Adobe have been investing more into their content fragments setup and are promoting their version of a head less CMS. Some of my initial thoughts are here

I've had the opportunity to work with these latest capabilities as well as look at their SPA editor.

While it is impressive and does show a commitment on Adobe's part to embrace this trend, I still feel that they need to go much more farther.

A CMS that exposes its content via APIs may be very helpful in transition but it is not enough to be a true headless CMS

Double Authoring

Based on how the product behave, I believe there is still too much focus on using fragments and building blocks built into web pages built in AEM as a starting point . i.e. It seems there is still the assumption that any fragments you create, to expose them , they must be authored into a web page / web fragment somewhere in AEM Sites to syndicate and to use - That seems like a lost opportunity to me , and not true headless

For example- Creating fragment / variations / building blocks - are all in DAM, yet there is no direct Content Services to expose DAM Fragments directly based on the taxonomy. We can use AEM's default JSON feed, but that brings all manner of extra metadata e.g. last modified by , last replicated etc, that we simply don't need

Content Services required one to author the fragment onto a page and then expose it appropriately. This simply doubles the authoring load for content that is only ever going to be used in a headless format outside of AEM

Custom Data Types for Fragments

As of 6.3 / 6.4 there were very much limited capability to define complex data types for fragments. Documentation or samples were scared

I believe this will change, and we did get good guidance from their consultants. I hope with the upcoming 6.5 they do start to embrace true headless CMS

Am looking forward to the upcoming Adobe Summit to see what develops

In the meantime, there are also quite a few interesting players in this space, not the least of which Butter CMS - worth checking out to see what they are doing.

------------

That's it for now - I may do another post on design archetype of what a headless CMS may need to consider. What's your take? how is your organisation adopting this paradigm and delivering experiences for digital - feel free to write in the comments below.