Bye, Bye Blackboard

Texas State University

The largest university in the Texas State University System and the sixth largest university in Texas serving over 29,000 students on a 457-acre campus located in the scenic Texas Hill Country between Austin and San Antonio.

Presenters

• Michael FarrisProject lead mf03@txstate.edu

• Jeff SniderDBA/Developer js38@txstate.edu

• Whitten SmartUser Support and Documentation ws15@txstate.edu

Blackboard

• Adopted in 1999 • Heavily modified and aging by 2004 • Complete rewrite of the custom code required

for deploying newer version• The same rewrite required for future releases

The Goal

Provide a learning management system that:

• Placed control in the hands of the people who use it, Texas State faculty.

• Supported the development and maintenance of customization with minimal restrictions.

The Project

To deactivate the customized version of Blackboard by facilitating a voluntary migration of faculty to a more robust, agile learning management environment.

The Project Team

Michael Farris – Project lead mf03@txstate.edu

Rori Sheffield – Project Assistant/User Support rp41@txstate.edu

Salwa Khan – SAKAI liaison/User Involvement sk16@txstate.edu

Jeff Snider – DBA/Developer js38@txstate.edu

Amy Boyd – Developer/Programmer ab46@txstate.edu

Sean McMains – Software Architect and Advisor seanmctex@txstate.edu

Yuanhua Qu – Developer/Programmer yq12@txstate.edu

James Buratti – Web Support jb63@txstate.edu

Jimmy Rico – User Support and Documentation sr03@txstate.edu

Whitten Smart – User Support and Documentation ws15@txstate.edu

Mary Cauble – Project & Change Management mc01@txstate.edu

Laura Trial – Graphic Design lt20@txstate.edu

Deborah Morton – Faculty Representative dbmor10@txstate.edu

Hideo Goto – Quality Assurance

The Beginning

• Interview faculty• I like• I don’t like• I want

• Document requirements• Complete gap analysis

Critical Success Factors

• Voluntary migration• Blackboard imports• Freely modifiable code• Faculty perception

Migration Process

Blackboard

Sakai Concept Study Pilot Open Final Operations and Maintenance

Operations and Maintenance Discontinuance End of Life

Migration Control Gates

Sakai enhancement releases

(1) Early Deployment and Transition Planning

(2) Initial deployment to users

(3) Detailed Discontinuance Planning

Project Paths

Application Development

Network and Server Infrastructure

User Involvement and Change Management

Branding, Identity and Positioning

Support Structure

Training and Documentation

Quality Assurance

Sakai Foundation Tracking and Advocacy

Team Coordination

• Team meetings• Redirect the Bullet retreats• Ticket system• Project site

OverviewThe Pilot

• Fall 2005• Membership

• 10 faculty, +/- 900 students• Spring 2006/Summer 2006

• Membership• 25 faculty, +/- 2000 students

• Criteria for faculty selection• Sites in Blackboard, extensiveness of Blackboard site,

computer use• Support

• Hand holding• Survey

• Results and Lessons Learned

GoalsThe Pilot

• Recruit 1,000 users• Develop initial branding• Develop strategy for features• Create demand for TRACS• Create proactive support structure• Create effective training• Develop Blackboard, TRACS inter-application

interface• Be ready for faculty

Change ManagementThe Pilot

• Executive Support• Provost• Vice Presidents• Assistant VP• Deans

• Faculty• Chairs• Faculty Senate• Focus groups• Liaisons

SupportThe Pilot

• Fall 2005• Handholding• One on one faculty training• In class training• Documentation• Phone and e-mail

SupportThe Pilot

• Spring 2006• Workshops

• Beginning• Advanced• Gradebook and Assessments

• TRACSfacts• OTRS

InfrastructureThe Pilot

Pilot system• Virtual, since we didn’t know

what we needed

What worked• Apache &mod_jk• Multiple app servers

What didn’t work• Files stored in DB• So few app servers (They die

a lot)

Lessons LearnedThe Pilot

• What We Did Well• Identified and selected pilot faculty• Created TRACSfacts• Paid attention to branding and user interface• Had faculty recruit colleagues for next

semester

Lessons LearnedThe Pilot

• What We Needed to Do Better• Remember, the user is not us• Acknowledge the dark side and do the opposite• Revise and prioritize relentlessly• Be gracious, be humble, be honest and be authentic• Communicate directly with students• Go slow, stay low, keep moving, and don’t get too

greedy

OverviewThe Migration Begins

May-05

Jun-0

5Ju

l-05

Aug-05

Sep-05

Oct-05

Nov-05

Dec-05

Jan-0

6

Feb-06

Mar-06

Apr-06

May-06

Jun-0

6Ju

l-06

Aug-06

Sep-06

Oct-06

Nov-06

Dec-06

0

100

200

300

400

500

600

700

Course Sites in TRACS

OverviewThe Migration Begins

• BB archive import• Curriculum for workshops and

documentation • Faculty readiness survey

TRACS Readiness SurveyThe Migration Begins

InfrastructureThe Migration Begins

• Open Migration System• What changed

• Real hardware• Several instances of the app

per server• Separate storage for files

• What didn’t work• Cheap network switches that

failed under load gave us a big black eye at the start of semester

OverviewThe Middle Years

May-07 Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07 Dec-07 Jan-08 Feb-08 Mar-08 Apr-08 May-080

500

1000

1500

2000

2500

Course Sites in TRACS

OverviewThe Middle Years

• Spring 2007 through Spring 2008

• Focused on reliability• Proactive in Sakai community• Expanded support efforts• Involved faculty in core team• Determined end date of Blackboard

Change ManagementThe Middle Years

• Message of the day• Faculty Steering Committee• Individual visits with the chairs• New faculty• Dean, Chair, Faculty, Student and TA messages• Published Blackboard end date • Who’s in BB, who’s in TRACS, who’s in BB and

TRACS, and different communication for each

SupportThe Middle Years

• Workshops• Training videos• TRACSfacts re-vamp• Faculty to faculty help• FAQ

SupportThe Middle Years

• Steering Committee• Role• Criteria• Support• Expectations

SupportThe Middle Years

InfrastructureThe Middle Years

• By Spring 08, average daily sessions had risen from 700 to 2500.

• Added another server capable of running four more instances of the app

• DB server load is consistently high, so we submit a request for a new server

Lessons LearnedThe Middle Years

• What We Did Well• Communicate, communicate, communicate• Offer training in every conceivable format• Steering Committee recommended end-date• Added a faculty member to the project team

• What We Needed to Do Better• No changes, no matter how “inconsequential,” right

before finals• It’s the Faculty Steering Committee• Acknowledge the obvious

The Final Days

OverviewThe Final Days

• Summer 2008

• Focus on last 5% of faculty in BB• Focus on staff project sites• Utilize targeted communications• Carryout progressive dates of BB

shutdown

Change ManagementThe Final Days

• Returned to handholding• Made telephone calls• Changed BB login page numerous times• Scheduled office visits• Insured administration awareness• Contacted project site owners

Support The Final Days

• Increase support staff• Conduct fewer workshops• Create more videos• Implement Bomgar• Improve coordination with campus

helpdesk• Deploy new telephone system

SupportThe Final Days

Jul-0

6

Aug-06

Sep-06

Oct-06

Nov-06

Dec-06

Jan-0

7

Feb-07

Mar-07

Apr-07

May-07

Jun-0

7Ju

l-07

Aug-07

Sep-07

Oct-07

Nov-07

Dec-07

Jan-0

8

Feb-08

Mar-08

Apr-08

May-08

Jun-0

8Ju

l-08

Aug-08

Sep-08

Oct-08

0

500

1000

1500

2000

2500

3000

BBTRACS

Lessons LearnedThe Final Days

• What We Did Well• Use multiple methods, avenues of communication• Track the stragglers

• What We Needed to Do Better• Test, test, test• No changes, no matter how “inconsequential,” at the

beginning of the semester• Remember the students• You can’t please everyone• Remember the non-traditional courses

InfrastructurePull the Plug

• New DB server finally comes in. One day before the start of Fall.

• Old DB server is overworked.• We tried to wait until a weekend

to upgrade -- Mid-week upgrade decided for us.

• New DB server is huge. Tuned for speed. MySQL allocated 12Gb.

Pull the Plug

• Build a better system and they will come.• Take the extra steps and time.

OverviewInto the Future

• Define archive retention process• Stabilize release cycles• Increase involvement of Steering Committee• Focus on pedagogy• Deploy a knowledge base• Improve QA test process• Create task-based help

InfrastructureInto the Future

• Increase file space• Big appetite for storage• Several gigs per day

• Multiple Load Balancers• One is fine, until an app blows up• More redundancy

• More RAM for app instances• Ideally 5+ Gb each

Q&A