Using Drupal as an enterprise platform for supporting multiple content managed web sites

Posted Oct 22, 2010 // 4 comments

 As I said in a post from last year, nobody wants just one website anymore.  I'm increasingly faced with questions about how organizations can use Drupal to build and deploy a whole family of content managed websites.  Here, I attempt to partially answer that question by outlining 5 different techniques for using Drupal within your enterprise.

Common Drupal Environments

What?  Multiple Drupal sites are deployed in the same or similar environments, presumably by the same organization or organizations that are related.  The sites are completely separate, but benefit from a common technology platform and organizational familiarity.  The sites must be maintained separately and do not share any components.

When? Good for organizations looking to deploy multiple sites that are not tied to one another.  For example, two sibling organizations with unrelated objectives and separate budgets and timelines might find this solution appealing, even though no economies of scale are gained by it.

Drupal Multi-Site Installation

What? Multiple sites are deployed in a Drupal environment that allows sharing of core and modules, but also allows for maintaining each site individually.  Officially, this technique is called multi-site in Drupal.  Functionality and design can be shared by using common modules and a parent theme, but can be overridden on each site as needed.  Content is generally completely separate and in individual databases.

When? Perfect in the situation where you have a couple sites that share functionality and some design elements, but need to flex on their own product cycles.  Good for, say, a publisher with several web properties that need to run on the same platform, but have owners and stakeholders with their own ideas about the specifics of the site.

Virtual Site Implementation

What? An increasingly popular site deployment model with Drupal, virtual sites (not a Drupal-specific term or concept) come in many different forms and can be implemented with several different techniques.  Essentially, virtual sites are perceived as different web sites to end users, but are actually running inside a single Drupal instance.  This model simplifies even further the maintainability of the sites, while bringing them closer together in terms of functionality and design.  It is generally assumed that content can be both unique or shared between the sites.  This model allows for design variations using sub themes.  Virtual sites have the advantage of being very easy to deploy and maintain because 95% of their make-up is shared across the platform. 

When? Good for a large organization that has several (or maybe even hundreds) of sub-organizations that need their own web properties, but are not given much functional or design control over those properties.  This model would work well for, say, a record label that has many artist websites that they want to maintain as single functional unit.  Browsers of an individual artist site may have no idea that a larger platform is being used or that there is a relationship between any of the other artist sites.  

Microsite Implementation

What? Similar to the virtual site implementation above most site components are shared, but content can be different on microsites (also not a Drupal-specific term or concept).  There may also be a more obvious relationship to a main parent site, like a common header or some shared navigation.  There could even be relationships between the microsites so that readers are encouraged to move between them.  From a design standpoint, microsites aren't allowed to vary much due to their very tight integration with the main parent site.

When? A common need in large organizations, microsites are great for big, content-rich web sites that need to be segmented across organization or informational lines.  Microsites are inherently easy to deploy and maintain, so proliferating them according to your content needs is a low-risk, low-effort endeavor.  An example usage scenario might be a newspaper site that wants to build geographically localized content sections for "Neighborhood News."

Drupal Installation Profile

What? Perhaps the most misunderstood (and difficult to pull off) model for platformization is a Drupal installation profile.  A very powerful feature, installation profiles can be used for stamping out identical clones of a standard Drupal site template.  Building an installation profile takes a deep understanding into the concept of exporting configurations from Drupal, a topic of which is way deeper than I'm able to go into here.

When?  Installation profiles are a large effort, so the decision to use them should not be one that is taken lightly.  There is a large investment up front, but it can pay off dividends if the economies of scale is proportioned correctly - we're talking about a lot of sites here!  They are appropriate for an organization looking to standardize the deployment of sites that need to operate on an individual basis and may all move off in wildly differing directions.  In other words, think of installation profiles as giving you a head start, but once you install one, it's up to you to make it the web site you want it to be.  One architectural note: If you are managing an installation profile within an organization, it would generally make the most sense to deploy the sites in a Drupal multi-site environment (described above).  This would give you the versatility of stamping out individual sites with a template, without the burden of having to maintain them separately. 

I stopped short of name-checking actual Drupal modules in this post.  That was intentional.  There are many great (and some not-so-great) modules out there that can help you achieve these solutions, or variations of them.  I encourage you to do your own research and join the debate - there are many different discussions on Drupal.org about this subject.  I would love to hear about your success or failure with any of these techniques, so leave a comment!