MSP SIG - Meeting 16 - 2023-11-07

Participants

Agenda

1. Review outcomes and actions from Ed-Fi Summit MSP meeting
2. Enrollment API community usage and revisit API strategy questions
3. Education Service Agency learnings (time permitting)

Materials

Notes

Review outcomes and actions from Ed-Fi Summit MSP meeting

On the topic of creating early opportunity for data specs, the following points were made

• MSPs only have so much power to recommend this
• SEAs also lack a mechanism for including vendors, as they have no contractual relationship to those vendors
• It would help for states to communicate better about legislative patterns and policy
• SEAs could consider using a "request for comment" process
  

On offering SEAs more support for data mapping, there was agreement 

Enrollment API community usage and revisit API strategy questions

On the general question of granular vs aggregate APIs, the general direction of the conversation was:

On the current Ed-Fi composites feature and the implementations (like enrollment), the feature is non-performant at scale: query size and page limits block performance. A couple of MSPs had tried to use this feature with no success. 1 MSP had used it successfully, but even there it was with a LEA of <15K student FTE. There are very few known uses of this feature (2 were cited, and it was unclear if either was in production). Also, code recompile is hard for users - need a more dynamic approach, perhaps based on database views

There was a long discussion about pulling data through the granular APIs or using aggregates (see diagram attached). OneRoster was generally seen as a good approach given its market momentum, but the issue of how to account for the breadth of data that users want was still a problem to solve for. The extreme number of OneRoster custom metadata extensions seen in the field (n.b., the Ed-Fi Summit session by ClassLink) raises questions as to if this approach scales to be a standards-based solution. There were some additional points/proposals:

• The possibility of an 80/20 approach: support OneRoster for 80% of needs, but when finer-grained data is not in that spec, use the granular APIs. There is some "economic" logic to this: when you want the more difficult to source data, then you commit to extra work to get that data
• It was also pointed out that most SIS systems have a OneRoster implementation currently, which raises the question of what does OneRoster on Ed-Fi get you? Another MSP responded that SIS implementations are not working smoothly in actual field work, and that decoupling this gives you more flexibility.
• Also need to consider the possibility of ID anonymization becoming a widely demanded feature and data minimization.