DXM Architecture Overview

Common Architectures

Traditional / Monolithic

Traditional CMSs such as WordPress or Drupal typically combine the content management and presentation layers of a website. This is a monolithic architecture and means content editors are typically interacting with the same system and code as content consumers.

The challenges here are:

1. The requirements of the CMS dictate the choice of platform or technology. If the CMS is written in PHP for example, you must extend and developer for that CMS in PHP;
2. Supporting multiple sites – this is typically done by installing multiple copies of the underlying CMS code for each site and/or each environment;
3. Sharing content and code – because each site is a separate installation of the CMS, sharing content and code can be a challenge as it requires promotion from one environment to the next; and
4. Scaling to accommodate larger numbers of content consumers.

Decoupled

Crownpeak DXM uses a decoupled architecture. This means that we separate the content management and content presentation or delivery layers.

At the core of the platform is the content repository that contains everything from content assets and template code to publishing configuration and workflow. All CMS code runs in the context of the content repository and we transfer content to the delivery layer through “publishing”.

Important consequences of this separation are:

1. The CMS doesn’t dictate or interfere with your delivery environment — you can use the most appropriate infrastructure and technology for your project, including re-using existing infrastructure, a vital concern for organisations that have existing platforms they have to support and often don’t have the resources, mandate or desire to change them;
2. You can publish content to multiple delivery environments or target content to different environments by site or workflow state;
3. The repository allows you to share content, code and configuration across multiple sites; and
4. You can scale, configure and secure the delivery environment appropriate to the content consumer profile and independent of the content management profile.

Headless

It is important to also distinguish between a decoupled architecture and a "headless" architecture.  A headless CMS provides its content from an API rather than through publishing resources. Content delivered this way is typically content-as-data rather than content-as-view. In other words, they allow you to edit, store, and manage content but leave the presentation design and delivery of that content to a separate application.

The challenges with headless are:

1. Looser control of the published views — how to ensure the same corporate or branding requirements are met?
2. Imposes a scaling challenge as the data access pattern is now many-to-one as all presentation layer instances call in to the content management layer.

You can implement a headless model using Crownpeak by publishing content from the CMS to Search G2 and then using the Search G2 API, based on Apache Solr, to query, retrieve and format your content as data.

Elements of DXM

Content Management System

Now that we understand that Crownpeak uses a decoupled architecture, let’s take a closer look at the elements of Crownpeak DXM and how they are made available.

On the content management side, we have the core CMS itself. This is composed of the content repository, which houses everything: assets, templates, models, workflow, configuration and so forth.

Templates are the means for the CMS functionality to be implemented and customised. A template is a collection of event handlers, written in C# and using the underlying CMS Template API. These event handlers are triggered whenever a content editor is interacting with an asset in the CMS whether creating, copying, editing, deleting or publishing.

The CMS also provides an Access API that is used whenever you need to interact with the repository from code. The Access API is used by the CMS user interface so any operation that you can perform in DXM will have a corresponding Access API method.

Crownpeak only provides the CMS on a software-as-a-service (SaaS) model, and has always done so. The CMS is provided on a multi-tenant model where there is:

• NO local installation;
• NO installation for each environment you are publishing to (dev, stage and live for example); and
• limited configuration required.

Crownpeak Services

On the content delivery side, Crownpeak provides for dynamic delivery of content through two services, also provided on a SaaS-basis:

• Search G2: Crownpeak’s Solr-based search service; and
• Web Content Optimizer (WCO): Crownpeak’s service for test and targeting.

Web Hosting

Crownpeak does offer web hosting facilities to all clients and a choice between:

• a Windows-based server running IIS with various ASP.Net options for server-side code; or
• a Linux-based server running Apache with Java and Tomcat available for server-side code.

Crownpeak hosting is provided on a managed service basis so there is complete operational isolation between clients. Crownpeak IT/Ops team take care of setting up, monitoring and managing the servers, which are always provided in a multi-server configuration for scalability and reliability.

Crownpeak hosting is designed to be as secure as possible, which means that there are NO remote connections permitted to the servers other than from the CMS itself. In addition, the scalability demands mean that Crownpeak does not install any database facilities on these servers.

Although Crownpeak hosting is easy and convenient for most clients, clients are welcome to use their own hosting. The only constraint here is that the CMS must be able to transfer files to the environment using SFTP or S3.