Upload
kacie-lickert
View
214
Download
0
Embed Size (px)
Citation preview
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.)
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 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.
Business Model - FAQs
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.
Business Model - FAQs
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
University of California
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.
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 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
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 – 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.)