TAG Meeting 2023-02-16

Agenda

1. Review highlights of January TAG

2. Ed-Fi Customer Success team plans for 2023

3. Housekeeping

4. Established and emerging patterns for “data in”

   • Vendor → API

   • Vendor → file → Data Import -> API

   • Vendor ←  → API

   • Vendor →  → API

Materials

Open

Open

Participants

Notes

1. Review highlights of January TAG

   1. Josh A, Rosh, and JF volunteer to help move the performance testing community forum forward

2. Ed-Fi Customer Success team plans for 2023

   1. Need to help managed service providers stay on the same page as Ed-Fi with external advice

      1. Ed-Fi Community Hub will help distill the most important / emerging guidance from Tech Docs into a more usable format.

      2. Suggestion of a customer advisory group to work with MSP and Ed-Fi vendors, learn from LEA and SEA implementations.

      3. EDITORIAL REMARK: arguably this applies to system integrators and collaboratives as well. Stephen

   2. Salesforce and Slack: yes there is an integration, and the Alliance will explore using it.

   3. Should we use Slack or Tracker?

      1. Tracker is the source of record.

      2. Slack best for asking for community support. Ed-Fi staff will usually redirect to Tracker if no one answers.

   4. Challenges with existing platforms

      1. Tech Docs – too much

      2. Slack - insufficient history and discoverability

      3. Stack Overflow is ideal for many → Community Hub

3. Housekeeping

4. Established and emerging patterns for “data in”

   1. Data Import

      1. Limited on deletes.

      2. Primarily intended for assessment data.

   2. Work around

      1. Emerging pattern used by several providers when a vendor does not provide data directly to Ed-Fi (either no connection, or some data are not included): export it directly to the lake / warehouse, bypassing the Ed-Fi API.

      2. Example: one LEA wants program participation information that is in their SIS. The SIS connects to the Ed-Fi API only for the SIS-certified resources, which do not include program participation. Therefore, export that info directly into the lake/warehouse.

      3. Warning: bypassing data integrity safeguards in the Ed-Fi API, thus the data engineering pipeline will need to be more complex to ensure data quality.

      4. It sounds as if this is becoming increasingly common in implementations, leading to the question: what value is Ed-Fi providing if we're having to work around it?

      5. Detailed discussion of certification

         1. SIS certification originally designed around data for the Dashboards. LEA's now need other data, and some vendors won't provide it because it is not covered in the certification.

         2. Is that the intent of the certification - to limit the data? In a very real sense, yes: that was the intent. So that SIS vendors (in particular) know that they have a limited scope of data to provide, rather than having open-ended requirements.

         3. Alliance is revising the list of required / optional fields this year.

   3. Middleware

      1. There are a few cases where a middleware component is provided by a third party that helps exchange data between vendor and Ed-Fi API. Did not go into detail.

   4. Vendor-hosted API

      1. A SIS vendor expressed concern with this approach because of the mismatch between the SIS data model and Ed-Fi model.

      2. EDITORIAL REMARK: I did not explain sufficiently that this meant the vendor having an Ed-FI-compliant API, so that the client isn't seeing the vendor's data model. Stephen

   5. These issues expose high barrier for vendors to start with (or expand) Ed-Fi integration.

      1. Are there additional tools we could provide?

      2. Need to have a unified ask to vendors from many parties, demonstrating a systematic market problem.