My UW-Madison Enterprise Portal Migration to Open Source Framework Jim Helwig EDUCAUSE Midwest...
-
Upload
gervais-price -
Category
Documents
-
view
215 -
download
0
Transcript of My UW-Madison Enterprise Portal Migration to Open Source Framework Jim Helwig EDUCAUSE Midwest...
My UW-Madison Enterprise Portal My UW-Madison Enterprise Portal
Migration to Open Source Migration to Open Source FrameworkFramework
Jim Helwig
EDUCAUSE Midwest Regional Conference, Chicago
March 23, 2005Copyright @ 2005 The University of Wisconsin Board of Regents
This work is the intellectual property of the author. 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 author. To
disseminate otherwise or to republish requires written permission from the author.
2
My UW-Madison Migration
• Who?
• Why?
• How?
• And?
• So?
• ???
3
My UW-Madison Migration
• Who? Background and history
• Why? Motivation for change
• How? Approach
• And? Current status, future
• So? Lessons learned
• ??? Questions
4
Who?
5
Who? - The players
• 41,000+ students
• 13,000+ Faculty/staff
• 700+ employees in DoIT
6
Who? - The players
• My UW-Madison Advisory Group
• My UW-Madison Service Team
• Portal Infrastructure Team
• Development groups
7
Who? - The portal
• My UW-Madison - MUM
• Came out of Academic Technology
• 1999 Concept
• 2000 Pilot
• 2001 All students
• 2002 All faculty/staff
8
Who? - The portal
• 94,510 customers over time
• 45,000+ active customers
• 15,000+ unique customers per day
• 1,000+ concurrent customers
• 50,000,000+ requests per month
9
Who? - The infrastructure
• Javaon Epicentric
on WebLogic Serveron Solaris
• 1 database server2 application servers
2 web servers1 Layer 4 switch
10
Who? - The applications
• 100+ modules
• Application aggregation and integration
• Student information system
• Communications
• Business services
• Help Desk
• … and more
11
12
13
14
Why?
15
Why? - Motivation
• Because we said so
• Major software upgrade
• Software maturity
16
Why? - Motivation
• Desired additional features
• Licensing
• Support
• Higher Ed Community
17
How?
18
How? - Concerns
• “Mucking about” with core, critical piece of infrastructure
• Many technical players
• Many campus players
• Existing portal
• Current requirements, future needs
19
How? - Approach• Campus requirements gathering
• Technical requirements
• Vendor presentations
• Proofs of concept
• Planning
• Implementation
• Rollout
• Follow-up analysis
20
How? - Campus Requirements
• 17+ members
• Led by DoIT Architecture
• Current and future stakeholders
• Several months
• Intense phase, multiple long sessions each week
21
How? - Campus Requirements
• Final 29 page document
• Matrix of features
– near to far term
– 25+ areas
– Critical/desired/optional
• Glossary
• Personal statements
• Use cases
22
How? - Technical Requirements
• Mostly DoIT staff
• Detailed vs. visionary
• 300+ line items
23
How? - Vendor Presentations
• Six products
• One week, four hour blocks
• Technologists, management, campus requirements team
• Not a lot of detail, but insightful
24
How? - Narrowing the field
• From six to two
• All could probably do the job
• None were perfect
• Epicentric (now Vignette) because of current investment
• uPortal because of unique model
25
How? - Proofs of Concept
• Two back-to-back, week long engagements
• Use cases from campus requirements team
• Selection of representative modules and features
• Ability to showcase others features
• Significant commitment of resources
26
How? - Final Selection
• Both could do the job
• Epicentric/Vignette upgrade would be more expedient
• Upgrade had more immediate value
• But…
27
How? - Final Selection
• uPortal easier to customize
• More support options
• Momentum within community
• Focused on Higher Ed
• More likely to influence future
• Better long-term value
28
How? - Planning
• Decision process took eight months
• Opportunity to research before giving rollout date
• Recognition of project size
• Separate planning project
29
How? - Planning
• Core team of ten technical leads
• Three months of weekly meetings
• Technical mapping document
• BOKs – Bodies of knowledge
• Tasks for each area of responsibility
• Merged into one comprehensive project plan
30
How? - Factors
• Academic calendar
• Resource constraints
• PeopleSoft upgrade?
• Planning with very limited knowledge
• Avoiding a mid-air collision
31
How? - Planning
• 450+ tasks
• 15,000-20,000 hours
• 16 months
32
How? - Implementation
Now
Testing
Setup Development SupportPlanning
August 2005Rollout of new portal
January 2004Migration planning starts
May 2004Initial project implementation plan complete
September 2004uPortal training
December 2004Major revision of project plan
June 2005Major development complete
33
How? - Implementation
• Core planning team morphed into core implementation team
• Individual leads responsible for particular tasks
• Tracked via MS Project
34
How? - CommunicationMUM Advisory Group
John Peterson
Migration Project Manager
Jim Helwig
Other Interested Parties
RO’s officeTech Partners
DoIT Help DeskMy-dev list
My-mumprodMy-mumqa
E-InfrastructureGroup
Bill Scheuerell
DoIT Communications
Brian Rust
DoIT CIO Office
MUM Service Team Leader
Annette Stratman-Durrer
MUM SponsorsJohn PetersonBill Scheuerell
Infrastructure Issues
Tab Issues
Timeline/Project Plan
Overall Look and Feel
Module Development
Policy Issues
MUM Service Team
Annette Stratman-Durrer
My FrontpageAl FriedmanNick Weaver
AcademicKathy Christoph
LibraryCarrie Kruse
Campus LifeTrey Duffy
FinancialSusan FischerCathie Hanlon
Student Record EnrollmentJoanne BergJim Steele
ResourcesJohn Peterson
Work RecordDon MinerDon Schutt
Tab sub committees
AcademicTim Aucremann
My FrontpageBrian Rust
Student RecordFinancial
EnrollmentOzzyie Chen
ResourcesWork RecordBrian Busby
MUM Tech Forum
Jim Phelps
UIUENick Weaver
Portal Infrastructure
Jim Helwig
Core migration groups
POST Middleware DRMT Networking
Auxiliary migration groups
Tab technical teams
Tech
nica
l Gro
ups
Adm
inis
trativ
e C
omm
ittee
s
My UW-Madison Migration Project – Communication Flow
Testing Issues
General Development Technical Issues
35
How? - Communication
• Bi-weekly core team meetings
• Bi-weekly service team meetings
• Bi-weekly sponsor update
• Monthly DoIT meetings
• Monthly advisory group meetings
• Monthly status update email
36
How? - Communication
• Tech forums as needed
• Developer’s email list
• Project home page
• Wiki
• Issue tracking system
37
How? - UI/UE
• User Interface/User Experience
• Led by UW-Communications
• Used surveys, card sorting, paper models, interviews
• Dove tailed with UW Home Page redesign
38
39
40
41
42
How? - External Support
• Getting support was critical
• Attended JA-SIG conferences for information and networking
• Follow uPortal mail lists
• Selected Unicon for training, mentoring, selected development, ongoing support
43
How? - More planning
• Unexpected tasks
• More knowledge
• Staff changes
• Need periodic review of project plan
• Avoid too much task detail
44
And?
45
And? - Current status
• Still on target for August 2005 rollout
• Intense portlet development
• Starting User Interface/User Experience development
• Installed development environments, working on QA environment
• Selected system platform
46
And? - Future
• Full QA this summer
• Extended testing, quasi-pilot
• Communication for customers
• Rollout in August
• Production support
• Follow-up surveys
• Back to application development
47
So?
48
So? - Lessons Learned
1. It’s huge
2. Set realistic timeline
3. Concentrate on communication
4. Involve the campus
49
So? - Lessons Learned
5. Track tasks and dependencies
6. Plan for periodic review
7. Find support
8. Don’t expect nirvana