Transcript Kuali PowerPoint

Coeus/KRA Technical Topics
Andy Slusar,
KRA Project Manager
(Cornell)
Bryan Hutchinson,
KRA Development Manager
(Cornell)
Terry Durkin,
KRA Development Manager
(Indiana University)
Coeus/KRA Technical Topics
•
•
•
•
•
•
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 Participation on KRA
• KRA Board
– Steve Dowdy
MIT
Voting Member
– Terri-Lynn ThayerCoeus/Brown Voting Member
– Tim Schleicher
Johns Hopkins Ex-Officio Member
– Jen Flach
Coeus
Ex-Officio Member
• KRA Functional Council
– Steve Dowdy
MIT
Voting Member
– Tim Schleicher
Johns Hopkins Member
– Jen Flach
Coeus
Member
• KRA Technical Council
– Sabari Nair
Coeus
Voting Member
• KRA Development Team
– Rajeev Mancheril
Former Coeus Developer
– Geo Thomas
Former Coeus Developer
• KRA Subject Matter Expert Teams
Functionality and Features
• The KRA 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 focus has been how to bring the Features of a richclient system to the Web.
Coeus and KRA
Compared/Contrasted
• History
• Architecture
• Look & Feel
Coeus and KRA - History
• Coeus
– 12 years of development
– 46 members in the Coeus Consortium
• KRA
– Part of the Kuali Foundation
– New Development (Startup Q1/2007
Development started July 2007)
– 7 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
Approach to Incorporating Coeus
Functionality in KRA
• Functional/Technical analysis of Coeus (lite and
premium) in light of KRA/Kuali
• KRA Functional and technical team trips to MIT
• Regular involvement of Steve Dowdy, Sabari
Nair, Jen Flach, Tim Schleicher, Rob Yetter and
other Coeus Subject Matter Experts (SMEs).
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
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 - 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
• 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.
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.
Filling Gaps
• Rice Enhancements for KRA Release 1.0
– 19 Enhancements Proposed
– 17 Approved, 1 Deferred for KIM, 1 Not needed based on
existing KEW functionality
– 15 Development Complete, 2 In Process
• Functional Questions
– 18 Decisions based on initial gap analysis, some of
which led directly to Rice Enhancements
– Continuing dialog via Lead SME/LBA/DM meetings
Convergence / Divergence
• Long-term proposal: Coeus and KRA
products merge into one.
• What is our upgrade path?
• Until the product merge, how do we keep
KRA and Coeus from diverging?
• How can we pro-actively help these two
products converge?
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
• Future
– Joint design
– KRA team members actively monitor Coeus enhancement requests
Proactive Convergence
• Proposal: KRA as a replacement for Coeus Lite
• Maintain shared db to make sure both KRA and
Coeus can run on top of any database changes
KRA makes
• Develop future Coeus modules using Kuali
architecture / Rice framework
• Coeus’ offshore team helping port grants.gov to
KRA / Kuali architecture / database agnostic code
Upgrade Path Strategy
• Keep the Coeus database structure largely
intact
– Minimize table changes
– Create views to help maintain backwards
compatibility
• Develop scripts to enable a seamless
upgrade for Coeus Institutions to KRA
For Further Information
•
http://www.kuali.org/communities/kra/
– General KRA Information
•
https://test.kuali.org/confluence/display/KRADOC/Home
– KRA Documentation
• Contacts:
– Andrew Slusar - [email protected]
– Bryan Hutchinson - [email protected]
– Terry Durkin - [email protected]
Questions?