Interfacing vs. Integrating

Speak with almost any campus technologist in higher education today about how a chosen system is employed and how end-users interact with it, and the answer will likely be the same: product X meets the needs of their office and serves a specific function, but ultimately there's a weakness when it comes to natively combining the information it provides with other processes for their department. Sharing data is often a manual and time consuming process. 

The concept that System A integrates with System B (new or existing) requires much more internal coordination than simply tying interfaces together logically. Even if one system can generate the necessary data elements and a second system consume the data, how does one make the determination that the two systems are "integrated?"

It takes a broader conversation to ensure that each office or department on campus that relies on each system has agreed to follow specific workflows to ensure that data in System A clearly represents how data in System B is used and vice versa. Often, integration efforts fall short in execution if changes to process are required or if business rules are not made clear to every user that interacts with each system.

Satellite applications often only provide data in silos. In such cases, these applications are more likely to present information than offer insight. However, if business process consciously drives integration, the opportunity to augment how an institution functions has a much greater chance to succeed. Any project that focuses first on the business use cases to help drive deep integration will always be more successful than one that simply stands up a system in a vacuum.