Project Contexts, Deployment Configurations and Use Cases

Project Contexts & Use Cases


Minnesota DOE (SEA)Florida CODE (Collaborative)Tulsa (LEA)Tucson (LEA)

Project Context

Describe context for T-ODS interest

Temporal/Longitudinal Use Cases

A general description of the temporal/multi-year use case(s) you are trying to address. Information should include:

  • What domains do you need temporal information for?
  • With as much specificity as possibly - what output(s) are you targeting?


Project Context

MDE is deploying an Ed-Fi data collection system for 18-19 school year to collect student demographic and enrollment data elements from a pilot group of school districts.  We are planning to ramp up this data collection over several years with the goal of all districts reporting student demographic and enrollment data elements in the 21-22 school year and retirement of the legacy student enrollment data collection system the following year.

MDE is evaluating T-ODS as the next-generation system for statewide data validation and data snapshots which will be used to populate data marts for the various systems that consume student demographic and enrollment data.  MDE’s legacy student enrollment data collection system uses a mainframe-based statewide data validation and data snapshot system which is over 25 years old.

Use Cases

  • MDE will initially use the Ed-Fi data collection system for collecting student demographic and student enrollment data which should also be supported by the T-ODS.  However, there is certainly a desire to expand the MDE Ed-Fi data collection system in future to include additional data domains including assessments, discipline, and course section enrollment, and we expect that the T-ODS should support those data domains too.
  • MDE’s legacy student enrollment data snapshot system currently supports two primary student enrollment snapshots: Fall and End of Year.  This snapshot schedule is based on School Finance data processing requirements.  Fall data snapshots and statewide validation checks are processed monthly: October, November, and December, finalized in January.  End-of-Year data snapshots and statewide validation checks are likewise processed monthly: October, November, and December and finalized in January the following year.
  • MDE’s T-ODS should be able to replicate this data snapshot and statewide validation process, including taking snapshots of Fall 19-20 data at the same time as End of Year 18-19 data. This is a known customization which Double Line Partners is planning to implement for Minnesota.
  • In order to realize benefits from a more real-time data collection, requirements from other MDE program areas for additional data snapshots.  MDE is tentatively anticipating 6 distinct data snapshots.
  • From these data snapshots, MDE will populate data marts for data calculations, aggregation, reporting and analytics.


Project Context

Use Cases

  • Florida State Reporting Periods (There are 17 periods)
  • End of Year

Project Context

Use Cases

Domains:

  • Student, StudentAssessment, SchoolAttendanceEvent, EducationOrganization, SectionAttendanceEvent, School, CourseTranscript, LocalEducationAgency, StudentAcademicRecord, GraduationPlan

Outputs:

  • To track high mobility of an at risk student for Grades, Attendance, Address changes
  • To record specific flags like ELL historically
  • To review how a student’s assessment performance improves or doesn't over time based on testing accommodations
  • To track demographic information historically
  • Student attendance over time
  • Student grades over time
  • Build a timeline of a student's K-12 performance
  • The ability to compare the graduation rate for schools between two different school years

Project Context

We are loading our data using a custom API and are working on Attendance and are poised to start on Assessments.

We plan to leverage the Ed-Fi ODS for our Power Bi/SSRS reporting requirements. We may also make modifications on the Dashboard if none are planned by Ed-Fi to allow views into past data (beyond prior year).

Use Cases

  • We were hoping across our complete install. We have student and Financial data for past 20 years
  • Currently we are student centric on multi-year, enrollment, attendance, discipline, assessments and  grades. We are evaluating this to replace our hodge/podge DW attempt

Ed-Fi ODS/API Deployment Configurations


Minnesota DOE (SEA)Florida CODE (Collaborative)Tulsa (LEA)Tucson (LEA)

Ed-Fi ODS/API Versions

  •  What version of the ODS/API are you currently working with?
  • What version of the ODS/API do you intend to use to evaluate T-ODS?
  • Planning to deploy Ed-Fi ODS/API v2.3 for the 18-19 school year.
  • Ed-Fi ODS/API v2.3
  • Dev, QA, Prod: ODS/API - v2.1
  •  Intend to use v2.1 to evaluate the T-ODS (Open to upgrading to the most recent 2.x ODS/API)
Dev, Prod: v2.3.1
  • We are not yet live to production. Downloaded and installed v2.3 last.
  • Ed-Fi ODS/API 2.3

 ODS/API Deployment Architecture

(On-premise, Azure, AWS)

On-premise

  • MDE is planning to deploy Ed-Fi ODS/API in a State of Minnesota tier 3 data center, not a public cloud.

 On-premise

  • in the NEFEC Data Center using Microsoft Server 2012/2016 (VM’s)

Cloud - AWS

  • On-premise for dev/testing
  • Cloud (Azure) for production.
    • Current plans are SQL Azure, but would consider using VM hosted SQL, we are still evaluating which is easiest to manage/modify.

 ODS/API Tenancy/Segmentation Model

(Multi-tenant or single-tenant)

Multi-tenant

MDE is planning to deploy Ed-Fi ODS/API in a multi-tenant model with a single ODS database per year, similar to WI.

Have both:

  • Multi-tenant for all NEFEC districts
  • Other FLCODE districts are single-tenant, district hosted
Single tenant (LEA) Single tenant (LEA)

ODS Storage Model

(Year-specific or multi-year)

Year-specific model

  • MDE is planning to instantiate a separate Ed-Fi ODS per school year

Multi-year model

  • A single ODS is intended to cover multiple years of operation – with rollover procedures determining what data is carried forward to a new school year.

Multi-year (question)

 Multi-year model (preference)

T-ODS Functionality

FunctionalityMinnesota DOE (SEA)Florida CODETulsaTucson 

T-ODS Snapshot capability: What is the anticipated periodicity of snapshots?

A total of 8 snapshots per year

Initially we plan two distinct snapshots, Fall and End of Year. 

  • However, each of those snapshots occurs once per month for 4 months per year: October, November, December, January
  • Those snapshots will be taken concurrently for two years of data: Fall snapshots from the Current Year ODS and End-of-Year snapshots from the Prior Year ODS.

A total of 18 different snapshots per year

  • Florida State Reporting Periods (There are 17 periods)
  • End of Year
Daily

 We currently have 2 years of daily historical data for our Synergy SIS, but we have not yet determined the feasibility of using this data. 

This data does allow us to pull any point, such as Term, Semester, EOYr, 10th day, 40th day, 100th day or other points

T-ODS query: Do you anticipate querying temporal data natively (via SQL queries) ,through an application, or both?

Likely natively, but not yet designed.

Both.

  • SQL Queries/Stored Procedures for Data Quality System
  • Applications:
    • PowerBI for EWS Project
    • Tableau for HCMS Project

Both.

SQL queries and API calls from another application

 Both.

  • We us Power BI and SSRS to access our current DW and hope this to eventually be one stop for all data reporting.

T-Bulk: Is bulk-load of prior years of data required?

If so, are you able to produce or acquire prior year data in Ed-Fi XML format?

No.

For the current project vision, no, we do not need bulk-load of prior year of data.  The T-ODS will be used for creating snapshots from which downstream data warehouses and data marts will be populated.

If our project vision changed to include bulk-load of prior years’ data into the T-ODS, it will likely not be for at least 5 years.

Yes.

The Bulk Load will be through the Mass Send to API functionality that exists in Skyward SIS. We plan to mass send data through API for previous years, snap-shot each year, and then set the current year for live data. Snapshots of the Current Year (1819SY) will be during each state reporting period

(question) (Chris Moffatt (Deactivated)) Does this produce Ed-Fi XML?

Yes.

We are bulk-loading prior years of data, and yes, we are able to produce these data in Ed-Fi XML format

(question) (rick.foster) What is the best method?,

We have data 9 years back in common data structures and could use the API.  We can produce XML format if necessary.

light-off (off) (Chris Moffatt (Deactivated)) The current T-ODS design supports Ed-Fi XML format as the only supported way of loading prior years of data

Do you anticipate needing to modify temporal data?

If yes, indicate how/where you anticipate performing the modification

No.

 Yes.

  • Use Case: Districts occasionally have to return to previous year data in the SIS to update grade changes, GPA’s, and Credits Earned
  • Business Process: It would be great if the district was able to make the update in the SIS and the SIS update then gets sent to the T-ODS. However, we would also be able to submit a manual change through SQL scripts if the district were to submit a help ticket to our Help Desk
  • Domains of Data: Student Grades
  • Additional Info: FLDOE DOE Reporting Presentation

Probably so...but we are not yet certain. One case where we anticipate needing to modify the temporal data is delayed entry of compliance based data. For instance, most compliance data in Oklahoma is reported as of October 1. In the event that a student has been tested and qualifies as an English Language Learner but that data is not in the source system, it will be important to be able to add that data in to be reflected on the tested date (not the entry date) in order to make sure compliance reporting is accurate and to make sure the correct $ amount is received from the state (assuming reporting is done through the ODS).

How/where update would be made: Via ODS/API. The current process is that these changes are updated in our source system. In an ideal state, the update in the source system would trigger a change in the ODS but this may have unintended consequences.

 No.

We would like to support point in time/repeatable results type data sets.

If relevant, provide information about alternative technologies/approaches you have investigated or intend to evaluate (in addition to T-ODSWe will be comparing the results of the T-ODS to the current MARSS statewide reporting data marts on the mainframe.  However, this is not really an “alternative” technology, but rather a “legacy” technology.   Our hope is that the T-ODS solution will allow us to eventually (in 5 years, once legacy MARSS system is retired) replace the legacy technology with T-ODS.
  •  We have reached out to Wisconsin to evaluate the multi-year modifications that they made to the ODS
  • We have considered simply using a new instance of the ODS for each new school year. (We hope that the T-ODS will be a usable alternative to using this approach)
Continuing with our data mart approach in the current dashboard application as the source of data and data changes is an option that we will consider if we are unable to utilize the T-ODS to the level we hope to.

As mentioned above we have historical-lized the complete Synergy database (300GB of non-image data). 

The method used was dynamically built merge statements using Effective Begin and End Dates with current row identified as Effective End Date of 29990101.