Key Software Components
There are many components that work together to make the KC system work, and they are too numerous and often too technical in nature to mention here. However, this topic aims to briefly summarize the major ones to give you a basic level of understanding that will allow you to use the KC software to accomplish tasks with confidence and success.
Currently falling under the Kuali umbrella is a core system known as Kuali Rice (KR), which is comprised of several technical modules, including Kuali Nervous System (KNS), which encompasses infrastructure components, and Kuali Enterprise Workflow (KEW), which automates routing of e-docs (electronic documents) for approval according to specified business rules. These are considered "core" modules because they depend on one another, and non-core modules and their components depend on the core, since they are necessary for other functional modules to operate. The specifications are available for institutions to develop their own interfaces to the core system modules, since any dependency of one non-core component on another non-core component is flexible to allow implementation of unique combinations of subsets via parameterization and service interface definition to meet an institution’s unique needs.
Figure 5 Kuali Rice (KR) Components and Synergy
Kuali Rice (KR) is an enterprise-class middleware suite of integrated products that make up a business application development framework for Kuali and non-Kuali applications using a modular, Service Oriented Architecture (SOA) approach with components such as workflow, notification, and user interface configuration.
Kuali Nervous System (KNS) is the underlying infrastructure code that any KC module may employ to perform its functions. KNS is functionality common to many modules. Examples include creating custom attributes, attaching electronic images, uploading data from desktop applications, lookup/search routines, and database interaction. KNS is a core technical module composed of reusable code components that provide common pieces of functionality. The KNS is a technical framework that enforces consistency in the applications that use it. It promotes adherence to the architectural principles and development standards defined by the Kuali architects. KNS also provides a stable core of development tools providing a more efficient development paradigm.
Kuali Service Bus (KSB) is a simple service bus geared towards easy service integration in an SOA architecture. In a world of difficult-to-use service bus products, KSB focuses on ease of use and integration.
KSB features Message-Driven Service Execution, Transactional Asynchronous Messaging, Synchronous Messaging, Queue Style Messaging, Topic Style Messaging, Quality of Service, Service Discovery, Reliability, Persisted Callback, Primitive Business Activity Monitoring, Spring Based Integration, and Programmatic Based Integration.
Kuali Enterprise Workflow (KEW) is the Kuali infrastructure service that electronically routes an e-doc to its approvers in a prescribed sequence, according to established business rules based on the e-doc content. It is considered a general-purpose electronic routing infrastructure or “workflow engine.” Client applications use KEW to automate and regulate the routing and approval processes for the transactions/documents they create. It starts with an e-doc that users compose in a client application such as the KC or some other Web application that requires routing and approval of documents.
KEW then routes the e-doc electronically to the attention of designated individuals, based on institutional or departmental business rules and policies. Via this centralized routing system, users can access and search for many types of e-docs from various client applications. This is accomplished from a single location, the Action List and Doc Search. The Route Log for a given document allows users to follow its progress. KEW streamlines mediated business processes across the enterprise.
Kuali Identity Management (KIM) provides central identity and access management services. It also provides management features for Identity, Groups, Roles, Permissions, and their relationships with each other. All integration with KIM is through a simple and consistent service API (Java or Web Services). The services are implemented as a general-purpose solution that could be leveraged by both Kuali and non-Kuali applications alike.
KIM services are architected in such a way as to allow for the reference implementations to be swapped out for custom implementations that integrate with other 3rd party Identity and Access Management solutions. The various services can be swapped out independently of each other. For example, many institutions may have a directory solution for identity, but may not have a central group or permission system. In cases like this, the Identity Service implementation can be replaced while the reference implementations for the other services can remain intact.
Kuali Enterprise Notification (KEN) acts as a broker for all university business-related communications by allowing end-users and other systems to push informative messages to the campus community in a secure and consistent manner. All notifications are processed asynchronously and are delivered to a single list where other messages such as workflow related items (KEW action items) also reside. In addition, end-users can configure their profile to have certain types of messages delivered to other end points such as email, mobile phones, etc.
E-doc is short for electronic document. The two terms are used interchangeably to refer to KC’s online forms that allow for the entry and selection of information. That information can then be saved for future modification by one or more designated users, each of whom may have different assigned roles in e-doc completion. E-docs can be routed to collaborators, reviewers and approvers electronically. Routing status is tracked. Records of performed actions are preserved for reference. In KC, a user initiates a “transaction” from their desktop Web browser by creating a new e-doc.
Upon saving or navigating between the various pages that make up the new e-doc (each with a separate screen), the initiator or collaborator receives immediate feedback on the validity of the document both in light of the appropriateness of data and the compliance with business rules via red error messages right on the document screen. Valid documents are routed by KEW to one or more designated Reviewers and Approvers based on the type of transaction and content of the e-doc. Fully approved transactional e-docs are sent for final disposition actions. One of those actions is to format and submit the approved document electronically to external organizations, such as Grants.gov.
Anyone who initiates, reviews or approves research administration transactions may be a user of an e-doc, including: Principal Investigators; Co-Investigators; Departmental Administrators; Departmental support staff, professional staff, and faculty; Fiscal Officers and Delegates; Deans, Directors, and Department Chairs; Institutional Review Board members; Office of Sponsored Projects Reviewers; Preparers; Aggregators; Budget Creators; Narrative Writers; FYI Viewers, etc.