Sunday, June 13, 2010

Migrating to a New Student Information System

Student Information Systems (SIS) are likely the most important database on
campus. Even if they don=92t do accounting, or fund-raising, they still han=
dle
the information and the work flow processes that are at the heart of the
school=96 who are the families and the students, and what are their courses
and schedules, and then reports, transcripts, attendance, and more.

We=92ve been working on a transition to a new SIS for two years. Year one w=
as
researching all possible database solutions, including continuing to work
with our current system. We reviewed 13 different options, and had full
sales pitches from eight, and had a nice spreadsheet showing pros and cons
of each. I can=92t offer up that sheet online , since the numbers and costs
and estimates were part of private conversations with the vendors, but at
the end of the process we had a pretty good idea of where we needed to go.

We=92ve had an in-house built FileMaker Pro 6 SIS for ten years. It was a
great solution in many ways, because our in-house database developer could
add wings off the system, and new reports, and new fields and functionality
at will. The downside was that the system became so large that it became to=
o
difficult to upgrade on a consistent cycle. Secondly, FileMaker Pro 6 force=
d
us to use interlinked database files (we reached about 200) that could only
be opened in clusters, meaning that you could only open parts of the
database at once, and we also had multiple user lists, meaning that people
like myself were in the system multiple times (once as a parent, once as a
staff member, etc.).

In 2004, FileMaker Pro 7 was released, which enabled a unified database
structure (not 200 interlinked files), but the problem was that all of the
previous development work would have to be broken and rebuilt again to do
the upgrade (about a year=92s worth of work, with a new employee to cover
regular database needs). However, there was a concern that even on FileMake=
r
7, 8, 9, 10, 11, we could have the same growth and renewal problems. Also,
we would be building a full system based on only one school, and pretty muc=
h
only one developer.

So, for six years, the school stayed on FileMaker 6, and each year we were
concerned if Filemaker 6 would continued to run on the newer versions of OS
X. In fact, we=92re having problems on Snow Leopard at the moment with it=
=85

To summarize, the school was used to a customized, easily changeable system=
.
Those of you who have any of the big SIS systems from the main vendors
probably know that =93easily customized and changeable=94 isn=92t an easy r=
oad.

Our choice was Veracross <http://www.veracross.com/>, because of its
customization ability. The system can be customized school by school becaus=
e
of the way the do their the interface layers. Now, not all customizations
are simply and fast, and new modules (such as the Transportation module we
are having them build) are not free, but at least we have options going
forward. Most importantly, it is a unified database with solid web
interfaces for faculty, staff, parents and students that can be developed.
Over time, we will fold in more modules that we need for counseling and
other services into the unified system.

So, this year we started doing scripted exports of nearly all data out of
FileMaker Pro 6, and documenting the data as best possible. These scripts
are repeatable, so that when we do the real, final export at the end of thi=
s
month, the same format with be retained but it will produce the latest data=
.
Veracross has been working for several months on scripting theloading of th=
e
data into our Veracross system, and making changes as necessary to
accommodate our data fields and structures we need. We are primarily moving
to the logic used within the Veracross system (single user database,
de-duplication routines), but they still need to know our special data
management and analysis routines.

What will happen at the end of this month is that we will roll our database
(sixth graders become seventh graders, etc.), export the final sets of data
from the entire system, move our local system into read-only mode, and then
Veracross will take our data for two weeks of scripted imports into
Veracross (based on the scripts written over the past few months) and then
de-duplicate and clean up our data (to achieve unification from the current
disparate sources).

A great example of de-duplication is the problem of emergency contacts. In
most system, emergency contacts in the SIS are =93hanging records=94 about
individuals who may have no other contact with the school. The bad part is
that many or most emergency contacts are actually other parents, but the
demographics entered for emergency contacts are never tied to the
demographics in the parent records. Thus, phone numbers may change in one
place, but not change in another. The Veracross system should de-duplicate
the data (ether automatically or with human intervention), so that parents
who appear as emergency contacts become =93blue and underlined=94 and have =
their
demographic data linked in both areas of the database, meaning a change to
one automatically changes the other.

The other thing the Veracross system offers is ability for parents to
directly update their demographic data online. The changes are directly
processed into the system with no delay, but there is nightly polishing
systems to clean up the data entry to school standards (ave. may be changed
to Avenue). There are also change reports for the school to see all the
online changes made, and roll-back the data if something is amiss. In fact,
much or most of the entire system has an audit log, so that previous values
can be seen and rolled back if needed. Our current system doesn=92t have th=
at,
and accidental changes means going to back ups to see what the data used to
be.

However, the flexible reporting in FileMaker posed a problem for the
transition. Users are used to centralized, heavily customized reports (like
class photo lists, labels for school events, and customized and stylized
reports for over 100 occasions). Veracross can do this for major reports
(like transcripts, report cards, etc.) and generic reports of data, but not
for dozens and dozens of uniquely customized and formatted reports, which
often need minor adjustments all the time. To side-step this issue, will
will continue to use FileMaker 11 as a type of Crystal Reports for users.
Using the API of Veracross, we will have a =93mothership=94 FileMaker 11
database continually updating core data-sets to our server room for use for
local databases. (Veracross is a hosted system running out of RackSpace dat=
a
centers). Thus, FileMaker 11 will be on users desktops, with a single menu
for a range of in-house built and customized reports. (Core reports will
stay in Veracross.)

Using the local data store,we will also post-process data for other exports=
,
such as to Moodle, Destiny, Catering and Security systems. Secondly, the
local data store should give us enough information to be an emergency
fall-back in case our cross-Atlantic connectivity to Veracross was
interrupted for any significant length of time. Most of us could run on
paper for a few days if needed, and the local data store could facilitate
that.

Okay, that=92s enough for now. Wish us luck=96 this is going to be a major
change. As noted in our planning, we will lose some functionality and ways
of doing things because of this transition, but the real value will be in
the ways a unified system should help use enable better use and management
of the data. Also, the system is designed to enable users to become more
sophisticated in their use of information outside of the database, such as
in the creation of Word merges that can be integrated back in the user
interface. A web interface will be used by nearly all faculty, students and
parents, but most staff users will use both the web interfaces and a light,
local client.

Jim Heynderickx, Director of Technology, American School in London

[ For info on ISED-L see https://www.gds.org/podium/default.aspx?t=3D128874 ]
Submissions to ISED-L are released under a creative commons, attribution, non-commercial, share-alike license.
RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=3DISED-L