Taking Stock of Your Integrations

By Criss Laidlaw posted 02-01-2017 09:07 AM


This is the first in a series of blog articles to be published by the HEUG Board of Directors, Integrations Work Group.  We hope that these articles inspire and encourage member institutions to think carefully about integrations and the necessary practices and disciplines needed to manage them effectively.  Comments, questions and healthy debate are all welcomed.

If your institution is thinking of moving a core application to a cloud platform, it is essential that you thoroughly understand the number and the nature of integrations (aka interfaces) affected by such a change.

Virtually all colleges and universities routinely exchange information by means of integrations to provide academic transcripts; update learning management systems; manage meal plans; facilitate financial transactions, provide benefits and payroll services; procure goods; refresh data warehouses; provision student accounts; send bills; receive tuition payments; comply with federal and state requirements, and much, much more.

In today’s interconnected world, the number of integrations that an institution depends on can easily number in the hundreds.  A college or university student records system serves as a hub for many integrations. The same is true for human resources, financial and other systems.

Integrations take many forms and have many attributes, including method of transport, direction, timing, information content, information structure, encryption, conflict resolution rules and, of course, the system or partner at the other end.  

Integration transport methods include on-premise, inter-application database links, web services transferring information in near-real-time between on- and off-premise applications, and transfers of data in flat file formats via SFTP.  An integration may even be as basic as walking a USB thumb drive across campus and delivering it to the recipient.

Integration direction may be incoming, outgoing or bidirectional.  The information content and structure may be dictated by your institution or by a vendor and may have built-in transformations of coding schemes (e.g. 1=Undergraduate, 2=Graduate), character sets and number formats. If the information is encrypted, sender and receiver must use the same encryption method.  Incoming information may conflict with information already present and the integration may need rules to resolve conflicts or at least a way to notify interested parties that a conflict exists.

While today’s cloud-based core applications vendors are unlikely to have all the integrations you need ready out of the box, they must be able to articulate a comprehensive approach to meeting your integration requirements.  The approach may involve the use of multiple products, possibly from more than one vendor.  But you can’t have a truly productive conversation with any prospective vendor unless you’ve first taken stock of your current integrations and plan for what you’ll need going forward.