1

A Community Source Student Information

System?

Leo Fernig

Richard SpencerJA-SIG

Austin, TX

December 6, 2005

2

The University of British Columbia

Medical/doctoral research university

Campuses in Vancouver and Kelowna, BC, Canada

47,000 students– many on-line services, 100% web

registration 3000 faculty and research staff

9000 other staff

80% growth in research grants over last 5 years

3

UBC SIS

Written in Java

Web enabled

Ongoing redevelopment

Combines in-house and commercial components

Mainly integrated, some services

Could be made available as open source

4

Community Source Objectives

Leverage the capabilities of our developers– Increase our ability to meet the needs of users

Greater control over the future of our systems

Systems that meet more of our needs

Easier to combine open source and commercial components

Use commercial service providers to implement and support some systems and system components

5

What we have learnt from others

A community source project will require:

Committed leadership

Committed partners with shared goals

Specific goals and objectives

Strong project management

– strict time based development Partners with appropriate resources and

capabilities

6

We are not hoping to....

Save money

Shorten development or implementation time

Build a complete open source system

Make an ideological statement

7

Some concepts for enterprise systems

8

Goals for enterprise systems

Deliver scalable, self-service processes

Focus on needs of end users (not just staff in central departments)

Retain departmental stewardship of systems– HR, Finance, Admissions, Registrars, etc.

An architecture that– allows individuals to have a single on-line identity– identifies individuals in all systems and processes– supports complete business processes– allows business processes to easily span systems

9

Service Oriented Architecture

Service

A software component that:– carries out a specific part of a business process

e.g. a credit card authorization.

– has a well defined, platform independent interface– is reusable

Service Oriented Architecture– loosely coupled services – services use middleware to communicate and

execute business processes– use standard schemas when they are available

10

Web services

Begin with a simple architecture

Use person to person contact for trust and discovery, as well as Web service automation

Begin to implement a true Web services architecture using– SOAP, WSDL, UDDI, etc.

Begin sharing services among small groups of institutions, hosting them at one institution for use at others

11

Key Enterprise Services

Identity management

Portal

Workflow (with rules engine)

Data warehouse

Reporting

12

Identity management Meta directory of basic identity information References to other repositories Authentication and authorization

– for users and applications

Role and group management– role based access to systems and services– decentralized administration of roles and groups

Represent organizational structures– academic and administrative

Federation

13

Portal Provide access to all enterprise systems

Customize with links to systems for each user

Manage logon to and logoff from systems

Channels can display customized information

Primary means of presenting information to users– Authentication and links to systems and services

allows presentation of personal, time sensitive information

14

Workflow

Available to all applications Uses roles and organizational structure from

identity management system Applies rules to processes Handles cross system and cross silo processes Does not require any personal intervention

Data warehouse Store summary and longitudinal data

Reporting

15

Student System Concepts Focus on the end user

Use the enterprise identity management, portal and workflow services

SOA, loosely coupled components

Use internal rules engines

Provide maximum configuration flexibility– aim: could system handle any variation we can

think of? (i.e. accommodate “our” practices)– not: which subset of the various approaches will

be supported (i.e. not just support “best” practice)

16

Simplified SIS schema

17

The core software stack

It is now possible to implement an entire core software stack out of open source components:

• OS Linux• J2EE container JBoss• HTTP server Apache• DB MySQL, PostgreSQL

Equally, if not more important: standards• JDBC standards for database connectivity• ANSI SQL • W3C standards for HTML, XML, XSD, SOAP• J2EE standards for Servlets, JSP, JMS etc

18

1. IDE Eclipse2. Frameworks Struts, Spring 3. Test suites JUnit, DBUnit, Castor4. Code management CVS5. Build Ant

Likewise, one can build with an entirely open source suite:

Again, the only caveat associated with propriety software in this context is the danger of embedding extensions that are not supported by the Java community process

Development tools

19

Business infrastructure layer

Abstract business engines.• Rules engines.• Search engines.• Control tables.

Back-end business services.• Communications framework (sending and tracking):

• Email• Hard copy• Phone

• Payments

20

Rules engines• Flexibility

• Visibility

• Intelligibility

21

2121

• A variety of options

• Different hybrid solutions

Rules Engines

22

Control tables module

• Code-decode tables

• Process control tables

• Business rules repository

23

Search engine1. A query

• Generator• Execution engine

2. A user interface

3. A relational/object mapping framework

24

Communications framework

• Dispatching messages:• Email• Printing

• Recording interactions:• Email • Conversations• Hard-copy

• Content creation:• Mail-merge• XML-XSL

25

Payments framework

Aggregates and consolidates various bills:• Tuition fees.• Rent.• Library fines.

Processes payments through a single:• Credit card service.• EFT service.

26

1. Built on a web services model

2. Exhibit underlying patterns.

3. Use the same infrastructure

Vertical applications

Common elements:

27

• Built on a web services model• Available through the Portal.• Available to authorized 3rd parties.

• The underlying patterns• A travel reservation system.

• Use of common infrastructure.• Rules engine implementations

• Prerequisite checking• Course restrictions• Degree requirements• Fee calculations

• Search engine• Finding available courses

• Communications framework• Confirmation of registration

Registration

28

Registration As a Set of Web Services

Identity Services

Degree Audit

SeatManagment

FinancialServices

RegistrationModule

Who is Joe ?

A 4th year BSC student

What does he need to complete his degree ?

9 credits of electives, CHEM 431, CHEM 456

Are there any sections available (preferably not Friday)

CHEM 431 Lecture Mon 10-11, Lab Tues 10-11

Yes, register in these sections

How much does it cost?

29

• Built on a web services model• Available through the Portal.• Available to any 3rd party.

• The underlying patterns• An identity management system.• A portfolio• A CRM

• Use of common infrastructure.• Rules engines:

• Admissions requirements.• English language requirements

• Communications framework• Confirmation of application.• Confirmation of admission

Recruitment/Admissions

30

• Built on a web services model• Available through the Portal.• Available to authorized 3rd parties.

• Faculties• Senate committees

• The underlying patterns• Workflow system.• Catalogue creation/maintenance

• Use of common infrastructure.• Rules authoring engines:

• Prerequisite rules• Degree requirements

• Search engine• Finding available courses

Curriculum development

31

• Built on a web services model• Available through the Portal.• Available to authorized 3rd parties.

• Centralized scheduling department• Faculties• Departments

• The underlying patterns

• Resource optimization

• Use of common infrastructure.• Search engine

• Finding resources• Instructors• Rooms• Equipment

• Rules engine• Usage constraint rules

Scheduling

32

• Built on a web services model• Available through the Portal.• Billing services available to authorized 3rd parties.

• Library• Housing

• The underlying patterns• Invoicing

• Use of common infrastructure.• Rules engine

• Fee assessment rules

Student financials

33

• Services all customers• Applicants• Students• Faculty• Administrators

• Provisioned according to• Roles• Permissions

Managed in the identity management system

The Portal

34

Question #1: How sophisticated should the architecture be?

Home grown vs industry standard

• Home grown: • XML-RPC

• Industry standards:• SOAP Simple Object Access Protocol (W3C)• WSDLWeb Service Definition Language (W3C)• BPEL Business Process Execution Language• UDDI Universal Discovery, Description and Integration (OASIS)

Web Services Architecture

35

Question #2: Should there be a universal dictionary of schemas?

• Within the SIS business domain there is a set of common objects:• Persons• Addresses• Courses• Awards• Transcripts• Etc etc etc

• Probably best to proceed in a piecemeal and empirical fashion• Take existing standards where they exist (eg EDI).• Only develop schemas on an “as-needed” basis

Web Services Architecture

36

Alternative models

• There are various architectural models that can be laid out along a continuum

• There is a close relationship between the architectural model and the governance, project management and economic structures of a community source project

Highly coupled applications builton a highly integratedinfrastructure

Loosely coupled applicationswith no common infrastructure

37

SIS as a series of loosely coupled applications

38

Implications of different models

Integrated infrastructure • More disciplined project management style• Greater economy through re-usability • Lower maintenance costs

Loosely coupled applications • Simpler project management • Coordination limited to protocols • Potentially higher costs • Higher maintenance costs

39

Different approaches to development

One approach to an creating an SIS with an integrated infrastructure• Take an existing SIS • Gradually rework the components • Each version gets closer to the blueprint

Loosely coupled applications • Take one vertical as “proof of concept”• Run it as a stand alone application• Start building the other verticals

Another approach to an creating an SIS with an integrated infrastructure• Take the core infrastructure of an existing SIS • Rework the infrastructure • Build one vertical as a proof of concept• Schedule the creation of the remaining verticals

40

A family of community solutions?

Conclusion