1. My UW-Madison Enterprise Portal Migration to Open Source Framework Jim Helwig EDUCAUSE Midwest Regional Conference, Chicago March 23, 2005 Copyright @ 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. 1 My UW-Madison Migration Who? Why? How? And? So? ???

3. 2 My UW-Madison Migration Who?Background and history Why?Motivation for change How?Approach And?Current status, future So?Lessons learned ???Questions

4. 3 Who?

5. 4 Who? - The players 41,000+ students 13,000+ Faculty/staff 700+ employees in DoIT

6. 5 Who? - The players My UW-Madison Advisory Group My UW-Madison Service Team Portal Infrastructure Team Development groups

7. 6 Who? - The portal My UW-Madison - MUM Came out of Academic Technology 1999 Concept 2000 Pilot 2001 All students 2002 All faculty/staff

8. 7 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. 8 Who? - The infrastructure Java on Epicentric on WebLogic Server on Solaris 1 database server 2 application servers 2 web servers 1 Layer 4 switch

10. 9 Who? - The applications 100+ modules Application aggregation and integration Student information system Communications Business services Help Desk … and more

11. 10

12. 11

13. 12

14. 13 Why?

15. 14 Why? - Motivation Because we said so Major software upgrade Software maturity

16. 15 Why? - Motivation Desired additional features Licensing Support Higher Ed Community

17. 16 How?

18. 17 How? - Concerns “Mucking about” with core, critical piece of infrastructure Many technical players Many campus players Existing portal Current requirements, future needs

19. 18 How? - Approach Campus requirements gathering Technical requirements Vendor presentations Proofs of concept Planning Implementation Rollout Follow-up analysis

20. 19 How? - Campus Requirements 17+ members Led by DoIT Architecture Current and future stakeholders Several months Intense phase, multiple long sessions each week

21. 20 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. 21 How? - Technical Requirements Mostly DoIT staff Detailed vs. visionary 300+ line items

23. 22 How? - Vendor Presentations Six products One week, four hour blocks Technologists, management, campus requirements team Not a lot of detail, but insightful

24. 23 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. 24 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. 25 How? - Final Selection Both could do the job Epicentric/Vignette upgrade would be more expedient Upgrade had more immediate value But…

27. 26 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. 27 How? - Planning Decision process took eight months Opportunity to research before giving rollout date Recognition of project size Separate planning project

29. 28 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. 29 How? - Factors Academic calendar Resource constraints PeopleSoft upgrade? Planning with very limited knowledge Avoiding a mid-air collision

31. 30 How? - Planning 450+ tasks 15,000-20,000 hours 16 months

32. 31 How? - Implementation

33. 32 How? - Implementation Core planning team morphed into core implementation team Individual leads responsible for particular tasks Tracked via MS Project

34. 33 How? - Communication

35. 34 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. 35 How? - Communication Tech forums as needed Developer’s email list Project home page Wiki Issue tracking system

37. 36 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. 37

39. 38

40. 39

41. 40

42. 41 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. 42 How? - More planning Unexpected tasks More knowledge Staff changes Need periodic review of project plan Avoid too much task detail

44. 43 And?

45. 44 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. 45 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. 46 So?

48. 47 So? - Lessons Learned 1.It’s huge 2.Set realistic timeline 3.Concentrate on communication 4.Involve the campus

49. 48 So? - Lessons Learned 5.Track tasks and dependencies 6.Plan for periodic review 7.Find support 8.Don’t expect nirvana

50. 49 Questions? Jim Helwig University of Wisconsin-Madison jim.helwig@doit.wisc.edu my.wisc.edu