KRICE Kuali Rice : Kuali Rice Roadmap

Introduction
Contents
The Kuali Rice Charter specifies that the
Application Roadmap Committeeis responsible
for defining the overall Kuali Rice Project 1. Introduction
Roadmap. That includes defining both 2. Vision
functional and technical requirements along 3. Background
with expected timelines for development. 4. Release Cycles
Technical enhancements and requirements will 5. The Roadmap Process
be submitted to the ARC from the Technology 6. Themes and Enhancements
Roadmap Committee (TRC)to be prioritized 7. Release Plans
among the functional requirements.

This roadmap combines a description of the

requirements we plan to support and the release
plans for our software development efforts. This
first generation roadmap was prepared as a
collaborative effort between the ARC, the TRC,
the Rice project board, the Rice project team
and contributions from other interested parties.
These bodies are representative of the Kuali
Application projects as well as direct investors
in Rice who intend to use Rice as a part of their
enterprise architecture independent of the Kuali
Applications. We are developing a transparent
community process for authoring future versions
of the roadmap, so this roadmap should be
considered a living document whose next version
will be prepared by the new process.

The goal of the Roadmap is to provide the

Kuali ecosystem with guidance and visibility on
the future directions of the Rice software. An
important element in this visibility is that the
Roadmap help the Kuali Application Projects (KS,
KC, KFS, etc.) in formulating their own product
roadmaps. It is expected that the application
project teams will utilize this roadmap in the
formulation of the individual application projects.
As well, organizations building standalone
applications using Kuali Rice will depend on
the information available in this roadmap for
institutional plans.

The roadmap will be presented in varying levels of

detail, and will appeal to business users as well as
technical users.

In order to preserve iterations of this document

while the underlying information evolves over
time, it will be frozen in PDF form at various
points, elements will be included in powerpoint
presentations, and other medium. The living
content is organized and maintained in the Kuali
community wiki.
Vision
Kuali Rice is a set of infrastructure and development tools that enable colleges and universities to
construct sophisticated application software. There are many components and technology strategies
that work in a coordinated fashion to allow quick development and implementation of application
software. The Kuali Rice Project sets forth the following vision statements to guide the evolution of these
components:

• First and foremost Kuali Rice is highly valued and supports the needs of the Kuali Applications by
providing:
° Foundational middleware that the Kuali Applications are built on
° A software development framework that simplifies, standardizes, and accelerates development

and implementation efforts.

• To provide a general-purpose framework and middleware suite than can be used by any institution
to build custom applications or custom integrations not specific to any of the Kuali applications. The
framework will enable novice programmers and business analysts to easily create new business
functionality by using high level design and configuration tools.
• To iterate Kuali Rice toward architecture that follows the principles of service-orientation; re-use
of best-of-breed components; and standards. This architecture will support the development of
modular, technology neutral applications, that can be integrated with existing systems - where open
source, custom developed, and commercial applications can be combined.
• To achieve sustainability through community source distribution and wide spread adoption

Background
The Kuali Rice project originally grew out of the Kuali Financial System (KFS) project when the architects
realized that many of the services and middleware components developed for KFS could be leveraged as
Kuali grew to develop additional applications. The project was officially chartered in April of 2009 with a
board of directors, and new supporting member institutions.

The following diagram is a conceptual representation of Rice. It represents both the application
development framework of Rice, as well as the middleware services and components. It is divided
into application development "tiers" and middleware "service domains". The blue boxes represent
components and features available in the 1.0 version of Rice. The gray boxes represent potential future
high level components and features that have been imagined and discussed.

The Kuali Rice Nervous System (KNS) is primarily represented in the application development tiers
of Presentation, Controller, and Persistencen as green boxes. KNS has objects and services that help
render user interfaces in the Presentation tier, like tag libraries and java server page templates. KNS
also includes controller objects for typical user interaction on screens like create, update, delete and
read operations on screens. The Persistence layer includes KNS features that make it easy and reliable
to store business objects and data that your applications produce. It also includes a key metadata
management system in the form of a Data Dictionary component that is used for coordinating services
and controllers in the other service tiers.

The KNS also has ease of use features to quickly integrate with the various middleware across all service
domains in the Services tier. Services in the Services Tier are divided into five service domain areas:

• Workflow and Messaging Domain - Includes Kuali Enterprise Workflow (KEW) and Kuali
Enterprise Notification (KEN) message notification engines. Future work is anticipated in developing
additional application integration and system connectors.
• Business Rules Domain - Includes frameworks for business rule development and execution
as well as information delivery and analysis. Current strategy is to leverage work done on Kuali
Student project that is building a rule engine on top of the open source Drools product.
• Identity and Access Management - Kuali Identity Management (KIM) provides services for
authentication and authorization management. It provides plug ins for common authentication
systems and robust authorization services for defining and implementing data access control policies
and procedures.
• Data Management Services - Includes "Master Data" services for holistic management
of common data (persons, organizations, facilities, budgets, etc.) shared across all the
applications. Proposed services in this domain include Kuali Organization Management (KOM) and
Kuali Entity Management (KEM).
• General / Core Services domain - Includes general purpose utility services for overall system
configurations and supporting functionalities like extensible notes and attachments.

In addition to the service domains, Kuali Rice includes a Service Bus (KSB). The service bus provides
service management and routing functionalities. It is anticipated that institutions may deploy Kuali
applications using other external service buses in addition to, or in replacement of, KSB. A major
principle set forth in the Kuali Rice charter is the "not invented here" principle. As Kuali Rice evolves
careful consideration will be given on adopting or using already available open source solutions.
Replacing the KSB with an acceptable open source alternative is being planned.
KRICE Kuali Rice : Rice Roadmap - Release Cycles

• Release Versioning Scheme

• Release Lifespan
• ° Major Version Lifespan
° Minor Version Lifespan
° Patch Version Lifespan
° Lifespan Summary

• Relationship of Kuali Rice Releases to Kuali Application Releases

• End-Of-Life for Major Versions
• Release Cycle
• Pre-Release Versions
• ° Development Builds
° Milestone Releases
° Release Candidates

This roadmap shall outline the intended major and minor releases, along with assumed timeframes and
expectations for delivering tier 1 and 2 enhancements. It will suggest tier 3 out of scope enhancements
that other interested parties are encouraged to deliver within similar timeframes.

The roadmap and the release cycle are inter-dependent. In order to plan how functionality and
technology are evolved in Rice, we need to understand what the release cycle will look like, and how it
will relate to the releases of Kuali Applications (KFS, KS, KC, etc.).

Release Versioning Scheme

Versions of Kuali Rice shall follow a numerical scheme consisting of three parts separated by periods:
Major.Minor.Patch

• Major Versions are intended to be long-lived versions of the software that consist of numerous
minor versions. The decision to create a new major version will be the result of the need for major
changes that cannot be successfully implemented without breaking version compatibility. It is
permitted that different major versions of the software will not be compatible with each other.
Applications that are created in later versions of Rice may not be compatible with earlier major
versions of Rice. However, a reasonable and well-documented upgrade path should still be made
available from a previous major version of the software to it's next major version.
• Minor Versions are where most of the new work on the software will be done. It is intended that
different minor versions within the same major version should be compatible.
• Patch Versions should be created to address security issues or bugs with an existing minor version
release. Different patch versions within the same minor version should be fully compatible with each
other.

The following graphic illustrates the relationship between the different version types.

Release Lifespan
Each of the different types of Kuali Rice versions will have an expected lifespan which will help to
determine how best to schedule roadmap items into a release.
Major Version Lifespan

As mentioned previously, a major version of Kuali Rice should represent large architectural changes or
paradigm shifts which could result in changes that cause incompatibility with previous versions of the
software. Efforts should be made to reduce this impact as much as possible. However, in order to allow
for continued evolution of the Kuali Rice software, these types of changes will be necessary.

Additionally, a major version will likely be started in parallel with work happening on a previous major
version. Subsequently, once a new major version is released, maintenance work will continue on the
previous major version until it's end-of-life (see End-Of-Life below).

Because of the impact that major versions will have on existing applications, new major versions should
be created only when necessary and should have a long lifespan.

Ideally, a new major version of Kuali Rice should not occur any more frequently then every 2-3 years.

Minor Version Lifespan

Minor versions will be where the majority of the new Kuali Rice work will happen. Generally, other Kuali
applications will work to align their releases with a specific minor version of Rice. The goal for minor
versions of Rice should be to maintain a relatively short release cycle in order to facilitate pushing out
new functionality for Kuali applications or other implementers in a reasonable time line.

However, minor versions of the software will still need to go through a rigorous quality assurance cycle in
order to ensure that the version is as stable as possible. This will require that sufficient time be allocated
for this during the release cycle of the minor version.

Taking all of this into consideration, the Kuali Rice team should strive for minor version releases every
6-9 months.

Patch Version Lifespan

Patch versions are to be primarily used for bug fixes and security issues. A minor version of Kuali Rice
will continue to be maintained with patches until the next minor version is released. Once the next minor
version of the software is released, previous minor versions will not continue to receive patches.

Because of the bug fixing and security focus of patch releases, these should be released as often as
needed.

Lifespan Summary

Major Versions: 2-3 years

Minor Versions: 6-9 months
Patch Versions: as needed

Relationship of Kuali Rice Releases to Kuali Application

Releases
As mentioned previously, Kuali Applictions (KFS, KC, KS, etc.) should attempt to align their release
schedule with a specific minor release of Kuali Rice. They should then work with the roadmap committees
to ensure that any Kuali Rice work that they require for their release be included in the roadmap and
release planning for that version of Rice.

Ideally, the Kuali Rice work will be done in advance of the application work and be completed prior to the
Kuali application's quality assurance period to allow time for the Kuali application to properly integrate
and test the changes. In practice, this can be difficult to accomplish. However, this should be a goal of
increasing importance as we continue to move Kuali Rice and the other Kuali applications forward.

The targeted version of Kuali Rice should be released to the public prior or in conjunction with the public
release of the Kuali application software on which it is dependent.
 This could probably use some more detail and a stronger statement on the actual process.

End-Of-Life for Major Versions

In order to reduce the overhead of maintaining numerous old versions of the Kuali Rice software, an end-
of-life policy will be implemented for older major versions.

A major version will reach it's end-of-life once two subsequent major versions have been
released.

For example, Kuali Rice 1.x will reach it's end-of-life once Kuali Rice 3.0 is released.

During the intervening period, patches will continue to be made available when needed for the previous
major version of the software.

Release Cycle
The Kuali Rice release cycle consists of a few distinct phases as outlined in the charter.

1. Preparation and Planning

2. Application & Technology Architecture
3. Software Design and Development
4. Software Testing and Configuration
5. Software Release & Implementation Support
6. Post-Release Support

Note that these phases are applicable to major and minor version work. Patch versions will be driven
based on bug reports from the community and other Kuali applications and will happen during the "Post-
Release Support" phase.

Pre-Release Versions
In order to allow for pre-release testing and upgrade planning by the community, Kuali Rice will provide
early availability releases of the software to the public. Each of these "releases" will fall into one of three
categories:

1. Development Builds
2. Milestone Releases
3. Release Candidates

The implications of making these versions available early include:

1. Licensing vigilance needs to be maintained in an ongoing fashion on the project. All licensing
policies and procedures must be followed rigorously in order to prevent accidental release of code or
binaries which are using improperly licensed code or libraries.
2. Release notes and changelog documentation needs to be maintained and updated in parallel and in
real-time to the development work. This will facilitate others being able to successfully work with the
early releases and test them prior to the generally available packaged release and documentation.

Development Builds

The development process of Kuali Rice is backed by a continuous integration environment in which
the software is continually built and automatically tested. This environment can be used to create
development builds of the software for those that are interested in working with very early and possibly
unstable versions of the software. The primary customers for these builds would be those in the
community that might want to apply patches to their local implementation or the other Kuali applications
which might be working with these development builds in parallel with development of their application.

Alternatively, the source code for the latest version will be publicly available at all times in source control
for those that want to obtain a copy of it.
Milestone Releases

A milestone release will represent a point in time in the release and development cycle when a major set
of enhancements or changes are completed. A minor version may only have one or two milestones while
a new major version may have many more.

What constitutes the milestones for a particular version of Kuali Rice will be decided during the planning
phase and will be based on the major roadmap items of which that release is composed. A milestone
release should be partially stable such that those who want to begin working with it can. It should be
accompanied by some documentation which gives interested parties the information they need to get
started with it. However, it is not required that this documentation will be complete.

Generally speaking, each version should have at least one milestone release prior to the beginning of the
Quality Assurance phase.

Release Candidates

A release candidate represents a version of the software with potential to be the final public release.
The intention of making a release candidate available is to allow for those in the community to work
with the software and report any bugs they may find. If there are no fatal bugs found with the release
candidate within a specified period of time, then the version is ready for release. If fatal bugs are found,
they will be fixed and a subsequent release candidate will be made available. A release candidate should
be accompanied with a mostly complete set of documentation.

Ideally, each version of the software should only go through 1 or 2 release candidate versions prior to the
generally available public release.

Should we define a maximum period of time during which a release can be in RC mode? a
month? longer?
KRICE Kuali Rice : Rice Roadmap Process

The Kuali Rice community has adopted a process and terminology similar to that used by Eclipse as
described in the Eclipse Roadmap.
There are three main parts to our roadmap:

1. Vision and background - Information about the Rice community, the vision articulated in the
community charter, and our strategic goals.
2. Themes and Enhancements - Describes the application areas, strategic drivers and use cases,
and requirements characterizing the purposes and needs which the Rice community is working
toward. This section also helps to describe the scope and priority for our work.
3. Release Plans - Describes the development efforts in terms of planned releases and a timeline for
their availability

Process Overview
A picture is worth 1,000 words...

The graphic below describes the people, the tools, and the processes involved in the evolution of the
Kuali Rice Roadmap. Our community endeavors to make the process of evolving the roadmap open,
transparent, inclusive, and predictable. The process itself is likely to evolve as our community evolves so
please feel free to contribute that evolution. One way to do that is to offer comments directly on these
pages.

People and Roles

The Application Roadmap Committee (ARC) - The ARC is a committee of appointed individuals who
represent the varied interests in Rice. The group is responsible for the goals and priorities represented in
the Rice roadmap.
The Technology Roadmap Committee (TRC) - The TRC is also a committee of appointed individuals
who similarly represent the varied interests in Rice. The TRC is different than the ARC in that it's
membership is highly technical. This group is responsible for overall technology direction and works with
the ARC to ensure that technology interests are well represented in the goals and priorities set for Rice.
The TRC is led by the Kuali Rice Lead Architect.

For more information about the Roadmap Committees and how they fit into the overall Rice governance
visit the Rice project governance area in Confluence.

Technology
The Kuali Rice Community uses Jira to manage our software roadmap. Discreet items are entered into the
Jira project as either one of:

• Planned Enhancement
• Research Item
• Suggestion

Once items are entered into Jira, a community conversation can take place about the item. This
conversation, and the rich information about the item ensures that the ARC and TRC are making informed
prioritization decisions. It also ensures a high level of transparency in the process as well as the direction
of the Rice software.

Process

Annual Roadmap Development

During the Annual Roadmap development the ARC and TRC will form a joint task force to:

- Develop the themes and priorities for the new roadmap

- Organize and prioritize items in the roadmap
- Determine target versions based on effort estimates and available resource budget for enhancements as
well as research items
- Produce static roadmap documentation (PDF, Static HTML, Presentations)

Semi-Annual Roadmap Review & Update

During the Semi-Annual Roadmap updates the ARC and TRC will re-validate priorities, adjust versions if
necessary, re-plan based on completed research, etc. An updated roadmap document may be produced.

Regular ARC and TRC meetings

The ARC and TRC will periodically review suggestions made for Rice enhancements and work suggestions
into the regular roadmap process. Suggestions that come from anyone in our community will be
considered input for the annual and semi-annual roadmap development activities.

Ad-Hoc Suggestions

Anyone can make a suggestion to influence the Rice roadmap. This is done using the Rice Roadmap Jira
project. The ARC and TRC will review suggestions periodically and consider suggestions as part of the
input into prioritization exercises.

Voting
The Kuali Rice Application Roadmap Committee is the group ultimately responsible for prioritizing the
roadmap. This group is made up of representatives from each of the Kuali Application Projects, and a
representative of Rice from the perspective independent of the Kuali Application Projects. Each item in
the roadmap is prioritized separately by each of the voting representatives, and from these priorities an
overall priority score is assigned to each item.
KRICE Kuali Rice : Rice Roadmap - Enhancement Requests and Themes

Introduction

In this section we capture the needs of our community that the Rice team will address. These needs are
expressed as a set of high level "Enhancement Requests" and organized into different "Themes". These
requests are captured from the needs expressed by the Kuali application projects, and those expressed
by organizations implementing and using Rice beyond the scope of the Kuali application projects. Each of
these constituents are represented in Rice governance provided through the Board, the ARC and the TRC.

The enhancement requests represented in this roadmap are a combination of change requests that come
from both experience using Rice as well as imagination of innovations which we can enable.

Themes
We have collected these requests into "Themes" as an aid in understanding related sets of requirements.
Themes provide a way to classify our community's needs, and may include both specific functionality and
general characteristics like performance, swapability, and robustness. The themes are:

Themes Description

Usability End user ease of use features

Development Ease of Use Support for speeding up

development with frameworks,
patterns, etc.

Ease of Implementation Ease of deploying into different

environments and technology
stacks

Modularity Improved swappability, loose

coupling of components,
reducing duplication

Service Orientation Improved interfaces, API's,

service contracts, etc.

Kuali Application Business Common functionality across

Drivers Kuali application projects

Adopting Existing Code Leveraging other open source

products, harvesting specific
application project work for
general consumption

Industry Standards Migration or adoption of new

standards

Project Standardization Naming standards, configuration

parameters, etc.

Platform Support Support for portability to

other database, languages,
web application servers, etc.
platforms

Versioning Compatibility
 Support for backward
compatibility between Rice
versions

Accessibility Enhancements to improve

access and usability for users
with disabilities

Internationalization & Enhancements to support

localization different country standards and
languages

Effort Estimates
Each of the roadmap items has an effort estimate associated with it. Here is a description of each of
those, including example roadmap items that fall under that effort estimate.

Effort Estimate Approximate Time Example

Trivial <= 1 day KRRM-2@jira - Spring 2.5

Framework Upgrade - (assuming
it's as non impacting as we think
it's going to be)

Low <= 1 week KRRM-33@jira - Adobe PDF

Form Plug-In Support -
(assumes we are just integrating
the work that has already been
done)

Medium <= 1 month KRRM-54@jira - Support for

Derby databases and automatic
database generation in support
of development, unit testing
efforts, quickstarts, etc.

High <= 3 months KRRM-9@jira - Action List

Improvements

Epic >= 3 months KRRM-1@jira - Replace OJB with

Java Persistence API (JPA)

Planned enhancements and research

The following tables represent planned enhancements and planned research. They are organized
according to each major theme below. You can also browse the entire roadmap directly in the Kuali Jira
repository. Jira refers to enhancement requests as issues. Some of the enhancements are assigned
multiple themes. As you review the requests below you will notice that some requests are listed multiple
times under different themes.

Theme - Usability

The following Requests have been classified into the "Usability" theme. This theme represents those
things that make using Kuali software easier for end users. Examples of usability items are:
 • Ease of navigation
• Consistent error handling
• Consistent and unambiguous help system

KR - Roadmap Theme - Usability (Kuali: Jira) (8 issues)

T Key Summary
KRRM-85 Contribute Adobe Acrobat PDF
automation capability developed
at Cornell
KRRM-29 WYSIWYG Graphical Workflow
Editor
KRRM-13 Implement simple Document-
Type-based Delegation Features
KRRM-21 Finish up remaining conversion
of KEW screens to use the KNS
framework
KRRM-83 Add the KFS Database
Description Screens and
functionality to Rice
KRRM-77 Implement "Remove/Replace
Principal" functionality
KRRM-16 Improved Error Handling and
User Messages
KRRM-15 Remaining improvements to
handling and consistency of
dates and timestamps

Theme - Development Ease of Use

The following Requests have been classified into the "Development Ease of Use" theme. This theme
represents changes that facilitate a Kuali software developer in the construction of Kuali applications.
Examples include"

• Quick reference and lookup

• Templates and Scaffolds
• Automated code generation

KR - Roadmap Theme - Development Ease of Use (Kuali: Jira) (3 issues)

T Key Summary
KRRM-29 WYSIWYG Graphical Workflow
Editor
KRRM-54 Support for Derby databases and
automatic database generation
in support of development, unit
testing efforts, quickstarts, etc.
KRRM-31 RIA (Rich Internet Application)
UI Frameworks

Theme - Ease of Implementation

The following Requests have been classified into the "Ease of Implementation" theme. This theme
represents change requests that make it easier to deploy Kuali software into various environments that
use a variety of different hardware and software configurations. It includes things like:

• Configuration files and global parameters

 • Parsers and ingesters
• Wrappers and API integrations

KR - Roadmap Theme - Ease of Implementation (Kuali: Jira) (8 issues)

T Key Summary
KRRM-85 Contribute Adobe Acrobat PDF
automation capability developed
at Cornell
KRRM-56 Expand support for XML import
and export of data
KRRM-70 Standardize Configuration
Parameter Names
KRRM-69 Standardize Service Names
KRRM-51 Rice tooling: administrative tools
for all Rice components (KEW,
KIM, BRMS etc). Generalizes
KRRM-29
KRRM-50 A consistent documentation
framework for all Rice
components (see KRICE
Documentation)
KRRM-41 Federated Identity Management
Services
KRRM-23 Implement a user interface
for making changes to various
aspects of the Data Dictionary

Theme - Modularity

Rice strives to create code that is modular. This results in many benefits including:

• Loose coupling of components for flexible design

• Reusability
• Swappability

KR - Roadmap Theme - Modularity (Kuali: Jira) (9 issues)

T Key Summary
KRRM-84 Investigate how KIM can be
modularized to run standalone
KRRM-60 Complete the API module of Rice
KRRM-70 Standardize Configuration
Parameter Names
KRRM-69 Standardize Service Names
KRRM-57 Remodularize the Kuali Nervous
System (KNS)
KRRM-65 Plan for RICE components
to interact with each other
exclusively through formal
published service contracts
KRRM-59 Architecture and functionality
review of KEN
KRRM-52 Modularity (SOA+ProjectBuild
+OSGI)
KRRM-48 Modularization and delivery of
Kuali Rice web content and web
modules
 Theme - Service Orientation

The following Requests have been classified into the "Service Orientation" theme. This theme
represents change requests related to making Kuali software more service oriented by building abstract
interfaces.

• Technology neutral APIs

• Standard service operations
• Standard message protocols

KR - Roadmap Theme - Service Orientation (Kuali: Jira) (3 issues)

T Key Summary
KRRM-69 Standardize Service Names
KRRM-59 Architecture and functionality
review of KEN
KRRM-22 Implement "update" operations
for the various KIM services

Theme - Kuali Application Business Drivers

The following Requests have been classified into the "Kuali Application Business Drivers" theme. This
theme represents the functional needs of the Kuali Applications that are common amongst all the
applications. Everyone developing Kuali software should look for opportunities of making the business
functions shareable and common for all other applications. Common types of business drivers include:

• Common configuration and administrative interfaces

• Common data elements and business processes
• Common search, filter and display controls

KR - Roadmap Theme - Application Business Drivers (Kuali: Jira) (19 issues)

T Key Summary
KRRM-68 Implement proper handling of
FERPA and FIPPA regulations
KRRM-67 KFS 4.0 Bug Fixes
KRRM-7 KIM Management Screens
KRRM-13 Implement simple Document-
Type-based Delegation Features
KRRM-12 Implement Escalation
Functionality
KRRM-9 Action List Improvements
KRRM-8 Document Search Improvements
KRRM-66 KFS 4.0 KNS Enhancements
KRRM-26 Design and implement Kuali
Entity Managment (KEM)
KRRM-25 Design and implement Kuali
Organization Management (KOM)
KRRM-22 Implement "update" operations
for the various KIM services
KRRM-77 Implement "Remove/Replace
Principal" functionality
KRRM-35 Award Budget - Data
Management Services
KRRM-28 Integration support for external
Document Management Systems
KRRM-23
 Implement a user interface
for making changes to various
aspects of the Data Dictionary
KRRM-17 Extract Batch Framework from
KFS into Rice
KRRM-16 Improved Error Handling and
User Messages
KRRM-14 Improve Capabilities of Exception
Routing
KRRM-6 Batch File Scheduler and Monitor

Theme - Adopting Existing Code

The following Requests have been classified into the "Adopting Existing Code" theme. This theme
represents the desire to engage with other horizontal open source software projects and use "best of
breed" solutions, integrate them into Kuali Rice, and participate in those community's. This direction
provides the following benefits:

• Minimizes the Rice code footprint that needs to be supported and maintained.
• Maximizes the amount of our community effort that goes into meeting the unique needs of our
community.
• Increases Rice's resilience to technology trends as diverse communities evolve their components
• Reduces risks
• Increases the potential pool of talent who will be able to contribute to Rice

KR - Roadmap Theme - Adopting Existing Code (Kuali: Jira) (7 issues)

T Key Summary
KRRM-59 Architecture and functionality
review of KEN
KRRM-30 DROOLS Business Rule
Management System
KRRM-58 Convert KEN user interfaces to
use the KNS
KRRM-36 BPEL / BPM Integration and
Support
KRRM-18 Extract and consolidate "Portal"
frameworks from KFS, Rice, etc.
into a shared framework for
creating our portals
KRRM-17 Extract Batch Framework from
KFS into Rice
KRRM-4 Replace KSB with alternative ESB

Theme - Industry Standards

The following Requests have been classified into the "Industry Standards" theme. This theme represents
opportunities to leverage new or emerging standards that make Kuali software interoperable with other
systems and software. Examples of Industry Standards include:

• HTML5, AJAX, Java FX, etc.

• Java 6
• REST, SOAP, WS-*, etc.
• XML, SQL, etc.
 KR - Roadmap Theme - Ease of Implementation (Kuali: Jira) (8 issues)
T Key Summary
KRRM-85 Contribute Adobe Acrobat PDF
automation capability developed
at Cornell
KRRM-56 Expand support for XML import
and export of data
KRRM-70 Standardize Configuration
Parameter Names
KRRM-69 Standardize Service Names
KRRM-51 Rice tooling: administrative tools
for all Rice components (KEW,
KIM, BRMS etc). Generalizes
KRRM-29
KRRM-50 A consistent documentation
framework for all Rice
components (see KRICE
Documentation)
KRRM-41 Federated Identity Management
Services
KRRM-23 Implement a user interface
for making changes to various
aspects of the Data Dictionary

Theme - Project Standardization

The following Requests have been classified into the "Project Standardization" theme. This theme
represents changes that make Kuali Rice software more consistent and efficient. It includes things like:

• Naming conventions
• Documentation standards
• Standards for messaging and error handling

KR - Roadmap Theme - Project Standardization (Kuali: Jira) (5 issues)

T Key Summary
KRRM-70 Standardize Configuration
Parameter Names
KRRM-21 Finish up remaining conversion
of KEW screens to use the KNS
framework
KRRM-75 Consolidate Notes and
Attachments between KNS and
KEW and KS
KRRM-61 Convert the KSB User Interfaces
to use the KNS
KRRM-58 Convert KEN user interfaces to
use the KNS

Theme - Platform Support

The following Requests have been classified into the "Platform Support" theme. This theme involves
changes that facilitate interoperability with common hardware and software products that Kuali software
runs on top of. It includes:

• Operating Systems like CentOS, Linux, Unix, Windows, etc.

 • Web Applications Servers like WebSphere, Apache, JBoss, etc.
• Database Management Systems like Oracle, MySQL, MS SQL Server, DB2, etc.

KR - Roadmap Theme - Platform Support (Kuali: Jira) (1 issues)

T Key Summary
KRRM-54 Support for Derby databases and
automatic database generation
in support of development, unit
testing efforts, quickstarts, etc.

Theme - Versioning Compatibility

The following Requests have been classified into the "Versioning Compatibility" theme. This theme
includes changes that facilitate interoperability between various Kuali software products. It includes both
framework compatibility and product compatibility like:

• Backward compatibility for earlier versions of Kuali Rice

• Cross product compatibility between Rice and KFS, KS, and KC
• Compatibility support for different versions of Java (i.e. Java 5 and Java 6)
• Compatibility for multiple types of web browsers (i.e. MS IE, Safari, Firefox, etc.)

KR - Roadmap Theme - Versioning Compatibility (Kuali: Jira) (6 issues)

T Key Summary
KRRM-81 Rice Version Compatibility
KRRM-60 Complete the API module of Rice
KRRM-2 Spring 2.5 Framework Upgrade
KRRM-70 Standardize Configuration
Parameter Names
KRRM-69 Standardize Service Names
KRRM-47 Upgrade underlying web
framework used by the KNS
(Struts)

Theme - Accessibility

The following Requests have been classified into the "Accessibility" theme. Accessibilty includes changes
that help ensure Kuali Rice software complies with regulations regarding support for individuals with
disabilities. It includes:

• Features for site impaired individuals

• Features for auditory impaired individuals
• Alternative input and output methods

KR - Roadmap Theme - Accessibility (Kuali: Jira) (1 issues)

T Key Summary
KRRM-3 Accessibility Standards
Theme - Internationalization and Localization

The following Requests have been classified into the "Internationalization and Localization" theme. This
theme represents changes necessary to help deploy and use Kuali Rice software in locations outside of
the United States with support for different languages and country conventions. It includes things like:

• Support for different language character sets

• Screen sizing conventions
• Conversions for units of measures
• Cultural considerations

KR - Roadmap Theme - Internationalization (Kuali: Jira) (1 issues)

T Key Summary
KRRM-82 Internationalization and
Localization Features
KRICE Kuali Rice : 2009 Roadmap - Release Plans

Rice Release 1.1

Key Themes for Release 1.1: Version Compatibility, Modularity, Ease of Implementation, Kuali
Application Business Drivers, Industry Standards, Usability.
Assumptions:

• September 2010 Release Date

• 850 developer hours per month capacity
• 50% of capacity, 3825 developer hours, available for roadmap work (5% reserved for work on
1.0.x, 20% reserved for bug fixes in prior releases, 25% reserved for QA work on 1.1)

KR - Roadmap for v1.1 (Kuali: Jira) (9 issues)

T Key Summary
KRRM-60 Complete the API module of Rice
KRRM-81 Rice Version Compatibility
KRRM-56 Expand support for XML import
and export of data
KRRM-2 Spring 2.5 Framework Upgrade
KRRM-7 KIM Management Screens
KRRM-1 Replace OJB with Java
Persistence API (JPA)
KRRM-68 Implement proper handling of
FERPA and FIPPA regulations
KRRM-84 Investigate how KIM can be
modularized to run standalone
KRRM-85 Contribute Adobe Acrobat PDF
automation capability developed
at Cornell

Rice Release 1.2

Key Themes for Release 1.2: Modularity, Development Ease of Use, Usability, Kuali Application
Business Drivers, Ease of Implementation, Service Orientation, Version Compatibility.

Assumptions:

• April 2011 Release Date

• 850 developer hours per month capacity
• 50% of capacity, 3000 developer hours, available for roadmap work (5% reserved for work on
1.1.x, 20% reserved for bug fixes in prior releases, 25% reserved for QA work on 1.2)

KR - Roadmap for v1.2 (tentative) (Kuali: Jira) (8 issues)

T Key Summary
KRRM-57 Remodularize the Kuali Nervous
System (KNS)
KRRM-29 WYSIWYG Graphical Workflow
Editor
KRRM-12 Implement Escalation
Functionality
KRRM-9 Action List Improvements
KRRM-8 Document Search Improvements
KRRM-70 Standardize Configuration
Parameter Names
KRRM-69 Standardize Service Names
KRRM-13 Implement simple Document-
Type-based Delegation Features
Rice Release 2.0

Key Themes for Release 2.0: Development Ease of Use, Platform Support, Kuali Application Business
Drivers, Service Orientation, Ease of Implementation, Modularity, Internationalization, Industry
Standards, Usability, Project Standardization, Adopting Existing Code.

Assumptions:

• April 2012 Release Date

• 850 developer hours per month capacity
• 50% of capacity, 5100 developer hours, available for roadmap work (5% reserved for work on
1.2.x, 20% reserved for bug fixes in prior releases, 25% reserved for QA work on 2.0)

KR - Roadmap for v2 (tentative) (Kuali: Jira) (13 issues)

T Key Summary
KRRM-66 KFS 4.0 KNS Enhancements
KRRM-54 Support for Derby databases and
automatic database generation
in support of development, unit
testing efforts, quickstarts, etc.
KRRM-52 Modularity (SOA+ProjectBuild
+OSGI)
KRRM-50 A consistent documentation
framework for all Rice
components (see KRICE
Documentation)
KRRM-22 Implement "update" operations
for the various KIM services
KRRM-82 Internationalization and
Localization Features
KRRM-59 Architecture and functionality
review of KEN
KRRM-30 DROOLS Business Rule
Management System
KRRM-26 Design and implement Kuali
Entity Managment (KEM)
KRRM-25 Design and implement Kuali
Organization Management (KOM)
KRRM-21 Finish up remaining conversion
of KEW screens to use the KNS
framework
KRRM-65 Plan for RICE components
to interact with each other
exclusively through formal
published service contracts
KRRM-51 Rice tooling: administrative tools
for all Rice components (KEW,
KIM, BRMS etc). Generalizes
KRRM-29

All Unplanned Future Enhancements and Research

KR - Roadmap - Not currently planned for release (Kuali: Jira) (41 issues)
T Key Summary
KRRM-77 Implement "Remove/Replace
Principal" functionality
KRRM-75 Consolidate Notes and
Attachments between KNS and
KEW and KS
KRRM-83 Add the KFS Database Description
Screens and functionality to Rice
KRRM-41 Federated Identity Management
Services
KRRM-35 Award Budget - Data Management
Services
KRRM-23 Implement a user interface for
making changes to various aspects
of the Data Dictionary
KRRM-17 Extract Batch Framework from KFS
into Rice
KRRM-16 Improved Error Handling and User
Messages
KRRM-74 Implement Referential Integrity on
KEW database tables
KRRM-62 Transitioning of Service Contracts
to Independent Product
Deliverables
KRRM-58 Convert KEN user interfaces to use
the KNS
KRRM-48 Modularization and delivery of
Kuali Rice web content and web
modules
KRRM-36 BPEL / BPM Integration and
Support
KRRM-31 RIA (Rich Internet Application) UI
Frameworks
KRRM-28 Integration support for external
Document Management Systems
KRRM-18 Extract and consolidate "Portal"
frameworks from KFS, Rice, etc.
into a shared framework for
creating our portals
KRRM-15 Remaining improvements to
handling and consistency of dates
and timestamps
KRRM-14 Improve Capabilities of Exception
Routing
KRRM-3 Accessibility Standards
KRRM-63 Work towards a common User
Interaction Model (UIM)
KRRM-61 Convert the KSB User Interfaces to
use the KNS
KRRM-47 Upgrade underlying web
framework used by the KNS
(Struts)
KRRM-45 RESTful service architecture
KRRM-44 Security Metadata - Data
Dictionary enhancements
KRRM-39 Application Connectors
KRRM-38 JMX - Java Management
Extensions Support
KRRM-37 RSS Support
KRRM-34 KIM Integration with Internet 2
Grouper product
KRRM-32 Mobile Application Support
KRRM-27 Support for different DBMS
platforms
KRRM-24 Add support for "versionable"
documents
KRRM-4 Replace KSB with alternative ESB
KRRM-72 Continued enhancement of Kuali
Rice sample applications
KRRM-53 Support for building JSR 168/JSR
286 Portlet applications
KRRM-42 Common Data Warehouse / Marts
KRRM-40 Directory / Registry Integration
KRRM-64 Work on a strategy for User
Interface that can leverage a
common dictionary service model
KRRM-33 Adobe PDF Form Plug-In Support
KRRM-19 Navigational Improvements in the
KNS
KRRM-6 Batch File Scheduler and Monitor
KRRM-43 Common BI and Reporting Support