Playing nice - Principles for Sitecore Content Hub and XM/XP working together

-

The Sitecore product family now provides two key platforms where you can manage content (and technically this is now expanding as you can manage content in Sitecore Send and Sitecore CDP as well -- the future for these is unclear however I'd expect the patterns below may well expend to those other delivery channels in a similar way). 

When you have platforms with overlapping capabilities, I believe it's always important to have some clear principles as to what the role of each system is in the overall architecture - so you know what you should and should not do in each place.  I guess it's kind of like putting together a recipe to follow when you are making decisions to ensure that everything works together and you don't end up with a failed cake.

Below I outline one way that I feel makes sense to align the responsibilities between Sitecore XP/XM and Content Hub in an enterprise digital architecture.

The moving parts

The Sitecore tools that we're considering are Content Hub which is known for Digital Asset Management but also provides a number of other capabilities, and Sitecore's CMS capabilities through either XM or XP.  With Sitecore's pivot towards "composable DXP" my view is that XP is likely to be phased out over time, with Sitecore CDP filling more of the personalisation gap.  The role as a content management platform however is similar between both platforms.  The  capabilities of both Content Hub and XP/XM are outlined below.

Content Hub

Sitecore Content Hub, the selected digital asset management platform, is a flexible platform with a number of modules.

  • Digital Asset Management (DAM) - This provides the baseline capabilities of digital asset management - storing and search assets and their metadata, creating renditions, managing digital rights, basic workflow and automatic tagging via the Microsoft Vision API.
  • Marketing Resource Management (MRM) - Supports modelling basic and multi-stage projects and tasks for creating and executing content production for marketing campaigns, including engaging and collaborating with internal and external teams.
  • Content Marketing Platform(CMP) - Supports the understanding of the content landscape and creation and execution of content strategy , and tracking content from idea through the production of content ready for publication into channels.
  • Experience Edge for Content Hub - provides a delivery platform allowing GraphQL access to content and other entities direct from Content Hub.

Sitecore Experience Platform

  • Sitecore XP and XM provide content publication capabilities including inline editing, page layout authoring, preview including device simulation, publishing workflow, form building, publication embargo and expiry dates all supporting headless delivery.
  • Experience Edge for Sitecore XM - which has not released yet, but will provide a scalable delivery platform for publishing of Sitecore JSS sites and runtime content delivery for headless sites.

Connectors

In addition the following technical capabilities are supported by current licensing.

  • Sitecore Connect DAM and CMP Connector for Sitecore XM/XP - which allows content authors in Sitecore XP/XM to select DAM assets from Content Hub, and also synchronises CMP contenet into Sitecore item buckets
  • Sitecore Connect DAM Connector for Salesforce Marketing Cloud - which makes assets in Content Hub available within Salesforce Marketing Cloud
  • Sitecore Connect DAM Connector for Adobe Creative Cloud - which makes assets in Content Hub directly usable within Adobe Creative Cloud tools like Photoshop and InDesign.

What goes where?

Based on the above, the most important question I feel is to establish the roles to be played by Content Hub (particularly CMP) as compared to Sitecore XM in the digital platform architecture.  Each enterprise will have slightly different requirements, however I feel that the principles below provide a sensible starting point:

Where is content managed?

  1. Content Hub is for production of content, from idea through to production.
  2. Content Hub should be used for content that may need to be reused cross channel. This may include things like:
    1. Media assets like images, video and audio files
    2. Articles
    3. Legal disclaimers and policies
    4. Descriptions of processes (e.g. returns)
  3. The above applies even in cases where there is slightly different copy per channel for that content (e.g. slightly different variation of an article summary for web vs mobile channel) 
  4. Content Hub CMP should be used for content that aligns to the content strategy
  5. Sitecore XM should be used for managing simple content used to drive UI within a single online channel, e.g. tool tips for a form, text for a login screen.

How is content accessed?

  1. Sitecore XM (including Sitecore Experience Edge for XM) is for publishing of complex content, where there is a need to:
    1. Define layout where multiple pieces of content are combined together (such as a homepage, landing page or an article page with multiple sections and modules that cross-reference other pages)
    2. Utilise advanced content publishing capabilities such as embargo and expiry dates (i.e. publishing restrictions)
    3. Require in-site content authoring abilities such as inline editing and preview in multiple device formats
    4. Where Sitecore is responsible for Search through Solr, this is accessed through Sitecore XM
  2. Content Hub will be responsible for pushing content into channels (e.g. Sitecore, SF Market Cloud), but will not be used for serving content direct to end users (excepting public links for assets)

These segregation of responsibilities may not suit all architectures, however I recommend spending the time up front to ensure the responsibilities of each system in your architecture is defined both in terms of where content is authored, along with where it is served to users

Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

-
Image
The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before.  Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud
Read more

Setting up TDS to work with Azure DevOps

-
Image
We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 displayName:
Read more

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec
Read more