Guest Blog by Matt Warden, CEO, Double Line, Inc.
Editor’s Note
From time to time, we are asked to give guidance to the larger Ed-Fi Community on technical topics that can be complex or may have created confusion. We welcome these opportunities and encourage the Ed-Fi Community to reach out to us to request this clarity.
As use cases arise and as Ed-Fi grows, we know that there is room for improvement, room for clarity and guidance on some of the finer points of Ed-Fi implementation. To that end, we’ve asked Matt Warden at Double Line to give us his take on extensions to the Ed-Fi model—what to be aware of and how to best approach unique needs and use cases.
The information is highly valuable and needed to be separated into two distinct sections: Types of Extensions and Considerations When Extending. We hope you find this article to be useful, and we welcome your feedback! Please send your comments or thoughts to [email protected].
Introduction
As Ed-Fi continues to grow, we are seeing more and more use cases. The diversity of use cases naturally brings up more situations where the standard fits most but not all of the use case. A new adopter of Ed-Fi pursuing one of these use cases will be faced with a decision whether or not to extend the standard. Without past Ed-Fi implementation experience to lean on, how can a school district or state education agency factor in the long-term costs of extending Ed-Fi, and balance it against the requirements from stakeholders and a need for a momentum-building win?
In this post, we offer a framework to think about extension decisions, allowing implementers of Ed-Fi to consider the timing and long-term implications of stakeholder requirements that may require extension. The areas we consider include:
- The type of the extension: customization or expansion
- The implications on application vendor support
- The level of alignment to the Ed-Fi community, and the ability to use Ed-Fi Alliance tools and Ed-Fi Exchange solutions
- The upgrade path to new versions of the Ed-Fi Standard and Technology
Part One: Types of Extensions
The Ed-Fi Extension Framework provides a mechanism to extend the Ed-Fi Standard and Technology. Using MetaEd, extensions are defined and then automatically apply to Ed-Fi Technology assets (e.g., the Ed-Fi ODS/API, documentation) through the use of MetaEd Generators. This approach empowers Ed-Fi implementers to create extensions without significant, repetitive changes throughout the Ed-Fi Standard and Technology. This automation lowers the effort to implement extensions, but does not change the considerations when deciding to .
In our experience, there are two primary types of extensions: customizations and expansions. At times, true customization is required to meet state-mandated data collections that do not have national relevance. Separately, certain use cases require expansion of the data model beyond the current scope of the Ed-Fi Standard.
These two types of extensions have different degrees of coupling to the core Ed-Fi Standard, and they therefore have different long-term considerations.
Customization
Customization extensions involve changes that have a localized relevance to the state or school district. There is little or no expectation that other school districts or states will be interested in implementing the same fields.
Here’s an example. In this case, a school district needed a few extra fields to describe a Course, which is a core Ed-Fi domain entity. In MetaEd, this extension looks like the following. Note the keyword “additions” on the existing Course entity.
After running MetaEd generators to produce Ed-Fi ODS DDL for the extension, the CourseExtension table is produced, with a foreign key to the core Course table.
Because customizations append fields to an existing core entity, the table inherits the primary key of the existing core entity. This represents one form of coupling to the core Ed-Fi version, which can have impacts when upgrading to a new version of Ed-Fi. The second form of coupling involves element conflict. If a future version of Ed-Fi adds the same element or an element with overlapping semantics as one of the elements in the extension, some thought is required to determine how to resolve the overlap and what to communicate to clients of the Ed-Fi API as far as how to send the data (in the core field, in the extension field, or both).
Expansion
In contrast to customizations, expansions involve broadly or nationally relevant entities covering areas of the K-12 data domain that are not (yet) covered by the core Ed-Fi Standard. An example of an expansion is the Teacher Preparation Data Model. Expansions are built with the expectation that other school districts and state education agencies will want to use it.
Here’s an example. A school district implementing the Ed-Fi Standard and Technology needed to track bus route information, which is currently not covered by the Ed-Fi Standard. Because nearly every district is interested in bus route data, this is not a local customization but a broadly applicable expansion.
The MetaEd definition of the BusRoute and BusDriverName domain entities is below. Note that there is no “additions” keyword, as this does not modify an existing domain entity.
After running MetaEd generators to produce Ed-Fi ODS DDL for the extension, the BusRoute and BusDriverName tables are produced. Note that there is no foreign key to core domain entities.
Part Two: Considerations When Extending
Before implementing an extension, whether a customization or an expansion (see An Aside: Types of Extension) consider the long-term implications. At times, legislative requirements or other needs may prevent you from using Ed-Fi without extension, but the decision to extend should be made in the context of a strong governance model considering factors like those described in the sections below.
Vendor Support & Compatibility
The more you extend the Ed-Fi Standard, the less likely you will benefit from Ed-Fi API integration in national vendor applications.
Just because you build the extension, does not mean the data will come. Adding even one additional element can create a 6-month dependency on your vendor’s release cycle. Your vendor will likely charge you for the customization. Or, worse, they may be unwilling to support the customization at all.
From the vendor’s perspective, if each customer requests a customization, the value of using a data standard diminishes and becomes a source of customer-specific code, when the opportunity provided by adopting the Ed-Fi Standard should be the opposite, leading to faster, more efficient release cycles.
Community Alignment and Ed-Fi Exchange Solution Compatibility
The more you extend the Ed-Fi Standard, the less you will be able to benefit from community-provided solutions and collaboration opportunities.
Many of you are solving similar problems in your school districts and state education agencies. The Ed-Fi Community is very rich with collaboration and shared solutions. The Early Warning Plugin for the Ed-Fi Dashboards, for example, was built by Double Line originally for the Pennsylvania Department of Education (PDE). It was later shared with and enhanced by our work with the Nebraska Department of Education, and further enhanced by Florida CODE. Later, the upgraded and enhanced version was shared back to PDE so that the creator could benefit from community enhancements. This rich collaborative environment is made possible through common use of the Ed-Fi Standard.
But deviating from the Ed-Fi Standard through customization extensions limits your ability to take advantage of some shared solutions and collaboration opportunities because your implementation of Ed-Fi differs from the implementation assumed by the shared solution or installed at your collaboration partners.
Upgrade Path
The more you extend the Ed-Fi Standard, the more difficult future Ed-Fi version upgrades may be.
While extensions created to expand the data model into new data domains are less likely to cause an upgrade problem, extensions created to customize the existing core data domains are a different story. When upgrading to a new Ed-Fi version, you may run into the following challenges with customizations:
- An element you added as an extension is now a part of core, and the semantics may differ
- An element you added as an extension must now move (e.g., in ODS terms, to a new table) due to changes in the structure of the core domain entity
- The unique key for the domain entity may change, causing a problem for your ODS extension table (since the foreign key will now be different)
Dealing with one or two such customized elements may not be a huge lift, but without a sensible governance model, you may find yourself accumulating enough customization to make the effort of an Ed-Fi version upgrade significantly more difficult.
Conclusion
Finally, because of their broad applicability, when considering an expansion, it’s important to coordinate with the Ed-Fi Alliance. Ed-Fi operates similar to an open-source community, and there are a number of resources and peer networks that you can access for help. You can engage in the Ed-Fi Community in a number of ways:
- Join in Ed-Fi’s Community, the organization’s primary input and feedback channel. Through a series of ongoing workgroups, special interest groups and input committees, Ed-Fi has formalized how they work with users in their community to ensure continuous improvement. Some of these groups may already be working on similar extensions or reference extensions may be available from past projects.
- Connect with the Ed-Fi Alliance Community through the Ed-Fi Slack Channel to find others who may be working on similar extensions and would be interested in collaborating.
- Submit a feature request ticket through Tracker with extension details and get more guidance and help from Ed-Fi technical staff.
- Attend the upcoming Ed-Fi Summit and Technical Congress to get connected to others that may have a similar use case and to learn how others have approached similar challenges.
