iCampus

Going Live at Illinois State University

Michael Erdely - mjerdely@unicon.net

Arturo Ramirez - aramir@ilstu.edu

Illinois State University

• Founded 1857, first public University in Illinois

• Public, coeducational, and residential

• 160 undergraduate major/minor options in six colleges

• 37 master programs, 2 Specialists, 7 Doctoral

• 850 acre campus is located in central Illinois, the communities of Normal-Bloomington

• Fall 2002 enrollment, approximately 17,500 undergraduates and 2,500 graduates

• http://www.ilstu.edu/

Why go with a Portal

• Educating Illinois strategic action plan – “Building a Technology Friendly Campus”

• Create an alternative personalized view of available services

• Homepage running out of real state space

• Need for virtual one-stop student services

• The purpose of going to a hardware store to buy a drill bit is not to own the bit but to make the hole …

Why go with uPortal

• Open source framework for presenting aggregated content

• Easiest route for adding value to existing systems

• Commercially supportable

• Based on XML/XSL transformations

• The only open source portal developed by and for universities

• Available content

State of affairs of iCampus

• iCampus Demo– What is in iCampus

– What can students see

– What are all the channels

– Why go with some UNICON channels

• Current usage stats (Grades, Elections, Registration)

Login

Home

Redbird

Transactions

Schedule

Schedule/Map

Text Books

Grades

GPA2

Financial Aid

Financial Aid

Financial Aid

Financial Aid

Email

Registration

Registration

Registration

Registration

Registration

Registration

Registration2

Campus Life

People Search

Voting

Matrix Skin

State of Affairs - Statistics

• Logins

– At peak times between 700-1200 users login every hour

• Voting

– 4000 student surveys completed (36 hrs span)

• Grades

– 7000+ users checked their grades through the portal within 48 hrs of being posted

• Registration (Sessions w/ 200 users aprox.)

– 3,120 hits in one hour – almost 1 per second

How did things work before iCampus

• Student Information Access System (SIAS)– Mainframe sessions: fast and reliable

• Cumbersome interface

• Accessible through TN 3270 emulator screens

• Messages / errors had to be brief – Information restricted to 80 chars per line

• Services that just weren’t available before– Redbird card, GPA Calculator, Financial aid awards accept/decline

system

SIAS Terminal - Login

SIAS Terminal - Menu

SIAS Terminal - Registration Menu

SIAS Terminal - Registration

SIAS Terminal - Schedule

SIAS Terminal - Course Directory

SIAS Terminal - Postal Address

State of Affairs - Campus Services

• Campus Services

– Well organized but at times nowhere to be found

– Departments changing links to their own pages

– In general, did not provide custom information

– Needed individualized attention

– High dependency on individual department’s own resources

State of Affairs - Web

Risks

• uPortal was in beta version at the time that iCampus work started

• Technology curve was steep

• Not enough buy in from the entire campus

• How can we import legacy data

• What if project failed

• Do we want real time data presented to the students

• Campus services are more visible so if something goes down people will notice

Engaging different departments

• How do you get other departments to buy into this idea– Proving iCampus Portal reliability and success (Elections)

– Saving them money (Eliminating mass mailings)

– Less headaches for staff

– Portal can get data across to the students in real time

• Initial reaction against a consolidated portal – It’s my data! Mine, mine, mine!!!

– It’s my hardware, my servers, my network!!!

Planning - History

• Planning phase - (Spring ‘00 – Spring ‘01)– Committees work: Have a good plan before coding (users first,

tech issues later)

• Prototype phase – (Fall ‘01)– Focus on a small population and do extensive testing– Initial development and first online test

• Going Live – (Summer ‘02)– 3000+ new freshman used for Preview program– More features than conservative planning proposed

• Today – (Summer ‘03)– All 20K+ students, faculty and staff have access

Planning - Committees

• Executive Development Group

• Oversight Planning Committee

• Development Team (16 campus staff)

• Content Committee

• E-commerce Committee

• Digital Imaging Committee

• Student Portfolio Planning Group(s)

• Faculty Staff Portal content

• LDAP Committee• ECAT

Planning - Groups

• AIS (data and data delivery)

• CISS (infrastructure)

• IWSS (front end and features)

• Registrar/admissions (SIAS one-stop)

• Campus community (content committee & focus groups)

Outside consulting• IBS Interactive Business Solutions/UNICON (uPortal

consulting and programming)

Planning - Channels

• How to come up with channels

– Content Committee analyzed campus needs

– Comes up with Initial list of 42 channels

– List reduced to 15 possible roll out channels

– Channel approvals go through Portal Content Committee before developers get anything going

Planning - Consulting Services

• Why UNICON

• Invaluable Experience – Wrote the initial uPortal prototype

– Heavily involved in uPortal management and development

– J2EE solutions for higher ed. since 1997

– uPortal Applications & Content

– uPortal Professional Services

– uPortal Training

Planning - People

• How many employees to go with– Relative to budget, campus commitment

• Training– uPortal training for portal developers and outside departments

– Common technologies (i.e. XML) training among developers from diverse fields Web, Mainframe, etc

• Focus groups– Basic load test

Planning - Money

200kConsultingMentoringTraining

100kHardware

80kReassignedStaff

80kNewPositions

50kMisc.

Budget: 500K

Marketing iCampus

• Focus groups – Users helping to identify what works and what doesn’t

• Preview program sessions– Great testing opportunities

• Home page visible link– Portal does not replace Home page– They complement each other

• Importance of graphic design – Make portal pages appealing to student population

Legacy System Integration

• Business logic – mainframe programs

• EAGLE – University of Florida– Enhanced Application Generation Language for the Enterprise

– Enables Internet access to mainframe databases and CICS resources

• Pros / cons

– Lack of experience using EAGLE

– Plenty experience using CICS (Cobol) queries that incorporate business logic

Business Logic

• A web developer’s dream• Keep business logic out of the iCampus portal!• Get XML from the outside all the time, anytime!

• Input : Simple form

• Output : XML <SCHEDULE_COURSE>  <COURSE_DEPARTMENT_NBR>412</COURSE_DEPARTMENT_NBR>   <COURSE_DEPARTMENT_ABBR>BSC</COURSE_DEPARTMENT_ABBR>   <COURSE_DEPARTMENT_NAME>Biological Sciences</COURSE_DEPARTMENT_NAME>   <COURSE_NUMBER>101</COURSE_NUMBER>   <COURSE_SECTION>014</COURSE_SECTION>   <COURSE_REFERENCE_NBR>220121</COURSE_REFERENCE_NBR>     <COURSE_LONG_TITLE>Fundamental Concepts In Biology</COURSE_LONG_TITLE>  

Channel Implementation

• In the beginning– Started off by gathering data from different sources (static channels)– Later, applications read and write to the mainframe (interactive)– Minimal documentation

• How are we building new channels– Trying to incorporate system requirements and documentation– More intensive testing and realistic time frames

• What has changed between now and then– iCampus is well known– Groups and departments want their content (own channel) in the portal– Anything goes wrong, you will know right away, everyone will

notice!

Development Lifecycle

• Phase 1 -Identify possible content, target user groups and data sources for the channel

• Phase 2 -Decide what is the best method to bring content into iCampus (XML being the preferred way)

• Phase 3 -Review simple requirements specification (Managers/Developers)

• Phase 4 -Create an initial XML document with basic content for the channel

• Phase 5 –Test channel in developer’s box and refine XML according to customer needs – Use CVS system!

• Phase 6 –Move channel to Q&A so customer and others can review it and make comments (test using focus groups)

• Phase 7 Load test in Q&A

• Phase 8 Roll out to production servers

Roll out strategies

• Initial– Good stickies (need really useful things)

– Small roll out size

• Current– Require access but have backups ready

– Expand target audience

– Advertise

• Future– Staff and faculty content

– Expanded documentation

Hardware

Load Balancer/SSL EncryptionEngine

Database

Other BackendSystems

Apache/Tomcat/mod_jk/uPortal

Lessons Learned

• Documentation is important – Developers think they can live without it

• Collaboration works– Communication among groups (JA-SIG, Universities, UNICON,

students) is crucial to identify problems and possible points of failure

• Keep code separated (independent) from uPortal framework– Prevention mechanism so you won’t be out of the loop when new

uPortal features are incorporated

• Users feedback is very important (icampus@ilstu.edu) – If you answer the questions and attend their requests they’ll keep

coming

Lessons Learned

• A portal may enforce extra effort for data keepers– Info available 24/7

• People should do what they know – Owners of content are responsible for their content not display

– Developers are not responsible for display

– Designers are not responsible for code

• iCampus becomes center of attention – Thinking about becoming involved with the portal?

• You will get blamed for everything (even when external data sources go down or not available)

Questions

?

Thank You

Michael Erdely

mjerdely@unicon.net

Arturo Ramirez

aramir@ilstu.edu