a next generation student system

1
a next generation student system
University of California Enrollment Services
Technology Conference October 16, 2007 Richard
Spencer, University of British Columbia
2
Agenda

• Why now?
• The vision
• Functional design and scope
• Technical architecture
• Development approach
• Community source
• Where we are and where were going

3
Why Now?

• Many student systems dont meet current needs
• Vendor solutions may not be the answer
• Development of in-house systems is challenging
• Increasingly complex technology requires
  specialist resources
• Competing for scarce IT resources in a
  constrained market
• User requirements and expectations increasing
  rapidly
• Budgets and funding are constrained
• Collaboration and open source systems development
  works
• We can build systems that do more for users

4
Vision Functional Objectives

• Support end users by anticipating their needs and
  simplifying (or eliminating) administrative
  tasks.
• Support a wide range of learners and learning
  activities .
• Support a wide range of business processes,
  including those that cross department and system
  boundaries.
• Make it easier to change business processes to
  meet institution needs and allow process
  improvement, using rules and workflow,
  configurable systems, and flexible data models.
• Reduce time staff spend on routine tasks, so they
  can do more to directly support students and
  faculty.

5
Vision Technical Objectives

• Develop a next generation architecture based on
  Service-orientation, implemented using Web
  Services.
• Publish service contract specifications. This
  will allow a large community work on the system.
• Produce a software product based on a set of
  services.
• Define and publish standards for development that
  can be used by others to develop services that
  are outside the scope of the core product.

6
Vision Sustainability

• Ensure the core services of Kuali Student are
  successfully implemented by the Founding
  Institutions.
• Promote the adoption and implementation of Kuali
  Student by a wide variety of educational
  institutions in North America and
  internationally.
• Build a community of interest that will sustain
  future maintenance, enhancement and development.
• Define product development and support processes
  that will help the community implement the
  software and provide operational support.
• Facilitate participation by vendors and service
  providers
• Evolve the technology and architecture of Kuali
  Student to keep up with new standards, tool
  releases and trends.

7
Functional design Elements

• High level entities
• person time learning units
• Concierge
• Rules engines
• Work flow
• Modular, configurable system
• Managed access to information
• Internationalization

8
Learning units

• course single lecture in a course 15 minute
  student presentation in a course
• participation in community service
• any activity that the student wants to include on
  a formal or co-curricular transcript
• a learning unit number is like a SKU...
• we can also have
• learning results
• learning plans
• learning resources

9
Concierge
We should use
Institutional Information
Personal Information
Information about the experiences of others
Requirements
Goals
Possibilities
to support users
10
Concierge
requirement to pay fees triggered by
completing registration
Concierge sits looking and listening for
changes persons state, institution rules, peoples
experiences, etc.
Concierge sees student complete registration
Concierge checks student info, rules financial
aid opportunities and guides student through
process
Uses
Information
Rules engine
process ends when fees are paid
Workflow
11
Functional Scope

• Tier 1 Functionality
• Curriculum Development
• Customer contact
• Configuration application
• Enrolment
• Degree Audit and Academic Evaluation
• Student Financials
• Concierge limited
• Application connectors

• Tier 2 Functionality
• Admissions
• Scheduling
• Awards and Financial Aid
• Concierge

12
Out of Scope Functionality

• Tier 3 Out of scope for Founders
• Recruitment
• Event Management
• Housing
• Athletics
• Alumni
• Family Financial Planning
• Elections
• Student Life

• Out of Scope
• Campus Calendar
• Student Portfolio
• Learning Management System
• Financial (FMIS) system
• Facilities Management
• Library
• Parking

13
Functional Scope
14
Technical architectureGuiding principles

• Service Oriented Architecture
• SOA methodology
• Web services
• Standards based (WS and industry standards)
• Separate governance process for service contracts
• Component Abstraction
• Abstraction of business processes and business
  rules
• Abstraction of presentation layer via a portal
• Abstraction of the data layer
• Leverage Open Source Technology
• Use an open source software stack
• Infrastructure built from open source products
• Java as the language of choice

15
Technical architectureBuilding the SOA stack
16
Development Approach

• Development project structure
• 5 year project starting July 2007
• Well defined phases of approximately 4-6 months
  each
• Clear definition of deliverables at each stage
• Each phase delivers a tangible asset
• QA reviews and checkpoints at the end of each
  phase
• Sign off of phase deliverables as complete
• Review plans for the next phase at the end of
  each phase
• Separate implementation projects at each
  institution
• Kuali Student does NOT include implementation
• Product is configured for institution by a
  separate team
• dictionary search rules BPEL authorization
• Agility, phases, time boxing, reusability and
  iterations

17
Development Approach
Technical Stream
Functional Stream
Jul 2007 Sep 2008 Oct 2008 Apr
2009 Jun 2009 July 2009

• Application Architecture
• - Process models
• ER models
• High Level Service Models
• Domain Definitions

• Technical Architecture
• Technology proofs
• SOA standards

Service Modeling R1 (Infrastructure Domain 1)

• Development Infrastructure
• Developers workbench
• Procedures
• Standards

Contract Design R1 (Infrastructure Domain 1)

• Develop Configuration
• Application
• Configuration Infrastructure
• Proof of concept Pilot

Program Management Communications
Service Modeling R2 (Domain 2)
Software Design Development R1 (Infrastructure
Domain 1)
Adjust plans and repeat for Releases 2/3/4
Contract Design R2 (Domain 2)
Release 1 Implement Test
Re-plan / Re-Architect / Implement Transition
to Support
18
Why Community Source?

• Benefits
• Shared resources means more efficient development
• Institutions share ideas and create innovative
  solutions, leveraging their user experiences
• Contributing institutions have direct input into
  functions and features
• Bring wide range of processes and requirements
• Sustainability a community that contributes to
  enhancements can ensure sustained development
• Support commercial partners for implementation
  and support are encouraged
• Kuali Student will
• Build a community of interest
• Establish procedures and standards for
  development
• Encourage commercial affiliates
• Share implementation experiences

19
Founder Partners

• Founders
• University of British Columbia
• University of California, Berkeley
• University of Maryland, College Park
• Florida State University
• San Joaquin Delta College

• Partners
• Massachusetts Institute of Technology
• Carnegie Mellon University

20
Founder and Partner Requirements

• Founder
• Align with the vision
• 1 million / year for 5 years in staff or cash
  resources
• 2 senior reps on the Board
• Representation on the Technical and Functional
  Steering Committees
• Commit to implement most modules
• Adhere to the governance of the Project Charter
• Active advocate to the community

• Partner
• Align with the vision
• Allocate resources to the project (typically 2 or
  3 staff)
• Not represented on the Board
• May have a representative on the Technical and/or
  Functional Steering Committee
• May commit to implement one or more modules
• Adhere to the governance of the Project Charter
• Active advocate to the community

21
Other Partners

The Andrew W. Mellon Foundation


22
Other Opportunities

• Founders
• Partners
• Contributors
• membership in Kuali Foundation
• Adopters
• commitment to adopt some modules
• Supporters
• display the bumper sticker

23
Risks

• Technology
• Business Analysis (SOA)
• Lack of Appropriate Skills
• Failure of the Partnership
• Size, Scope, and Complexity
• SOA Approach
• Standards Compliance
• SME Staff Availability
• Budget / Cost Estimates
• Funding
• Departure of Key Members (Board, Steering, other)
• Working with a distributed team
• Change management challenges

24
Where are we today?

• Legal agreements between founders
• Partnership with Kuali Foundation
• Project charter approved
• Project launch workshop in Vancouver July 30
• 2.5 M Mellon grant awarded
• Contributors program being finalized

25
Where are we going

• Kuali Student will
• Support users by anticipating their needs and
  saving them time.
• Support a wide range of learners and learning
  activities in a wide range of institutions by
  using a flexible, configurable, data model.
• Support a wide range of business processes, in
  different institutions, using a configuration
  application.
• Make it easy to change processes, using rules and
  workflow.
• Use a Service Oriented Architecture, implemented
  using Web Services.
• Achieve sustainability through community source
  development and wide spread adoption.

26
Information

• www.kuali.org