/
March 2026 - Ed-Fi Data Management Service Workgroup

March 2026 - Ed-Fi Data Management Service Workgroup

Participants

Not Captured

Agenda

  • Overview of DMS progress since the last workgroup meeting

  • Walkthrough of the new relational backend design

  • Discuss Implications for implementers, states, and vendors

  • Address questions and review next steps

Workgroup Goals

  • Gather input to prioritize features and refine the application design, ensuring alignment with early adopter needs.

  • Provide an opportunity for workgroup members to actively contribute by participating in hands-on testing, helping to identify bugs, usability issues, and areas for improvement. Your feedback will directly shape the final product.

  • Collaborate to ensure the development achieves a stable release candidate and reaches a 1.0 release by Q1 next year.

Presentation

Key Takeaways:

Release Timeline and Strategic Shift

  • Accelerated Relational Storage: In response to community feedback, the DMS architecture has been modified to prioritize relational storage as the primary model for version 1.0.0. JSON storage will be available as an opt‑in feature.

  • Target Dates: The Ed‑Fi Alliance is targeting a July 2026 release for DMS 1.0.0 and a November 2026 release for version 1.1.0.

 

Relational Backend

  • The relational model is ODS‑like, but includes several structural differences.

  • Existing data‑out ETLs can be refactored to work with DMS; the required changes follow a consistent pattern across the model.

  • Direct writes to the DMS database are not recommended, as they require updating centralized infrastructure tables under the dms schema, which adds operational overhead.

 

Questions and Discussion

  • When migrating to DMS with the configuration service replacing the Admin API, will the admin app work with the configuration service?

    • Yes. The Configuration Service and Admin API (v3) will both implement the same Management API Specification, so the Admin app version backed by Admin API (v3) should work seamlessly with CMS.

  • When Document Cache is not populated and streaming isn't used, how does the API get data?

    • If the document cache exists and is populated, the API uses it for faster reads. If streaming is enabled, the document cache becomes the primary source for CDC (Change Data Capture). If the cache is not populated, the API will read directly from the underlying relational tables.

  • Is the General Student Program Association abstract base class necessary if data is already stored separately in concrete classes?

    • The workgroup noted that this is a Data Standard–level question. Currently, there are no references back to GeneralStudentProgramAssociation (unlike EducationOrganization). However, future model enhancements may require a reference back to GeneralStudentProgramAssociation.

  • Would supporting multiple schema versions on a single API instance reduce deployment costs?

    • Yes, it could reduce hardware/software overhead and deployment overhead. However, this feature isn't fully designed yet. The consensus was that core features should be prioritized first, with this as a future enhancement. The general sentiment was positive about the idea for cost benefits.

  • Do agencies still need views that mimic the ODS schema to make migration easier?

    • The workgroup response was that such views are not necessary. If agencies require them, they can create views tailored to their needs, rather than relying on Ed‑Fi to develop and maintain them.