Ecosystem Review & Analysis

The sections below outline insights from the Data Ecosystem Audit, emphasizing key takeaways and visual examples where feasible.

Flagship Systems Have Enabled Significant Interoperability

Oracle Fusion and Azure Active Directory (AAD) (with support through ClassLink’s “OneSync” utility) represent the strongest connection points between applications in the AIU’s Data Ecosystem. Both are enterprise systems housing key data resources, and they serve a critical function in passing this information securely to other systems.

To comprehend the scope of data integration offered by Oracle and AAD, consider the chart below, showing the total number of other systems each application connects to. While a handful of systems has 2-7 integration points, Oracle and AAD each have well over double as many, showing their significant role in connecting data across the ecosystem.

These major system-connectors offer several strategic advantages in a large data ecosystem:

  1. Single Source of Truth: When a well-connected system, such as Oracle, is the “source of truth” for a data point (a staff member’s name, for example), changes to that data point can be made in a single place and propagate to other systems, reducing (A) the overhead required to make changes, and (B) the probability of data entry errors. In the contrary scenario, when the same data point is maintained separately in unconnected systems, there is a high likelihood of inconsistency between data sources and the time spent maintaining that data is multiplied by the number of systems in which it is maintained

  2. Data Interoperability: By serving as a standardized connection point for certain data resources, systems like Oracle and AAD facilitate easy implementation of additional applications that require the same “rostering” data.

Many Programs Interact with the Same Data Points, Separately

While AIU programs and services vary widely across divisions and departments, a common set of data resources are consistently tracked and managed by many teams. Each team, in turn, has developed its own business processes, data systems, and data management practices for these common data points. Consider the following resources:

  • Student Demographic Information
  • Student Enrollment History
  • Student Program Participation
    • EL Qualification
    • Special Education (IEP) Provisions
    • 504 Plan
    • McKinney Vento Status
    • Migrant Education Program (MEP) Status
    • Economic Status/Medicaid Eligibility
  • Student Assessment Results
  • Student Attendance Records
  • Staff Demographic Information
  • Staff Certification/License Information
  • Program Intervention Offerings

The School-Based Access Program (SBAP) team, for instance, tracks most of the above data resources for eligible students, using shared spreadsheets to collect the information from partner schools and maintaining the data in a Microsoft Access Database. Meanwhile, the same basic demographic information, enrollment information, and program participation information is obtained, tracked, and reported independently by the English as a Second Language (ESL) team, the Non-public Schools Program (NPSP), and the Speech and Language Services (SLS) team, each of which uses an independent Access Database, collection of spreadsheets, or enterprise system(s) to track the information for their students.

Some students overlap multiple programs–for instance, students receiving ESL instruction may also receive SBAP-eligible medical services; in this case, both AIU teams obtain, track, and manage that student’s information separately. Not all students overlap across programs, of course; however, the use of separate systems to track similar information–even for different students–necessarily duplicates the like business processes used by each team for data collection, data quality monitoring and validation, and reporting.

Data Reporting Obligations Influence System Dynamics and Dictate Staff Time

Most program teams cited state data reporting requirements as the driving force behind local data system selection and functionality. This was particularly true for teams using non-enterprise-level data systems (e.g., an Access database as opposed to licenses for a third-party application system). Several of these teams’ primary state data submission portals do include functionality to run reports on submitted data*; however, no teams are able to carry out program operations using solely the state submission portal and reporting features, as there is still a need for pre-submission data validation, a single point-of-entry (i.e., not all staff–usually only 1-2 per team–have portal upload access), and post-reporting records retention for auditing purposes.

*Perhaps the most idiosyncratic of these is the e-Data portal for Adult Education, which provides program staff a Microsoft Access Database frontend template and source data to run reports and data validations in a local instance of Access.

Back to top