Portland State University - Multi-department CMS Development

Challenge

Client requested that each department within the organization have a consistent look and feel, security policy, and feature set. However each department site should not allow users the ability to modify other department sites without expect permission. The solution also needed to provide flexibility for each department should a department want to use a different theme, community module, or develop custom modules the system should easily support this behavior. The solution also needed to provide the ability to rapidly deploy new Drupal websites with minimal technique knowledge.
 

Solution

Drupal provides several different options when creating multiple sites the three options are:

a) Single Drupal Site with Community Modules
The technique would co-mingle all department data into a single set of database tables. Security policies, content, navigation, and user information would be managed by the community modules. This would result in a single Drupal site with a single set of Drupal source code and a consolidated database with separate content spaces created using group-based modules provided by the Drupal community.

Pros
Totally automated group creation reducing the need for technical personnel when a new department site was requested. Provide a consistent security policy, features, and display of information.

Cons
No clear way to change the theme from group to group, because all departments are within a single Drupal site the default Drupal themeing framework will not work. Any change to the security policies, settings, or features would require custom development to integrate into the group community module. Other community modules are not "group" aware and would require custom development to make the modules work in context to the group community modules. Group modules imply a specific work flow, navigation, and user experience that may not follow the requirements of the organization and or individual department. No clear way to quickly split one group from the rest and host on a separate instance of Drupal.

b) Individual Drupal source code per department
This technique would duplicate the Drupal source code and database for each department site. The result would be duplicate Drupal source code, modules, media, and database for every department.

Pros
Complete separation of each department site reducing any possibility of corruption from another site. Total freedom to customize each department site with new modules and themes without affecting other sites. Individual sites will have separate database tables making site isolated from each other.

Cons
No easy way to update modules and source code, 20 to 400 sites would be very labor intensive to upgrade and update when a patch or new release were available. No easy way to share information between sites, such as user accounts roles, sessions, etc without creating 3rd party systems and routines.

c) Single Drupal Source code per department sub-site
This technique would provide multiple department sites using a single Drupal source code tree. Each department sub-site would have separate database tables shared within a single database.

Pros
Provides a consolidated source code for easy updates to all sites.
Individual sites will have separate database tables making site isolated from each other.
Provides a framework to override modules and load modules per-site.
Provides a framework to override themes and load custom themes per-site.
Provide a framework to share data between departments.

Cons
Shared source code could take down all sites if an error were to occur
 

Robert's Thoughts

Drupal provides many different options to solve a business or technical problem. In most cases the solution may only work for the given business case and may not support any supplemental requirements or strategies. It is the responsibility of the solution team to weigh in all requirements and devise a complete solution that supports all of the requirements not just the initial needs. This is why I don't support using an agile approach to Drupal because without looking ahead to the end goal you can waist weeks if not months re-factoring the design and never devise a strategy that meets all requirements.