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 (http://www.kuali.org/communities/kra/)
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 (http://www.kuali.org/communities/kra/)
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
Coeus Lite - Look & Feel
Kuali - 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
– https://test.kuali.org/confluence/display/KRAC
OEUS/Technical+Gap+Proposals
• Functional Gaps
– Confluence
– https://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:
https://test.kuali.org/confluence/display/KRACOEUS/Gap
+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
(https://test.kuali.org/confluence/display/KRACOEUS/KRA+Workflow+Gap+
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
Example - Workflow
Example - Workflow
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 fullfeatured 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
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
• http://www.kuali.org/communities/kra/
•
•
•
•
Terry Durkin - tdurkin@indiana.edu
Bryan Hutchinson - bh79@cornell.edu
Andrew Slusar - as833@cornell.edu
Sabari Nair - snair@MIT.EDU