KRA/KFS Integration Team
Findings and Recommendations
As of November 5, 2007
Mission of Integration Team
To recommend to the KRA and KFS Functional Council the strategic direction for
KRA/KFS integration, including identification of specific components of the integration.
This strategic direction should also facilitate future Kuali systems.
Recommendation
The Integration Team identified several entities that would be used by both systems and
that are therefore necessary for an integrated product. Attributes related to each of these
entities would be identified in order to accommodate that both KRA and KF Systems.
1. A Kuali Identity Management module will be created by Rice that provides for
the storage and cross application use of context specific, and shared, “person”
related data. Identified integration points and processes will be developed as
service APIs to be used by KRA and KFS with the intent of being used by all
Kuali applications. Person related identity and role data will be managed and
stored in this module.
2. Core, shared, data (of a definitional nature) for all “external entities” should be
managed by a simple facility or service central to all Kuali applications.
Candidates for inclusion would be those such as Sub Contractors (KFS), Sponsors
(KRA), Agency (KFS), Vendor (KFS), and KRA Organization Data. See also
item 6. It is further recommended that the consistent titling of this data should be
“External Entity”.
3. A Kuali Organization Management (KOM) module should be developed within
Rice, for maintenance of all internal organizations. This solution would provide
the ability to use a single hierarchical structure, or context specific hierarchy
structures unique to each application, but with overlapping organizational
branches. This solution would achieve technical re-use across projects. If KOM is
not built, the minimum level of integration must provide a common set of service
APIs to allow for seamless integration between the applications. A centrally
maintained hierarchy is extremely important in controlling, for example, data role
up for reports, establishing ownership of data, and accommodating workflow. It
is further recommended that the consistent titling of this data should be
“Organization” (from KFS), thus doing away with the KRA/COEUS “Unit”.
4. An object code table would exist in KFS that would be accessed by KRA. Object
Codes are data elements for which the authoritative source is the financial
function, and therefore the data are best located and maintained in the financial
system. This table needs to accommodate any additional attributes needed by
KRA.
5. Proposal data are necessary for both systems but should be maintained in KRA, as
the research administration function is the authoritative source. Certain proposal
data are necessary for financial post award administration that is managed out of
the financial system. This table will need to accommodate any additional
attributes needed by KFS.
6. Sponsor data are necessary for both system but the authoritative system should be
KRA. Certain sponsor data maintained in KRA are necessary for financial post
award administration that is managed out of the financial system. This table will
need to accommodate any additional attributes needed by KFS. Further review of
external entities should occur to see if that central table (referred to in Item 2
above) can accommodate Sponsor. NOTE: This analysis was done during
the10/23 meeting, and we agreed that Sponsor should be accommodated.
7. Research Administration may require a separate mapping process for object codes
for proposal budgets. KRA calls these budget categories and KFS calls them
levels. The Integration Team recommends that KRA and KFS budget subcommittee review the best process for accommodating separate mapping while
maintaining the integrity of financial data for financial reporting purposes.
Summary
The seven recommendations made at this time by the Integration Team are considered to
be necessary for an integrated product. In addition to the specific recommendations the
Integration Team has been tasked with looking at the details of each of the above entities
to determine more detailed data and functional requirements. The technical teams for
KRA, KFS and RICE will examine these specifications to determine the best actual
solution for the long and short terms given resource constraints and timing.