Rice Charter Update University of California July 20, 2009 Bill Yock

ITAG Contributions to Charter The Rice Charter was actively being developed during period of evaluation Initial findings helped enforce and shape similar principles and success metrics (interoperability, modularity, standards based, etc. ) Helped define direction towards collaboration with “ Interested Parties” Helped shape the Vision (Foundational Middleware, standardized development frameworks, technology neutrality, etc.)

Rice Charter Status The Charter was officially signed by the Rice Board in May 2009 and is posted at Contents: −Project Vision, Objectives and Success Indicators −Functional Scope and Technical Architecture Governance −Implementation Considerations (QA Practices, PM Practices, Licensing Mgmt, Project Documentation, Implementation Support, Community Sustainment, etc.) −Project Delivery Approach (Project team, modular delivery, version and compatibility, development phases, etc.) −Project Organization (Investing Partners, Adopters, Interested Parties, etc.) −Project Financial Administration (Cost assumptions, funding assumptions) −Project Management (Planning, communications, change requests, risk management, etc.)

Rice Project Governance

Rice Directions and Business Model University of California July 20, 2009 Bill Yock

Rice Positioning and Business Model Major Themes (To be discussed in this session) −Positioning of Rice in regards to other similar open source software −Business Model and Sustainability (To be discussed in afternoon Rice roadmap session) −Interoperability and Coexistence −Federation and Reuse UC ITAG Evaluation helpful in preparing a FAQ for other institutions preparing to do an evaluation

Positioning - FAQs QuestionAnswer How does Rice compete with and/or compliment other middleware solutions? The intent is for Rice to be a fully self- functioning, lightweight, and mature middleware platform that leverages as much existing open source software as possible. Additionally, it should be able to complement and connect to existing and well established institutional middleware. What advantage does Rice have over similar middleware solutions? The value of Rice will become more distinct as common business practices amongst the Kuali Applications (Finance, Student, Research, etc.) evolve. This is especially true as common architectures mature (i.e. data architectures, business rules, federated IdM, etc.)

Business Model - FAQs QuestionAnswer What is the ongoing commitment and funding investments for Kuali Rice? All Kuali projects, including Rice, are “Community Sourced” development efforts. This means that institutions interested in participating contribute resources towards the development and evolution of the projects. Investments are managed overall by the Kuali Foundation and are coordinated to sustain long term viability. The initial Kuali Rice project received significant long term investments from 8 institutions. In addition, development resources from the other Kuali projects are often contributed to enhancing Rice.

Business Model - FAQs QuestionAnswer How are decisions made regarding future directions that Kuali Rice will take? The Kuali Charter outlines many principles that govern the direction of the project and the evolution of the middleware components. One primary principle is the “Not invented here” principle which indicates that as much as possible Kuali Rice will use readily available and acceptable open source technologies.

Business Model - FAQs QuestionAnswer Who decides what open source technologies to build or use within Kuali Rice? “Investing Partners” making significant investments receive voting rights on the Rice Board of Directors. Representatives are selected to serve on roadmap committees that prioritize and evaluate technology and functionality options. The Kuali Rice project team works with the roadmap committees to develop and implement decisions. Kuali Rice “Adopters” and other “Interested Parties” are expected to contribute implementation knowledge for all to benefit from.

Rice Status Update University of California July 20, 2009 Eric Westfall – Kuali Rice Project Manager

Rice Status Target date for public release is July 31 Team is currently in the final phase of QA, working on packaging, licensing, release notes and continued testing During development of Rice 1.0, approximately 1,100 issues have been resolved. Colorado State University and San Joaquin Delta College went live on July 1 st with a pre-release version of KFS 3.0. This included a pre-release version of Rice 1.0. Innovativ Consulting has been working on the documentation for the Rice 1.0 release. This includes a significant amount of new documentation as well as improvements to our existing documentation.

Rice 1.0 – Major Changes Major refactoring of package structures to conform with project standards Refactoring of all database identifiers (table names, column names, etc.) to conform with project standards Reorganization of Rice modules including explicit separation of API and Implementation classes.

Rice 1.0 – Major Changes Implementation of Kuali Identity Management Module −Replacement of existing identity services supplied by KEW −Integration of KIM authz into other modules of Rice (most notably KNS and KEW) −Created a Kuali CAS Server which integrates with KIM

Rice 1.0 – Major Changes Rewrite of numerous KEW screens to leverage the KNS application framework, including (but not limited to): −Document Search −Action List −Route Log −Routing Rules

Rice 1.0 – Major Changes Consolidation of duplicate framework code and services that existed in KEW and KNS −Lookup framework removed from KEW, replaced with KNS −Application Constants removed from KEW, replaced with KNS system parameters −Duplicate concept of “Document Type” removed from KNS, consolidated with KEW Document Types

Rice 1.0 – Major Changes A new document for maintaining Document Types was implemented Improved compliance with accessibility standards (in the KNS as a framework and in KEW implementation) Upgrade from XFire to Apache CXF as backend implementation of KSB web service functionality

Rice 1.0 – Major Changes Improvements to the way that services can be published to the KSB service registry Foundation put in place for future replacement of OJB with JPA Numerous other bug fixes and miscellaneous improvements Major rewrites and improvements to the Rice documentation

Rice 1.1 – Features and Timing Rice 1.1 is the next major release of the Rice software This will be more then a set of simple enhancements and bug fixes, we are planning to undertake some significant projects as part of this release Kuali Coeus 2.0 and Kuali Student 1.0 are going to be using a 1.0.x version of Rice instead of waiting for Rice 1.1 to be completed

Rice 1.1 – Features What follows is a list of proposed changes in Rice 1.1, the final decisions have not yet been made by the ARC One commitment made by the Rice project for version 1.1 is to provide compatibility between versions moving forward −There is a working group formed in the TRC which is working to identify what work will be required to facilitate this

Rice 1.1 – Features Conversion from OJB to JPA − there is a working group formed in the TRC that is working on the plan for this Support for simple Document Type-based delegation Remove/replace user functionality for doing mass changes to data that depend on a user −update permissions, groups, roles, rules, etc. when someone leaves the university or changes positions

Rice 1.1 – Features Extract the batch framework from KFS into Rice Various Document Search improvements Create standards for naming of Rice configuration parameters and implement them Create standards for Rice service names and implement them Improved XML ingestion features and fixes to schemas for easier use in XML tools

Rice 1.1 – Features Improvements to KNS Help System Consolidate KEW help system with KNS help system Consolidate KEW notes and attachments with KNS notes and attachments −possible other work here as well regarding using alternate storage for attachments (like a CMS) Convert KEN GUI screens to use the KNS Convert KSB GUI screens to use the KNS

Rice 1.1 – Features Improvements to Action List to allow for display of custom columns Improvements to delivery preferences Add support to KNS for versionable documents Allow for greater customization of exception routing Extract “Global” or “Mass” document framework from KFS

Rice 1.1 – Features Improvements to Document Search implementation to ensure that it’s behavior is consistent with other KNS-based lookups −Includes general improvements to the design of the document search “back-end” Implement more screens in KIM for maintaining data Upgrade to Spring Framework version 2.5 Other miscellaneous improvements

Rice 1.1 – Timing Facilitating compatibility between Rice versions post 1.1 is the top priority for the Rice 1.1 release That work alone is expected to take a significant amount of time, since we will be locked in to certain decisions once Rice 1.1 is released Analysis and planning alone for this is likely to take a few months

Rice 1.1 – Timing JPA work is also expected to require a large amount of time, includes authoring documentation and tools for existing applications to help with their conversion All of this will be discussed with the ARC when we bring these items to them for planning and prioritization of the Rice 1.1 release

Rice 1.1 – Timing Prior to discussion with the ARC, it’s hard to predict the amount of time the release will take Original targets were fall of this year However, Rice 1.0 release has taken longer then expected so 1.1 release may need to slip into next year As mentioned before, this will depend on decisions made by the ARC −Some of these items could end up on the wish list after ARC prioritization

Rice Roadmap – Future Directions University of California July 20, 2009 Bill Yock

Rice – Wish List We refer to our requested list of future features as the “The Wish List” What follows is a list of items that have been suggested by others and are on our list to consider for future implementation When and to what extent this work happens will be determined by the roadmap committees

Reference Layer Framework

Rice – UI Layer Wish List Improved Web 2.0 and AJAX Support Extensibility of GWT Portlet Support Mobile Application Support BI Dashboard Widgets Business Activity Monitoring Widgets Improve KNS (eDoc Lite) to be more flexible (tightly coupled to Dictionary Services) Improved support for Accessibility

BI Layer - Wish List BPEL/BPMN Support −In general, better support for industry standard workflow constructs, service orchestration Adoption of KS Business Rule Mgmt Framework (Based on Drools Open Source Rule Engine from KS Project) Common Business Domain Vocabulary Institutional Research / Enterprise Reporting Data Marts and Canned Reports

ESB Layer – Wish List Continue to evolve KSB toward more industry standards −At the extreme case, this might result in replacement of the KSB −At a minimum, improve utilization of other open source products within KSB (such as Active MQ) RSS Support − primarily in the context of the notification module

Integration Layer - Wish List Implement support for graphical workflow design tool Implement support for automated “escalation” in the workflow engine Greater configurability of notification preferences Application Connectors – Common vendor package implementation maps Support for JMX and monitoring

IdM Layer – Wish List KIM endorsed by Internet2 with integration to Shibboleth, InCommon, Grouper, etc. Federated IdM services Directory / Registry integration and interfaces Integration with Organizational / Group services

Data Mgmt Layer – Wish List Master Data Mgmt Services (organization, budgets, space, calendars, etc.) Metadata Management Services (data dictionary, data governance, data lineage, data quality, etc.) Data Warehouse Services (rule driven ETL, common data structures, etc.) Document Management Services (Document storage, search, retention, etc.)

Rice – Technical Wish List Modularity and ease of deplyment (OSGi support, decouple Rice components, etc.) Microsoft Interoperability Certification / Support of various platforms (hardware, operating systems, DBMSs, etc.) RESTful development support