1. … the next generation student system is coming!
Cath Fairlie
Kuali Student Program Director
Kuali Days VI
May 13, 2007
Introductions.
I’m __________________________________ .
Ask questions about audience. Who from IT, who from Registrars office?

2. Kuali Student is... a modular, open source, standards-based next generation student system being developed through a community source process over a 5 year period, that will be delivered through a service-oriented architecture and web services,
The objective of this overview presentation is to give you a very broad understanding of what Kuali Student is, the project that is underway to develop it, and how the higher education community is joining together to create it

3. Agenda Why now? The vision Functional design and scope
Technical architecture
Development approach
Where we are and where we’re going
Community source
Opportunities to contribute to Kuali Student
I’ve got about 30 minutes of slides to present, which will leave us lots of time for questions at the end.
OR Ask the audience to interrupt and ask questions as we go. (This presentation takes about 60 minutes if questions interspersed. )
These are the topics I will cover….
I’ll focus quite a bit of time on the Functional Design as this what truly makes our system a “next generation student system”

4. Registration University of Alabama 1973
Mellon RIT Retreat
Why Now?
Registration University of Alabama 1973
Kuali Student Status Report

5. Why Now? Registration Today:
Sathyabama University, July 2005 – 2km queue for registration

6. Why Now?
Transcripts in 1983

7. Why Now? Transcripts in 2002 Mellon RIT Retreat - 2008
Focus on sameness of process, and systems that map to old style manual processes
Kuali Student Status Report

8. Why Now? Many student systems don’t meet current needs
Vendor solutions may not be the answer
Development of in-house systems is challenging
Collaboration and open source systems development works
We can build systems that do more for users
I’ll start with a little bit of background on Kuali Student. Why are we doing this now?
When we look at today’s students, they are always on, always connected. And their expectations for how they interact with the university is the same. The student system is often the first interaction they have with the university and they expect it to be a positive experience.
At the institution, the way we are setting programs for these students is changing. The 4 year undergraduate degree, offered by one institution is no longer the only option. There are joint degrees granted from multiple institutions, on-line degrees, we even have students defining their own courses. Our current systems cannot meet these changing requirements.
When we look at vendor solutions, many institutions find the are too expensive for their budgets, or do not provide the functionality that their custom solutions do today.
At the same time, our ability to continue to develop in-house systems is declining
Increasingly complex technology requires specialist resources
Competing for the same IT resources in a constrained market
User requirements and expectations are going up
Budgets and funding are going down
As we look around us, we’ve seen that open source, collaborative systems development can work. With JA-SIG (uPortal), Sakai, Kuali Financials there is a track record of success.
When we look at all of these factors, we feel that now is the right time to develop an open source student system: Kuali Student.

9. Vision: Functional Objectives
Support end users by anticipating their needs
Wide range of learners and learning activities.
Wide range of business processes
Easier to change business processes.
Reduce time staff spend on routine tasks
So what is our vision for Kuali Student? First I’m going to talk about the Functional Vision, because this is what truly makes us “next generation”.
Support end users by anticipating their needs and simplifying (or eliminating) administrative tasks.
First of all, it is PERSON CENTRIC (student, faculty, staff) – organized around their needs, not admin needs.
We also want to support as wide a range of learners and learning activities as possible. Not just the 4 year degree program, but Continuing Ed, Graduate Studies, International curriculums, etc.
Support a wide range of business processes, including those that cross department and system boundaries.
….Crossing departmental silos….. …. Supporting multi-institutional degrees…..
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.

10. Vision: Sustainability
Successfully implemented by the Founding Institutions.
Promote the adoption and implementation of Kuali Student
Build a community of interest to sustain development
Define product development and support
Facilitate participation by vendors and service providers
Evolve the technology and architecture
We also have a vision for Sustainability. Its not enough to build the software, we also need to ensure its long term sustainability.
We’re going to do this by…
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
…Kuali Commercial Affiliates program…..

11. Vision: Technical Objectives
Develop an architecture based on Service-orientation, implemented using Web Services.
Publish service contract specifications
Produce a software product based on a set of services.
Define and publish standards for development
There are 4 key technical objectives:
Develop a next generation architecture based on Service-orientation, implemented using Web Services.
Publish service contract specifications.
This is a very important deliverable since it will allow others in the community to extend the functionality of Kuali Student beyond the core software by working to the service contract definitions.
Of course, there will be software developed. KS will 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.

12. Functional design: Elements
High level entities
learning units, person identity, time
Concierge
use what we know to help people achieve their goals
Rules engines, work flow
rules and logic are not in the code
Modular, configurable system
your processes, not someone else’s “best practices”
Managed access to information
people can see what they should be able to see
Internationalization
language, characters, currencies, systems
There are 6 key functional design elements that are fundamental to achieving our vision for Kuali Student.
The first two: high level ABSTRACT data entities and the Concierge application are extremely important to the vision. I’ll talk about these in more detail.
The next 3 concepts are about flexibility:
Rules engines allow us to abstract the business logic from the programs, making it easier to change as the business changes.
Work Flow allows us to abstract the processes, change the process flows as the business changes.
Web Services allow us to have a modular design, that can configured at implementation time to meet our needs
Other important design elements are managed access to information – exposing the data through services for reporting purposes
And, Internationalization – multi-currency and multi-language

13. Entity: Learning units
A learning unit can represent:
a course; a single lecture in a course; a 15 minute student presentation in a course
participation in community service
a year of study
a degree program
any non-credit, continuing studies, or other activity
A “learning unit number” is like a SKU...
We can also have:
learning results
learning plans
learning resources
So, what is a learning unit?
This is an abstract concept that some can appreciate immediately, but others need to think about it for a while.
A learning unit may be…
We can also combine learning units to make other learning units: labs and lectures can be combined into courses. Courses are combined into a learning plan.
We also have learning results and learning resources.

14. Concierge We should use: Institutional Information Personal
Information about
the experiences
of others
Requirements
Goals
A concierge at a hotel, anticipates our needs and makes it easy for us to achieve our objectives. The concierge in Kuali Student will do the same thing.
In the student system we have a lot of data available to us:
Institutional information, personal information, and information about the experiences of other.
We can use this information to make it easier for the user. For example, we can use degree requirements and student goals (learning plans) and possibilities to support our students when they are looking for a course.
Possibilities
to support users

15. Concierge Concierge sits looking Concierge “sees”
requirement to pay fees
triggered by completing
registration
Concierge sits looking
and listening for changes in
a person’s 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
Here is another example about paying fees.
Step through the revelation on the slide.
Information
Rules engine
process ends when
fees are paid
Workflow

16. Functional Scope Tier 1 Functionality Tier 2 Functionality
Learning Unit Management
Person Identity
Configuration application
Enrolment
Degree Audit and Academic Evaluation
Student Financials
Concierge – limited
Application connectors
Tier 2 Functionality
Admissions
Scheduling
Awards and Financial Aid
Concierge
A student system is a very large system with many possible components. It was necessary for us to draw a box around those components that are in scope for OUR project. To do this, we defined the functionality into Tiers.
Tier 1 functionality consists of the core functionality of a Student System. It is functionality that the founders are committed to both developing and implementing and we felt it was of high priority to implement soon.
Curriculum development was chosen as the first module because:
It represented functionality the founders did not have
It is low risk – not student facing
It has high benefits because a really flexible and configurable way of defining curricula lies at the heart of the vision
Tier 2 functionality is also core functionality that the Founders are committed to developing and implementing, but it is less important or time critical for the Founders. So it will be developed in the latter part of the project.

17. 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
Tier 3 functionality is out of scope for the Founders project. We believe that these modules should be part of a robust student system, and it should be part of Kuali Student. But, it is not part of our initial 5 year project. We are encouraging other projects and partners that might want to take these modules on.
Tier 4 functionality is truly out of scope for a student system. These are functions that are expected to have their own application to provide support. But note it is within our project scope to develop Application Connectors (through services) to these out of scope applications.

18. Functional Scope and Timeline
This is a high level timeline so you can very generally see how this 5 year project is laid out.
Green bars are Founder scope.
We started in July 2007, so we are here now. (Describe current phase we are in.)
Yellow bars are Tier 3 functions that we are encouraging Partners to take on. This work does not start until the 3 year after the service contracts have been designed and published.
The blue box at the bottom, indicates connectors to other applications. They will be developed along with the appropriate module in the green bar.
I’m going to take a closer look at what is happening in the first 2 years of the project in a few slides.

19. 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
We’re going to switch tracks a bit and talk about our technical architecture.
We are still working on and developing the details of our technical architecture, but we started with 10 guiding principles that are fundamental to our vision.
The first 4 are about Service Orientation:
A Service Oriented Architecture using Web Services – because the services are autonomous, re-usable and loosely coupled, they’re easier to implement and maintain.
Published Service Contracts & Standards – to allow the community to easily contribute to the product development while still ensuring the quality of the result.
The next 3 are about Component Abstraction:
Abstraction of the presentation layer from the application logic give us a Flexible User Interface which enables each institution to customize the presentation of the system through their user portal.
Abstraction of the Data Model, along with Rules-based Business & Process Logic –enables the system to support a wide range of learners and learning activities in a variety of institutions. It can be configured at implementation time to satisfy the specific business processes and requirements of each institution.
As a result of this abstraction, we will deliver Kuali Student with a Reference Implementation. Kuali Student will be distributed with standard data models and business processes pre-configured. A ‘copy and modify’ approach will speed the implementation process.
And lastly, we will leverage open source technology:
Kuali Student will be built entirely on open source software infrastructure stack so the reference implementation can be downloaded without any licensing fees. All licenses will be compatible with the Educational Community License issued through the Kuali Foundation.

20. Architecture Concierge Portal User Contact Admission Registration
Applications
Business
Services
Notification
service
Evaluation
service
Enrolment
service
Concierge
Infrastructure
Services
Rules
service
Workflow
service
Identity
service
A very simplified view of the architecture
Information
Learning
plan
Program
requirements
Program
availability

21. Architecture Existing Applications Design in Progress
Selection completed
Aug-Dec 2007
At the portal layer, many institutions already have an existing portal that they want to use and for many of us that is uPortal. For our reference implementation, we will show KS running under uPortal.
Between August and December we completed our selection of a set of products for our reference infrastructure stack: If you’d like a more detailed description of the products we chose and the rationale, please attend the Technical Overview session to be held right after lunch at 1:00pm
During the recent months (January - May 2008), we have been working on the Developers Workbench and the design of the first set of services for Learning Unit Management and Person Identity, and the Configuration Application.
The configuration application will be used to configure the system at implementation time, allowing us to:
Define rules to the rules engine
Define process flows to the workflow and BPEL engines
Define abstract data concepts such as learning units and learning plans into course, degrees, etc.
We have also been working on the implementation of the Authorization and Authentication services in the KIM module of Kuali Rice.
Implementation in
Progress: KIM

22. Development Approach
KS is a 5 year project, with 7 partners distributed across a wide geographical area
A project of this complexity requires a structured approach to development and project management
Agility, phases, time boxing, reusability and iterations
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
A project of this complexity requires a structured approach to development and project management. Our development approach requires:
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
Although the SOA methodology requires an upfront investment in application architecture and service modeling, we will still be applying agile development techniques: Phases, Time-boxes, Iterations
The Kuali Student project does not include implementation, BUT… The Founders will be implementing the application modules as they are developed. Each of the Founders has set up a parallel Implementation team who will work alongside the product development teams to prepare the institution for implementation.

23. Phased Modular Approach
Functional Stream
Technical Stream
Aug 2007
Oct 2008
Nov 2008
May 2009
July 2009
Aug 2009
Application Architecture
Technical Architecture
Service Modeling &
Contract Design
Release 1
Development Infrastructure
Develop Configuration
Application
Program Management & Communications
This diagram gives you a visual view of the phased modular approach. At each phase we have defined specific, tangible, measurable milestones.
We are here 
We have completed the Application and Technical Architecture work as scheduled
We are now focusing on the Service modeling and contract design as well as the development infrastructure
First software will be released to the Founders on April At least 1 founder will implement immediately (UBC) so we can learn from the experience and test our implementation and support processes.
During the first 2 years of the project, we will also be focusing on Community Development
development of the Commercial Affiliates
developing other potential adopting institutions
developing potential partners who may want to develop Tier 3 functionality
Service Modeling &
Contract Design
Release 2
Software Design &
Development
Release 1
Adjust plans and repeat for
Releases 2/3/4
Implement & Test R1
Re-plan / Re-Architect / Implement & Transition to Support

24. Where are we today? Legal agreements between Founders
Partnership with Kuali Foundation
Project charter approved
$2.5 M Mellon grant awarded
Project launch workshop July 30, 2007
Technology architecture - recommendations completed
Technology stack – proof of concept completed
Application architecture - recommendations completed
Service modelling & contract design
Developers Workbench & Configuration Application
Contributors program - being finalized

25. Founder & Partners Founders Partners University of British Columbia
University of California, Berkeley
University of Maryland, College Park
Florida State University
San Joaquin Delta College
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
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
Partners
Massachusetts Institute of Technology
Cambridge University

26. The Andrew W. Mellon Foundation
Other Partners
The Andrew W. Mellon Foundation
Supported by:
AACRAO
NITLE
Advancing liberal education in the digital age
Mellon Foundation has awarded us a grant of $2.5 million dollars over the first 2 ½ years of the project to develop Kuali Student.
In addition, we have 2 organizations: AACRAO and NITLE that have agreed to help us engage the larger community to gather feedback on our designs. They will help us by using their communication channels to test our assumptions and see if the solutions meet the needs of the larger community.
AACRAO - American Association of Collegiate Registrars and Admissions Officers.
NITLE - National Institute for Technology and Liberal Education

27. Why Community Source? Benefits Kuali Student will
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
There are many benefits of Community Source.
The most obvious is the shared developer resources – more efficient development
The one that is most surprising we have found, is the degree of sharing of ideas and innovative solutions that have nothing to do with the system. This happens when the SMEs get together to discuss requirements and they share their experiences. A very large unexpected benefit.
Along with higher education institutional users and contributors, the Kuali Student project will build a community of interest that also includes commercial vendors, to sustain future maintenance, enhancements, and developments of the Kuali Student product. It will establish procedures and standards for development that can be used by the community to extend the core functionality and to integrate commercial packages.
This community will also be able to share implementation experiences and leverage user experiences in order to deliver more efficient, productive student services. It is anticipated that the community will contain a wide diversity of institutions that have implemented or support Kuali Student including for example, research intensive universities, small liberal arts colleges, community colleges, international universities, commercial vendors, and continuing education institutions.

28. Why join the Community? Provide specific input on product direction
Access project documentation and artifacts as they are developed
Have early access to software for testing and implementation
Contribute enhancements to ensure the quality and suitability of the end product
Help develop support processes and product release strategies.
Contribute knowledge and experience to the community
Implement some or all of Kuali Student sooner
There are many benefits to contributing, but the most significant is being able to provide specific input into the product directions and development priorities.
In addition, access to project deliverables and WIP will provide a significant advantage in implementation when the time comes. The implementation team will have had a chance to work with the product development team, moving a long way up the learning curve.

29. Contribution Opportunities
Founders
substantial commitment in money and people
Partners
significant commitment to core product
Contributors
Help sustain, or enhance by developing new modules
Adopters
commitment to adopt some modules
Supporters
get the Kuali Student chocolates
Contributors:
Align with the vision
Join the Kuali Foundation
May contribute funds toward the sustainment of Kuali Student
May develop and contribute associated modules (Tier 3) or enhancements
Express an interest in implementing one or more modules
Agree to sign the Contributors Agreement, and abide by the Educational Community License
Act as an advocate for the Program
Not a rigid formula – tailored to the situation
We welcome all forms of engagement.
Over the course of 5 years we recognize that supporters may become adopters or contributors!

30. Information
or Google: “Kuali Student”

31. Kuali Student will... Support end users
Support a wide range of learners and learning activities
Support a wide range of business processes
Make it easier to change processes
Deliver a product based on services
Be sustainable through community source development and adoption.
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.

32. Future Students….