MSP SIG - Meeting 16 - 2023-11-07
Participants
Agenda
Review outcomes and actions from Ed-Fi Summit MSP meeting
Enrollment API community usage and revisit API strategy questions
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.