Part 3 in our “unpack the stack” series on composable martech is all about the data – specifically, access to the data – the middle layer of the stack. The next set of capabilities we’re exploring is Orchestration and Federation. These two capabilities go well together because they are very similar and have some overlap, so let’s unpack ’em.

Orchestration and Federation in a Composable Architecture

At a high level, the “orchestration and federation” category represents the underlying access and routing to data across a variety of back-end martech products – from PIM, CMS, Order Management, DAM, Marketing Automation, internal and external proprietary databases, etc. While the prior topics of FEaaS and Experience Builders focus on the visual expression of content, data, and layout, orchestration and federation capabilities provide access (and intelligence!) to the actual content and data to hydrate those experiences. Let’s better understand the differences here.

Orchestration vs. Federation

The reality is these terms are often used interchangeably, so the definitions below are my take based on how they are often used in reality and… a bit of the dictionary:

• Federation means bringing multiple sources of data/content together into a consolidated and predictable “place” – in reality the “place” may be a martech tool that holds a copy of all of the data/content, or simply an API facade that sits on top of the underlying systems’ APIs. More on this in a bit. The key point here is it’s a unification layer in the martech stack, a single entry point to get access to the back-end systems via a single API.
• Orchestration is the same as Federation, however, is brings a bit more logic to the data party, providing some level of intelligence and control on exactly what data/content is provided for consumption. It’s like air traffic control for the flow of data from back-end systems.

Examples of Content Federation

Content Federation is a unification capability where you can combine multiple back-end sources together in a composable stack. A few examples include:

Hygraph Content Federation

Hygraph Remote Sources unify multiple back-end source system APIs directly into the Hygraph API so the consumer (e.g. a web app) only needs to access the Hygraph API and not all of the underlying other systems directly. You can read more about the content federation concept from Hygraph or see it live in a video! One thing to note is that Hygraph does not actually fetch and store external data inside Hygraph, instead the remote source’s API schema is added to the Hygraph API so a single call to the Hygraph API will make an “under the hood” call to the external API from Hygraph at query time.

Contentful Content Orchestration’s External References

Contentful External References (ironically) is a feature of Contentful “content orchestration” (see what I mean by these being used interchangeably?). External References allows system users to register external API sources that get merged into the Contentful GraphQL API so a consumer only needs to use one API. This is nearly identical in capability to Hygraph, however, one important thing to note is that Contentful allows for bi-directional editing of external data.  That means a CMS user can directly edit the external data from the Contentful CMS UI (assuming the API is setup to handle that). One key advantage of bi-directional editing is that a business user does not need to log into the other systems to make edits, they can stay inside the Contentful interface to do all of the editing.

Netlify Connect

Netlify Connect is another good example of federation following a similar model to Hygraph and Contentful. In Netlify Connect you can configure multiple “data layers” to back-end systems using pre-built integrations provided by Netlify, or to your own proprietary system using the Netlify SDK. A great use case for this custom approach is if you have a proprietary system that is difficult to get data out of and requires custom code.

The most notable difference with Netlify Connect is that it actually fetches and caches your external data into its own database and exposes snapshots of the historical data. This means you can use historical data revisions to query a specific set of data at a point in time, especially if you need to troubleshoot or rollback the state of an experience.

Optimizely Graph

Unlike the prior examples, Optimizely is a more traditional DXP that is leaning heavily into headless with the likes of Sitecore, Adobe, dotCMS, and others.

Optimizely Graph is the new GraphQL API to serve headless experiences built on Optimizely. One subtle (and maybe overlooked?) feature of Graph is the ability to register external data sources and synchronize them into Graph. Based on the documentation as it stands today, it appears this work is primary developer-driven and requires developers to write custom code to fetch, prepare, and submit the data to Graph. That said, the benefits mentioned previously still stand. This allows headless experiences to consume content from a single API while behind the scenes the synchronization process fetches and stores the external data into Graph.

Enterspeed

Enterspeed is a good example of a pureplay product that focuses on unification as the middle layer in a composable architecture. It allows you to ingest external data, transform that data, and deliver that data to various touchpoints, all via a high-speed edge network.

WunderGraph Cosmo

WunderGraph provides GraphQL microservice federation. It’s an open source and hosted product that helps you manage multiple back-end databases, APIs, authentication providers, etc. Additionally, its designed in a way for developers to declare the type of compositions of APIs they want using code, following a Git-based approach, instead of requiring UI-based setup and configuration.

Hasura

Hasura provides GraphQL federation similar to WunderGraph. It provides a single GraphQL API to consumers with the ability to connect several underlying systems such as REST APIs and databases (e.g. Postgres, SQL Server, Oracle, etc.).

Examples of Orchestration

Digital Experience Orchestration with Conscia

DXO is an emerging capability pioneered by Conscia.ai to help solve the problem of integrating many back-ends to many front-ends. DXO helps to orchestrate the complexity in the middle via a unified layer that all back-end services and systems of records communicate with, as well as a unified front-end API for experiences to consume:

A key tenet to this approach is to continue to leverage real-time APIs from the back-end systems, for example, a pure play headless CMS and a commerce engine. The DXO not only acts as a façade in front-end of these back-end system (similar to an API gateway), but it also provides other benefits:

• Unifies data across back-end systems of record like you see with Federation
• Provides enhanced business logic and rules by allowing business users to chain APIs together, avoiding static logic written into code by developers
• Offers performance improvements by caching the real-time calls to the back-end APIs as well as pushing as much computation (e.g. business logic) to the edge closer to the end users

One key value proposition of Conscia’s DXO is a business user-friendly canvas to integrate multiple API call responses and create chains of calls. For example, the response of one API call might become an input to another API, which is often hard-coded logic written by developers:

Conscia’s DXO provides two key capabilities:

• DX Engine as the federation layer to unify multiple back-end sources of data and content, as well as a rules engine and intelligent decisioning to orchestrate the right content and data for the individual experience
• DX Graph as a centralized hub of all data, especially useful if you have legacy back-end systems or proprietary systems with hard to access data. The DX Graph can connect to modern APIs to visualize (via a graph!) all of your data, but crucially it becomes a centralized hub for proprietary data as well that may require scheduled sync jobs, batch file processing, and similar ways to integrate.

Similar patterns: API Gateways & BFFs

Is this like an API Gateway?
Yes and no. An API gateway provides a façade on top of multiple back-end services and APIs, however it mostly performs choreography as an event broker between the back-end and front-end (client). An orchestration system puts the brain in API gateway, being a centralized hub, and allows business users to control more of the logic.

Is this similar to the BFF (backend for frontend) design pattern?
Sort of. If the specific federation or orchestration tooling you are using allows you to control the shape of your API responses for specific consumers (e.g. frontend clients in a BFF), then you can accomplish a BFF. This is definitely a good use case for Conscia.

Why do orchestration and federation matter in composable architecture?

In a truly composable stack, we need to consider the fact that multiple systems in use means multiple sources of truth: CMS, another CMS, maybe another, PIM, DAM, OMS, the list goes on. It is absolutely possible to integrate directly with all of these systems directly from your head (the experience implementation you are providing such as a web site, mobile app, etc.). However, direct integrations like this tend to break down when you scale to multiple experiences since all of the back-end data integration logic is in a specific experience implementation/head (e.g. the website application code).

So, what’s the alternative to putting the integrations directly in your head?

• Abstract it out and build a DIY integration layer: this sounds like a lot of work, but it certainly is possible. However, it may be hard to scale, add features, and maintain since it will turn into a bespoke product within your architecture.
• Buy a federation/orchestration tool: why build it when there are products that already handle this? Focus on your specific business instead of building (and maintaining!) a bespoke product (like a CMS, and PIM, and OMS, etc.)

A dedicated federation/orchestration layer offers the following key benefits:

• A single unified API for consumers (marketing site, web portal, native mobile app, data syndication to other systems/channels, etc.)
• Promotes the concept that systems of record should truly own their data and avoids needing to write custom middleware to handle the orchestration and logic across many systems (e.g. head-based integration or a custom integration layer)
• Encourages reuse of data and content: it offers data-as-a-service, so you can focus on how to activate it on your channels.
• May provide contextual intelligence to control and personalize API responses to individual visitors in a dedicated data layer to power tailored omnichannel experiences. 

We have it all, so what’s next?

Seems like we have everything we need here, what else is there? Let’s (re)package up the first three capabilities into a larger topic – stay tuned for part 4 where we will talk about Digital Experience Composition (DXC).

Welcome back for Part 2 in a series on composable martech, where we unpack the stack into the emerging capabilities that make modern architectures. This time we’re talking about Experience Builders, which go hand-in-hand with Part 1’s topic, Front End as a Service.

Experience Builders have been around for a long time. In fact, the concept of drag and drop or point and click page template creation has been around for ages, going back to early content management systems as the visual on-page editor experience, very common with traditional monolithic all-in-one (!) suites. In this context we’re talking about Experience Builders in a composable stack, where the underlying CMS may not be an all-in-one solution or a hybrid headless solution.

As I mentioned, Experience Builders go together with the prior topic, Front End as a Service (FEaaS). While FEaaS focuses on the individual UI component creation, design, and data binding, Experience Builders allow business users to compose multiple components together to form bespoke web pages or reusable page templates. In fact, many FEaaS providers also offer the Experience Builder capability, allowing users to build the repository of components and assemble them together into page layouts.

Traditional Experience Builders

As a baseline of understanding, let’s first look at experience builders that come embedded in traditional CMS/DXP solutions – whether you consider them to be monolithic, all-in-one, unified, etc.

Traditional experience builders are typically offered as the out of the box visual in-line on-page editors provided with a CMS (or DXP). They often support either drag and drop or point and click page layout creation with placeholders or content areas to assign UI components. The fidelity of freedom of page design is often configurable, from blue sky blank slate where you can design the layout of the whole page, to what I like to call “paint by numbers” where the page layout and components are “fixed” and content just needs to be entered.

Below are a few examples of traditional experience builders that you may have seen or worked with over the years.

Sitecore’s Experience Editor (fka Page Editor) is the point-and-click turned drag-and-drop visual editor of the XP product with the ability to in-line edit content and add UI components into page-level placeholders:

Optimizely’s On Page Editor provides similar capabilities as Sitecore with on-page in-line editing and placement of content and blocks into content areas:

HubSpot’s SaaS CMS has a visual editor as well, likely what you would expect from a CMS that manages and delivers its own content:

Composable Experience Builders

Now let’s move on to modern composable experience builders since that’s the topic of this series. This is where things get a bit blurry between traditional suite providers going composable and headless-first pure play point solutions. Monolithic-turned-composable DXP players (if you believe that’s even a thing) and pure play headless CMSs are both “meeting in the middle” (a great Deane Barker phrase that I completely agree with) with a lot of emphasis on Visual Editing with headless-based solutions. This is a big topic that is being discussed a lot, recently from industry veteran Preston So with the idea of a Universal CMS. I’ve even written about it before as an emerging trend in the space.

As you may know, headless CMSs were initially celebrated by developers for their ability to use web APIs to fetch content, freeing developers from the underlying CMS platform technology, however this came at a price for marketers, often losing their visual editing ability that we talked about in the traditional experience builders above. Well, its 2024 now, and times have changed. Many solutions out there are turning to visual editors that work with headless technology to bring the power back to the marketers while keeping developers happy with modern web APIs. Let’s take a look at some examples and the wide spectrum of solutions.

dotCMS’s Universal Visual Editor

dotCMS’s new Universal Visual Editor is an on-page in-line editing app built to support headless sites, including SPAs, and other external apps that may fetch content from dotCMS.

AEM’s Universal Editor

AEM’s new Universal Editor supports visual editing for any type of AEM implementation, from server-side, client side, React, Angular, etc.

Contentful Studio

Contentful Studio includes a newly released visual builder called Experiences. This is a very interesting example where a traditional pure play headless CMS is clearly pushing upmarket, innovating to capture the needs to marketers with this no code drag and drop tooling.

Optimizely’s Visual Builder

Optimizely’s yet-to-be-released (likely arriving in H2 of 2024) Visual Builder appears to follow suit with the likes of Adobe, dotCMS, and other traditional suites by offering a SaaS-based editor for headless implementations. The timing of this is likely to appear after their release on the upcoming SaaS CMS offering.

Sitecore XM Cloud Components & Pages

Sitecore XM Cloud’s Components and Pages go hand-in-hand: FEaaS and Experience Builder working in harmony. Interestingly, these interfaces not only support Sitecore-based components such as built-in UI components (OOTB), Sitecore SDK-developed components (via developers), or FEaaS components (via authors), they also allow developers to “wrap” external components and allow marketers to use and author with them, bringing a whole new level of flexibility outside the world of Sitecore with bring your own components (BYOC). This brings composability to a whole new level when coupled with using external data sources for component data binding.

Uniform

In many ways Uniform lives in a category of its own. We’ll unpack that (pun intended) a bit more in a future article in this series. That said, one of the most well-known capabilities of Uniform is its Visual Workspace. Uniform empowers marketers though the visual editor by focusing on the expression of the underlying content and data, bringing the actual experience to the forefront. There’s much more to be said about Uniform on this topic, so stay tuned.

Netlify Create & Builder.io

As I mentioned in the prior article on FEaaS, Netlify Create and Builder.io both offer modern composable Experience Builders that are very similar in nature but have some notable nuances:

• Builder.io goes to market as a Visual Headless CMS, offering the experience builder visual editing with its own CMS under the hood so you are not required to bring in another tool to manage the content. However Builder.io also supports using an outside CMS such as Contentful, Contentstack, and Kontent.ai
• Create provides an Experience Builder canvas that works solely with external CMSs supporting Contentful, Sanity, DatoCMS, and other custom options available

Features of a modern Experience Builder

So, what features do modern experience builders provide?

• Design reusable page layout templates through structural components (columns, splitters, etc) on a visual canvas
• Assemble and arrange page layouts with UI components (often built via FEaaS tools)
• Configure visual design systems for consistent look and feel when multiple components come together, for example, typefaces, colors, sizing, padding/margin, etc.
• Ability to communicate with multiple back-ends to compose an experience sourced from multiple systems (e.g. a product detail page sourcing data from a CMS, PIM, and DAM)
  • Note: many pure play providers offer this while some suite providers are “closed” to their own content – but perhaps other features in the stack can solve this. Keep reading this series to learn more
• Flexibility to build both reusable page layout templates and one-off bespoke pages (e.g. unique landing pages such as campaigns)

The combination of FEaaS and an Experience Builder is very common in a composable stack made up of many headless products as it empowers business users without needing developers to implement integrations with back-end APIs. I’ve written about this topic before in the CMSWire article “5 Visual Editing Trends in Composable Martech Tools.” At the end of the day, Experience Builders are the “visual editor” that was missing in the early days of pure play headless CMS’s that mostly favored a great developer experience with elegant APIs and SDKs.

What’s next?

Where are we going to get all of the content from? It’s all about the data! The next topic will cover the underlying systems that can serve the right content and data to these experiences. Stay tuned to learn more about orchestration and federation!

Welcome to Part 1 in a series on composable martech, where we unpack the stack into the emerging capabilities that make modern architectures. This round is focused on Front End as a Service.

Front End as a Service (FEaaS) is a fairly new term for a concept that isn’t necessarily new – however it is becoming more common as martech tools pivot towards SaaS solutions with API-first headless capabilities.

FEaaS represents the top of a composable technology stack, the front-end of an experience that end users interact with. This can be a traditional website, a web-based logged-in portal/application, a commerce storefront, or even a touch-based kiosk web application.

Benefits of FEaaS

FEaaS provides an overall goal of empowering business users to take control of the front-end experience power by headless products without requiring developers. These tools provide business users with the ability to design and layout UI components from atomic elements onto a canvas, and bind “back end” data from various martech tools, sometimes called “glue code” in the headless world and the biggest criticism of headless products.

FEaaS offers the following benefits in a composable architecture:

• Drag and drop low/no code tooling for business users to layout and design individual UI components to be used in a digital experience
• Ability to bind custom components to back-end data via APIs, for example mapping new components on the front-end to a CMS API response to fetch content
• Some FEaaS providers also offer ways to make components reusable and delivered via a CDN, for example wrapping them in Web Components for generic reusability.

Examples of FEaaS

The spectrum of FEaaS providers is quite wide and includes pureplay headless content providers that are pushing upmarket to provide more business user tools beyond their roots as API-first developer-friendly tools. Additionally, traditional enterprise suite providers are pushing down-market to appease business users that want more flexibility and control of the digital experience without requiring “expensive” platform developers to build UI components and integrate them with back-end APIs.

Netlify Create (fka Stackbit) offers a canvas to design and layout components. Like many other providers, this offers both the component creation capability (FEaaS) as well as an Experience Builder (or Page Builder) to compose multiple components together into a page template. We’ll get more into Experience Builders in the next post.

Sitecore XM Cloud Components is another example of FEaaS, offering the ability to create bespoke components from atomic elements, like sections, boxes, images, text elements (paragraphs, headings, etc). It’s basically browser-based Figma with the output being functional UI components that can accept data from various martech systems (PIM, CMS, DAM, etc.).

To illustrate the key point about accepting data from various systems, Sitecore XM Cloud Components offers a data sources section to register external (and internal) API endpoints to fetch data from other systems via API endpoints and GraphQL:

Builder.io offers similar functionality as Netlify Create with a canvas for drag and drop atomic elements. Additionally, it provides a page template builder which we will discuss in the next post, as well as its own built-in headless CMS. 

Finally, Shogun is a FEaaS provider (among other things) for commerce storefronts. Like others, it provides a drag and drop canvas to compose elements together into bespoke reusable components intended for a commerce store with the integration “glue” into Shopify and BigCommerce as the underlying commerce engines.

What’s next after FEaaS?

As you can see FEaaS is an incredibly powerful capability in the composable stack, especially when multiple headless products are being integrated. FEaaS brings back the power to the business user to design and build UI components without relying on developers to build them as custom components and handle all of the data binding with back-end systems. That said, FEaaS is a complex capability and should be limited to mature digital teams that can govern component creation and usage.

The next topic we’ll cover in this series will focus on how we put these components together to compose actual page layouts and designs: Experience Builders.

It’s clear in 2024 that the martech spaces continues to adopt a composable mindset towards technology architectures. Traditional martech players are offering more flexible product offerings by decoupling architectures, breaking up large suites into independent composable products. Newer cloud-native pureplay and point solutions are offering extension points and turn-key integrations with other composable tools to fit nicely into new modern architectures. New and emerging categories of composable products are being born, helping to integrate and orchestrate workflows, content, and data across a variety of loosely connected martech products.

It’s clear that products across the full spectrum are doubling down on improving marketing and business user tooling, ensuring they provide a delightful experience to business users and developers alike.

The purpose of this series is to unpack many of the new trends, capabilities, and categories of products in modern martech architectures. We’ll cover a variety of topics, from visual authoring experiences, content aggregation, multi-product orchestration, and integration tools. Let’s dive into the series from here – below you will find an up-to-date index of everything in the series.

Part 1: Frontend as a Service (FEaaS)

Part 2: Experience Builders

Part 3: Orchestration & Federation

As a long-time Sitecore practitioner (since 2008!), witnessing the evolution of Sitecore development over the years has been fascinating. With Sitecore’s transformation from a web CMS into a comprehensive martech suite, the role of a Sitecore developer has undergone a significant shift. Let’s dig in as we aim to redefine what it means to be a Sitecore developer in the modern era.

Sitecore Development Through the Years

The Old Days of Sitecore Development with .NET

In the early days‍, Sitecore development was tightly coupled to .NET technologies due to its monolithic architecture, thus requiring specialized .NET developers. The evolution from XSLT to ASP.NET Web Forms and eventually ASP.NET MVC marked a continuous evolution with Microsoft’s .NET advancements.

Modern Sitecore Development with Flexible Options

The introduction of JavaScript Services (JSS) in 2018 marked a pivotal moment. Headless solutions became prominent and JSS became a first-class citizen of the Sitecore developer experience. Processes and workflows changed dramatically:

• In-line editing via Page Editor/Experience Editor worked with headless implementations
• Developers could start to build solutions without a Sitecore instance
• Front-end UI developers became “Sitecore developers”
• It became possible to host your site on Node.js instead of directly on a .NET-based CD server

The further shift towards a composable architecture, especially with SaaS offerings like XM Cloud, further transformed the development landscape with significant decoupling of many capabilities into distinct products. With this flexibility came more responsibility to integrate these and other 3rd party products.

Skills of a Modern Sitecore Developer

1. Web Development Background

A modern Sitecore developer is a web developer, however you are no longer required to be a .NET specialist. You can embrace many of the modern web development languages and technologies since APIs are now headless. Sitecore officially provides SDKs for Next.js, React, Angular, Vue, and .NET Core which will give you a benefit with modern development. Next.js development offers the most value since it supports all capabilities of XM Cloud (e.g. Headless SXA, personalized page variants, etc.)

2. Broad Cloud-Native Technology Mindset

Considering the fact that Sitecore products now make up just a portion of martech solutions is crucial. Integration with other systems may involve exploring various technologies and platforms like Azure, AWS, Netlify, Cloudflare, etc. A modern Sitecore developer understands the broader set of technologies required for effective martech solutions. For example, leveraging integration platforms (iPaaS) for integrating many-to-many products, using serverless functions, edge functions, workers, etc. to handle API proxies for JavaScript code, the list goes on.

The old days of using Sitecore itself as an integration hub are gone. You consider the role of other adjacent composable tools to stay flexible, enable marketers, and avoid building your own bespoke monolithic application, for example, you understand the concept of loose coupling and the role of orchestration.

3. Loose Coupling & Orchestration

We know there are many layers in a modern martech implementation. You might have a CMS, a PIM, a marketing automation platform, and you need to build a website with future plans to build more experiences (displays, apps, etc). How do you build it in a way that doesn’t turn your website head implementation into an integration layer? You don’t want all of your business logic that stitches these products together in the web channel-specific implementation. What happens when you go to build that digital display? Or a mobile app? Having a mindset of loose coupling is essential.

You avoid the common headless newbie trap of mixing presentation and integration in your head application. Keep your digital experience (the ‘head’) focused purely on the visual display. If you are stitching content and data from multiple systems, do not use Sitecore (the CMS) to ingest that and become the central publishing system. Do not use your ‘head’ on top of Sitecore to do that either. Point-to-point integrations will not scale and negate the purpose of composable architecture.

Instead, leverage an orchestration layer to aggregate and deliver the right content and data via APIs. You can certainly build this layer yourself, or use a commercial SaaS product.

Over time as you scale and begin to offer experiences across channels your new architecture will scale with you via the orchestration layer.

4. That Content Strategy Hat Looks Good on You!

You understand the core principles of content modeling and focus on pure content representation, not “content in a specific context.” For example, you focus on content models that can be reused beyond a website for a native mobile app or a 3rd party consumption API. If you need to introduce channel-specific concepts such as “Page” you do that separate from the pure content. This sets you up for true omnichannel support in the long term.

5. Know Your Audience: A Marketer’s Perspective

I’ve written about this before, but I’ll say it again: the primary audience for a CMS and other martech tools is the marketer! So, to be a better CMS developer, you should understand and think like a marketer. This doesn’t mean you need to be an expert, but understanding their point of view, understanding their workflow across many tools in the stack, understanding their day-to-day will give you insights into how best to support them and improve their efficiency.

The Modern Sitecore Developer

The landscape of Sitecore development has experienced a profound shift over the years, from its .NET origins to a more versatile, composable architecture. The role of a modern Sitecore developer now demands a broader skill set, from a variety of development platforms and SDKs to fostering a cloud-native technology mindset. The introduction of JavaScript Services (JSS) and the transition to composable architecture, particularly with SaaS offerings like XM Cloud, have opened doors for front-end UI developers and highlighted the importance of loose coupling and orchestration layers for scalable, channel-agnostic solutions.

Beyond technical proficiency, a modern Sitecore developer embraces content strategy principles and adopts a marketer’s perspective. Content modeling focuses on pure content representation for omnichannel support, while understanding marketers’ workflows becomes paramount as you assemble and integrate multiple products. This holistic approach defines the Sitecore developer of today, equipped not only with technical coding skills but also a keen awareness of the broader digital ecosystem in which their solutions operate. As Sitecore continues to evolve, this versatility and forward-thinking mindset remain essential for success.

Happy new year and welcome to 2024! In less than 11 months the MVP contribution timeline will end, so don’t wait 10 months to start thinking about contributing valuable content to the community – now is the time to start!

As a quick recap of the MVP timeline

• The MVP community contribution timeline is from December 1st through November 30th of the following year. MVP applications are typically due the last day of November and span the 12 months mentioned.
• The MVP year (being an MVP) is from February 1 though January 31 of the following year. New MVP announcements are typically on or around Jan 31st/Feb 1st for the next year.

While I have been a Sitecore MVP for many years, this past December was my first year that I volunteered to be an application reviewer, an option that current MVPs get. I learned a lot going through the review process and have observed many traps that applicants fall into, so I’d like to go over some recommendations and tips for MVP aspirants planning to submit applications in the future.

Recommendations when submitting community contributions

Screenshots

Many of the tips below recommend you take screenshots to show something happened (Slack messages, emails etc), especially if there is no URL like a blog post to link to. A few ways you can accomplish this:

• Take a screenshot and upload to a Dropbox / Google Drive / One Drive and get a sharable URL. Use that URL in your application contribution link. This was an excellent tip I got from Rob Huffstedtler a few years ago.
• If multiple screenshots show what happened for a single contribution (I had a meeting about this product feature with Sitecore then sent a follow up email with my feedback), paste them into a Word doc and export that to a PDF, then drop that PDF onto a Dropbox / Google Drive / One Drive.

Make it easy for reviewers to verify your contributions!

If you are worried about access to the asset links on shared drives, you can even set the links to expire after the application review period, so set an expiration date for early February for the following year. Also note: current MVPs that may review your application are under NDA.

Video/Podcast Content

If you are sharing a video link (e.g. YouTube) or a Podcast (Apple, Spotify, etc), if your portion talking about Sitecore is a subset of the media, please indicate at what timestamp you are speaking about the relevant content. It’s not fair to a reviewer to listen to or watch a video for 40 minutes to hunt for what your Sitecore community value-add was, if there was any at all. Obviously, if the entire topic was presented by you all about Sitecore you don’t need to do that. Make it easy for reviewers to verify your contributions! More information is better than less.

Public Speaking in Person

If you presented at a user group or some sort of event (Sitecore conference, industry conference, etc), take a picture of yourself there, or have a screenshot of your name on the intro slide and a screenshot of the official invite (an email blast, a meetup.com event page, etc). Just do something to show you were really there AND you were speaking. Make it easy and 100% clear to the reviewer you were there and you presented. Don’t make reviewers go hunting for proof. Make it easy for reviewers to verify your contributions!

Public Speaking Virtually

If you are speaking at a user group or conference virtually, obviously if you have a recording of the event, simply share that. But if you don’t, similar to above, take a screenshot of you speaking on screen with the content showing. Maybe a screenshot of the title/intro slide with your name and 1-2 more screenshots showing detail content of your presentation to show real content. If you are concerned about taking screenshots while you are presenting, if a video was recorded you can take screenshots from that recording after, or ask a friend or attendee to take screenshots for you. Make it easy for reviewers to verify your contributions!

Organizing Events

If you [co]organized an event, please describe what you specifically did. It’s understood that it’s a group effort sometimes, but make it easy for the reviewer to know what you were accountable for and contributed. If we are guessing and don’t know, it’s basically like you were not involved. If that means you need to take a screenshot of emails with sensitive data blurred/redacted, do it. For example, coordinating the facility, setting up a meetup.com page for the event or similar, email blasts or marketing. Prove what you did, more information is better than less. Make it easy for reviewers to verify your contributions!

Collaboration/References/Feedback with Sitecore

If you collaborated with Sitecore by providing value back to influence the products (either with the sales team or directly with product), find a way to SHOW that happened. Don’t say “please speak with so-and-so” – instead show a screenshot of an email showing the value you are providing back. If there is sensitive data such as client names, blur/redact it. Make it easy for reviewers to verify your contributions!

Common traps to avoid

Client Project Work vs. Published Learnings from Project Work

Don’t share links to client projects you worked on and claim that as a community contribution. It’s not. It’s great that you are a practitioner of Sitecore, but developing the site for your client provides no value in of itself for the community. Instead, if you learned new things during that project, find a way to share that with the community – a SUG presentation, or a blog post with redacted client data. Take the project experience and bring value to the community from it in a responsible way. A significant number of Sitecore blog posts out there are based on real-world project experiences practitioners have. In fact, if you spent all that time working on a project, for a small amount of incremental time you can document key things you learned and provide a lot of value back to the community. So, the math says…. you should do this. Don’t forget, make it easy for reviewers to verify your contributions!

Event Attendance vs. Event Contribution (Organizer, Speaker)

Attending events such as a local SUG, SUGCON, DX, Symposium, etc in of itself is not a value add to the community. You ARE the community at this point. To be considered as an MVP, you need to provide value back at these events via speaking engagements or organizing the event. Please don’t list event attendance on your application unless you presented or [co]organized.

Sitecore partner marketing vs. individual community value-add content

If within your role at your company you publish materials on Sitecore services your company provides, such as service detail pages, bespoke workshops, and generalized marketing material that promotes Sitecore services, this content is primarily promoting your company and its services, it’s not thought leadership. Instead, in addition to doing your job by creating this content, provide your personal take and opinion on the topics of Sitecore products, capabilities etc. You’ve already come this far by talking about why your company is in a prime position to implement Sitecore products, so take it a little further and give your own personal commentary. Why Sitecore? What do you believe differentiates its portfolio and why should customers pick Sitecore?

Supporting MVPs vs. Contributing as an MVP

If within your role at your company you manage a group of Sitecore practitioners (developers, architects, strategists, content designers, etc) and you carve out time for them and promote the concept of community participation, that’s excellent. Please keep doing that. But that itself is not MVP community contribution. Please understand the difference between leading by example and making community contributions as a potential MVP vs. enabling potential MVPs to thrive on your team.

One last tip for you

The MVP Application is open most of the year on the MVP website. So as you are making contributions you can already be documenting them on your application throughout the year.

Thank you for all that you do and may the community thrive!

That’s all for my MVP application tips! If you have any questions about the MVP program or contributions to the community, there are many resources out there to help. Please visit the official MVP website or ask any direct questions in the Sitecore community Slack.

As we wind down 2023, it looks like we are getting a nice little holiday gift from the Sitecore Content Hub ONE product team. They just announced the long-awaited introduction of GenAI features into the product! Let’s crack this open and see what’s inside.

What’s included

Text fields (short, long, and rich text) now have a new GenAI button that will prompt you to generate new text content or improve existing content.

Here is an example of it for an existing headline short text field. Since there’s existing content it offers to adjust or improve the content through pre-defined prompt templates:

Here’s an example with a rich text field for an article’s body content with no existing content. It can help generate content about a topic:

This is a great start to introducing GenAI into content production, and its especially important in the context of a pureplay CMS like Content Hub ONE, since the primary use is to manage pure content, agnostic of how it will be presented and consumed.

If you want to see a preview of these features in a live demo recording you can watch the clip below from SUGCON NA back in October 2023:

What’s possibly coming in the future

The product managers of Content Hub ONE, Ezgi and Hande, mentioned at SUGCON NA earlier this year that a few other GenAI enhancements may be coming in the future:

Control the pre-defined prompts themselves inside Content Hub ONE. This will give organizations even more control over how they intend to use GenAI to generate content, possibly creating additional prompts they need for their specific business. The product team at Sitecore is still testing this capability and considering if they want to provide this level of control to customers.

Use GenAI to create a content model based on a description of the type of content you are trying to model, for example, a food recipe. This is a feature that some other market-leading headless CMS’s have today and I’m not surprised as a possible use case. It will help with the burden of trying to design a well-defined content model and will take advantage of the GenAI language model training data out there to design a good starting place for new content models. Again, this is not guaranteed as a future feature but it is being considered by the product team.

Stay tuned for more enhancements to the SaaS portfolio

If you are not already aware, please keep an eye on the Sitecore Changelog – available in both an elegant web app or via RSS. The Changelog provides updated features, enhancements, and fixes to products across the SaaS suite and is a great place to keep up with your favorite products. It’s also powered by Content Hub ONE

Today I am going to show you a way to implement redirects using Netlify’s redirects capability and Content Hub ONE as the underlying repository to manage the redirects. This technique can be implemented with any headless CMS (e.g. XM Cloud), however I decided to use Content Hub ONE due to the simplicity. Also, since Content Hub ONE is still a very new headless CMS, at the time of this writing it does not have webhooks out of the box. I’m going to show you a workaround to get updated redirects published to Netlify.

Redirects Content Model

In Content Hub ONE I created a very simple model to represent a redirect with a “from path” and “to path” – it can easily be augmented with more fields such as status code (301, 302, etc). Netlify supports redirecting to other paths on the same domain or other fully qualified domains.

The GraphQL and result are very simple and will be easy to fetch and put into our Netlify redirects format:

Netlify Redirects

Next we need to understand how redirects work on Netlify so we can get the right data from Content Hub ONE to Netlify in the expected format. Netlify uses a flat file in the root called _redirects with space or tab delimeters between the to and from values on each line:

Note: you cannot directly access _redirects as a plaintext file by the URL in your browser. Netlify sends an error to the browser. So the best way to test redirects is to test them individually or write out another physical .txt file to the file system with the same content.

Generate Redirects Node.js Script

The full repository of the sample code is available on GitHub.

Let’s now write a Node.js script to query for redirects in Content Hub ONE. Since this script runs server-side I decided to use Axios to make the requests:

Because I am doing this demo with Next.js, all public assets need to be placed into the public\ folder. If you use this solution where that is not required make sure you update your script.

Also note, the script (node ./scripts/generate-redirects.mjs) is added as a postbuild script in package.json so it runs automatically after build

Netlify Build

Setting up a new site and build on Netlify is ez-pz. It will probably take you about a minute to do. Since this is a Next.js app, it automagically did most of the configuration work for me:

Also, make sure you add your environment variables for API_ENDPOINT and API_KEY which are used in the code:

Again, in true Netlify fashion you can easily paste these into Netlify to load them in:

Scheduled Build to Publish New Redirects

Now we need a way to build and deploy the app with new redirects over time so we keep the redirects up to date based on published content. Once Content Hub ONE introduces webhooks we can use a content publish webhook to trigger a Netlify build hook to build the app. Since webhooks don’t yet exist in Content Hub ONE a workaround is to schedule a webhook POST using Pipedream. Thanks to Dan Solovay for this idea from his SUGCON NA talk.

In Pipedream I created a Scheduled trigger that runs hourly. You can set it to run every 5 minutes if you really want, or whatever interval makes sense for you:

Then I added a step after the trigger to POST to my Netlify build hook which will rebuild the app and thus query for new redirects and rebuild the _redirects file.

Where can we go from here

The purpose here is to show you how to leverage Netlify’s redirects capability with the flat file to execute redirects on the edge. You can use any headless CMS you want to store and manage the redirects. The added value of using Content Hub ONE here was to show how to workaround not having a wehbook on content publish. Using a scheduled job with an integration platform like Pipedream can allow you to schedule builds over time to keep content fresh.

A few ideas to improve this solution are:

• Separate Netlify builds – find a way to run just the `postbuild` script in a Netlify build. This will allow us to have a build hook just for regenerating redirects and not the whole app. If you know how to do this in Netlify please comment below!
• Webhooks – the best solution would be to use a CMS-managed webbook for content publishes. Once Content Hub ONE introduces these I will update and simplify the solution.

I previously wrote about Sitecore Content Hub ONE and its place in the market as a new pure-play headless CMS. One of the key differentiators of a pure-play headless CMS is the lack of any presentation or visual rendering of content. They focus on managing content in its purest form in a repository to syndicate it to any channel. While many organizations still leverage pure play headless CMS’s to build traditional web experiences, a good fit use case is to provide physical world and virtual world omnichannel experiences. Let’s dive in!

Use Cases for Virtual Worlds

Brands can leverage virtual worlds to bring a traditional physical experience to consumers in a browser-based virtual experience. There are a number of use cases where this may be beneficial, for example:

Education

Universities often provide campus tours to prospective students looking to get a feel for the campus. What if a prospective student cannot make the physical journey to the campus but still wants to experience what it is like? A partially curated free-form virtual tour in a web browser can enable prospects to navigate around the campus, see key landmarks, and learn information about the campus — the same information afforded in a live physical tour.

(Image: virtual tour of Harvard College, the undergraduate program at Harvard University)

Healthcare

Hospital systems and buildings are often filled with endless corridors and elevator banks all over the place. Sometimes it can be overwhelming to know where to go. Providing a virtual in-browser experience of navigating the corridors and clinics of a hospital can afford people the ability to see what they’re getting into before going to the hospital.

This is also an opportunity for personalization! For example, say you’re having a procedure at a hospital and have never been to a particular part of the building. A few days before your procedure you can receive an email with a link to a curated tour of entering the building and navigating the exact path to the clinic or location in the building where you need to go.

(Image: curated virtual journey into Boston Children’s Hospital)

Tourism

A pandemic hits the entire world. Travel is shut down. Tourism and cultural events grind to a halt. Providing a virtual experience for a tourist destination may be in order. Museums, sporting venues, and historical landmarks are among the types of locations that can still provide an experience without a physical presence.

From Virtual Back to Physical

We can take the virtual world concept one step further by implementing an omnichannel strategy. Museums and landmarks can take physical signs/plaques at exhibits and turn them into digital signs. You know what can power that digital signage? The same content from the same headless CMS. So the content can be updated over time and it will consistently syndicate out to both the physical digital signage and virtual in-browser experience. Win-win!

(Image source: https://www.intuiface.com/blog/museums-and-interactive-displays)

Sitecore Pano – Manage Virtual Experiences in Content Hub ONE

Sitecore Pano is a demo of a virtual world-like experience using a panoramic library and Content Hub ONE to source content. Each panoramic scene contains an equirectangular image and any number of hotspots. Hotspots use pitch and yaw for dimensional placement on the panoramic image, and text when hovering over them of informational content. The possibilities are endless with how you want to augment your virtual experience with content since under the hood Content Hub ONE can store any content you need.

Try Sitecore Pano

How can I get involved?

As of 11/8/2023 the GitHub repository is now available: https://github.com/mursino/sitecore-pano

We are happy to announce our new partnership with Netlify, one of the original high-performance WebOps platforms for the modern web. Netlify is a composable cloud platform with three key capabilities:

• Connect anything across various content and data sources
• A frontend cloud development and hosting platform for your decoupled architecture
• First-class content editing in a composable stack

We are really excited to be partnering with Netlify as we are now able to offer this solution not only to our Sitecore customers – whether they are on XM Cloud or XM/XP – but also other customers leveraging other CMS and DXP products in a composable martech stack.

Why Netlify?

Netlify bet big early on by coining the term Jamstack (an architecture built with JavaScript, APIs, and markup). The combination of the exploding API Economy, where so many providers are offering robust APIs to integrate with other services, plus the pace at which modern web technologies such as JavaScript frameworks are maturing has led to enormous adoption of Jamstack-based composable architectures. Netlify’s portfolio provides a well-rounded set of capabilities to be the engine that powers a composable stack.

Netlify Connect

Netlify Connect is a content and data unification layer that allows organizations to federate content from many different sources in their stack. This capability enables teams to orchestrate content and data flow through a single hub that powers any and all customer experiences they provide: websites, storefronts, native mobile apps, digital signage, voice interfaces, or syndication of content to other sources. Connect synchronizes with connected back-end systems – CMS, DAM, PIM, commerce – by using webhooks to fetch updates and store them in a Netlify graph database. Connect then exposes a unified GraphQL API for developers to build experiences with high performance without having to make point-to-point integrations to back-end systems. The graph database that powers Connect decouples front-end experiences and avoids round trips to get data from backends.

If you are an organization with several different back-end systems powering your digital experiences, you should consider Connect for a few reasons:

1. It prevents the need to make multiple point-to-point integrations with martech systems, thus avoiding the dreaded MACH Monolith
2. It cleanly decouples the updating of new back-end data from front-end experiences by storing an up-to-date database of connected content. This enables high-performance edge-based digital experiences, regardless of how back-end systems may perform.
3. It exposes a single unified GraphQL API for developers of any language and framework to consume in their DX applications, exposing all of your connected content.

Netlify Platform

Netlify Platform is the front-end cloud hosting platform. It provides numerous features to support your frontend experiences:

• Build and deployments
• Deployment previews
• Split testing for testing new user features
• Serverless functions
• Edge functions to support personalization, localization, A/B testing at the edge
• Identity management
• Super simple forms integration to capture submissions

Getting started with the Netlify Platform is a breeze and it supports most of the modern Jamstack-friendly frameworks such as React, Next.js, Astro, Vue, Nuxt, and SvelteKit.

Stackbit

Stackbit rounds out the composable trifecta that is Netlify by solving one to the biggest pain points of a composable architecture: first-class content authoring with headless martech tools

It enables page-level visual editing of content that is sourced from multiple backend systems such as CMS products, commerce, PIM, etc. It provides both live preview and in-line editing in visual pages to speed up content authoring for web-based content. It’s also very simple, touting a single configuration file to get set up and running. Sticking with the decoupled nature of Jamstack, Stackbit supports all web frameworks and can even be used without a framework just with some minimal requirements to enable live editing of content.

Sitecore + Netlify

Sitecore’s product portfolio has pivoted toward a composable architecture with headless SaaS products, so this means frontends can now be built in any web language. The preferred method to implement Sitecore XM Cloud is with the Next.js SDK which can be deployed to Netlify due to the decoupled nature of the architecture. Sitecore customers can run and scale their frontends on the Netlify Platform – even on traditional XP or XM with the use of headless JSS. If you’re on XM Cloud today, take look at our guide on how to deploy your site with the Netlify CLI.

We are excited to see the possibilities and integration between Sitecore and Netlify continue to mature as the XM Cloud product continues to be adopted.

Content Hub ONE is Sitecore’s entry into the pure play headless CMS market. For years this market was dominated by well-known players such as Contentful, Kontent.ai, Contentstack, Sanity, and Strapi. Many of these headless CMS solutions provide streamlined CMS capabilities to manage content and deliver it through web APIs. As we talked about in the last article, the decoupling of the front end experience and back-end CMS is at the core of a headless CMS. Content Hub ONE is Sitecore’s truly headless agile CMS, so let’s dig in.

What is a pure play headless CMS?

Solutions like this are called “pure play” because they are literally defined by their Headless (capital H, it defines the product!) nature. They provide a CMS with absolutely no head. As a marketer, you can model and manage content, but you have no control over the presentation and display of how content is consumed. It’s not built into the CMS like other solutions (like XM Cloud). The focus is truly on just managing content, so it is lightweight, and agile. It does one thing and does it well.

Use cases for Content Hub ONE

Since Content Hub ONE is truly about managing content, and just that, there are a few use cases that differentiate it from larger more complex CMS solutions:

Simple content marketing websites with fixed designs/layouts

A headless CMS like Content Hub ONE is a good entry point into the CMS space if you want to focus on managing pure content and don’t have needs to manage web page layouts and designs. This is a good fit case if you have a simple content marketing website and the marketing team works closely with developers with design changes. You may be thinking that sounds contrary to what we preach: “put as much control as possible in marketers’ hands!” Sometimes marketing teams don’t need and want to manage web page layouts and designs. They want to focus on generating content and letting their existing page templates work as designed, as opposed to more bespoke needs where they would create unique page layouts through drag and drop.

Here’s when a content marketing website might be a good fit for headless:

• Simple content marketing website, typically a corporate website with some industry thought leadership, e.g. a few pages are about the company (products, services, team) and most of the rest of the content follows a single pattern/template (blog posts/articles, solutions, etc.)
• Priority on efficient content creation and publishing, not bespoke page layout design. Keep it simple – focus on 5-7 fixed visual templates
• Acceptable to leverage existing in-house or agency development team for small enhancements to layouts and design

Campaigns

Campaigns microsites are a good use case for a pure play headless CMS like Content Hub ONE. Campaign sites typically contain just a few pages with minimal templates. They are often short-lived and therefore don’t usually need a lot of control over page layouts.

Here’s when a campaign microsite might be a good fit for headless:

• Minimal visual templates (2-5) with fixed designs (i.e. no need to control layouts)
• Primary call to action such as lead gen form via JavaScript embed or iframe (an easy thing to store in the CMS)
• Some need to change content, because final content is never final

I’ve personally built several campaign microsites in the late 2000’s that had hard coded content. Bad idea. As a developer that just meant more work for me through the life of a campaign. A headless CMS is a no-brainer here (pun intended).

Highly immersive experiences

Highly immersive experiences, typically on the web channel, are overly interactive experiences that don’t fit the mold of a visual template-driven website. They are often fully dynamic based on underlying content (in the CMS) and programmed to work a certain way by developers. Since they don’t fit the need for drag and drop page design and are powered by raw content, they are an excellent fit for a headless CMS. The most important aspect of building these experiences is ensuring marketers and developers are in lock-step with business logic, something we talked about in the prior article.

Some examples of these web experiences include:

• Highly animated sites with non-linear customer journeys, e.g. presentations or pick your adventure
• Product configurators
• Virtual / panoramic worlds  (stay tuned to see this in action in the future!)

Omnichannel content strategy

Brands that reach their customers though many channels need to provide a consistent and seamless experience across all touchpoints. These brand marketing teams don’t focus on a single channel such as a .com website or store, but all possible channels. They focus on content creation at atomic levels with a sound content model, regardless of where content may be published and consumed. Brands like this syndicate content out to many touchpoints such as campaign sites, native mobile apps, digital billboards, primary web properties, storefronts, and even emerging channels such as voice assistants.

The most important part of this use case it to focus on a sound and scalable content model, ensuring it’s not biased toward a specific channel (e.g. like creating page-centric content types for web). Content models should focus on granular content chunks at the most atomic level as possible. One way to think about content consumption is like eating food: for any specific channel, do I want a bite, a snack, or the meal.

Yin and yang – appeasing marketers and developers

The minimalistic design and simplicity of the CMS interface makes it a great tool for marketers to focus on content management. There’s no extra clutter, everything is deliberate – less is more! It reminds me of Apple devices, you just jump right in and start using it without needing to read documentation to figure out where to begin.

The simplicity of Content Hub ONE is underpinned by an elegant developer experience based on headless delivery. Since content is published via web APIs and developers build the actual experiences, its important to honor the sentiment of an omnichannel content strategy. Content Hub ONE is language and framework agnostic, allowing developers to build for any platform and device. GraphQL powers the API layer that is hosted on Experience Edge, a CDN-backed endpoint. Additionally Sitecore offers .NET and JavaScript SDKs.

The separation of concerns between content management (marketers) and content delivery (developers) allows teams to work independently in a truly headless CMS.

Three Pillars of Content Hub ONE

There are three pillars to Content Hub ONE. We’ve discussed these before, but let’s dig in a bit.

1⃣ Content Model (content designers)

The content model is the most important part of any CMS, as it drives the structure, relationships, and attributes of your content. It is the essence of your content, defining it in an abstract way such that you can represent all of your content in your unique content model.

Each content type in the model represents a single class of thing – an event, a product, a service, etc. Content types contain fields that represent the underlying data at the most atomic levels – title, date, author, featured image, etc. Fields may contain the granular content itself or provide relationships to other content – 1-to-1 or 1-to-many relationships.

2⃣ Content Authoring (marketers)

Content authoring is the process of marketers producing and entering content into the CMS for publishing. The authoring interface mirrors the content model defined and will update as you make changes to your model.

Since Content Hub ONE is a pure play headless CMS, there is no concept of page hierarchy like there is in other Sitecore CMS products (XM, XP, XMC). Content is simply grouped into lists by content type.

3⃣ Content Delivery (developers)

Content Hub ONE provides both preview (draft content) and delivery (published content) APIs in GraphQL format. This allows developers to build experiences with any language and on any platform, from Objective C for an iOS devices to Ruby on Rails for a web app. While any language and framework will work, Sitecore does offer more robust SDKs for .NET and JavaScript developers.

Additionally, the CLI is available for developers to remotely interact with Content Hub ONE. This can be useful to serialize basic content and media to the file system for developer onboarding. Publish tasks can also be accomplished via the command line.

Developers looking to get reference code implemented for Content Hub ONE can look at the Sitecore Content Hub ONE demo repo .

Wait, isn’t XM Cloud headless? What’s the difference here?

If you’re wondering if both XM Cloud and Content Hub ONE are headless, they are. However the nuance is in pure play headless. vs. hybrid headless.

As we’ve seen, pure play headless provides headless delivery and just that. You do not make changes to how the CMS works and you have no concept of web page layouts/display. Its truly channel agnostic. You model and author content, then deliver it to experiences though an API:

Conversely, hybrid headless is a CMS that gives you the benefits of a decoupled architecture with a content API layer (in this case, Experience Edge) for headless content delivery. However, it also offers the benefits of a traditional CMS with customization to the back-end CMS as well as in-context visual page editing for web content. The in-context visual page editing is possible though the use of an editing host which renders your web experience inside Experience Editor or Pages:

Hmmm, tell me more about XM Cloud

Sure thing, let’s head there in the next part of this series. Stay tuned!

The concept of headless CMS has been around for a long time — some might even say that’s how the original CMS products and publishing platforms of the web operated. However the concept of headless is still fairly new in the world of Sitecore, with JavaScript Services (“JSS”) — the first true foray into headless — only being about 5 years old. Since Sitecore’s flagship DXP solution Experience Platform (XP) has such a significant footprint and install base, many experienced .NET Sitecore developers may have not yet plunged into the world of headless until now. The purpose of this series is to better educate you on the concept of headless in context of Sitecore products. Experienced Sitecore developers need not worry, headless is here to stay, so let’s get your head on straight.

What did we have before headless?

Before we dig into what headless is, let’s take a step back and understand the world before this pivot. Sitecore’s older products such as XP and and XM (both on-prem/IaaS/PaaS) leveraged a coupled architecture. In this architecture model, the back-end CMS application running the interface for content authors is coupled to the front-end application running a website. What does this mean? They are literally running on the same application instance on a web server.

Now if you’re thinking that doesn’t make sense because you can scale between CM (content management) and CD (content delivery) servers, so the CMS and the website are separated, you’re correct. However, the CD server itself is still running Sitecore, it’s just “hardened” to remove access to CMS UI features and databases that are not needed to run a website. But you can’t take the Sitecore out of Sitecore.

CMS industry veteran Deane Barker has a nice way to explain a spectrum or stages from coupled to decoupled architectures. On one end of that spectrum the “CMS publishes into a complete remote CMS install.” This is essentially where traditional scaled XP or XM sits. The CD server has a nearly full install of Sitecore running so that is can run all of the .NET-based API layers to ultimately look at caches and SQL database records in the “web” database to fetch content. The website must run on .NET because the underlying Sitecore technology runs on .NET.

So what is headless?

In order to understand ‘headless’ we need to understand the parts of the technology stack. When you interact with a someone, you generally look at and speak with their head — it’s literally the face of that person. The body then supports the rest of them. Similarly, when you interact with a website, you experience the ‘head’ of that site, but underneath that head lies a system of tools to support it such as a CMS and database server — the body. You may see the ‘front stage’ but it all happens because there is a ‘back stage’ to support it. A headless CMS is one that doesn’t provide that front face itself, you must build it on your own.

If we understand one end of the spectrum being a full install of Sitecore delivering content and therefore coupled to the platform architecture, is the other end of the spectrum headless? Indeed it is. In a decoupled headless architecture, the back-end CMS platform is decoupled from the front-end application to render websites when published. The CMS platform itself ends at the API and nothing else sits on top of that in the same application.

So how does that work with the .NET-based Sitecore API? How do I get Sitecore.Context.Item from another application to run my website? You don’t. Adios .NET API! This is where web-based APIs come in. In a headless CMS, a web API is now the boundary between your CMS in the ‘back stage’ and the website in the ‘front stage.’ You (the Sitecore customer or partner) are now responsible for determining what technology to use to build and host your head (the website). In Sitecore terms this is called a rendering host.

Why is there a big pivot towards headless?

There are a variety of reasons that headless CMS has become popular over the last decade. While I cannot exhaust every possible reason, I strongly believe it comes down to a few key reasons:

Performance: a win-win for marketers and customers.

A decoupled front-end experience can be hosted, managed, and scaled independently from the CMS software, so you can take advantage of CDN-based hosting if you statically generate your website, or you can deploy inexpensive elastic servers to host as close as possible to visitors, thus improving site performance. As site performance increases, search engine rankings and overall customer experience gets a lift. This is a huge win for marketers looking to acquire and retain customers that expect near instant site loads.

The API economy: powering the software that is eating the world

Every year Postman publishes the State of the API Report, and it’s clear every year that APIs are the new economy. SaaS products with interoperability across many solutions rely on web standards and APIs to work. These APIs are open and exposed for other products to integrate, so they use common standards such as JSON-based data exchange over HTTP. Advancements in API technology and the “snowball effect” of most SaaS solutions providing APIs enables much more connectivity and integration opportunity across the martech stack. What was once a platform-specific .NET API is now exposed over HTTP for any application to consume Sitecore content.

Technical flexibility: everyone is now a potential Sitecore developer

Significant advancements in client-side (JavaScript) technologies and the emergence of web-based APIs has given rise to nearly unlimited options for building your website, the head. Gone are the days of needing to be a .NET developer to build a website on Sitecore. Any language and framework that can consume a web API and JSON can be used to build an experience. The potential landscape of Sitecore developers is now the entire web software engineering world. While there are some significant benefits to leveraging Next.js to build your website, .NET developers also have the .NET Core SDK to work with, so the skill set transition can be minimal.

Security: decoupling protects the business

Your website is not the land of Oz, you do not want to expose what is behind the curtain. A decoupled architecture creates pure separation between the back-end CMS and tooling from the front-end website. The surface area for security incidents is much smaller when the back-end CMS is separated from the public website your hosting since you are only responsible for securing the front-end, while the CMS SaaS provider secures the back-end.

How does this relate to composable?

You might be wondering where the other trendy term “composable” comes in. Headless and composable may seem interchangeable and sometimes be used in that context, however they are not. They are, however, complementary in modern marketing technology stacks.

Headless describes how a particular piece of technology exposes itself. If a CMS is headless, you know it provides a web API as a boundary to build a website (head) on it. If a commerce engine is headless, it provides a web API as a boundary to build a storefront (head) on it. Headless is a descriptor of a specific capability in the technology stack. It means it does not force a visual templating capability on you, you are free to build your own head.

Composable describes how a marketing technology stack is put together. For example, if you have a single platform with tightly-coupled capabilities (CMS, DAM, CDP, etc.), the platform is monolithic in nature. Conversely, if you have a platform assembled together with many separate individual products that are not tightly coupled, its composable. How do you assemble them and make them talk to each other? Well you probably know where this is going: through web APIs.

Composable is a whole topic of its own for another time. However there are a few key things to note:

• Composable is a spectrum – it doesn’t need to be composed of all pure play solutions, it certainly can be anchored by a core capability such as a monolithic CMS (like XP)
• Composable brings its own complexity with multiple products in the mix and needs to be integrated carefully. Many different point-to-point integrations just creates many couplings of decoupled/headless products. This is where composition (DXC) and orchestration (DXO) technology should be considered.

What’s next, where does this leave me, the Sitecore developer trying to find my way?

We’re going to dig in further in this series on headless solutions in Sitecore’s portfolio and guide you towards a new mindset of how to build Sitecore solutions. First up on our journey is Sitecore’s simple pure play headless CMS, Content Hub ONE.