Participants

Agenda

1. Welcome and in-person introductions
2. Market Evolution and the Ed-Fi Tech Portfolio
3. API Convergence & Fragmentation - Problems & Concepts
4. API Design and Coordination - Awareness

Materials

Notes

Market evolution and Roadmap

General recommendations/points: focus more on API and elements focused on sourcing data, less on downstream tools. Focus on scale-up efforts and away from DIY. Thoughtfully retire older tooling. It may be worth more experimental work at unlocking ETL/ELT, but such efforts should be community-based.

Other points

• It’s harder and harder to find on-premise developers to support the on-premise model.
• some questioning about “assessment data remains the primary source of data…”. Is this what instructional leaders are saying, or just IT folks? This polling was primarily with IT staff, with a broad spectrum of relationships with the instructional staff.
• These assessments are a huge source of backlog on getting analytics from an Ed-Fi system. Huge CSV’s with nothing but text. Takes a long time to integrate. Just trying to understand what all of these different columns mean is difficult.
  • Would be nice to have a low-code mapping tool for the academic people who know the assessments to handle the integration.
  • Also think about how to help SIS’s map their state-by-state (or LEA-specific) customization.
• Suggestion: Ed-Fi should concentrate exclusively on the “ODS API and to the left” (data in), leave data out to vendors and agencies. Do more to help with that standardization of data coming in.
• And maybe even the tooling should be maintained by others (including admin tools). Ed-Fi could concentrate on the “kernel” at the center. Make sure it is easy to maintain, deploy, move components around
• At what point does Ed-Fi not even need to build an API anymore? Not there today, but that could be a goal. One reason for Meadowlark is to help show how this can be done.
  • Probably still need a reference implementation… though perhaps not necessarily deployable. Would that be a problem for SEA’s?
  • Main point: there could be multiple implementations, and would like to see the market producing it.
  • But not sure that anyone wants to spend money on developing API, even if possible. Want to concentrate on the value added on top of having that API.
• Start retiring old tech - put real dates on it
• Admin tools - how much investment should we put there?
  • Divide between those who want a GUI and infrastructure as code that can be pushed out using Ansible, Chef, etc?
  • Admin App shows up for collaboratives, lowest common denominator (GUI) needed to support them. On one hand, Ed-Fi is not directly in touch with those users, which is inefficient. On the other hand, providers don’t want to spend their investment on this. Thus back to Ed-Fi.
  • Admin App is great for a single organization. Admin API better for scale up. Should make sure that Admin App is utilizing Admin API so that you concentrate Ed-Fi investment on the API. Eventually vendors may take over on the GUI, with Admin App slowly ramping down.
  • “If you guys build it, we as MSP’s have no incentive to invest in it”. SEAs could easily setup credential management in their own tools, instead of running Admin App.
  • Risk of de-investing: does that shut down the DIY districts?
    • “Anyone can do it” is expensive to develop and get right.
    • There is a case that we should encourage using MSPs, and discourage DIY.
• “If the Alliance or a neutral party did Ed-Fi hosting, we would just work on the data out solution instead of hosting.”
• Data Import
  • Good for point and click for end-user, but not as useful for vendor integration.
  • Does not help an assessment vendor to connect to the API.
  • Could Data Import be re-envisioned as a vendor-support tool?
  • Standardized file format that Assessment providers would produce.
    
• LMS Toolkit
  • Another case where file standardization could be useful.
  • Does API need to extend to LMS? Can we do better with things like Canvas Data Services? (Also have bulk SQS and bulk data export).
  • One vote: yes, still need that - force the providers to standardize to keep standardization.
  • Perhaps it should be more open source with more contributors.
  • Is there any reason to put this data into the API? Maybe just go directly into analytics systems.
    

API Convergence and Fragmentation

General recommendation: do a phased approach and early adopters will tell you what is missing and how important it is.  Use product management need to digest new requests and prioritization

Other comments

• Meadow Lark gave us an opportunity for 2nd implementation and discover what is an actual standard or a de-facto standard based on the implementation
• There are features (see slide) and the question is should they be required for an Ed-Fi data standard?
• Another example of ODS/API features is the current ability to filter on everything
• 1 vote for likes complete parity because those features are helpful
• Is API to exchange data or is it to get data access?  Doing filters in MeadowLark is easy, doing the exact same implementation is expensive
• .NET error messages would be nice if matched but better to follow tools standard data out
• We need a process guidance on how to give direction (without micromanaging)  instead of the detail decision on each feature and its importance for parity
• Profiles and authorization schemes are an example of there may be better solutions in the future
• Our implementation created some features that 
• We should look at standards and approaches to API to define the requirements that both solutions should implement to.  
• Who are we evaluating this for because right now is used by SIS and means investment costs passed to those vendors.  We need to make sure those vendors are represented because they might step away from those implementations.  Vendors have already staked a lot of investment on this current approach
• End point to end point spec would mean it would allow for better community intervention and support
• Perfectly acceptable to include these changes to SIS because they are used to seeing annual changes in the summer switchover
• Maybe use suite as interface differences when thinking about modifications.
• JSONleniency is helpful during implementation but should be turned off in production to enforce data afterwards.  
• Profiles may not be needed until statewide implementations so it would be possible to phase some of these pieces in.  Need to be careful because people may say “I’m using it” but it could be used as a hack to solve a different problem.
• If we are thinking about changing then should think about how to do this in a modern way.
• We don’t have a descriptor API specification.  Things like Effective Begin and End Date are not used by ODS/API.  Which is less relevant with year specific ODS databases
• Version and metadata is another example of how to thoughtfully include
• Recommendation:  

API Convergence & Fragmentation

General recommendations: 

• Concept 1 is aggressive and potentially has many drawbacks, particularly the confusion and complexity it could create. It wasn't outright rejected as a possibility, but the feeling was that it was not an obvious solution.
• Concept 2: not a bad idea, but would have at best a minimal impact, and would also introduce change that could confuse key community members.
• Concept 3: not discussed at length, but generally favorable. Look for ways to automate this.

Other comments

• Concept 1
  • Good domain-driven design approach
  • Breaking into smaller concerns gives you some change management possibilities
  • Does that mean multiple smaller certifications? Yes, perhaps on the order of 10.
  • How do you handle dependencies between domains?
  • Advantage: can modify Assessments (for example) without any change in the other domains. Each domain can be governed by the relevant vendors.
  • There is a risk of this approach making it more complicated to track large-scale implementations
  • Easier for a SIS to say “in these states, we support Domain XYZ Standard A”?
  • More complicated to support the software, with a large matrix of data standards.
  • With one big data standard, people can mistakenly think “we get all of these data in the standard” when any implementation might only be populating 65%. Could clarify the communication “this LEA fully supports this (micro-standard)”.
  • Sometimes a SIS simply doesn’t support a thing that is in today’s certification, and they have to find a way to fudge getting data to support. This breakdown could potentially help with that.
  • In short: more granular (con: more complex) providing greater information about the SIS integration capabilities.
  • Can we be more explicit about what has changed in the API when a new version comes out? (example in the OpenAPI specification). Only provided in written documentation today.
  • Another issue: when you narrow the standard, how do we ensure referential integrity
• Concept 2
  • Data changes and cascade of changes.
  • Some vendors just want to delete it all and resend it.
  • “I like this” -Rosh
  • Dangerous for states - could introduce a lot of new complexity
  • How many extensions are really needed in the first place? Can you just push extra information into StudentIndicator?
  • SIS developing for a state… this would help? [Editor: didn’t understand the point from Instructure]
• Concept 3
  • Shouldn't agencies be doing this?
  • Could you get someone else to do this?
  • MappingEdu in concept was supposed to help
  • Could we build something from Open API specifications running in the field?