Guidance Memo on Custom and Configuration-Specific Functionality

Membership Guidance Memorandum

Custom and Configuration-Specific SIF Functionality

It has come to the attention of the Association, both via end users and implementers, that technical design and implementation issues are arising that impede our global attempt to increase "out of the box" interoperability using SIF. While occurrences of these issues are not new or unique, it has become a task for the Association to bring these issues to light with the membership and the marketplace as a whole. This memorandum will serve as the first in a series of notices that highlight best practices and provide guidance that both reflect the "spirit" of SIF and address the needs of the entire SIFA community.

The SIF specification is defined to facilitate data sharing and reporting between applications in the pK-12 administrative and instructional environments. It enables interoperability between applications by defining both a physical, XML-based data model for representing pK-12 data, and an infrastructure for communicating that data between SIF-enabled applications reliably and securely. The purpose of the open publication of the SIF specification is to promote transparency by enabling both developers and end users to understand the SIF data model and transport capabilities.

A given SIF-enabled application typically supports and shares a subset of the SIF data model that is both applicable to the application space and that fulfills the interoperability needs of end users of the application, as well as other SIF-enabled applications with which it shares data via SIF. The needs of end users can vary considerably and many vendors take that into consideration when designing SIF-enabled applications, offering savvy end users and integrators of SIF technologies the ability to customize the data sharing capabilities of applications through any number of means, including but not limited to configurable data mappings, sharing data via user-defined SIF elements (SIF_ExtendedElements), custom "SIF" objects, and custom definitions and handling of content in elements defined by SIF. ("SIF" is and will be used in quotes to indicate SIF-like functionality that is actually an extension to SIF be it provided by a vendor or developed by an integrator or end-user configuration of a SIF-enabled application.)

While the varying needs of end users provide opportunities for innovation, the understanding of end users of specifics of various implementation methodologies varies considerably and has the potential to create unanticipated expectations about what comprises SIF interoperability. The tendency to expect complete interoperability "out of the box" has been one of the most significant ongoing challenges facing the organization. And, while configuration-specific and/or custom SIF functionality puts a powerful tool in the hands of vendors, integrators and end users alike to fulfill the diverse and changing interoperability needs of end users, the entire SIF community needs to be fully aware that these custom-defined supersets of SIF functionality benefit just that, the needs of a particular set of end users, and can depend upon a particular configuration or even a particular mix of SIF-enabled applications remaining the same over time. As configurations change and as different applications begin to share data, the functionality provided by these custom solutions can cease to be available or even lead to interoperability issues, which in turn can lead to confusion not only among end users that understandably come to perceive a custom SIF solution as a standard SIF solution, but also between vendors as they struggle with these end user expectations of custom SIF functionality being available and/or reproducible in any and all SIF-enabled applications.

As we work to increase SIF adoption in the US and around the world, the opportunities for SIFA and its members to benefit from this expansion increases, as does the chance that these inconsistencies will arise and threaten the very expansion we all seek. As such, included below are an initial set of best practices and guidance with regard to custom and configuration-specific SIF functionality that we encourage all SIFA members to understand and integrate into their own practice. In particular, the first two, documentation and communication, can be key to successful experiences with SIF, irrespective of whether custom and/or configuration-specific functionality is in place.

• Clear and Complete Documentation of what end users should expect with regard to data sharing and interoperability via SIF is already indispensable, but it is absolutely critical for any custom or configuration-specific SIF functionality in the hands of end users. Vendors should clearly document any "value-added" functionality provided via SIF or "SIF functionality" that is configuration-dependent, or any configuration capabilities in their SIF-enabled applications that can lead to custom and/or installation/configuration-specific SIF functionality. Likewise integrators that deploy and/or configure SIF-enabled applications on behalf of their clients need to document any dependencies end users should be aware of. End users need to be fully aware of any features seemingly made available by SIF specifications actually being dependent on custom deployments of SIF or "SIF" functionality, a particular mix of applications being in place, etc.

• Forthright Communication: When interoperability issues arise or end user expectations based on configuration-specific SIF or custom "SIF" functionality arise that cannot be supported by other SIF-enabled applications "out of the box," clear, forthright communication especially with end users but also between vendors is critical. It is harmful to the reputations and experiences of all involved, SIFA and SIF included, when a configuration-specific or custom feature ceases to function or does not function the same when different SIF-enabled applications are sharing data and is then accompanied by communication implying that such features would continue to function if Vendor or Application B would support SIF or "SIF" as extended by Vendor or Application A. Refer end users to the documentation previously mentioned alerting them of dependencies on custom and/or configuration-specific functionality, and communicate how, if at all, they might achieve the same or similar functionality through other means.

• Adherence to the SIF Data Model: The primary extensibility feature endorsed for the SIF data model is the use of SIF_ExtendedElements. These are application- or user-defined elements that can be added to objects defined in the SIF data model. As with any custom or configuration-specific SIF functionality, documentation and communication are key. SIF_ExtendedElements can provide great value-added benefit to end users and for installation-specific needs; they can also create and lead to proprietary dependencies between SIF-enabled applications. Moreover, as per the SIF Implementation Specifications that support them, SIF_ExtendedElements should not be used to redefine or "move" data elements that are defined elsewhere in the SIF data model. They are only intended to extend the SIF data model with data otherwise unavailable. This means that an application should not rely on a SIF_ExtendedElement on one object for convenience or whatever reason when the element is already defined in another SIF data object. If the element is needed, use the data object where it is defined. If the only way to fulfill the needs of a particular end user quickly is to violate this direction, document it accordingly, and plan to have the corresponding application updated to use the SIF data model as specified.

• You Are the SIFA Community: Never lose sight of the fact that you are SIFA and that you are the authors of SIF. Whether a vendor, integrator, end user or other SIF community member—if you are creating custom and configuration-specific or extending SIF functionality in such a way that would benefit the community as a whole, consider having it standardized by introducing it to a SIFA working group or task force. Likewise, if you find the need to work around the SIF data model for the sake of convenience, usability or general applicability, or SIF is not defining the data you need, do not hesitate to notify a SIFA working group or task force so improvements and additions can be considered.

The SIF Implementation Specification development process is an ongoing, dynamic collaborative process that allows for input from various stakeholders throughout. For the past decade SIFA has succeeded by creating a unique community of developers, integrators and end users that is collectively revolutionizing the way data is shared and the way schools operate around the world. Critical to our continued success is a firm dedication to our collaborative principles and an acknowledgment of our reliance on faithful adherence to SIF specifications as the demonstration of that dedication. We appreciate your willingness as a member of the SIFA community, whether vendor, educator or integrator, to play your vital role in this ongoing dynamic process and welcome your active participation in helping to craft our common future.