Recommendation #2: District and TEA Validated and Aggregated Data Loaded into a Data

3.5.2.1 Description

In conjunction with recommendation #1 above, the various data aggregations, snapshots, and formulaic calculations required by TEA would not occur in the ODS, but rather by means of taking snapshots of data extracted from the ODS and loading them into the ADW. The ADW represents the data repository for official TEA data, the system of record, which will house all required aggregations and snapshots needed for program, state and federal reporting.

The process for moving data from the ODS to the ADW would be as follows. First, snapshots of the data would be taken from the ODS and run through a business rules engine to support aggregations and calculations of the data. The calculations/aggregations and associated data would available for districts and ESCs to review and approve prior to loading into the ADW. As a result, this model moves the burden of maintaining the aggregation algorithms from the school districts to the TEA level. By doing so, the school districts and ESCs do not need to pay the local SIS vendors to build and maintain those

algorithms, and the school districts can focus on the quality of the raw student data streams to the ODS.

TEA would publish all aggregation and business rules used for compliance, accountability and performance reporting. The rules should be made available to the ESCs and districts level well in advance of the compliance report date so that they may perform, if desired, local validations and data quality checks prior to TEA processing. Though it may be technically more difficult, TEA may also provide access to the transformation software which implements the business rules, such that districts, if they wish, can run their own transformations and compare the validity of the resulting data.

The ADW would be structured to support longitudinal analysis. In addition, it would be supported by a reporting and analysis tool which is further described under recommendation #3. Finally, IBM

recommends that the ADW be the responsibility of and managed by the TEA Information Technology Services Division, whose role in both is one of maintenance, support and enhancements for its customers, the districts for the ODS and the TEA and other appropriate stakeholders for the ADW.

3.5.2.2 Issues Addressed

The following issues are addressed by this recommendation:

 Current data collection model imposes significant burden on local districts.

 Stakeholders need data that is more timely, relevant and actionable 3.5.2.3 Benefits & Impacts

Performing all derivations and aggregations at the TEA instead of at the districts and ESCs will drive a number of benefits for quality data management. This approach will:

 Assure that districts use both data field and aggregate validation processes to check their data for completeness and accuracy. (i.e., that not only are the code values correct, but that the aggregated results are appropriate for the school or district.) Detail will be submitted by the ISDs at which point

the TEA will create and report the aggregates back to the ISDs from the ADW. Today, ISDs are creating aggregate data fields and submitting this information directly to the TEA. Local

implementation of current aggregation rules is both costly and inconsistent. Moreover, auditing of these aggregates by the TEA is very challenging since the source data is often not available.

 The ADW database design will include tables that stores snapshots and other needed data

aggregations while preserving the raw level data in other tables so that school districts can take an aggregate number and drill down to the underlying data. This will ensure integrity of the source and aggregate information.

 Reduce the complexity and cost of the source system ETL process for the districts and the source system vendors since the submissions consist of the native operational data

 Greatly reduce costs associated with maintaining local state reporting requirements as prescribed by separate compliance mandates.

 Ensure that business/aggregations rules are applied consistently and universally among districts (removing issues related to “local interpretations” of the rules)

 Provides longitudinal data analysis capabilities

 Allows data to be leveraged for multiple purposes by appropriate stakeholders

 Provides a scalable and flexible environment as data and reporting requirements change

 Accommodates business intelligence analysis and reporting efforts

 Centralizes data storage across the state and the TEA to help assure consistency, security and a cost effective approach through shared resources.

3.5.2.4 Implementation Strategy

Category Strategy

Policy 1. Develop and implement agency-wide policy and processes for publishing certified and operational education data, including who, what, when, where, in what format and for whom it is being published. Include data sources used to develop published information.

2. See Strategies #3 through #5 under Section 3.5.1.4 (Operational Data Store) Organization 3. Utilize the data management office

4. Utilize the data stewards for each major data area

5. Expand role and resources supporting the TEA generated aggregations Business 6. Data requirements and change management process to focus on data fields Process used for multiple purposes

7. Data submission formats, business rules

8. Business and aggregation rules for each compliance report

9. Data requirements and change management process to focus on raw data fields used for multiple purposes

10. Data submission formats, business rules based on raw data streams 11. Business and aggregation rules for each compliance report

Technology 12. Local data management systems must determine how they will accommodate data standards (either programming changes, translation protocols or

combination of both)

13. Deploy metadata tool for agency-wide management of data standards.

14. Develop ETL processes that support the data aggregations using the data governance rules and other agency-wide data standards

3.5.2.5 Rejected Alternatives

Recommendation #1 (Stream raw data) cannot be realized without this recommendation being adopted and implemented as well. As such, the TEA and other stakeholders would not have the means to gather, store and share more timely data.

3.5.2.6 Tasks/Projects

1. Develop functional and technical specifications for the new data model

 Identify and document data requirements

 Develop data extract submission format requirements based on data requirements and standards

 Develop data business and validation rules for operational data submissions

 Develop data model for Operational Data Store (ODS) based on data standards

 Develop processes including source-to-target mapping of where the raw data from districts will reside in the ODS

2. Develop data collection application and portal interface

 Solicit input from district and ESC representatives

 Identify functional and design specifications for interface

 Develop and test portal interface prototype

3. Develop and implement change management plan including

 Communication plan

 Training plan

 User job aids and manuals

4. Develop project implementation plan including

 Pilot strategy

 Migration Strategy 3.5.2.7 Tasks/Projects

1. Develop functional and technical specifications for TDCARS data model

 Identify and document data requirements

 Develop data extract submission format requirements based on data requirements and standards

 Develop data business and validation rules for operational data submissions

 Develop data model for Operational Data Store (ODS) based on data standards and business rules

 Develop ETL processes including source-to-target mapping of where the raw data from districts will reside in the ODS

2. Develop data collection application and portal interface

 Solicit input from district and ESC representatives

 Identify functional and design specifications for interface

 Develop and test portal interface prototype

3. Develop and implement change management plan including

 Communication plan

 Training plan

 User job aids and manuals

4. Develop Project Implementation Plan including

 Pilot strategy

 Migration strategy

3.5.3 Recommendation #3: Business Intelligence and Reporting Tools to Support End User