A Community Source Student Information System

1
A Community Source Student Information System?

• Leo Fernig
• Richard Spencer
• eStrategy Advisory Council
• January 12, 2006

2
UBC SIS

• User focused (students, faculty, staff)
• Written in Java
• Web enabled
• Ongoing redevelopment
• Combines in-house and commercial components
• Mainly integrated, some services (CSB)
• Could be made available as open source

3
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

4
What we have learnt from others

• A community source project will require
• Committed leadership
• Committed partners with
• shared goals
• appropriate resources and capabilities
• Specific goals and objectives
• Strong project management
• strict time based development

5
We are not hoping to....

• Save money
• Shorten development or implementation time
• Build a complete open source system
• Make an ideological statement

6
Some concepts for enterprise systems
7
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

8
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
• shared infrastructure components (IDMS, portal)
• loosely coupled services
• use middleware to communicate and execute
  business processes (workflow, rules)
• use standard schemas when they are available

9
Web services

• Start with a simple architecture
• Use person to person contact for trust,
  discovery, and Web service integration
• Begin to implement a true Web services
  architecture using standard protocols
• SOAP, XML, BPEL,WSDL, UDDI, etc.
• Begin sharing services among small groups of
  institutions, hosting them at one institution for
  use at others

10
Key Enterprise Services

• Identity management
• Portal
• Workflow (with rules engine)
• Data warehouse
• Reporting

11
Student System Concepts

• Focus on the end user
• Use enterprise identity management, portal and
  workflow services
• SOA, WS, loosely coupled components
• Use internal rules engines
• 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
  practices)

12
Simplified SIS schema
13
The core infrastructure

• It is now possible to run an extremely large
  transactional
• system entirely on license free software
• OS Linux
• J2EE container JBoss
• HTTP server Apache
• DB MySQL, PostgreSQL
• More important standards
• JDBC standards for database connectivity
• ANSI SQL
• W3C standards for HTML, XML, XSD, SOAP
• J2EE standards for Servlets, JSP, JMS etc

14
The evolution of Open Source
Kuali(2004)
Enterprise solutions
Sakai(2004)
uPortal (2001)
Tools and components
Eclipse (2004)
PostgreSQL (1999)
Apache (1995)
Core Infrastructure
Linux (1991)
1990
1995
2000
2005
15
Business infrastructure layer
A set of common modules

• Used by all vertical applications
• Some built on SOA
• Consistent and rapid development

16
Rules engines

• Business drivers
• Unmediated interactions
• Transperancy
• Empowering vs proscriptive

• Technology solution
• Rules engine technology
• Rules authoring software

17
Vertical applications
Common elements

• Built on a web services model
• Exhibit underlying patterns.
• Use the same infrastructure

18
The Portal

• Services all customers
• Applicants
• Students
• Faculty
• Administrators
• Provisioned according to
• Roles
• Permissions
• Managed in the identity
• management system

19
Architecture issues
Question 1 How sophisticated should the web
service architecture be?
Home grown vs industry standard

• Home grown
• XML-RPC

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

20
Architecture issues
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

21
Different architectural models

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

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

22
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

• 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

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

23
A possible future?
A family of community solutions?
24
Possible next steps

• SOA workshop
• Agreement on a technical architecture
• Finding the right partners
• Agreeing on governance and project management
• Forming a community
• Agreeing on initial priorities
• Beginning to implement the SOA
• Delivering new components and functions