open source - the next wave a next generation student services system richard spencer pesc 3 rd...

Open Source - The Next Wave A next generation student services system

Richard Spencer

PESC 3rd Annual Conferenceon

Technology and StandardsWashington DC, May 2, 2006

2

A next generation student services system

A university’s mission:• learning and development

• scholarship and discovery of knowledge

• transmission of knowledge

• community engagement

the intellectual activity of faculty and studentsis the means of production

faculty and students are our key customers

we need more heads or more time to increase productivity

3


Faculty and students need:• more time

– fewer administrative tasks

– less time spent on remaining tasks

• better service– no more line ups!

• more support– access to useful, helpful, information

– knowing which rules apply and how they apply

• improved morale– processes that “just work”

...we should be trying to increase productivity...

4


The Expedia model• Where do you want to go• When do you want to go there• You can choose:

– the airline– the class

• You can sort the results by– price– departure or arrival time

• and there’s more.....– one way, return, multiple legs?– seniors or children, other special fares?– is there anything else we can help you with?

5


How we often deal with our customers• Give me your personal information first

– including your name, gender, date of birth...

• Here is our list of 80 programs• Choose one or two you think might fit• Pay us• We will let you know if we can admit you .....but it will take us a few weeks to figure this

out• We will give you a registration time• Then you can search for the courses you need.. ....good luck!

6


Letting studentsadmit themselves

7


Self admission• If there are specific admission requirements:

– e.g.: required courses, grades or gpas

• Students choose a program & enter their own courses and grades

• A rules engine determines if they are admissible– they get a full explanation of:

• what credentials were used, what was missing• how the admission gpa was calculated• why they did or didn’t qualify for admission

• They can admit themselves..– and print their admission letter in real time

8


Reflecting on self-admission• Students:

– do the grade submission work– get an immediate answer– can see the rules and how they have been applied

• The process allows:– a student to try multiple “what if” scenarios– counselors to advise students on program requirements

• The rules engine could allow the student to:– select a program, and see what is required to enter it– enter what they have, and see what they are eligible for

• Staff can concentrate on value added work

• The process is scalable!

9


Applicantlogin

Identityservice

Evaluate applic’t/offer choices

Program/aidinformation

Informationcollection

Prior inst.information

Applic’t bio& other info

Choice not availableApplicantregisters

Outcome

Choice available

10


Some concepts for enterprise systems

11


The evolution of enterprise systemsFirst generation (e.g.: student record systems)• store data, print reports

Second generation (e.g.: student information systems)

• run the processes in central departments

Next generation (e.g.: student services systems)• support the end user (students & faculty)

• support cross-department business processes

• use rules engines (decision services)

• make it easy to implement “our” processes– not forced to use someone else’s “best practices”

12


Goals for enterprise systems• Scalable, rule based, self-service processes• Focus on needs of end users (not just staff in

central departments)• Retain departmental stewardship of systems

– HR, Finance, Housing, Admissions, Registrars, etc.

• An architecture that:– supports different academic and business processes– supports complete business processes– allows business processes to easily span systems– allows incremental, modular upgrades– allows use of components from multiple sources

13


Service Oriented Architecture

14


SOA goals• break business processes down into:

– process or control logic– business logic– application functions

• use standard data models and schemas• build reusable “services” to provide the

business logic and application functions• use rules engines for the internal logic• use workflow for the process logic • loosely couple components • agility - make process change easier!

15


Open and CommunitySource

16


The evolution of Open Source

CoreInfrastructure

Tools andcomponents

Enterprisesolutions

Linux (1991)

1990

Apache (1995)

1995 2000 2005

PostgreSQL (1999)

Eclipse (2004)

uPortal (2001)

Sakai(2004)

Kuali(2004)

Moodle(2001)

jBoss (1999)

SSS (2006) ???

17


Open vs. community source

Open source• Open membership• Large developer

community• Individuals may decide

priorities & projects• Local development can

lead to different versions• Source code is open for

review and change• Corporate contributions

welcome

Community source• Membership in a community• Smaller development

community• Priorities established by

community • Locally developed components

are compatible• Source code may be included

in commercial products• Institutional and corporate

contributions welcome

18


Community source objectives

• Productivity– more developers working on project

• Reliability– more eyes looking for bugs

• Innovation– institutions are free to innovate and share

• Direction– partners can have input into Community projects

• Evolution– Community can ensure sustained development

19


Community source possibilities• Developing modules at different schools• Combining open source and commercial

components• Using commercial service providers to

implement and support systems and system components

• Community source examples:– uPortal - enterprise portal– Sakai - course management– Kuali - financial system– OSP - portfolio

20


Community source challenges

• Maintaining and managing the community

• Agreeing on standards

• Agreeing on priorities

• Project design and management

• Integrating components with existing systems

• Combining components from different schools

• Ensuring support

• A reasonble life cycle

21


Imagining a next generationstudent services system

22


A next generation student system• Community source development

• Focus on end users, and what they want to do

• Use:– Workflow

– Internal rules engines (decision services)

– SOA, web services, and enterprise services

• Make it easy to redesign business processes– Processes can cross unit boundaries

• Extend functionality into new areas

• Scalable, rule based, self-service processes

• Personal help when it’s needed

23


Thank you

open source - the next wave a next generation student services system richard spencer pesc 3 rd...

Documents