Your SlideShare is downloading. ×
0
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Kuali Student: A Next Generation Student System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Kuali Student: A Next Generation Student System

489

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
489
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Need a picture of today’s students – always on, always connected. Courses from many institutions at once Changing Environment: Many institutions are finding that their student systems no longer meet their needs Vendor solutions are expensive and do not provide the functionality that custom solutions do today The 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 increasing rapidly Budgets and funding constrained Institutions are looking to collaboration and open source systems development to solve these problems
  • Service Learning units Configurable – to meet individual institutional needs
  • Share development costs across partners Shorter time to deliver the total project On-going sustainment costs shared by the community of adopters
  • Architecture for all of UBC Definitions to share the work Deliver a product that can be configured and used by a variety of institutions Define standards for partner development
  • 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. 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
  • SOAD is different from OO in several respects (more emphasis on process and less on domain models) In theory SOA can be implemented on any platform (RMI, CORBA, DCOM etc). In practice WS is the only realistic alternative Standards: we do not want to replace vendor lock-in by product lock-in Governance: because of the enormous importance of service contracts in the SOA we need to pay special attention to the governance process for service contracts Rules: this is a “made in UBC” variation on SOA. Instead of having business logic encapsulated in individual services, ikt it externalized in a rules engine. Portal. Unlike our sister projects, Sakai and Kuali financials, we are going to deliver our user interface layer through a portal right from the start. Data layer. OS stack: everything from the database to the WS engines and registry must be open source. We cannot be the reseller of a commercial product. The various frameworks (ORM, MVC) used in the development must also be open source Lastly, the actual code base is java (open source) 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. A Flexible User Interface – abstracted from the application processes and application logic, this enables each institution to customize the presentation of the system through their user portal. An Abstract Data Model , along with Rules-based Business & Process Logic – so that the system can 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. 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. An Open Source Software Stack –The system will be built entirely on open source software infrastructure 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.
  • Building the Stack using open source products The first thing we are going to do is to select a set of products for our infrastructure stack. WS engine: must support latest ve5rsions of SOAP and WSDL Authentication server: essentially a single sign-on service like CAS Authorization: still a fuzzy area. We will have to align authorization policies across different business domains (eg LMS and SIS). Rules engine: We are taking business logic out of individual services and moving it to a rule engine. Service registry: Multiple concurrent topologies Implementation multiplexing BPEL service. We need to be able to configure business processes differently for the needs of each institution Portal (uPortal) Rules Engine (JBoss Rules, Open Rules) Authentication and Authorization (CAS, Acegi, JAAS) Data Binding Tools (jibx, Castor, JaxB) Web Services Engine (Axis 2, Xfire, JAX-WS, Spring WS, JBoss WS) Orchestration & Workflow ) (KEW, jBPM, BPMScript, Intalio, Agila, Pi-Calculus Service Registry (jUDDI, Infravio, UDDI) ESB (KSB, ServiceMix, JBoss ESB, Mule, Open ESB, Celtix) Database (mySQL)
  • Second thing is to build the Developers Workbench Many technical problems that we only need to solve once. We will develop services module stereotypes that developers can use, allowing them to focus most of their efforts on business logic Design Tools (MagicDraw) Build Tools (Maven, Ant) Source Code Management (Subversion, Aegis, GNU-Arch, CVS) MVC / Presentation Layer Framework (Spring, Struts, JSF) User Interface Toolkits (Dojo) Development Environment (Eclipse and Plug-Ins) ORM Tools (Hibernate, OJB, TopLink, Castor JDO, Ibatis, Torque, Jaxor)
  • 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.
  • 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
  • Complex Risk Assessment using a Risk Index (number from 1 – 9, Risk = Impact * Probability) Technology Risk SOA is new and very new to higher education BA Risk SOA methodology: new, often vague Lack of Appropriate Skills Community Source helps fill gaps, but what about the gaps that can’t be filled? Failure of Partnership What if the risks are too great for one or more founders? Size, Scope, Complexity Typical risk for any project SOA Top-Down Time investment in designing an SOA system Standards Compliance Completeness of standards; availability of open source components that are truly standards-based SME Staff Availability Institution priorities Budget Have we budgeted correctly, estimated correctly? Funding Funding pressures at one or more institutions cause funding decrease to Kuali Student Departure of Key Members - Knowledge lost, replacing key members, learning curve, etc.
  • Transcript

    • 1. … the next generation student system is coming! Kuali Days V November 14, 2007
    • 2. Agenda <ul><li>Why now? </li></ul><ul><li>The vision </li></ul><ul><li>Functional design and scope </li></ul><ul><li>Technical architecture </li></ul><ul><li>Development approach </li></ul><ul><li>Community source </li></ul><ul><li>Where we are and where we’re going </li></ul>
    • 3. Why Now? <ul><li>Many student systems don’t meet current needs </li></ul><ul><li>Vendor solutions may not be the answer </li></ul><ul><li>Development of in-house systems is challenging </li></ul><ul><ul><li>Increasingly complex technology requires specialist resources </li></ul></ul><ul><ul><li>Competing for scarce IT resources in a constrained market </li></ul></ul><ul><ul><li>User requirements and expectations increasing rapidly </li></ul></ul><ul><ul><li>Budgets and funding are constrained </li></ul></ul><ul><li>Collaboration and open source systems development works </li></ul><ul><li>We can build systems that do more for users </li></ul>
    • 4. Vision: Functional Objectives <ul><li>Support end users by anticipating their needs and simplifying (or eliminating) administrative tasks. </li></ul><ul><li>Support a wide range of learners and learning activities. </li></ul><ul><li>Support a wide range of business processes , including those that cross department and system boundaries. </li></ul><ul><li>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. </li></ul><ul><li>Reduce time staff spend on routine tasks , so they can do more to directly support students and faculty. </li></ul>
    • 5. Vision: Sustainability <ul><li>Ensure the core services of Kuali Student are successfully implemented by the Founding Institutions . </li></ul><ul><li>Promote the adoption and implementation of Kuali Student by a wide variety of educational institutions – in North America and internationally. </li></ul><ul><li>Build a community of interest that will sustain future maintenance, enhancement and development. </li></ul><ul><li>Define product development and support processes that will help the community implement the software and provide operational support. </li></ul><ul><li>Facilitate participation by vendors and service providers </li></ul><ul><li>Evolve the technology and architecture of Kuali Student to keep up with new standards, tool releases and trends. </li></ul>
    • 6. Vision: Technical Objectives <ul><li>Develop a next generation architecture based on Service-orientation , implemented using Web Services . </li></ul><ul><li>Publish service contract specifications . This will allow a large community work on the system. </li></ul><ul><li>Produce a software product based on a set of services . </li></ul><ul><li>Define and publish standards for development that can be used by others to develop services that are outside the scope of the core product. </li></ul>
    • 7. Functional design: Elements <ul><li>High level entities </li></ul><ul><ul><li>person; time; learning units </li></ul></ul><ul><li>Concierge </li></ul><ul><li>Rules engines </li></ul><ul><li>Work flow </li></ul><ul><li>Modular, configurable system </li></ul><ul><li>Managed access to information </li></ul><ul><li>Internationalization </li></ul>
    • 8. Learning units <ul><li>Course; single lecture in a course; 15 minute student presentation in a course </li></ul><ul><li>Participation in community service </li></ul><ul><li>Any activity that the student wants to include on a formal or co-curricular transcript </li></ul><ul><li>A “learning unit number” is like a SKU... </li></ul><ul><li>We can also have: </li></ul><ul><ul><li>learning results </li></ul></ul><ul><ul><li>learning plans </li></ul></ul><ul><ul><li>learning resources </li></ul></ul>
    • 9. Concierge Institutional Information Requirements Personal Information Goals Information about the experiences of others Possibilities We should use: to support users
    • 10. Concierge Concierge sits looking and listening for changes persons state, institution rules, peoples experiences, etc. Concierge “sees” student complete registration requirement to pay fees triggered by completing registration Concierge checks student info, rules & financial aid opportunities and guides student through process process ends when fees are paid Rules engine Workflow Uses Information
    • 11. Functional Scope <ul><li>Tier 1 Functionality </li></ul><ul><ul><li>Curriculum Development </li></ul></ul><ul><ul><li>Customer contact </li></ul></ul><ul><ul><li>Configuration application </li></ul></ul><ul><ul><li>Enrolment </li></ul></ul><ul><ul><li>Degree Audit and Academic Evaluation </li></ul></ul><ul><ul><li>Student Financials </li></ul></ul><ul><ul><li>Concierge – limited </li></ul></ul><ul><ul><li>Application connectors </li></ul></ul><ul><li>Tier 2 Functionality </li></ul><ul><ul><li>Admissions </li></ul></ul><ul><ul><li>Scheduling </li></ul></ul><ul><ul><li>Awards and Financial Aid </li></ul></ul><ul><ul><li>Concierge </li></ul></ul>
    • 12. Out of Scope Functionality <ul><li>Tier 3 – Out of scope for Founders </li></ul><ul><ul><li>Recruitment </li></ul></ul><ul><ul><li>Event Management </li></ul></ul><ul><ul><li>Housing </li></ul></ul><ul><ul><li>Athletics </li></ul></ul><ul><ul><li>Alumni </li></ul></ul><ul><ul><li>Family Financial Planning </li></ul></ul><ul><ul><li>Elections </li></ul></ul><ul><ul><li>Student Life </li></ul></ul><ul><li>Out of Scope </li></ul><ul><ul><li>Learning Management System </li></ul></ul><ul><ul><li>Student Portfolio </li></ul></ul><ul><ul><li>Financial (FMIS) system </li></ul></ul><ul><ul><li>Campus Calendar </li></ul></ul><ul><ul><li>Facilities Management </li></ul></ul><ul><ul><li>Library </li></ul></ul><ul><ul><li>Parking </li></ul></ul>
    • 13. Functional Scope and Timeline
    • 14. Technical architecture: Guiding principles <ul><li>Service Oriented Architecture </li></ul><ul><ul><ul><li>SOA methodology </li></ul></ul></ul><ul><ul><ul><li>Web services </li></ul></ul></ul><ul><ul><ul><li>Standards based (WS and industry standards) </li></ul></ul></ul><ul><ul><ul><li>Separate governance process for service contracts </li></ul></ul></ul><ul><ul><li>Component Abstraction </li></ul></ul><ul><ul><ul><li>Abstraction of business processes and business rules </li></ul></ul></ul><ul><ul><ul><li>Abstraction of presentation layer via a portal </li></ul></ul></ul><ul><ul><ul><li>Abstraction of the data layer </li></ul></ul></ul><ul><ul><li>Leverage Open Source Technology </li></ul></ul><ul><ul><ul><li>Use an open source software stack </li></ul></ul></ul><ul><ul><ul><li>Infrastructure built from open source products </li></ul></ul></ul><ul><ul><ul><li>Java as the language of choice </li></ul></ul></ul>
    • 15. Technical Architecture
    • 16. Developers Workbench
    • 17. Configuration Application
    • 18. Development Approach <ul><li>Development project structure </li></ul><ul><ul><li>5 + year project starting July 2007 </li></ul></ul><ul><ul><li>Well defined phases of approximately 4-6 months each </li></ul></ul><ul><ul><li>Clear definition of deliverables at each stage </li></ul></ul><ul><ul><li>Each phase delivers a tangible asset </li></ul></ul><ul><ul><li>QA reviews and checkpoints at the end of each phase </li></ul></ul><ul><ul><li>Sign off of phase deliverables as complete </li></ul></ul><ul><ul><li>Review plans for the next phase at the end of each phase </li></ul></ul><ul><li>Separate implementation projects at each institution </li></ul><ul><ul><li>Kuali Student does NOT include implementation </li></ul></ul><ul><ul><li>Product is “configured” for institution by a separate team </li></ul></ul><ul><ul><ul><li>dictionary; search; rules; BPEL; authorization </li></ul></ul></ul><ul><li>Agility, phases, time boxing, reusability and iterations </li></ul>
    • 19. Technical Stream Functional Stream Jul 2007 Sep 2008 Oct 2008 Apr 2009 Jun 2009 July 2009 <ul><li>Application Architecture </li></ul><ul><li>- Process models </li></ul><ul><li>ER models </li></ul><ul><li>High Level Service Models </li></ul><ul><li>Domain Definitions </li></ul><ul><li>Technical Architecture </li></ul><ul><li>Technology proofs </li></ul><ul><li>SOA standards </li></ul>Service Modeling R1 (Infrastructure & Curriculum Development) <ul><li>Development Infrastructure </li></ul><ul><li>Developers workbench </li></ul><ul><li>Procedures </li></ul><ul><li>Standards </li></ul>Contract Design R1 (Infrastructure & Curriculum Development) Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure & Domain 1) Adjust plans and repeat for Releases 2/3/4 Program Management & Communications Contract Design R2 (Domain 2) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support <ul><li>Develop Configuration </li></ul><ul><li>Application </li></ul><ul><li>Configuration Infrastructure </li></ul><ul><li>Proof of concept Pilot </li></ul>Phased Modular Approach
    • 20. Why Community Source? <ul><li>Benefits </li></ul><ul><ul><li>Shared resources means more efficient development </li></ul></ul><ul><ul><li>Institutions share ideas and create innovative solutions, leveraging their user experiences </li></ul></ul><ul><ul><li>Contributing institutions have direct input into functions and features </li></ul></ul><ul><ul><li>Sustainability – a community that contributes to enhancements can ensure sustained development </li></ul></ul><ul><ul><li>Support – commercial partners for implementation and support are encouraged </li></ul></ul><ul><li>Kuali Student will </li></ul><ul><ul><li>Build a community of interest </li></ul></ul><ul><ul><li>Establish procedures and standards for development </li></ul></ul><ul><ul><li>Encourage commercial affiliates </li></ul></ul><ul><ul><li>Share implementation experiences </li></ul></ul>
    • 21. Founder & Partners <ul><li>Partners </li></ul><ul><li>Massachusetts Institute of Technology </li></ul><ul><li>Carnegie Mellon University </li></ul><ul><li>Founders </li></ul><ul><li>University of British Columbia </li></ul><ul><li>University of California, Berkeley </li></ul><ul><li>University of Maryland, College Park </li></ul><ul><li>Florida State University </li></ul><ul><li>San Joaquin Delta College </li></ul>
    • 22. Other Partners <ul><li>Supported by: </li></ul><ul><li>AACRAO </li></ul><ul><li>NITLE </li></ul>The Andrew W. Mellon Foundation
    • 23. An Opportunity to Contribute <ul><li>Align with the vision </li></ul><ul><li>Membership in the Kuali Foundation </li></ul><ul><li>Contribute funds toward the development of Kuali Student </li></ul><ul><li>Express an interest in implementing one or more modules </li></ul><ul><li>Abide by the provisions of the Educational Community License </li></ul><ul><li>Act as an advocate for the Program </li></ul>
    • 24. Benefits of Contributing <ul><li>Able to provide specific input on product directions, needs and expectations </li></ul><ul><li>Access to project documentation and artifacts as they are developed </li></ul><ul><li>May participate in Beta testing and may have early access to software for testing and implementation </li></ul><ul><li>May contribute to bug fixes and enhancements to ensure the quality of the end product </li></ul><ul><li>May contribute implementation experiences and materials back to the community body of knowledge </li></ul><ul><li>May provide input to the development of support processes and product release strategies. </li></ul>
    • 25. Other Opportunities <ul><li>Founders </li></ul><ul><li>Partners </li></ul><ul><li>Contributors </li></ul><ul><li>Adopters </li></ul><ul><ul><li>commitment to adopt some modules </li></ul></ul><ul><li>Supporters </li></ul><ul><ul><li>display the bumper sticker </li></ul></ul>
    • 26. <ul><li>Technology </li></ul><ul><li>Business Analysis (SOA) </li></ul><ul><li>Lack of Appropriate Skills </li></ul><ul><li>Failure of the Partnership </li></ul><ul><li>Size, Scope, and Complexity </li></ul><ul><li>SOA Approach </li></ul><ul><li>Standards Compliance </li></ul><ul><li>SME Staff Availability </li></ul><ul><li>Budget / Cost Estimates </li></ul><ul><li>Funding </li></ul><ul><li>Departure of Key Members (Board, Steering, other) </li></ul><ul><li>Working with a distributed team </li></ul><ul><li>Change management challenges </li></ul>Risks
    • 27. <ul><li>Legal agreements between Founders </li></ul><ul><li>Partnership with Kuali Foundation </li></ul><ul><li>Project charter approved </li></ul><ul><li>$2.5 M Mellon grant awarded </li></ul><ul><li>Project launch workshop July 30, 2007 </li></ul><ul><li>Application Architecture – in progress </li></ul><ul><li>Contributors program being finalized </li></ul>Where are we today?
    • 28. Where are we going <ul><li>Kuali Student will: </li></ul><ul><ul><li>Support users by anticipating their needs and saving them time. </li></ul></ul><ul><ul><li>Support a wide range of learners and learning activities in a wide range of institutions by using a flexible, configurable, data model. </li></ul></ul><ul><ul><li>Support a wide range of business processes , in different institutions, using a configuration application. </li></ul></ul><ul><ul><li>Make it easy to change processes , using rules and workflow. </li></ul></ul><ul><ul><li>Use a Service Oriented Architecture , implemented using Web Services. </li></ul></ul><ul><ul><li>Achieve sustainability through community source development and wide spread adoption. </li></ul></ul>
    • 29. Information www.kuali.org/communities/ks/

    ×