The 4 C’s of a Content Management System (Including Sitecore)

If you use Sitecore or any other Content Management System (CMS), there are 4 primary areas to keep in focus. These areas are the 4 “C’s” of Code, Configuration, Content, and Cloud Platform/Infrastructure. Whether you are implementing, managing/administrating, developing, or hosting the CMS… the 4 “C’s” are here to help you to more easily implement and maintain your CMS/DXP.

Why Use the 4 C’s?

Separating the CMS into 4 key swim lanes allows for easier governance with clear ownership of items. It also helps with agile execution of items. This is especially helpful when developing new features, as some features may cross over 1 or all of the 4 C’s.

As an example, if you are developing a new feature that integrates with an external API, you would have “Code” to write to consume or use the API, potential “Configuration” in the CMS roles for application connection to the API, may require “Content” that accompanies the API output, and ensuring the network is allowing the API communication as part of the “Cloud Platform/Infrastructure”.

Details on the 4 “C’s” are as follows:

Code

The code layer of your CMS is the custom code, whether C# in an .NET MVC/Helix pattern, edge code and frameworks like JavaScript/React/Next.js, styling/CSS, or any other programming languages/frameworks that represent the backend models, business logic, front end pages, and any custom modules developed by you.

Separating the code layer from the other “Cs” in a initial project or ongoing management perspective allows more agility and distinct work items so code based activities are clearly defined, and other activities are not lumped into the code “swim lane” that require distinct work such as connecting an API via configuration and networking.

This is critical as the other C’s may require a different skillset and you don’t want these lost within the mindset of “go code the CMS”.

Configuration

From connection strings to enabling features, every CMS platform has configuration files. This layer of the 4 “C’s” focuses on detailing out the key configuration changes in the platform required to meet a desired outcome. This may include your own configuration files (ex. Sitecore Include files) and these should be treated separate of your code layer as these compliment what you have codified in the platform.

Configuration is where platform engineers tend to play and it may be a separate skillset (normally a developer has awareness/skills in both Code and Configuration layers, but the depth of knowledge may vary). Oftentimes, a configuration change requires input or documentation from the CMS vendor so that configuration is aligned to what the platform needs to operate. Configuring Redis timeouts in Sitecore is one such example.

Using our external API example, you may need to create a connection string entry in the platform configuration so the application can speak to the API, whereas the code layer performs an action against the API.

Content

What’s a CMS without content? From creating and publishing to syncing and migrating content, there is a lot of work to be done in the content layer. This C focuses to any content related activities that support the content that will be displayed in your CMS. Of note, this is separate from code, where you are creating templates to display content in a page or widget, but rather focused to your taxonomies, content types, and metadata tied to defining a piece of content and how you manage the storage and synchronization/migration of content.

This layer is where you take the time to define your content strategy, content structure, publishing governance, and how you will migrate/manage your stored content. You will find yourself using the GUI of your chosen CMS frequently as well as tools for stored content management such a Razl, Unicorn Sync, Sitecore Serialization, etc. This is a distinct layer of work in itself due to the level of content management expertise along with deep knowledge of content migration and synchronization strategies.

In the API example, you might be pulling external data that correlates to certain pieces of content…. or may be providing the actual content itself! The content aspect of that scenario needs to be treated as its own consideration.

Cloud Platform/Infrastructure

Depending on which cloud platform, on premises infrastructure, and edge devices you are leveraging to host your CMS… you will have varying features/capabilities and require deep subject matter knowledge to manage this critical layer. As an example, there are a range of PaaS settings and tuning to support Sitecore in Azure that many are not aware of… and that is just the tip of the Azure platform.

Diving deeper, you may require a host of experts for the differing layers with this “C” as networking capabilities are different from Cloud App Service knowledge and different from storage expertise, etc. This is another example why this “swim lane” needs to be distinct of the others.

In the API example, you might need to configure networking to allow for the external API connection, or perhaps you are hosting the API yourself and need to setup the required Virtual Machines, App Services, networking, etc.

Conclusion

Its clear that a Content Management System has several distinct layers… so distinct that it may require differing skillsets for successful management. By following the 4 “C’s” you can separate these layers into distinct “swim lanes” while ensuring collaboration across resources. Leveraging an Agile tool such as Jira or Azure Boards within Azure DevOps can help in this regard (just don’t get lost trying to overdo Agile, as that is easy to do!).