… the next generation student system is coming!

Kuali Days V

November 14, 2007

Agenda

• Why now?• The vision

• Functional design and scope

• Technical architecture

• Development approach• Community source

• Where we are and where we’re going

Why Now?

• Many student systems don’t 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

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.

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.

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.

Functional design: Elements

• High level entities– person; time; learning units

• Concierge• Rules engines• Work flow• Modular, configurable system• Managed access to information• Internationalization

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

Concierge

InstitutionalInformation

Requirements

PersonalInformation

Goals

Information aboutthe experiences

of others

Possibilities

We should use:

to support users

Concierge sits lookingand listening for changespersons state, institution

rules, peoples experiences, etc.

Concierge “sees”student complete

registration

Conciergerequirement to pay feestriggered by completingregistration

Concierge checksstudent info, rules &

financial aid opportunities and guides student

through process

process ends when fees are paid

Rules engine

Workflow

Uses

Information

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

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

– Learning Management System

– Student Portfolio – Financial (FMIS) system– Campus Calendar– Facilities Management– Library– Parking

Functional Scope and Timeline

Technical architecture:Guiding 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

Technical Architecture

Developers Workbench

Configuration Application

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

Technical StreamFunctional Stream

Jul 2007

Sep 2008

Oct 2008

Apr 2009Jun 2009July 2009

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

Technical Architecture-Technology proofs-SOA standards

Service Modeling R1(Infrastructure & Curriculum Development)

Development Infrastructure- Developers workbench - Procedures- Standards

Contract Design R1(Infrastructure & Curriculum

Development)

Service Modeling R2(Domain 2) Software Design &

Development R1(Infrastructure & Domain 1)

Adjust plans and repeat forReleases 2/3/4

Pro

gram

Man

agem

ent

& C

omm

unic

atio

ns

Contract Design R2(Domain 2) Release 1 & Implement Test

Re-plan / Re-Architect / Implement & Transition to Support

Develop Configuration Application- Configuration Infrastructure-Proof of concept Pilot

Phased Modular Approach

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• 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

Founder & Partners

Partners• Massachusetts Institute of Technology• Carnegie Mellon University

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

Other Partners

Supported by:• AACRAO• NITLE

The Andrew W. Mellon Foundation

An Opportunity to Contribute

• Align with the vision• Membership in the Kuali

Foundation• Contribute funds toward the

development of Kuali Student• Express an interest in

implementing one or more modules

• Abide by the provisions of the Educational Community License

• Act as an advocate for the Program

Benefits of Contributing

• Able to provide specific input on product directions, needs and expectations

• Access to project documentation and artifacts as they are developed

• May participate in Beta testing and may have early access to software for testing and implementation

• May contribute to bug fixes and enhancements to ensure the quality of the end product

• May contribute implementation experiences and materials back to the community body of knowledge

• May provide input to the development of support processes and product release strategies.

Other Opportunities

• Founders

• Partners

• Contributors

• Adopters– commitment to adopt some modules

• Supporters– display the bumper sticker

• 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

Risks

1. Legal agreements between Founders

2. Partnership with Kuali Foundation

3. Project charter approved

4. $2.5 M Mellon grant awarded

5. Project launch workshop July 30, 2007

6. Application Architecture – in progress

7. Contributors program being finalized

Where are we today?

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.

Information

www.kuali.org/communities/ks/