KRA/KFS Integration Team
“Guiding Principles”
July 27, 2008
1) When the idea of the KRA/KFS Integration Team surfaced during the May face to face,
the understanding was that the group would attempt to identify integration requirements
in time for their review during the August F2F, and such that they could actually be made
in concert with coding for KFS Phase IIB and/or KRA Phase IA. These changes will only
be made in this time frame if resources are available.
2) The due date for the deliverable of this team is the Face to Face meeting scheduled for
August 20-22.
3) An analysis of the integration requirements will be done from the perspective of data first,
then process. We need to identify the data that really should be in one place (e.g., a
shared table). The deliverable should be a functional spec which defines the data
required by KFS from KRA, and data required by KRA from KFS, and the data that both
systems may have in common. Secondly, we should define the time line so we can see
at what point in the process the data is required by each system. With that information,
the KFS and KRA technical teams can subsequently do a high level technical design and
produce estimates. The integration team should focus on WHAT AND WHEN. The
technical team can focus on the how.
4) As part of analyzing the data integration requirements we will need to make some type of
a “value/effort” call. At this point it will likely be important to have some idea as to the
business process requirements related to “sharing” a piece of data.
For example, there is a STATE table in both KRA and KFS. Once we know how the state
table is used in each system, and how we think it would work in a shared environment,
we would be able to answer the question, “what is the value of sharing the data from this
table in terms of greater usability of the KRA/KFS integrated product?” We might also
know a bit about the effort needed (at a very high level) to 1) share a single table; 2)
develop a service to pass updates to replicated tables, 3) develop another solution. In
this case, I’m going to guess that the STATE table would provide a low to medium value,
with a low effort required. And this last sentence would represent the type of value/effort
analysis that we need to make for every integration point.
A more complex piece of data is the Organizational Unit (KFS), Organizational Hierarchy
(KRA). The business rules and dependencies associated with sharing and updating the
institutional organizational units are likely to be complex, the attributes are also likely to
be different (e.g., the KRA table uses “levels” to express hierarchy, whereas the KFS
table uses “reports to”), and all of this structure would need to be normalized in a shared
table, and in order to have both systems actually share a new table would likely mean
coding adjustments throughout both systems. This would be an example of a high
value/high effort integration point.
However, part of the decision making has to address the institutional implications of using
two different data sets. It is certainly possible that significant internal problems could be
created if different systems used different sets of “organizations”.
5) We will not attempt, at this point, to identify the exact process logic that is required to
integrate the two modules. We will document the business requirements (and this is
necessary to determine the effort required to actually create the integration solution).
6) We need to keep in mind the rationale for the integration analysis: Implementing KRA
and KFS together should provide benefits to the schools choosing to do so. The
integration points we rank with high value should reflect this rationale.
7) In summary, the integration team will document:
1. each possible data integration point
2. the business rules associated with the need to share the data (KRA to KFS, KFS
to KRA)
3. business rules will cover when the data need to be shared (conditions and
triggers),
4. the relative value of the integration requirement (high, medium, low) assessed by
virtue of whether or not it benefits the usability of a KRA/KFS integrated product
and whether it creates institutional problems
5. a relative level of the effort required to automate the integration (high, medium,
low) assessed by virtue of the impact on changes required to the table itself (to
normalize attributes from KRA and KFS), and/or to actually code the automation