1. 1 A Community Source Student Information System? Leo Fernig Richard Spencer JA-SIG Austin, TX December 6, 2005

2. 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. 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. 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. 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. 6 We are not hoping to....  Save money  Shorten development or implementation time  Build a complete open source system  Make an ideological statement

7. 7 Some concepts for enterprise systems

8. 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. 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. 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. 11 Key Enterprise Services  Identity management  Portal  Workflow (with rules engine)  Data warehouse  Reporting

12. 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. 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. 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. 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. 16 Simplified SIS schema

17. 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. 18 1. IDE Eclipse 2. FrameworksStruts, Spring 3. Test suites JUnit, DBUnit, Castor 4. Code management CVS 5. BuildAnt 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. 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. 20 Rules engines Flexibility Visibility Intelligibility

21. 21 A variety of options Different hybrid solutions Rules Engines

22. 22 Control tables module Code-decode tables Process control tables Business rules repository

23. 23 Search engine 1.A query Generator Execution engine 2.A user interface 3.A relational/object mapping framework

24. 24 Communications framework Dispatching messages: Email Printing Recording interactions: Email Conversations Hard-copy Content creation: Mail-merge XML-XSL

25. 25 Payments framework Aggregates and consolidates various bills: Tuition fees. Rent. Library fines. Processes payments through a single: Credit card service. EFT service.

26. 26 1. Built on a web services model 2. Exhibit underlying patterns. 3. Use the same infrastructure Vertical applications Common elements:

27. 27 Built on a web services model Available through the Portal. Available to authorized 3 rd 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. 28 Registration As a Set of Web Services Identity Services Degree Audit Seat Managment Financial Services Registration Module Who is Joe ? A 4 th 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. 29 Built on a web services model Available through the Portal. Available to any 3 rd 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. 30 Built on a web services model Available through the Portal. Available to authorized 3 rd 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. 31 Built on a web services model Available through the Portal. Available to authorized 3 rd 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. 32 Built on a web services model Available through the Portal. Billing services available to authorized 3 rd parties. Library Housing The underlying patterns Invoicing Use of common infrastructure. Rules engine Fee assessment rules Student financials

33. 33 Services all customers Applicants Students Faculty Administrators Provisioned according to Roles Permissions Managed in the identity management system The Portal

34. 34 Question #1: How sophisticated should the architecture be? Home grown vs industry standard Home grown: XML-RPC Industry standards: SOAPSimple Object Access Protocol (W3C) WSDLWeb Service Definition Language (W3C) BPELBusiness Process Execution Language UDDIUniversal Discovery, Description and Integration (OASIS) Web Services Architecture

35. 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. 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 built on a highly integrated infrastructure Loosely coupled applications with no common infrastructure

37. 37 SIS as a series of loosely coupled applications

38. 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. 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. 40 A family of community solutions? Conclusion