Elements of an Ed-Fi Architecture
- Sayee Srinivasan
- Eric Jansson
Contents
Overview
Successful Ed-Fi architectures look similar in terms of technical processes. They also share underlying communications and governance processes. (Click on the image to expand.)
Figure 1. SEA Ed-Fi-based architecture - click to expand
Elements of the Architecture
| Steps | Diagram |
|---|---|
State education agencies (SEAs) publish data specifications for technology providers so the technology providers can prepare to support Ed-Fi-based data collection. These specifications include Ed-Fi-defined elements and may also be extended. We recommend 6-8 months for this step in advance of production. |
Figure 2. SEA data specifications |
| Several months prior to entering production, SEAs should publish sandboxes that technology providers can use to prepare their API-based integrations. This is when tech providers should start their development work based on the new specifications. |
Figure 3. SIS sandbox |
| When technology providers are ready and the school year begins, the system goes into production and near-real-time data begins to flow from districts to the state. |
Figure 4. Data flow |
| Once data is flowing, the state typically provides a submissions report that shows the district that data is flowing and the SIS provides back errors that result from data format errors or other errors that are detectable by the API. |
Figure 5. SIS integration |
SEAs periodically move data from the Ed-Fi ODS to an Ed-Fi ODS that is multiyear. This environment generally has some additional columns to allow for multiple years of data to be compared. States make the decision to migrate to the multi-year environment and run validations either as a nightly process or as soon as the data lands in the Ed-Fi landing zone ODS. In this environment, the states validate the data according to the state business rules and log the errors. Errors are reported back to the LEA via a state error portal. The LEA then fixes the errors, the data is re-transmitted to the API (generally in near-real-time) and the data quality improves. |
Figure 6. SEA Validations |
States populate a longitudinal data warehouse system for their reporting needs. In some cases, this system is based on the Ed-Fi data model. In others, it is a third-party or existing agency system. From the SLDS, states generate datamarts for state and federal reporting (such as EDFacts). |
Figure 7. State SLDS |
Individual State Architectures
Some states running on Ed-Fi have shared their architecture diagrams to guide new users! These are provided below. Click on the images to expand.
| State | Diagram |
|---|---|
| AZ |
Figure 8. Arizona architecture diagram |
| IN |
Figure 9. Indiana architecture diagram |
| NE |
Figure 10. Nebraska architecture diagram |
| WI |
Figure 11. Wisconsin architecture diagram |
