Thursday, February 24, 2022

Headless vs. Hybrid — Choosing an Enterprise CMS System

Headless vs. Hybrid— this is one of the most critical questions raised when organizations identify a new Web Content Management platform for their organization. The answer to this question is not simple and based on the business needs and other factors like current platform, resource skill, etc. In this post, I am talking about choosing the enterprise CMS system Headless vs. Hybrid based on my understanding; the process will vary based on your needs and current state( Happy to receive feedback ).

Let us quickly see some of CMS architecture patterns.

Traditional(Coupled) CMS architecture:

A Traditional/Coupled CMS knits the front end and the back end layers into a single stack.

  • also known as monolithic architecture
  • the tight connection between the back end and the front end layers
  • Managed through a single platform
  • Back end + front end(in the same system)
  • WYSIWYG editors and templates — content authors can quickly create the content/pages.
  • Example — WordPress Traditional CMS

Typical Headless architecture:

headless CMS is a back-end-only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.

  • Offers the backend for content storage and management
  • API First Development
  • UI is separated(Independent of backend) needs to build the experience layer outside CMS.
  • Content-as-a-service (CaaS) API — omnichannel content delivery to any platform/device, REST, and GraphQL API endpoints are supported.
  • CMS has no predefined front end with standard templates for displaying data
  • Backend + API
  • Lack of WYSIWYG editors or templates/components for in-context page editing
  • Example — Content Stack and Contentful

Hybrid Architecture:

A Hybrid CMS (or Hybrid Headless CMS) gives you the freedom and APIs of a headless CMS with the marketer-friendly functionality of a traditional platform.

  • Combines the features of traditional and Headless CMS
  • the backend is separated from the front end by an API
  • either use out-of-the-box templates/components for delivering content to the web or transmit your data to other devices via an API
  • Backend + API + frontend
  • Not API First Development
  • WYSIWYG editors or templates/components for Enhanced in-context page authoring
  • Inbuilt UITraditional Websites) + External UI(Headless Websites/Apps)
  • Example — Adobe Experience Manager(AEM) and dotCMS

Let us now see some high-level challenges and positives for headless and hybrid architecture.

Let us see some CMS-based scenarios and the architecture suited for that scenario.

Website Only — the organization requires only websites, a traditional or hybrid CMS might fulfill the need.

App-Only — the organization is focused on an app or IoT, with limited editorial requirements; a headless CMS or Hybrid CMS might fulfill the need.

Mixture — the organization requires rich web content, URL handling, extensive editorial requirements, and reuse across different channels; a hybrid CMS might be the solution.

Based on the above use cases, this makes sense for some of the organizations to have two different platforms to manage headful and headless use cases; this will introduce management overheads and increase the implementation/operational cost.

Let us now see some implementation architecture with the headless and hybrid model.

Business Unit Specific Headless Architecture:

In this model, the global team creates and manages the content while the experience layer is hosted and managed by the individual(BU) teams.
The benefits of this model are the content is reusable, as it is hosted through a global CMS platform, while the BU teams will have the required flexibility to manage and host their websites and apps (Experience Layer). This model enables the individual BU's to manage their changes separate from other BU teams or global teams.
My view is that this is a more suitable architecture for the headless CMS. The CMS team manages the content globally, but each BU is in charge of its experience layer — the only concern is that BUs rarely have their development resources and hosting platforms; setup intern increases the overall cost.

Global Headless Architecture:

In this architecture, globally manage content and the experience layer, but at the same time, individual apps can consume the data as required. The benefit here is the global platform manages both content and experiences, which will help to reduce the operational cost. But the concern here is building a global FE platform that supports all the websites/experience requirements and managing the platform.

Global Hybrid Architecture:

In this architecture, the content is managed through a global platform; also, most websites are hosted into the same Hybrid platform using the templates and components enabled by the platform. At the same time, the content can be consumed by other channels through the content as a Service API whenever required. The benefit of the architecture is the single global platform managing the content globally and most of the websites while allowing to consume the Content through APIs to support omnichannel requirements. Some constraints are platform impact due to global changes, content duplication, component duplication, etc. — a robust platform governance process is required to minimize the impacts. Another constraint is locked down with the single vendor, which may create issues if any plan to migrate to a different platform.

Let us quickly see some of the essential parameters to evaluate while identifying the new CMS platform.

Complete/Centralized Platform:

The "Complete/Centralized Platform" is more about platform vs. stack; most of the Hybrid platforms provides the end to end capability to manage the business needs on a single platform, the same time Headless CMS system enables the content management stack(some headless tools enables additional capabilities) but need other toolsets e.g. hosting platforms, maybe a caching layer, etc. to enable the complete platform.

Authoring capabilities:

Flexible authoring capabilities

  • enables authors to manage content and pages with less developer dependency
  • authors can do WYSIWIG in-context page/content editing
  • Create structured data for omnichannel delivery, tagging, etc

The hybrid platform enables in-context page/content editing, but at the same time, Headless platforms focus more on content editing.

Reusable Templates and Components(Headful):

Reusable templates and components to support traditional website delivery, the author should quickly use the existing templates and components to build new pages without dev dependency. Most of the Hybrid platforms enable the reusable template/components for simplifying the website delivery; at the same time, Headless platforms focus more on backend content management and delivery.

Content as a Service API(Headless):

Support for omnichannel delivery, enable different delivery APIs, e.g., REST, GraphQL, quickly expose the omnichannel Content through APIs, API first delivery for omnichannel focused systems.

The CMS Hybrid system enables the APIs to deliver the content across multiple channels but may not follow the API first approach; at the same time, Headless systems allow API first delivery channels.

Extendable/Customizable:

The platform is extendable/customizable to meet the organization's business needs and integrations. Most of the Hybrid systems are more customizable from both Front End and Back End; at the same time, Front End is entirely customizable in Headless architecture but will be some restrictions on extending Back End content management.

Media Library/Digital Asset Management Requirements:

The capabilities to support Media Library/Digital asset management requirements may be internal to the platform or flexible to integrate with external systems, support easy management of all the required assets, e.g., images, pdfs, videos, etc.

Search Capabilities:

Flexible search capabilities to identify the pages, content, tags, assets, etc.; hybrid platform enables centralized search capability to identify all the artifacts from a single location. The Headless architecture uses multiple systems to help the end-to-end solution that centralizes search may be a constraint.

Advanced Workflows and approvals:

The workflow capabilities set up the required business process flow for content/page review and approval.

Link management:

Link management helps the content authoring team manage the page links easily and update the content reference upon move/delete operations. The hybrid system may easily control the page links, references, etc., but Headless perspective developer support is required for link management.

Preview/Publishing Capabilities:

The capabilities to preview the pages/content quickly before making the changes live to the end-users also flexibility on publishing options, e.g., scheduled publishing, review/approval, etc. The Hybrid platform allows the content authors to preview the pages(Content along with experiences) before making; the headless systems will have limited preview capabilities, but some headless systems have started adding preview capabilities.

Migration(Reusability):

The migration from the current CMS system is one of the critical factors while identifying a new CMS system while the organization is currently on a CMS system; identifying the closest system helps you migrate the current artifacts while supporting all the business needs and addressing the constraints on the existing platform. The number of sites/integrations enabled with the current system, and the volume of content that should be migrated should be factored in.

Scalability:

Scalability is another important factor; the platform should auto-scale based on the ongoing business needs.

Security:

Security is another crucial factor; the platform should be protected from all security issues — e.g., XSS, DOS, etc. The headless architecture by default enables security by separating the content from the presentation layer. Still, additional effort is required to ensure the presentation layer s protected. The Hybrid system consolidates the security into a single platform but may need a significant effort to ensure the platform is protected.

Accessibility/SEO Support:

Accessibility/SEO support is a hot topic nowadays to ensure the site is accessible for all and ranked on the search engines. The headless architecture will enable the required flexibility to the FE developer to handle the Accessibility/SEO requirements(some headless CMS enables authoring capability to manage the SEO configuration, but development effort is required to manage them). The hybrid architecture empowers the marketing team to manage the page SEO but may need a significant amount of effort to enable the necessary capabilities.

Resources/Skillsets:

The availability of the resources and the required skillsets
Supporting the new platform implementation is one of the significant factors — should consider the primary technology switches, e.g., switching from Java to PHP. It is also how quick and easy cross-training the current resources into the new platform.

Dev vs. Marketing:

The control between Dev and marketing teams, Marketing team quickly performing the content creation/updates, launching Campaign sites, landing pages, new websites with minimal or no support from the Dev team — Hybrid architecture makes more sense.
On the other hand, the Dev team controls the FE delivery same time the marketing team only manages the backend content; the marketing team is dependent on the Dev team to complete most of the activities apart from Content authoring.

Personalization:

The platform should either support the personalization use cases OOTB or integrate seamlessly with external personalization/CDP engines.

Support for Modern Front-End frameworks:

The support for the modern Front-End frameworks, e.g., React, Angular;
The headless architecture gives complete flexibility to the FE developer to choose the required modern FE technologies for the presentation layer.
Hybrid systems may have some restrictions on using the modern FE frameworks for traditional website delivery(Some of the Hybrid Platforms Support Morden FE frameworks).

Multi-Site Support:

How quickly the marketing team can launch a new country/language site; by reusing the existing website pages/content
Most of the Hybrid platform provides the Multi-Site Manager framework to support this use case; Headless CMS enables the capability to generate multi-site content but may need effort from the FE team to enable the experience layer.

Cost:

The cost is the important factor most of the time to decide the CMS platform for the organization — the tool cost, hosting, operational cost, resourcing cost, etc. The Hybrid platform upfront cost(tool cost) will be more; the headless CMS cost will be minimal compared to the Hybrid platform but need to factor in additional tool requirements like Hosting platform, CDN, etc. Sometimes identifying the resources to support Hybrid will be challenging. Headless architecture needs more FE resources to manage the complete platform and the ongoing business requirements. The operational cost may reduce overtime for the Hybrid platform if enabled correctly but may increase for the Headless platform.

Access Management:

Manage the access for the content/pages/assets; the system should support the required level of access management to support the organization's business workflow. In most cases, the access management capability of the Headless systems is limited.

Translation:

Translation capability is one of the factors to support multilingual websites; most of the Hybrid/Headless platforms support automated translation processes.

Integration with PIM/eCommerce Systems:

The capability to integrate with the PIM/eCommerce may be optional based on the business requirements. Some Headless platforms enable integration capabilities with e-commerce platforms, but the overall responsibility stays with the FE team to build the required PIM/eCommerce integrations. At the same time, most of the Hybrid platform enables the connectors to integrate with the PIM/eCommerce systems (Consolidate the experience under a single platform)— but may need to watch out, the integration may well work with the e-commerce system part of the same vendor landscape, not with external platforms(customization/additional implementation required to support the external platforms)

Connection with Marketing ecosystem:

Another significant factor to consider is how well the system integrates with the Marketing ecosystem to enable the end-to-end personalized user experience. Most of the Hybrid platforms well integrate with the marketing ecosystems — the constraint is that they may integrate well with the marketing ecosystem supported by the same vendor, not with external systems. On the other hand, developer effort is required to enable the necessary integrations with the marketing ecosystem.

Version Control:

The requirement to version control the content, pages, assets, etc.; store the required number of versions for future references and auditing also restore the versions whenever required. Headless CMS versions the content; the only difference is Hybrid platform can version the actual page rather than only the content.

Cloud-Native:

Another significant factor is hosting options, Cloud-hosted vs. Cloud Native(SAAS) vs. On-prem hosted. In most cases, the headless platforms are Cloud Native(SAAS); the Hybrid platforms give different options. Some of the significant factors that influence the hosting options

  • the data security requirements of the organizations — some organizations may not want to host the data to the cloud platform
  • the effort required to keep the platform up to date with the latest capabilities/changes and security enhancements should seamlessly upgrade with new capabilities/changes and security changes.

Enabling Rich User Experience:

Delivering a world-class user experience is one of the hottest topics discussed now; the user experience impacts the website's bounce rate. The headless platform gives total control to the FE developers to build rich users experiences, at the same time Hybrid platform may enable some restrictions to the FE resources to allow the required experiences(most of the Hybrid platforms started supporting modern technologies for FE delivery, but still you may see some limitations), should use the headless feature of the Hybrid platform to support rich user experience requirements.

Vendor Lock-in:

The Hybrid Architecture may lead to long-time vendor lock-in; migrating to a different platform will be more challenging in the future, but at the same time, the headless architecture enables some flexibility on this considering both Content Management and Experience Layers are separated.

Some of the factors to answer the "Headless vs. Hybrid" architecture question

  • business needs
  • organizations Enterprise/Marketing architecture landscape
  • Current CMS and the challenges and restrictions with existing CMS
  • availability of the required resources/skills
  • marketing team requirements(Dev managed vs. Marketing team managed),
  • user experience requirements
  • Dev flexibility
  • the CMS use case(Website only, App only, Mixture), etc.

In my perspective, headless architecture is more flexible and built on modern tech stacks, so consider headless architecture.

  • If the Frontend team can support all the business scenarios and integrations without much impacting the current landscape,
  • Enough FE resources to handle the migration from current CMS, ongoing operational support
  • The marketing team is ready to adapt to the new content management model and ok to lose the website management control then Headless architecture more suites.

Hybrid architecture more suites

  • When website delivery is an essential requirement at the same time, it should support the omnichannel use cases
  • Centralized/Complete platform to manage the web content management requirements.
  • The marketing team required more control
  • the Development team wants the flexibility to define the experiences based on the business needs(Headful or Headless).

Note: "This post reflects my personal view, not my organization's view."



Tuesday, February 22, 2022

Website Structure in AEM — Multi-Site Manager(MSM)

 In this post let us explore how to use MSM concepts to structure websites in AEM.

The site structure is driven by multiple factors, set up a site structure that meets your goals

  • Multiregional, multilingual needs
  • Content re-use/Duplicate Content/Content Velocity
  • Content distribution
  • Translations(automation third-party translation connectors )
  • Access Control/Governance(Who manages the global/local websites and content)
  • Create a consistent fluid look among sites

Multiple site structures can be enabled based on the above factors, some of the important structures are

  • Individual websites
  • Multinational Site
  • Multilingual Site
  • Multinational and Multilingual
  • Multi-departmental Site

Country Based Standalone Websites- The site1, Site2, and site3 are independent and have no relationship between them, if required multiple languages can be supported through language copy(let us understand more about language copy later in the post). Even in some cases separate apps for different websites — e.g separate code modules, components, templates, etc based on the nature of the website.

Region-Based Structure — manage the content at the global level and different region levels, this will enable the region-based teams to enable the local content at the same time reuse the global content.

Multi-National/Multi-Lingual Websites — the language masters(unpunished pages) help to manage the pages for all supported languages, en is the global master and other languages created as a language copy from en. The live copies through blueprint can be used to define country-specific websites, the content is easily managed through language masters and rolled out to individual sites, the inheritance can be broken whenever required.

The AEM MSM(Multiple Site Manager) can be used to enable the required site structure and enable the content reuse. Let us see some of the important concepts on MSM.

MSM(Multi-Site Manager) — MSM enables you to use the same site content in multiple locations. MSM enables a set of tools to manage sites that share the same content. MSM defines the relationship between content, enforces a common base structure and common content across multiple sites. MSM maximizes the reusability of the content but at the same allows the individual websites to localize the required content.

Blueprint — A source template for multiple pages, defined from a site or set of pages. Blueprint configuration identifies an existing website that you want to use as the source for one or more live copy pages. Blueprint configurations enable you to push content changes to live copies. In AEM as a Cloud Service, every live copy source is enabled as a Blueprint, it means no need to create the separate BluePrint Configurations. Refer to the following links for more details — https://github.com/adobe/aem-enablement/blob/master/AEMAsACloudService/02_MSM_Improvements/README.md (AEM 6.5.12.0 now backports this AEM as a Cloud feature — refer to https://experienceleague.adobe.com/docs/experience-manager-65/release-notes/release-notes.html)

Live Copy — A site created from Blueprint, even the live copies can be directly created from another website without a blueprint. The live relationship is maintained between master pages and live copy pages. The live copies inherit content from the master, which means anytime the content changes from master can be rolled out/synced to live copy pages. The relationship(inheritance) between the master pages and the local pages can be canceled based on the need to enable the local content.

Language Copy — A Language Copy provides a way to create a copy of a site (or part of a site) that is specially designed for translation. There is no live relationship as established in the case of Live Copy. It is one time copy of the content. Please note there is no translation as part of the Language Copy Creation, some external translation vendors should be engaged for content translation but AEM enables the required frameworks to automate the translation process.

Rollout — The process Synchronizes from the source to the live copy, Can be triggered by an author (on a blueprint page) or by a system event (as defined by the rollout configuration).

Synchronize — A manual request for synchronization, made from the live copy pages. The changes from the master pages are synchronized to the live copy pages.

Let us now quickly see how to enable Multi-National/Multi-Lingual Websites(refer to the above diagram)through MSM structure.

(I have created a sample project through the latest AEM Arch type, and using local Cloud SDK for demo) — the same project will have the minimal templates and components enabled also the sample site structure, I am going to create a new multilingual/multinational website following the MSM framework and using the default template and components.

As a first step create a language master website structure(in our case en — /content/msmdemo/language-masters/en), create language-master and en pages under site root, also required child pages under en page.

The site structure should follow some of the below rules to enable MSM

  • The website has a root page.
  • The immediate child pages of the root are language branches of the website.
  • The root of each language branch has one or more child pages.

Now create the required languages-masters from en master under /content/msmdemo/language-masters, Create a language copy from en master e.g es, fr, etc — en is the global master and the content is translated to different language masters, the country-specific websites are created from language masters as a live copy.

Add the required pages from en master

Select the target language and enable the translation configurations — refer to the below posts for more details on translations

Now the language master setup is completed, let us create country-specific websites for supported languages.

As a first step, create the website root pages(country nodes) e.g /content/msmdemo/us, /content/msmdemo/fr, etc.

Create a live copy from the corresponding language masters to the target country folders.

Select the language master and select the destination(/content/msmdemo/us)

Enter Title, the name, select the required rollout configs then click on create

Repeat the same steps for all the languages supported for a specific country.

Now you should be able to roll out/sync changes from language masters. To perform 1 to many rollouts ( language masters to multiple live copies), select the language master associated with the live copies e.g /content/msmdemo/language-masters/en, select properties, select the Blueprint tab — Blueprint tab is visible only when the language masters are associated with at least one live copy.

Select the rollout config and roll out changes, the changes from language master will be sent to all the live copies(you should be able to select the required live copies). Even you should be able to see the live copy overview.

The rollout can also be initiated from references UI, select the live copy page e.g /content/msmdemo/us, and select References. Now you can roll out the changes to that specific live copy.

You can also compare the changes before rolling out.

Instead of rollout, you can sync the changes to the live copy pages.

Select the live copy page →Properties → Select Live Copy tab →Click on Synchronize

You should be able to Suspend — Suspending live copy inheritance for a page is a temporary action. Once suspended the Resume action becomes available, allowing you to reinstate the live relationship or Detach — Detach permanently removes the live relationship between a live copy and its source/blueprint page.

In AEM 6.5, you could only do one-to-one rollouts for a large site, using the synchronize button in the AEM Live Copy User Interface. In order to do a one-to-many rollout, you had to set up a blueprint configuration(AEM 6.5.12.0 now backports this AEM as a Cloud feature). AEM as a Cloud Service automatically makes any live copy source to a blueprint, select a page from the Blueprint site(source of the live copy, in our case language masters), open the page properties, click the Blueprint tab and click Rollout to all the selected live copies.

The MSM framework can be customized based on the business need e.g the rollout configurations can be customized to rollout/synchronize the required content and properties. While MSM supports a high degree of customization typically the best practice for the performance, reliability, and upgradeability of your website is to minimize customization.

MSM is one of the important features in AEM that helps you to manage multiple websites that share common content; helps the authors to quickly launch the website in different countries by reusing the content from existing websites. The Live Copy concept in the MSM framework helps to maintain the live relationship between different websites that helps the content authors to roll out the changes quickly across multiple websites. The MSM structure should be defined carefully considering different factors e.g Access Control/Governance, COntent Reuse, Website specific content, etc.

References:

https://experienceleague.adobe.com/docs/experience-manager-64/administering/introduction/msm.html?lang=en

https://experienceleague.adobe.com/docs/experience-manager-65/administering/introduction/msm-best-practices.html?lang=en