Making the Transition to SaaS Headless CMS and Service Architectures

While the concepts are simple, my experience with other systems and architectures presented obstacles to comprehending and adopting SaaS headless content management philosophies and techniques. This blog post intends to provide guidance for architects, developers, and organizations migrating to headless content management systems from other web experience management platforms, though some suggestions are more broad and may apply to any service-oriented architecture. If you have additional perspectives on these topics, please comment on this blog post.

  • Use your experience but forget most of what you know about existing content management solutions; envision a completely new CMS architecture intended to truly separate data from presentation and logic.
  • Implement applications as aggregations of independent functions (services) rather than monolithic platforms.
  • The content management system is not the foundation of the application; the data is the foundation of the application.
  • The content management vendor is responsible for managing the content management application and environments.
  • The CMS is a UI for managing data.
  • All text is JSON; dates, numbers, and other simple values are text.
  • All APIs are JSON HTTPS endpoints.
  • Focus on data modeling.
  • Use the CMS for its purpose: content (generic data) management.
  • Build your solutions next to the CMS rather than on top of it.
  • The CMS is the body managed by the vendor; customers manage content delivery heads.
  • You own the content delivery build processes, application services, web servers, and any content delivery networks beyond those provided for content delivery services.
  • All systems are completely unaware of the internals of all other systems, interacting only through webhooks and services.
  • SaaS uses webhooks, services, and UI customizations rather than back-end configuration and customization.
  • All interactions, including UIs and UI extensions, involve only HTTPS services and webhooks.
  • You are responsible for applications that orchestrate services and process webhooks for applications that expose services and process webhooks.
  • Use the most standard and common technologies possible.
  • Minimize and abstract vendor technologies, use of vendor software development kits, JSON formats, UI extensions, and other proprietary technologies.
  • Use only hosted services, SaaS, static files, CDNs, serverless, and other modern technologies.
  • Strongly consider implementing an event management system.
  • Focus on key objectives such as rapid content creation, deployment, and re-use.
  • Reduce expectations and simplify solutions.
  • Use independent, purpose-built systems for search, authentication, event management, commerce, stalking/experience management, and otherwise.
  • Be prepared for increasing use of JavaScript, including both front-end application integration and server-side frameworks.
  • Make some time to invest in understanding and prototyping solutions based on what you consider to be the most common requirements for web solutions.

Additional Resources

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 )

Google photo

You are commenting using your Google 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: