rice charter update university of california july 20, 2009 bill yock

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 http://rice.kuali.org

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

http://rice.kuali.org/

Rice Project Governance

Kuali Rice Board

Application Roadmap Committee

Kuali Foundation Board

Kuali Financial Reps

Kuali Student Reps

Kuali Coeus Reps

Kuali Rice Reps

Future Project Reps

Technology Roadmap Committee

Kuali Financial Reps

Kuali Student Reps

Kuali Coeus Reps

Kuali Rice Reps

Future Project Reps

Kuali Rice Project Manager

Kuali Application IntegrationWorking Group

Kuali Technology IntegrationWorking Group

Kuali Rice Developers

Rice Directions and Business Model


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

Question Answer

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

Question Answer

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.


Question Answer

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.


Question Answer

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


July 20, 2009

Eric Westfall – Kuali Rice Project Manager

Rice 1.0 - 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 1st 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.


• 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


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


• 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


• 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


• 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


• 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


• 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


• 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


• Improvements to Action List to allow for display of custom columns

• Improvements to email delivery preferences• Add support to KNS for versionable

documents• Allow for greater customization of exception

routing• Extract “Global” or “Mass” document

framework from KFS


• 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


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

ServiceOriented

ArchitectureServices

Rice KSB

Plugins / Wrappers

ESBs, Registries,

Service Engines,

etc.

Kuali Web Apps (Student, Coeus, Finance, etc.) Enterprise Portals (uPortal, Liferay, etc.)

Rice KNS

Struts

Plug Ins / WrappersRIAs, AJAX, GWT,

etc.

Rice FuturePortlets

Rice FutureBI Dashboards

RichUser

InterfaceServices

Rice FutureBusiness Rule Mgmt System

Rice Future BI / Reporting

Framework

BusinessIntelligence

Services

Plug Ins / WrappersBPM, BPEL Engines, Bus Activity

Monitors, etc.

RiceKEW

RiceKEN

EnterpriseIntegration &MessagingServices

RiceKIM

Rice FutureAccess & Roles

Identity & Access Mgmt

Services

Plug Ins / Wrappers IdM, Authz, Authn, Access & Roles,

Security Services, etc.

Plug Ins / Wrappers Message Queues, App Connectors,

Workflow engines, etc.

Master Data Management

Rice Future KOM

Rice FutureOther MD

DataMgmt

Services

MetaData Management

Rice KNS

Data Dictionary

Rice FutureMetadata

Plug Ins / WrappersDoc Mgmt, Storage

Services, Data Profiling, etc.

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

rice charter update university of california july 20, 2009 bill yock

Documents