March 2002 — Special Feature

Print this article

Click here to receive your FREE subscription to T.H.E. Journal

How SIF Works

The software engineers and educators who developed the SIF Specification were drawn from companies and districts large and small, and from all across the K-12 landscape. They represented countless years of institutionalized software development and database design, and each had a vested interest in preserving the systems they helped create. But they also realized that enabling software pro-grams to "talk" to each other and share data was so important that they needed to overcome their own company-centric view of the problem. They needed to develop a solution that was flexible, scalable, reliable, secure and affordable, both for the schools as well as the vendors.

Their solution meets all of these needs with remarkable grace. The SIF Specification views a school or district as a single system of data in which the software applications make up the component parts. This logical grouping of software applications is called the SIF Zone. At the center of this Zone is a software application called a Zone Integration Server (ZIS). This program serves as the "central nervous system" of the Zone by tying together all of the applications, facilitating their communication and regulating their activities (see Figure 1: Zone Integration Server). The school's or district's technical administrator determines the manner in which a ZIS structures the Zone, including all security and authentication parameters.

Data Objects and Agents

As mentioned earlier, many of the companies that created this Specification had already invested significant resources in developing and maintaining software applications. The question was how to get each of these different, and sometimes competing, software applications to talk to each other and share data. The answer was twofold: the Data Object and the Agent. A Data Object is a standard definition of some piece of school system information. For example, a student's name, address and phone number are part of the "StudentPersonal" Data Object. By having different software programs understand this common definition of a student, it is possible for them to share this information properly. The SIF Specification currently defines 19 Data Objects, with an additional 40 Data Objects in the Draft mode, and more to be defined as the Specification evolves. By agreeing on these definitions, SIF makes it possible for software programs built on different platforms and with different database designs to share data.

How each application moves and processes these Data Objects is the job of the Agent. The list of things this Agent is required to do is documented in the SIF Specification. Because this functionality is specified in a standard format, software vendors have some choice about how this Agent functionality is added to their software applications. Some vendors have chosen to make the Agent functionality built into their application, while others have chosen to have the Agent run as a separate module or service. Regardless of how it is implemented, all Agents produce the same results, because the rules for Agent behavior are specified and agreed upon.