Coeus - KRA Migration Bryan Hutchinson - Cornell University Andy Slusar - Cornell University Terry Durkin - Indiana University Sabari Nair - MIT

Coeus - KRA Migration Background Coeus and KRA compared/contrasted How we identified gaps How we are filling gaps Convergence / Divergence Q & A

Background The vision statement from the KRA project’s successful proposal to the Andrew W. Mellon Foundation asks: “What if any and every college and university could use, without fee, an outstanding research administration system that embodies the ‘best of’ techniques and processes for research administration, while maintaining the flexibility to fit disparate institutional structures and needs? “This is entirely possible via a community source partnership to pool resources, requirements, and execution of an efficient development process. The software and community developed through this process could meet college and university needs while providing an economically sustainable path for the future.” The KRA project is the instrument to develop this software and its community. - Kuali Foundation web site (

Background A significant part of this model is the wholesale adoption of the functionality in a proven system, thereby avoiding the inertia of a “clean sheet” design. The KRA partner institutions have therefore agreed, from the outset, on the functional components that the project will deliver. The project has chosen MIT’s existing Coeus system as its baseline design. KRA will then fill in functionality missing from Coeus, update its technical architecture for easier integration with other administrative systems, and release open source software backed by the Kuali Foundation. - Kuali Foundation web site (

Coeus and KRA Compared/Contrasted History Architecture Look & Feel

Coeus and KRA - History Coeus –12 years of development –44 members in the Coeus Consortium KRA –Part of the Kuali Foundation –New Development (Startup Q1/2007 Development started July 2007) –6 Partner Schools Currently

Coeus and KRA - Architecture Coeus –Java on top of Oracle Stored Procedures –Not Service Oriented Architecture (SOA) KRA –Kuali Architecture and Rice –Database Agnostic –SOA

Coeus and KRA - Look & Feel Coeus –Coeus Premium: Swing desktop application –Coeus Lite: Web Application with functionality subset KRA –One Web Application –Standard Kuali Look & Feel

Coeus Premium Look & Feel

Coeus Lite - Look & Feel

Kuali - Look & Feel

How we identified Gaps Functional/Technical analysis of Coeus in light of KRA/Kuali Trips to MIT - small team Regular feedback loop with Sabari

Gap Analysis - Technical Technical Gaps: things that Coeus does that Kuali (Rice) cannot currently do technically Technical Gap Proposals in Confluence Examples: –Workflow –Custom Attributes

Gap Analysis - Functional Functional Gaps: Functionality that Kuali won't support regardless of technology Functionality vs. Features Rollup of Functional Decisions in Confluence Examples: –Lookup Framework –Custom Attributes –Complex UI

Functionality and Features Our mandate is to provide all of the Functionality of Coeus in KRA. When providing COEUS functionality we are seeking Functional Equivalence not an exact copy of COEUS functionality. For example KRA screens are functionally equivalent though their appearance and flow is different. The questions related to Functional Gaps often refer to how functionality is going to be delivered, focusing mainly on how to bring the Features of a rich-client system to the Web. For example, the functionality of the Unit Hierarchy is an integral component of Coeus and will remain so in KRA. Coeus provides the feature of viewing the Unit Hierarchy as a tree. This feature does not currently exist in Kuali

How we are filling gaps Process Documentation Development

Filling Gaps - Process Technical Gaps –Proposals are documented in Confluence and JIRA; the Enhancement Proposal pages in Confluence include: Technical Guide (how the enhancement will be implemented in Rice) Client Developer Guide (how a developer of an application built on Rice would make use of the enhancement). User Guide (how and end user would use the enhancement if applicable). –Presented to KRA/KFS/Rice Integration Team (Weekly Meetings) –Approved Proposals are scheduled for a Rice release

Filling Gaps - Process Functional Gaps –Regular review with Lead SME's –Decisions/Recommendations are presented to the Functional Council –Decisions that require technical implementation are taken back to the KRA development team

Filling Gaps - Documentation Technical Gaps –Confluence and JIRA – OEUS/Technical+Gap+Proposalshttps://test.kuali.org/confluence/display/KRAC OEUS/Technical+Gap+Proposals Functional Gaps –Confluence – OEUS/Rollup+of+Functional+Decisionshttps://test.kuali.org/confluence/display/KRAC OEUS/Rollup+of+Functional+Decisions

Filling Gaps - Development Technical Gaps –Upon Approval are assigned –Work is being done by both the Rice team and the KRA Team Functional Gaps –Any Functional Gap decisions that require development work are assigned to a KRA developer

Example - Workflow Workflow was discussed in depth at the KRA-Coeus Technical Task Team meeting in Boston 2/28 - 3/2/07 Following this meeting, a Gap Analysis document was developed: +Analysis+-+Workflow +Analysis+-+Workflow Both Coeus and KRA (through KEW) support workflow functionality. However they do it in different ways. As a result of the Gap Analysis, several Technical Gaps were identified, and several Functional Questions were raised.

Example - Workflow Rice Enhancement Proposals were written for the technical gaps and presented at the Rice Integration Team meeting where they were approved. JIRA Tasks to implement the proposals were assigned. Some have been completed and some are still in progress. Functional Questions were presented to the Lead SMEs who provided answers and shared information back with the larger Functional team.

Example - Workflow Technical Gap: 'Meta-Rules', 'Rules', and 'Conditions' Context: Coeus Rules can have multiple conditions combined with boolean logic, and each condition can be based on a database column, YNQ answer or a database function. Coeus has the concept of Meta Rules where individual rules are combined with ordering and if/then logic. Proposal: We can model Coeus conditions and routing rules as KEW rules if we make some modifications to the framework. See Implementation Discussion for more info ( Discussion#KRAWorkflowGapDiscussion-implementationdiscussion ). Discussion#KRAWorkflowGapDiscussion-implementationdiscussion

Example - Workflow Technical Gap: 'Multiple Approvals' Context: Coeus prompts the user, when they get their first approval request, if they are going to get future approval requests and allows them to choose to receive these requests or bypass them (opposite of ignorePrevious KEW configuration where system determines if user gets future requests based on static configuration.) Proposal: We could do routing report and look for user in those, then prompt if necessary & pass flag to KEW if this action should stand in for future action requests (the flag to KEW is the enhancement).

Example - Workflow Technical Gap: 'Inbox - View Resolved Gap' Context: Coeus shows users both pending and resolved items in their Inbox (Action List equivalent) Proposal: Enhancement Show Resolved items in action list, perhaps as a separate tab (this is the same thing as the My Outbox enhancement request described in Workflow Document Search Enhancement Request.)

Example - Workflow

Functional Questions Context: Coeus contains a nice UI to maintain Routing and Notification Rules and Meta Rules, while most of the workflow configuration for KEW is done in XML. Rules can be maintained via a web UI in KEW, but it is not as nice or full- featured as Coeus. Question: How much of the existing Routing Maintenance UI In Coeus Premium should be kept?

Example - Workflow Question: Can we deliver version 1 of KRA without the fancy UI and depend on the XML configuration in KEW, and then include the Rule Maintenance UI improvements in a later release? Proposal: Stick with the existing KEW XML configuration for Phase 1 of KRA, and then deliver a more full-featured UI that is similar to Coeus Premium (allowing for differences between desktop and web clients) in a later Phase. This will allow us to concentrate on functionality first and features later.

Example - Workflow Implications: –If we stick with existing KEW XML configuration for Phase 1 of KRA, there will be more technical expertise and possibly more training/documentation required for implementing schools, however, it reduces the demand on the development team and allows them to concentrate on replicating Coeus Functionality. –If we need to implement a more complex UI in Phase 1, this will take developer resources away from replicating other Coeus functionality (Reality Triangle). Decision: We will move ahead using the KEW XML based configuration for Phase 1. A more advanced Workflow configuration UI (similar to Coeus) will be deferred until Phase 2.

Example - Workflow

Convergence / Divergence The Plan: At some point these products should merge. What is our migration strategy? Until that happens, how do we keep KRA and Coeus from diverging? Can we pro-actively help these two products converge?

Migration Strategy Keep the Coeus database structure largely intact –Minimize table changes –Create views to help maintain backwards compatibility Develop migration scripts to help Coeus schools migrate to KRA

Managing Divergence Coeus has regular releases, and these aren't slowing down, nor should they at least for now KRA needs to have a complete functional release that can be implemented to show we're legitimate We need to keep track of new Coeus releases and manage which features get put into KRA Meeting at MIT in September reviewing Coeus 4.3 functionality Future –Joint design –KRA team members actively monitor Coeus enhancement requests

Proactive Convergence KRA replacing Coeus Lite Maintain shared db to make sure both KRA and Coeus can run on top of any database changes KRA makes Keep Coeus database as much intact as possible Develop future Coeus modules using Kuali architecture / Rice framework Sabari's offshore team helping port grants.gov to KRA / Kuali architecture / database agnostic code In the future we will need to develop migrations scripts for Coeus schools to migrate to KRA

Q & A Questions?

Contact Terry Durkin - Bryan Hutchinson - Andrew Slusar - Sabari Nair -