1. Case Study: Building and Managing a CMS Infrastructure for Higher Ed Alozie Nwosu WebServices Group Brown University CIS

2. Why present a case study? Community. 3. Brown.edu + Drupal = BrownSites

Departmental Website Template Service 4. Application and Data Integration platform 5. March 2010 March 2011: planning through initial deployment 6. Project team including members from Brown CIS and Public Affairs and University Relations 7. Platform: Drupal 6, PHP 5, MySQL 4, Apache 1.3 8. December 2011: version 1.1 w/ ~160 sites (~70 Prod + ~90 Dev/Sandbox)

9. Drupal Implementation Scale 10.

Brown.edu Home Redesign 11. Economic Crisis -> Re-org

Getting off the Ground: Dumb Luck 12. Yea carrots!!! 13. CMS Implementation: The 4 Pillars

Know Your Constituents 14. Identify Your Resources 15. Choose Your Tools (Wisely) 16. Plan for Growth

17. 1st Pillar: Know Your Constituents 18. 2nd Pillar: Identify Your Resources 19. 3rd Pillar: Choose Your Tools...wisely 20.

Problem :Deploy multiple subfolder sites with minimal maintenance 21. Options:

• Multiple cores 22. Single core + single database (table prefixes) 23. MultiSite (multiple databases)

BrownSites uses subfolder MultiSite w/ db per site

• Discrete database per site; shared users across sites 24. Shared core modules 25. Granular permissions per sites

Multiple Sites?MultiSite. 26.

Problem : Expedite deployment of multiple sites. 27. Options:

• Aegir 28. Install Profiles + Features 29. Jenkins 30. Home grown solution

BrownSites uses home grown deployment script

• Built using Perl 31. Easiest way to go satisfying our requirements 32. See more: Appendix 2

Deployment Automation: Follow the Script 33.

Problem:Configure/customize admin interface to encourage adoption. 34. Key issues discovered through usability testing during Pilot and Early Adopter phases 35. Variety of interventions required:

• Well-defined roles/permissions 36. WYSIWYG API + TinyMCE config and customizations 37. Admin module and custom users page 38. Workflow and Workflow Access for publication workflow

Ease Adoption through Ease of Use 39.

Problem : Pull data from closed/silo'd systems to department websites. 40. Options:

• Data import via module (e.g. Feeds, Node Import,...) 41. Custom module

BrownSites using custom modules (and APIs) for external data

• Bedework Event Calendar ( http://events.brown.edu ) 42. Banner (course information)

APIs: No more silos 43. 4th Pillar: Plan for Growth 44. Put It All Together

Start playing and exploring early 45. Define client/system requirements as clearly as possible

Align project with:

• policies and organizational strategies 46. influential stakeholders

Test with users ( earlyandoften ) 47. APIs APIs APIs- the glue, the secret sauce, le raison d'etre

• May need to break out API/Data Integration into its own project

48. BrownSites: Present and Future 49. Q & A 50. Thank you. Brown WebServices: http://www.brown.edu/webservices Contact the team: webservices@brown.edu Contact me:

email: alozie@brown.edu 51. twitter: @theaphro 52. d.o: alozie

53. Appendix 1: Key BrownSites Modules

AdministrationUsers

• Admin Role 54. Role Delegation 55. Admin 56. Boost 57. Backup and Migrate

Custom

• Calendar Widget 58. Brown Courses 59. Brown Template Options

Media

• Image Assist 60. Embedded Media

Usability/UI

• WYSIWYG API 61. TinyMCE (library) 62. Better Formats 63. Dynamic Rendering 64. Vertical Tabs 65. Views Bulk Operations

Users

• Admin Role 66. Role Delegation 67. Workflow & Workflow Access

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