Elements of an Ed-Fi Architecture



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


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. 


Figure 8. Arizona architecture diagram


Figure 9. Indiana architecture diagram


Figure 10. Nebraska architecture diagram


Figure 11. Wisconsin architecture diagram