Coeus - KRA Migration

1
Coeus - KRA Migration

• Bryan Hutchinson - Cornell University
• Andy Slusar - Cornell University
• Terry Durkin - Indiana University
• Sabari Nair - MIT

2
Coeus - KRA Migration

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

3
Background

• The vision statement from the KRA projects
  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/)

4
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 MITs 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/)

5
Coeus and KRA Compared/Contrasted

• History
• Architecture
• Look Feel

6
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

7
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

8
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

9
Coeus Premium Look Feel
10
Coeus Lite - Look Feel
11
Coeus Lite - Look Feel
12
Kuali - Look Feel
13
Kuali - Look Feel
14
How we identified Gaps

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

15
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

16
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

17
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

18
How we are filling gaps

• Process
• Documentation
• Development

19
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

20
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

21
Filling Gaps - Documentation

• Technical Gaps
• Confluence and JIRA
• https//test.kuali.org/confluence/display/KRACOEUS
  /TechnicalGapProposals
• Functional Gaps
• Confluence
• https//test.kuali.org/confluence/display/KRACOEUS
  /RollupofFunctionalDecisions

22
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

23
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/d
  isplay/KRACOEUS/GapAnalysis-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.

24
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.

25
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/KRACOEU
  S/KRAWorkflowGapDiscussionKRAWorkflowGapDiscus
  sion-implementationdiscussion).

26
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).

27
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.)

28
Example - Workflow
29
Example - Workflow
30
Example - Workflow
31
Example - Workflow

• Functional Questions
• ContextCoeus 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?

32
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.

33
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.

34
Example - Workflow
35
Example - Workflow
36
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?

37
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

38
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

39
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

40
Q A

• Questions?

41
Contact

• http//www.kuali.org/communities/kra/
• Terry Durkin - tdurkin_at_indiana.edu
• Bryan Hutchinson - bh79_at_cornell.edu
• Andrew Slusar - as833_at_cornell.edu
• Sabari Nair - snair_at_MIT.EDU