… the next generation student system is coming!

1. … the next generation student system is coming! Kuali Days V November 14, 2007

2. Agenda • Why now? • The vision • Functional design and scope • Technical architecture • Development approach • Community source • Where we are and where we’re going

3. 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

4. Vision: Functional Objectives • Support end users by anticipating their needs and simplifying (or eliminating) administrative tasks. • Support a widerange 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. • Reducetime staff spend on routine tasks, so they can do more to directly support students and faculty.

5. 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. • Builda 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.

6. 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 productbased 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.

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. 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 Functional Scope

12. 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 Out of Scope Functionality

13. Functional Scope and Timeline

14. 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

15. Technical Architecture

16. Developers Workbench

17. Configuration Application

18. 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

19. Phased Modular Approach Functional Stream Technical 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 & Curriculum Development) • Development Infrastructure • Developers workbench • Procedures • Standards Contract Design R1 (Infrastructure & Curriculum Development) • 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

20. 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

21. 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

22. Supported by: AACRAO NITLE Other Partners The Andrew W. Mellon Foundation

23. 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

24. 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.

25. Other Opportunities • Founders • Partners • Contributors • Adopters • commitment to adopt some modules • Supporters • display the bumper sticker

26. 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

27. 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 • Application Architecture – in progress • Contributors program being finalized

28. Where are we going Kuali Student will: • Supportusers by anticipating their needs and saving them time. • Support a wide range oflearners 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.

29. Information www.kuali.org/communities/ks/