BrownSites: Building and Managing a CMS Infrastructure for Higher Ed


Published on

Drupal Case Study Presentation of BrownSites, the Drupal-based departmental web template service deployed for Brown University. Presented at DrupalCampNYC (held at John Jay College), Dec. 10, 2011.

*Download presentation file for helpful background notes.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • [Community] Higher Ed + Technology: - low cross communication - low system compatibility Drupal Community: - strong + awesome!!! - shared knowledge helped us succeed - we wanted to give back
  • cms implementation projects can range from individual site/application to organization-wide platform. On the Coffee cup scale: large to jumbo. Characteristics of large-jumbo: - across organization, - centralized support (training, documentation, upgrades), - common platform for app development ("forms", "databases", app templates), - integration with enterprise systems (APIs).
  • 1) Economic Crisis => Organization Reorg - Senior Administration + Brown Corporation mandate for resource consolidation - translation: reduce need for technical specialists in departments by providing better centrally-supported tools 2) Brown Corporation mandate for Home redesign/upgrade - provide new look and feel for - better showcase news, evemts, and integrate multimedia - improve maintenance tools for more responsive updates – provide automation and integration with other systems where possible
  • The carrot: a system that upgrades the design of the site and makes site easier to maintain. diminishes the effects of... The stick: a) approval required for hiring of external resources for department website design and development. b) some department technical personnel/functions absorbed into CIS (university's IT department)
  • 4 Pillars ["maaaarble columns!"] of CMS Implementation CMS Implementation big undertaking. Core team of 8. Planning started Feb 2010. Pilot sites launched Feb 2011. Bulk of development Sept 2010 through January 2011. For success: 1) Constituents: audience, stakeholders, users. Needs, wants, constraints. 2) Resources: team members, skill sets, existing/projected infrastructure. In-house vs. external resources. Constraints: Budget? Time? Personnel? Other? 3) Tools: start learning early. Build test sites. Online articles and videos. Webinars and training sessions. Identify technical challenges early. Leave room to experiment. 4) Growth: Be prepared. Gradual deployment. Support? Training? Platform performance and scaling?
  • Who are your constituents? What are their needs? Constraints? Overlaps? Conflicts? Identify and target key requirements. Identify potential collaborators - especially Pilot and Early Adopters. (focus of WebServices Design Team.) Two initial roll-outs: a) Pilot - tested rollout process and training. b) Early adopters - system enhancements, retest deployment and training, initial implementation request process. Key stakeholders: who's got leverage? Who will support (with funding or clout)? Upper level support (directives from upper IT management, budgeting, university governance and strategy?). For BrownSites project: Mike Pickett (CIO), Plan for Academic Enrichment, the Brown Corporation (redesign and re-org).
  • Who's the team? What tools and skills are already in place? What tools and skills are needed? BrownSites Personnel: 11 person web services team (7 fulltime + 4 interns). 3 members of UNIX Admin Team. 2 person computer education team. 1 member of the Help Desk. 3 members of Public Affairs and University Relations (PAUR). Infrastructure: Running Apache (version), PHP (version: ), and MySQL (version: ) on Linux. Prior Drupal installations for today@brown and news@brown (PAUR). Pilot department site projects in 2009 & early 2010 (PTP, BME, GradSchool).
  • Drupal = Flexibility => (near) Infinite Possibility Rubber Meet Road: Modules, Techniques Important stuff: - Platform: MultiSite vs. MultiCore, DB Prefix - Deployment Automation - Usability Accommodations/Enhancements - Data Integration: Bedework, Banner
  • Use the information gathered from learning about constituents, resources and tools to prepare for the issues of deployment process, training, support/maintenance, customization, performance/scaling (site count, server traffic, database size,...). What tools can you put in place (server analytics, watchdogs, load testing)? What team member support roles do you need (trainers, help desk, communications, IT directors)? What non-technology resources are needed (communications and outreach, IT policy, customer service strategy/procedures)? For BrownSites, preparations included Boost configuration, database backup (via Backup and Migrate), Disaster Recovery coordination and testing, request process development and stewardship (including training and production launch). Custom development and exceptions: policy, intake, process, prioritizing, charge back.
  • [Elmer's Easy Squeeze]
  • Brownsites version 1.1 (version 1.2 planned release 2/1/2011) ~160 sites deployed (~60 production) Plans: Improve system upgrade process (currently: manual sql dump scrubbing) improvements to request and deployment automation (e.g. better integration btwn request and deploy systems) Automate site decommission Build/Integrate faculty/staff info by dept.
  • BrownSites: Building and Managing a CMS Infrastructure for Higher Ed

    1. 1. Case Study: Building and Managing a CMS Infrastructure for Higher Ed Alozie Nwosu WebServices Group Brown University CIS
    2. 2. Why present a case study? Community.
    3. 3. + Drupal = BrownSites <ul><li>Departmental Website Template Service
    4. 4. Application and Data Integration platform
    5. 5. March 2010 – March 2011: planning through initial deployment
    6. 6. Project team including members from Brown CIS and Public Affairs and University Relations
    7. 7. Platform: Drupal 6, PHP 5, MySQL 4, Apache 1.3
    8. 8. December 2011: version 1.1 w/ ~160 sites (~70 Prod + ~90 Dev/Sandbox) </li></ul>
    9. 9. Drupal Implementation Scale
    10. 10. <ul><li> Home Redesign
    11. 11. Economic Crisis -> Re-org </li></ul>Getting off the Ground: Dumb Luck
    12. 12. Yea carrots!!!
    13. 13. CMS Implementation: The 4 Pillars <ul><li>Know Your Constituents
    14. 14. Identify Your Resources
    15. 15. Choose Your Tools (Wisely)
    16. 16. Plan for Growth </li></ul>
    17. 17. 1st Pillar: Know Your Constituents
    18. 18. 2nd Pillar: Identify Your Resources
    19. 19. 3rd Pillar: Choose Your Tools...wisely
    20. 20. <ul><li>Problem : Deploy multiple subfolder sites with minimal maintenance
    21. 21. Options: </li><ul><li>Multiple cores
    22. 22. Single core + single database (table prefixes)
    23. 23. MultiSite (multiple databases) </li></ul><li>BrownSites uses subfolder MultiSite w/ db per site </li><ul><li>Discrete database per site; shared users across sites
    24. 24. Shared core modules
    25. 25. Granular permissions per sites </li></ul></ul>Multiple Sites? MultiSite.
    26. 26. <ul><li>Problem : Expedite deployment of multiple sites.
    27. 27. Options: </li><ul><li>Aegir
    28. 28. Install Profiles + Features
    29. 29. Jenkins
    30. 30. Home grown solution </li></ul><li>BrownSites uses home grown deployment script </li><ul><li>Built using Perl
    31. 31. Easiest way to go satisfying our requirements
    32. 32. See more: Appendix 2 </li></ul></ul>Deployment Automation: Follow the Script
    33. 33. <ul><li>Problem: Configure/customize admin interface to encourage adoption.
    34. 34. Key issues discovered through usability testing during Pilot and Early Adopter phases
    35. 35. Variety of interventions required: </li><ul><li>Well-defined roles/permissions
    36. 36. WYSIWYG API + TinyMCE config and customizations
    37. 37. Admin module and custom users page
    38. 38. Workflow and Workflow Access – for publication workflow </li></ul></ul>Ease Adoption through Ease of Use
    39. 39. <ul><li>Problem : Pull data from closed/silo'd systems to department websites.
    40. 40. Options: </li><ul><li>Data import via module (e.g. Feeds, Node Import,...)
    41. 41. Custom module </li></ul><li>BrownSites using custom modules (and APIs) for external data </li><ul><li>Bedework Event Calendar ( )
    42. 42. Banner (course information) </li></ul></ul>APIs: No more silos
    43. 43. 4th Pillar: Plan for Growth
    44. 44. Put It All Together <ul><li>Start playing and exploring early
    45. 45. Define client/system requirements as clearly as possible </li></ul><ul><li>Align project with: </li><ul><li>policies and organizational strategies
    46. 46. influential stakeholders </li></ul><li>Test with users ( early and often )
    47. 47. APIs APIs APIs - the glue, the secret sauce, le raison d'etre </li><ul><li>May need to break out API/Data Integration into its own project </li></ul></ul>
    48. 48. BrownSites: Present and Future
    49. 49. Q & A
    50. 50. Thank you. Brown WebServices: Contact the team: Contact me: <ul><li>email:
    51. 51. twitter: @theaphro
    52. 52. d.o: alozie </li></ul>
    53. 53. Appendix 1: Key BrownSites Modules <ul><li>AdministrationUsers </li><ul><li>Admin Role
    54. 54. Role Delegation
    55. 55. Admin
    56. 56. Boost
    57. 57. Backup and Migrate </li></ul><li>Custom </li><ul><li>Calendar Widget
    58. 58. Brown Courses
    59. 59. Brown Template Options </li></ul><li>Media </li><ul><li>Image Assist
    60. 60. Embedded Media </li></ul></ul><ul><li>Usability/UI </li><ul><li>WYSIWYG API
    61. 61. TinyMCE (library)
    62. 62. Better Formats
    63. 63. Dynamic Rendering
    64. 64. Vertical Tabs
    65. 65. Views Bulk Operations </li></ul><li>Users </li><ul><li>Admin Role
    66. 66. Role Delegation
    67. 67. Workflow & Workflow Access </li></ul></ul>
    68. 68. Get new site information from request database Create sites directory from default template folder Create temp folder Create empty site database and db user Update settings.php with db and db user Execute database import from paramaterized SQL dump Modify http config files – define site alias *upon errors throw error, stop execution, rollback where possible ** if success, operator manually reboots apache cluster to apply site alias changes Appendix 2: Deployment Script Highlights