Skip to end of metadata
Go to start of metadata

Introduction

The Kuali Rice Charter specifies that the  Application Roadmap Committee is responsible for defining the overall Kuali Rice Project Roadmap. That includes defining both functional and technical requirements along with expected timelines for development. Technical enhancements and requirements will be submitted to the ARC from the Technology Roadmap Committee (TRC)to be prioritized 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.

ARC and PROJECT Team Calendar of Events

Calendar

5 Comments

  1. Notes from discussion with Cath...

    Still need to make it clear that this roadmap is about Rice, not about the applications. There's some ambiguity about the boundaries of Rice itself. Org is an example, student awards is another. Are these part of Rice?

    Possibly improve the diagram to show the relationship of Rice to the applications and the boundaries of Rice.

  2. The Introduction and Vision sections all seem to be going in the right direction from my perspective.  So, I don't have much to add there other than to say I agree with how we're headed here.

    I really like the visual in the background section.  A picture speaks a thousand words in this case.  It would be nice if you could click on the blue boxes and get more detailed information about those particular Rice components.  If we plan to share the roadmap with the public, it would be helpful.  I like the general layout and organization of this diagram - very helpful in understanding what Rice is about.  I agree with the comment about also trying to show the relationship of Rice to the other Kuali applications.  That would be helpful as well.

  3. A few comments on this page:

    1.  Under the Introduction section, fourth paragraph first sentence it describes the "2009 Kuali Rice Roadmap".  What is the life of what we are developing?  Does 2009 describe it appropriately or will this send a message to the audience of the document that a new roadmap will come out in 2009?  What if we just called it the Kuali Rice Roadmap without a year assigned?

    2.  Under the Vision section, first sentence it should say "colleges and universities", not just universities.

    3.  Also under Vision should we consider adding a bullet that speaks to the achievement of efficiencies and consistencies in structure and use of data across all Kuali applications?  I understand Cath's concerns that the roadmap is about Rice, but Rice is about the applications.  Possibly the bullet could read "To gain efficiency in data structures while providing a frame that will enforce consistency of data across all Kuali applications for implementing institutions."

    4.  The background section, first sentence, makes the Rice project sound as if it just started in April 2009.  Such a significant change in April 2009 might be scary to the audience so if we can somehow quickly outline the history of Rice in the context of the 2009 charter it might provide good clarity.  Unfortunately I have no suggestions on how to achieve this.

    Chris, I am not sure if you wanted people to directly edit the document or just provide the comments in the comments section.  I haven't used this tool much in the past. 

     A final comment is that I am not sure we are describing our audience for the roadmap as well as we should.  The third paragraph of the introduction could be expanded to complete this.

    1. I've addressed #2, #4, and the last comment about audience.

      I'm struggling with comment #1 and how to address it. Right now I think we're focused on the 2009 version of the roadmap. Though these pages will live on and evolve, the document will be frozen at some point (November?), made into a PDF, presentations, etc. At that point, the pages here will begin to evolve again and represent something more than the "2009 version."

      One solution is to simply call this the "Kuali Rice Roadmap" as you suggest. I guess I'm leaning toward that, and somehow giving it a version when we create a static snapshot. What do others think?

      Regarding #3, since this comes word for word from the Rice project charter, we would need to get this submitted to the board of directors for consideration. Should we do this?

  4. I vote for calling this just "Kuali Rice Roadmap" and figure out a way to version it later.

    Regarding adding another bullet to the vision regarding structure and use of data across applications, I strongly agree with this and would advocate submitting to the Rice Board for Charter modification.  This is really what the "master data" services concept in the reference layer framework diagram is all about.