| Time | Item | Who | Notes |
|---|
| High Level Architecture Review | | - Diagram borrowed from the Parent Portal architecture, focused on Microsoft Stack.
- Does the high approach make sense for the reporting and visualization project?
- What would this look like for other technologies? What pieces need to be updated?
- ORM based approach works for reporting at the individual student level. To support aggregate level reporting how would this work and how easy would it be for organizations down the road to implement this?
- Lessons Learned from Parent Portal:
- The performance was terrible in the first iteration, as the focus was on parents once teachers started using it the number of students increased so they had to move to a view to help with performance issues.
- For an aggregate, we wouldn't do everything in entity frameworks and move to use aggregate views.
- Another challenge of this design is where in the pipeline content creation and rendering is going to happen. Some metrics require a trivial effort to aggregate but others might need some complex decisions. Aggregating clientside vs. serverside, in cases for example where we want to enable drill-downs.
- The broader goal is to define back end architecture that can support both cases, build your own or use a client:
- Build your own dashboard application
- Build your own dashboards with Tableau or something else this back end architecture should support it.
- We can at least have a layer of abstraction with views that allow for the backend to stay more consistent. This should change less often than the ODS versions. Douglas Loyo would like to take this a step forward and create a web-enabled API, are we taking this too far. It would be great if we can have a data mart layer on top of the ODS.
- Views that are supported by the Analytics Middle Tier, but if those views are part of a contract that doesn't change version to version of the ODS.
- Use Case to write data back into the ODS to capture user interaction data. We need to be able to A/B test everything, would like to run A/B test to see if updates are worth adding/maintain. Knowing what is improving usage is usually missing from reporting and visualization tools.
- Giving people the ability to explore as much as we can to get from the ODS, which probably means having use cases pre-defined to make it more self-service.
|
| Security | | - Security Approach Overview, also borrowed from one of Douglas' projects - also with an application focus:
- There are enough identity providers that we don't need to re-invent the wheel.
- Aiming to use standard claim set for education, what claims can be standardized for education. Used JWT in the parent portal application
- Web/Mobile applications can benefit from this approach.
- For Tableau, PowerBI or others the hope is that SSO would be able to handle this.
- What about cases where the user's identity is not connected to email addresses? (Legacy accounts with username strings?)
- YesPrep had a similar issue with legacy users, they ended up asking parents to create a Gmail account if they wanted to access the parent portal.
- Azure providers and others usually allow emails to be entered.
- In some instances teachers and students they teach are known data in that instance this should be able to work to know who that user is connected to (students/courses/etc). When people are not tied to a student, for example, a guidance counselor might be harder to define who they should have access to. This case might need additional back end security via a query.
- The ODS has cohorts that might be able to handle scenarios where it is not as clear cut as teachers/students. Ed-Fi Dashboards have a claim set approach that might be worth looking at.
|
| Next Steps | Itzel Torres (Deactivated) | - Update the architecture diagram based on discussion and feedback.
- The goal is to continue working through the multiple modules of the architecture to get to the pieces and technology we want to tackle with a POC that will then inform the MVP architecture decision.
- We also want to capture any risks or out of scope items for the MVP but that will need to be considered for the final version of the proposed reporting and visualization approach.
|