Drupal Architecture for Healthcare: Why go Headless, Decoupled?
We are often asked about the different architecture options for Drupal. In this article we provide an overview of the various architecture approaches and how they can benefit healthcare organizations (or any industry, for that matter).
Drupal architecture generally falls into two main categories, traditional or decoupled. Each has its advantages and appropriate use cases.
A Natural Progression for Drupal
The Drupal community has been exploring non-traditional architecture options for almost a decade, including headless and decoupled. However, despite these efforts, most organizations still use Drupal in a traditional, unified setup. While the traditional approach works well in many cases, healthcare organizations looking to expand their digital marketing and patient engagement efforts should consider the benefits of a decoupled approach.
Flexibility is one of Drupal's core principles, and its modular structure allows organizations to build dynamic web experiences for their audiences. The introduction of decoupled and headless architecture options further extends this flexibility and enables Drupal to power even more dynamic digital experiences. Additionally, Drupal's evolution into an API-first platform makes it well-suited to leverage these newer approaches.
Acquia, the leading cloud platform for Drupal, has focused heavily on supporting headless and decoupled architectures in recent years. Its HIPAA-compliant cloud hosting is a great option for the centralized content repository often used in decoupled setups. Competitors such as Pantheon and Platform.sh have also made efforts to support and promote headless.
Drupal Architecture Options
Traditional or Unified Drupal
(Sometimes referred to as monolithic)
In a traditional architecture, Drupal is used for both the front-end presentation of content and the back-end management of content. Content editors add or manage content through Drupal's authenticated back-end admin section, while visitors view the front-end content, templates, and design system presented by Drupal via an HTML rendering engine (Twig).
The traditional approach provides all of the extensive content management features that have made Drupal one of the most powerful and widely used CMS platforms. The primary reason for using this approach is simplicity. If an organization is using Drupal to manage a website or set of websites and doesn't plan to reuse the same content for other digital channels or devices, a traditional architecture may be the best option.
Decoupled Drupal
In a decoupled architecture, different systems are used to control the back-end content management and front-end content presentation. In this setup, Drupal is typically used for back-end storage and management of content. The content is then accessed through Drupal APIs and presented in the front-end systems of an organization's choice. As a result, the Drupal repository (back-end) and front-end systems are decoupled.
In a decoupled architecture the content can be presented in any number of front-end systems and applications. These might include.
- Websites
- Native mobile apps
- Digital signage
- Chatbots
- IoT devices
- Smart watches
- Fitness trackers
- Voice devices (Alexa, Siri, Google Home, etc.)
- Patient portals
- Intranets
Headless Drupal
While the terms decoupled and headless are sometimes used interchangeably, they don't always have the same meaning. Headless refers specifically to Drupal's role in back-end content management within the context of a larger decoupled architecture. In this approach Drupal is not providing the front-end (the head). It has no head. It’s headless! In other words, Drupal is serving as the headless CMS in a decoupled architecture.
Advantages of Decoupled & Headless Drupal Architecture
Drupal is one of the best options for managing and storing digital content. It has evolved into an easy to use and feature-rich platform for organizations of all sizes. We don’t’ want to lose that. Especially for organization’s who’s marketing teams enjoy working with Drupal and aren’t interested in moving to another platform.
While Drupal is an excellent platform for content management, a traditional architecture may introduce limitations for front-end developers looking to leverage modern design systems. Using Drupal for the presentation layer can also result in bulky code and slower page loads. In contrast, headless architecture can result in faster page speed, as display logic is handled on the client side rather than the server.
A decoupled headless architecture combines the strengths of a strong Drupal-based back end for managing content with flexible, fast consumer experiences presented in the appropriate digital channels and applications.
A headless Drupal approach also provides additional benefits for marketing and development teams.
- An API-first approach that enables developers to use APIs for data consumption
- A clear 'source of truth' for content stored in a centralized repository
- Streamlined content syndication using a 'create once, publish everywhere' model
- A streamlined development process where back-end and front-end teams can work independently without impacting each other
What About Composable Architecture?
Composable architecture and composable DXP are terms coined more recently that describe an independent approach to the broader digital marketing and digital experience platform (DXP) stack. Whereas the terms decoupled and headless have typically been more specific to the CMS. But not always. Google “composable vs monolithic CMS” for a good trip down the rabbit hole).
Typically, but not necessarily, there’s a decoupled and headless CMS at the center of the composable architecture. The concepts are largely intertwined.
As an example, picture a Drupal back-end site used to create and manage content, which then provides APIs consumed by Salesforce CRM, Marketo marketing automation platform, Epic patient portal, ReactNative mobile app, and a consumer website built in HTML and Next.js or Gatsby.
Using a single vendor DXP, Adobe or other, to power most, or all, of those digital platforms would not be considered a composable architecture. Some would call that a monolithic architecture. A Google search for “composable vs monolithic DXP” results in varying definitions and conflicting opinions on the matter.
The jargon is continually evolving. Largely driven by the shifting marketing efforts of the major DXP vendors and industry analysts (e.g., Gartner and Forrester).
Other Headless CMS & DXP Options
There are dozens of CMS platforms marketing themselves as the leading solutions for headless content management. Products like Contentstack and Contentful were created specifically as headless platforms and have built large customer bases. Most modern CMS platforms can now be deployed in a headless architecture, including Adobe, Sitecore, WordPress, and Optimizely.
Alliance has experience working with all these platforms, including enterprise headless DXP strategy and implementation for large health systems. Contact us to learn more about the best approaches to implementing any of these content management architectures for healthcare.
Advantages for Healthcare Organizations
Drupal has seen tremendous growth in healthcare over the past decade. Hundreds of health systems and hospitals run their websites on Drupal, including industry-leading websites like Rush, Duke Health, Advent Health, Northwell Health, and UCLA Health.
For organizations that are already using Drupal, there is no need to switch to another CMS for back-end content editing and management. However, it may be beneficial to switch to a headless architecture to simplify content delivery and presentation across multiple platforms and take advantage of the benefits discussed earlier.
A decoupled approach aligns well with the structure and needs of health systems.
- Sizeable marketing teams with wide-reaching internal and external communications responsibilities.
- Distributed content authoring and management models. Often leveraging Drupal’s versioning, scheduling, and workflow capabilities.
- Many disparate and disjointed platforms and vendors used for marketing, internal communications, and patient engagement. For example, websites, campaign landing pages, email marketing, social, CRM, portals, mobile apps, and intranet.
- Common third-party integrations, plugins, and external data sources often slow page loads. This further emphasizes the need to streamline frontend technology and responsiveness.
A decoupled architecture using headless Drupal as the centralized content repository is well suited for this complex environment.
If you have questions or need support defining, implementing, or optimizing decoupled Drupal or a broader composable DXP strategy, we’d love to help!