Duke’s Faculty Database System: Content Management for Faculty Information EDUCAUSE Baltimore...

Duke’s Faculty Database System: Content Management for

Faculty Information

EDUCAUSEBaltimore

January 13, 2004

Copyright Melissa Mills, Kevin Wiitte, and Adrienne Moore, 2004. This work is the intellectual property of the authors. Permission

is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement

appears on the reproduced materials and notice is given that the copying is by permission of the authors. To disseminate

otherwise or to republish requires written permission from the authors.

Duke UniversityJanuary 13, 2004

Faculty Database SystemAgenda

• What is the FDS?

• Project Time Line

• Technical Overview

• Implementation

• Next Steps

• Questions?


Themes

• Tool for Faculty

• Adaptability < => Complexity

• Efficiency


What is the FDS?

• Ties to enterprise systems

• Repository of faculty CV data

• Operational system- faculty submit annual reports

- chairs submit annual evals

• CMS to syndicate faculty & dept data


Features

• Easy to access

• Flexible/Scalable

• Secure


History

• Grassroots - Math Dept

• Solution to a Problem

- timely web page maintenance

- annual reports from faculty

- faculty incentive

• First implementation - 1998


Project Time LineYear One:

• June 2001: FDS commissioned by Dean of A&S• October 2001: Delayed implementation while collecting feature

request• January 2002: Showcase training for pilot departments

Year Two:• June 2002: FDS production system ready for runtime; Input for

individual departments begun• November 2002: Annual report submission feature deployed• May - June 2003: Pilot project assessed

Year Three:• July 2003: Deployment to 34 departments• December 2003: Annual reports required of 600 faculty


Project Team

• Sponsor: Dean of A&S (W. Chafe)

• Developer: Sr Sys Admin, Math (Y. Yu)

• Liaison: Assoc Dean for Computing (M. Mills)

• Project Manager: IT Communications Consultant (A. Moore)

• Technical Support: Director, Sulzberger Interactive Lab (K. Witte)

Technical Overview


FDS System Implementation

• LAMP: Linux, Apache, MySQL, Perl/PHP/Python• Bulk of function written using Perl and CGI• Secure, scalable and very fast• Built around open standards and non-proprietary data

formats• Thoroughly integrated with enterprise systems on and

off campus• Content published using templates which means the

same data can be published in innumerable ways


FDS System Security and Data Integrity

• Data input is validated, database queries systematically checked

• Sensitive data is protected by GPG 128-bit public key encryption

• Data is always transmitted using Secure Sockets Layer (SSL)

• System backups are encrypted as well• Single sign-on via secure, trusted authentication

mechanism• Rich role-based authorization layer• Supporting third-party utilities operate within virtual

software jail• Secure, dedicated server with redundant safeguards and

failovers


FDS System Scalability and Performance

• Generic Linux server setup with large disk array and excess RAM

• Tuning and caching support a large number of concurrent users

• MySQL database is very small, fast and efficient• Persistent web and database server connections• Database caching minimizes redundant query parsing

and fetching• Capable of handling more than 100 requests per second

with sub-second response times being the norm• Can handle 30,000 users, more than eight million queries

per day


FDS Interfaces to Enterprise Systems

• Duke’s Student Information Services & Systems (SISS)• Duke’s LDAP-based Enterprise Directory• Kerberos (KRB5) and Webauth authentication

mechanisms• National Library of Medicine's PubMed• American Mathematical Society’s MathRev• America Physical Society’s E-print• Can parse most manuscript data formatted using well-

formed XML


FDS Templating System

• Makes the FDS a true content management system• Database queries spawn XML data output streams• XML is merged with appropriate template to render HTML• Same data can be rendered innumerable ways via

templates• Custom scripting language for building templates• Every template in the system is stored in the database• Every web page generated by the system is based on a

template• Templates parsed and certified each time one is

modified/created• System supports template versioning and staged

publishing


FDS in Operation


QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.


FDS Technical Lessons Learned

• Tricky balance between complexity, usability and adaptability

• Customization is the feature that makes a system like this viable

• Write once, publish anywhere via templates increases efficiency, and ensures consistency and accuracy of published data

• Template development requires specialized skills:- more like coding JavaScript than straight HTML- most faculty and staff will avoid customizing their own

templates- web development staff creates the majority of FDS templates- up-front need for hands-on technical assistance can be high

for each department


FDS Templates - Streamlining Development

• Create thorough documentation on custom templating language

• Build library of “à la carte” template themes from which departments may chose elements from a ready palette

• Utilize and communicate development caps on investment of time and energy

Implementation


Train Departmental Managers

• FDS managers/administrative assistants had to be convinced

• Funding data entry of faculty CV info and providing website customization made the project possible

• Getting the right contacts in departments made all the difference


Data Entry

• Collect faculty CVs and enter last five years’ worth of data

• Goal was to enter enough data to ease the annual report process for faculty

• Trade-off between efficiency and the benefits of departmental oversight


Collect and constantly respond to feedback

• Ability to swiftly respond to feedback by implementing new features has helped ingratiate the system to its users.

• Different disciplines have different requirements


Get template customization underway

as soon as possible…

THEN introduce faculty to FDS

• Customizing the web pages made it much easier for departments to understand how the database would work for them

December 2003

The Arts & Sciences Faculty come face-to-face with the FDS


We have a few regrets...

• Very little time for training

• No contextual help

• Not enough time for proactive customization

• Not enough time to get a flu shot


But on the whole, it was a success

• The privacy policy was important

• Some things you can really only learn by doing


To-do list

• Focus groups• Contextual help• Integrate with university grants

database• Implement ability to upload

publications in BibTeX format• More work on user-interface and

web customization strategies


Next Steps

• Focus groups- Department chairs- Dept’l managers- Faculty

• Institutional directions- Faculty databases- Zope4edu

• www.facultydatabase.org


FDS Information

• Dr. Yunliang Yu, Developer• Pilot Report:

http://www.aas.duke.edu/comp/fds/pilotreport.pdf

• Faculty Database System http://fds.duke.edu/

• Questions: [email protected]


Presenters

• Melissa J. Mills Associate Dean of Arts & Sciences for Computing

[email protected]

• Kevin Witte, Director Cynthia Sulzberger Interactive Learning Lab

[email protected]

• Adrienne MooreIT Communications Consultant, Arts & Sciences

[email protected]


This presentation is available at:

http://www.aas.duke.edu/comp/fds/fdsbaltimore2004.ppt

Duke’s Faculty Database System: Content Management for Faculty Information EDUCAUSE Baltimore...

Documents

Transcript of Duke’s Faculty Database System: Content Management for Faculty Information EDUCAUSE Baltimore...