Building a Better Enterprise

Until recently, data automation in school districts centered around one application—the student information system. Data from various sources, including classrooms, central offices, libraries, and cafeterias, would flow in and out of the SIS, helping to streamline day-to-day school management and coordinate state and federal reporting. Instructional systems, such as those for conducting formative assessments and delivering curriculum, sat apart from the SIS in their own information silos.

Today, however, this “classical” model is gradually being replaced. As districts struggle to meet No Child Left Behind requirements, improve instruction, and above all, raise student achievement, they’re asking for data to be synchronized across the various systems and accessible to all stakeholders. As a result, student data has suddenly moved to the center of the district enterprise, with the data warehouse facilitating its flow.

Here’s a sample “student-centered enterprise” scenario. A math teacher is working at home on her lesson for the next day. She logs in to the district’s instructional management system and opens up the lesson plan generation tool. Meanwhile, she simultaneously has access to demographic, grade, and assessment data for each student— information that’s being fed to her from the district’s data warehouse. Armed with this collection of data, along with current knowledge about her students’ strengths and weaknesses, the teacher then selects appropriate activities and resources. The result: a data-informed lesson that individualizes instruction for each student.

The previous example illustrates how teaching and learning can be enhanced when traditional silos of information are linked together and pushed to users in a unified way rather than pulled haphazardly from various systems. For most school districts this represents an enormous paradigm shift, one that requires a rock-solid vision and strategy to execute successfully.

UNDERSTANDING THE VISION

Before looking at how districts might go about moving from a classical to a student-centered enterprise, here is a breakdown of the differences between the two approaches.

• Classical:
• Student information system at the center of data automation
• Systems stand alone and gather information separately from each other
• Focus of data typically at building level with central administration
• Relevant student information manually duplicated throughout various systems, burning up an enormous amount of resources and negatively impacting data quality
• Data for individual students cannot be imported or exported in real time; in most cases districts have to go through the unwieldy process of exporting information for the entire student body all at once (also known as batch transfer)
• No data modifications from external sources accepted; students and parents can’t remotely log on and enter change of- address information into the system
• Assessment systems might consist of a traditional grade book, homework, and teachers’ qualitative observations about students
• Self-contained curriculum products and resources aren’t able to interact with other systems on the enterprise; for example, standalone math software that uses an internally developed rubric that is not correlated to the actual curriculum
• Student-Centered:
• Data warehouse at core of data automation
• Automated free flow of student information across the entire enterprise
• When data—for example, assessment results—is added or changed this information is automatically updated wherever it appears in the enterprise
• Data about individual students can be transferred in real time
• Outside stakeholders can access relevant information and make modifications (where they have clearance to do so)
• Assessment system provides educators with immediate feedback on student progress; for instance, teachers might give students a five-question quiz that’s scanned into an assessment management system, with results being immediately tabulated and electronically pushed to a portal interface for each educator
• Curriculum solutions integrated with the enterprise; for example, reading software that uses externally gathered performance data (in addition to internally developed rubrics) to gauge student achievement and adjust instruction accordingly
• Curriculum and accompanying resources are dynamically linked and keyword-searchable through a universal content-neutral interface
• Metadata architecture establishes a baseline for longitudinal evaluation; metadata is data about the data, such as who authored it, what kind of condition it’s in, who has access to it, and other characteristics
• Business intelligence tools allow data from different systems and external sources to be compared and contrasted to each other, such as analyzing the relationship between attendance, gifted programs, socioeconomic status, and achievement

GETTING FROM HERE TO THERE

Having established the benefits of the student-centered approach, it’s time to turn to execution. How can district leaders begin to move away from the classical paradigm?

Phase 1: System Automation
Most districts have already invested in SIS systems to automate student information and run day-to-day operations. This is your data baseline. The next step, which has taken on critical importance in an NCLB era, is automating assessment. The objective here is to find a tool, or set of tools, that delivers immediate feedback about student progress to educators. This doesn’t necessarily mean you have to go out and purchase an online assessment application; paperbased assessments that can be scanned into the system can be equally effective. Only after the first two systems—the SIS and AMS—are in place should you even begin to think about incorporating learning or instructional management systems.

Phase 2: Making the Data Flow
By far the biggest challenge facing school IT leaders is the inability of the classical model (composed of the SIS, AMS, LMS, and IMS components, manual or automated) to transfer data among each other. One reason why moving data is so difficult is that the individual components—from the SIS to the IMS—are designed to be the primary repository for all data, including their own. The technical way of saying this is that each system has its own set of “authoritative data elements” along with data elements that are obtained from other systems.

The first order of business for districts, therefore, is to develop a dataflow empowerment system. The purpose of the DES is twofold:

To move data to allow easy access to the authoritative data elements transmitted to the data warehouse from the SIS, IMS, LMS, and IMS components. The DES will keep track of which components “own” which data elements and which ones have permission to request data copies. This is called the data element permission architecture, and it’s something lacking in most standalone system components.

To empower users. The DES also serves as the platform for software programs that deliver up-to-date information— including an in-depth look at student data—to stakeholders. Some enterprise systems have this functionality, but in most cases they’re limited in scope.

Making the DES work requires a well-defined data warehouse. The data warehouse is like the center of a wheel into which data from the different components of the enterprise—the spokes—flow. Once in the warehouse, the data can then flow out to a number of applications, including business intelligence tools that analyze the data as well as tools for communicating information to all stakeholders, that is, students, educators, parents, and community members.

Another essential key to getting the DES off the ground is choosing how you’re going to transport the data and what import/export interface you’ll use— in other words, how you’ll be tying all of your systems together. There are many different approaches to enterprise integration, including building custom interfaces using screen scraping or application program interfaces or investing in a large-scale enterprise integration solution. For more on the various approaches, see “Application Integration: A Strategy Guide,” at www.techlearning.com/schoolcio.

Phase 3:Mining and Analysis
The final step to creating a studentcentered enterprise is adding a business intelligence system. The BIS analyzes the information stored in the data warehouse and determines relationships between different sets of data based on the metadata architecture.

Another objective of the BIS is to provide a common and dynamic analytical reporting tool and user interface across and within all system components (for example, SIS and DES). In practice, this means teachers can harvest data located throughout the enterprise— student grades, assessment templates, instructional materials, and more— using the same content-neutral user interface. The BIS can also make state and federal reporting easier. Instead of pulling reports from each system component, the BIS would serve as the primary reporting tool and would push data elements to state and federal compliance systems, alleviating the burden of compliance reporting.

So, how to make this happen? Some business intelligence tools are integrated into the district’s data warehouse. They can also be purchased as standalone tools that are then integrated with the warehouse. Many of these products include Online Analytical Processing (OLAP) functionality, which lets users perform queries and analysis on a wide range of data. For a searchable guide to analytics products, see http://productfinder.databasepipeline.com.

Without question, the road to creating a student-centered enterprise will be filled with many challenges as technology becomes a seamless part of infrastructure and instruction. Conveying the value of such a system to all stakeholders will require a visionary leader and a committed executive management team at the wheel. Are you ready?

Elbie Yaworsky, former chief technology officer of the Pittsburgh Public Schools, is president of Frameworks Information Technology.