The Academic Record is the “heart” of a Student Information System.
Registration and admissions feed data into the Academic Record only to be pumped back for prereq checking, degree audit, grading, fees and calculations, billing, and finally graduation and transcript production. All these subsystems access and then turn around and feed the academic record with new data.
With all those connections does it make sense to transplant this, “the heart” of a living breathing Student Information System?
Most universities opt for a BIG BANG approach when installing a new SIS, not because they want to, but because they have to. Some SIS vendors even demand you cut over completely to their systems, including Financials and HR. Even if you were not bound contractually to use their systems, the cost of designing and implementing all of those integrations becomes prohibitive. So much for “Best of Breed” and phased rollout.
EagleApps and DXtera think there is another way, a better way.
By taking the time to formally define the Academic Record as a service we can identify how data can get into the Academic Record and how it can be taken out. By aligning with established standards we found that those pathways can be succinctly defined. It doesn’t have to be a “free for all” with every subsystem just reaching in and grabbing what it wants and then updating what it thinks it should. These cleanly defined interfaces can then be leveraged for a phased rollout instead of a big bang.
Phase 1 – First Module
Whatever subsystem is your burning need, pick it, and implement it. In this example, it is the Student Accounts module. Instead of wiring the Legacy SIS directly to the new system, we wire it through this new Academic Record Service. This is not a full-fledged Academic Record Service but it processes enough information to support this single subsystem. In this case enough to generate tuition charges and assess fees.
Business users can now begin to gain confidence in the nascent beating heart of this Academic Record. Enough at least to support one subsystem.
Phase 2 – Additional Subsystems
In this phase, we enhance the Academic Record Service to include grades and program data as well as historical data. It can now pump the data needed to run degree audits and allow students to create and manage their own 4-year academic plans and produce transcripts. It also supports small back feeds, forwarding degree audit results back to the legacy SIS to support graduation.
In this phase, Business users have growing confidence that this adolescent Academic Record’s heart will be strong enough to support multiple subsystems. The beauty is that each subsystem can be phased in on its own timeline.
Phased Rollout – Step 3 – Cutover
Once key subsystems have been turned on, the registration system can now be implemented. The umbilical cord to the Legacy SIS can finally be cut.
Business users can relax because their adult Academic Record heart is now beating completely on its own.
If you want to learn more about this approach check out http://dxtera.org/solutions/eagleapps/