SaaS Headless CMS Architectural Considerations, Part II

This blog post lists some considerations for architecting SaaS headless content delivery solutions. This blog post serves as Part II of a previous blog post, Considerations for Headless CMS Architectures – Deliverystack.net.

  • CMS Vendor: While all SaaS headless CMS may have similar architectures, each vendor has distinct features and implementation differences, for example regarding user interface extension.
  • Additional Vendors and Products: For experience management, commerce, and other integrated applications.
  • Content Delivery Solution Architecture: Whether and how to use static exports, application servers, services, and client access such as JavaScript.
  • Integration Architecture: User interface extensions, webhooks, event buses, and other interfaces to search, commerce, and other applications.
  • Hosting Infrastructure: Platforms for content delivery and other applications including server-side logic and edge caching and edge networks; whether and when to manage servers as opposed to leveraging CDNs and serverless infrastructure.
  • Development Toolsets: What tools to use for each aspect of the solution including the build process, server-side logic including process automation, and JavaScript frameworks.
  • Deployment Methodology: Continuous integration/continuous delivery, deployment processes and their impact on search indexes and caching, and so forth.
  • Publishing Patterns: Especially considering their impact on search indexes and caching.
  • When to Access What: What text and media to retrieve from the CMS during the content delivery solution build process, from the application server during content delivery, and from the client.
  • How to Access What: Which elements in the solution access CMS services; whether and how to centralize and broker CMS access.
  • Content Types: Collections of fields that define the types of entries managed by the CMS, including properties for individual fields.
  • Information Architecture: How entries relate to each other.
  • Security: Authentication (login), authorization (access rights), and role management (membership) for both the CMS and published site as well as penetration testing, attack mitigation, and other aspects of content delivery.
  • Publishing Workflow: Approval and other processes to apply before content reaches content delivery.
  • CMS Systems: Whether to implement development, test, and other systems, and how resources such as content types and data flow between these systems.

Moving to headless CMS, and really moving to service-oriented architectures in general, will not deliver full value without a change in mindset from monolithic applications to microservice architectures. Compose applications from services.

CMS user acceptance can be a challenge in any implementation, especially if users prefer an alternative CMS or have unrealistic expectations. Optimize the CMS user experience for the most common use cases. Involve CMS users in prototyping to refine requirements, to begin user training, and to improve commitment.

The following provide and link to additional information that may be relevant to anyone reading this text.

If you know of additional considerations for architecting the heads for headless content management systems, please comment on this blog post.

4 thoughts on “SaaS Headless CMS Architectural Considerations, Part II

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: