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

50

Questions?

Jim HelwigUniversity of Wisconsin-Madison

jim.helwig@doit.wisc.edu

my.wisc.edu