Implementing the Common Education Data Standard Series – 4

Strategy Considerations for Policymakers
Gary West

When the Common Education Data Standards (CEDS) [1] were first introduced, there was much discussion about “adoption and implementation” – adoption has a meaning different from implementation.  As the discussions continued, it became clear that adoption is not a sufficient goal – if your state education agency (SEA) is to benefit from CEDS, you must implement the standards in some operational way. 

Your agency probably does not want to change the structures of existing data systems.  Such changes have a tendency to “break” things – links within the data system are sometimes lost, important applications quit working as needed, and other bad things tend to happen.  Such changes cost a lot – and fixing the things that break can – will – cost even more.

That might be the case if your agency tries to change its existing SLDS and other datasets so those can conform to CEDS.  At the same time, there is a real need for you to consider voluntary implementation of the Common Education Data Standards in order to meet your expanding data needs and to reduce the future costs of maintaining your data systems and applications.  In addition – and most importantly – implementation of CEDS will create capacity for your agency to become a true service agency.

Implementation of CEDS in your SEA will start with several considerations by you and your team.  Implementation must:

  • Be voluntary; you must see the value of CEDS to your future work and the future work of other educators in your state;
  • Respect the investments you have already made in your data and information systems; you cannot afford to throw away your current systems and start over;
  • Meet your SEA’s comprehensive data needs for providing services to teachers, learners, and other stakeholders; you cannot afford to make changes now that must be changed again later when new data needs are identified; your changes must lay the foundations to support growth as your future data needs grow (as they will);
  • Provide data that can be used in collective and collaborative efforts with other SEAs and within your own districts; meeting the needs of mobile students and meaningful research requires that your data are portable and contain records that can be used to guide decision-making in real-time;
  • Create a data system that can reduce your agency’s costs while improving services to learners and other stakeholders; the implementation of CEDS in a significant number of SEAs will create economies of scale in the education data marketplace, resulting in savings, efficiencies, and capacities that have never existed before; and
  • Adapt to evolving and emerging data tools, strategies, and needs; the Common Education Data Standards will continue to evolve as educators’ data applications needs continue to evolve.

Strategies for implementation must help you build capacity to meet your educational goals and to facilitate the appropriate collaboration with other SEAs, whenever needed and whenever appropriate.

In addition, the implementation of the Common Education Data Standards will create the common data vocabulary and language that all education stakeholders can use to have meaningful conversations about the real needs of K-12 education.  That common vocabulary and language will mean that all educators and other education stakeholders can know – for the first time – the data that form the foundations for real decisions and action.  Teaching and learning can become an integrated personalized process.

The mechanism described in this series of papers is an effective and efficient way to implement the current version of CEDS and to prepare for implementation of future versions.  CEDS implementation must meet your agency’s growing data needs and must build a foundation for the development of cost-effective educational applications to meet those needs.  

When CEDS 2.0 was released in January 2012, it included a comprehensive data dictionary with elements from early learning, K-12, and postsecondary education.  CEDS 2.0 also includes a logical data model that will describe relationships between and among the data elements to form specific records for learners, educators, learning standards, resources, and more.  CEDS 2.0 also includes a set of tools to help your agency create an operational version of your data as defined by the data dictionary and the logical data model.

Currently, most state education agencies have built their statewide longitudinal data systems (SLDSes) without regard for CEDS; after all, the CEDS effort did not begin until after many SLDS projects had been funded already and implemented.  As a result, SLDSes do not provide a means of sharing data easily across SEAs or for informing applications to support an individual SEA’s needs.

In addition, most agency SLDSes do not contain all the data elements that will be defined in CEDS – although many SEAs have built other datasets that contain many of the additional CEDS elements. 

With those factors in mind, the implementation mechanism described in this comprehensive document involves specific strategies for an SEA (like yours) to implement CEDS for the purpose of creating a data and information system to meet its data needs.  In general, those strategies are:

  •  Work with districts (local education agencies, or LEAs) to collect, at the SEA level, the CEDS elements that are needed;
  • Build out your SLDS and other datasets that are needed to accommodate all the CEDS elements;
  • Create an extract-transform-load (ETL) [2] application that will pull data from your existing datasets systems and will convert those data formats and values as defined by CEDS;
  • Transform the CEDS formats into an XML [3] version of your data; and
  • Load the transformed data into your operational data store (ODS) [4]

The specific work to implement this mechanism is described in other sections of this series of papers.

There are several reasons that this mechanism is worth considering:

  • Building your ETL application will be cheaper than converting or modifying your existing SLDS and other datasets and systems; 
  • The use of CEDS to define the data that come out of the ETL process (and that are stored in your ODS) ensures that you have a dataset that will be compatible and comparable with the ODSes in other SEAs; and
  • The creation of an ODS in each SEA ensures that applications written for use in one SEA can also be used in other SEAs – meaning you can take advantage of a marketplace with applications that work on your ODS as well as the ODSes of others. 

The ETL application described above will be unique for your SEA because your SLDS and other datasets will be unique to your agency.  The purpose of the ETL application is to gather your unique data elements and convert those elements to CEDS formats and values based on the CEDS data dictionary and logical data model; thus, the data that comes out of the ETL process remains unique to the SEA but is in a format that is the same – that is common – in every SEA.

Before that ETL process can be run, however, there are a few things that must be done:

  • Your SEA must collect the appropriate data elements from your districts and store those data in the SLDS and/or other accessible datasets;
  • The appropriate elements in your SLDS and other datasets must be “mapped” to the CEDS elements; and
  • Your agency must have a physical place (the ODS) in which to store the data that are extracted and transformed.

 In its most basic form, the ETL application would include the following sequential functionality:

  1. Look into your SLDS and other datasets, find the data elements identified through the mapping process, and extract those elements and their values into a logical data store;
  2. Transform those elements to the CEDS formats and values – the result is a set of data elements that align to the CEDS requirements;
  3. Further transform those elements into an XML version of your dataset; and
  4. Load the XML version of your data into your physical operational data store (the ODS).

In this basic ETL application, steps 1 and 2 would be unique for your SEA – because your SLDS (and other datasets) are different from those of your colleagues in other SEAs.  Both of those steps rely on the data dictionary and the logical data model in CEDS – first, to identify the elements to be extracted and, second, to know what those elements should be converted to (formats and values).

Steps 3 and 4 in this basic ETL application can be the same for each SEA – because the conversion to XML starts with the data that are already in CEDS format.  The CEDS-to-XML part of the ETL application can be created once and shared with all SEAs; it would then become part of the complete ETL application for each SEA.

This mechanism for implementing CEDS and creating a physical ODS through an ETL application offers various options to you.  As examples:

(a)   Your policymakers may choose not to include some elements in the data you collect from districts.  That is possible and acceptable in the process; the ETL would simply create CEDS elements and records and would leave those excluded elements with null values (that is, empty).  The output of Step 2 would include all the CEDS elements in the appropriate record formats, but some elements might be empty if that were your SEA’s choice.

(b)   Your SEA may choose to transform your data into a format other than XML (for example, SQL [5]) and store those data in a separate ODS (another dataset or database).  That would be possible and acceptable – as long as that dataset or database could export the data in XML format to your CEDS-compatible ODS. 

(c)   All SEAs may collaboratively decide that XML is not an efficient storage strategy and may decide that the use of a relational database format (like SQL) may be more efficient and useable.  In that case, the ETL would not output XML; instead, your ETL application would create an ODS that would align with the agreed-upon physical data model – and other SEAs would do the same thing.

Because the implementation of your ODS is defined by CEDS, the quality and completeness of the work related to CEDS is extremely important.  Additionally, because one of the goals of your ODS is to reduce the costs of applications that can be shared across states, the compatibility and comparability of the data in your ODS are also important.

Collaboration with your colleagues throughout the implementation process will help ensure the quality, completeness, compatibility, and comparability that are needed.  That collaboration starts within your schools and districts and expands to include your colleagues in other state education agencies.

The implementation of the Common Education Data Standards creates capacity to change the way your agency does its business – as well as having direct impact on the services you want to provide to your districts, schools, educators, and learners.

Gary West [6]
April 30, 2012
garywwest2@gmail.com

Permission is granted to share this document with anyone, in print or electronic format, as long as the content is not changed in any way.

Endnotes for Policymaker Strategies

[1] The Common Education Data Standards:  http://ceds.ed.gov/

[2] ETL stands for “extract, transform, and load.”  While there is much technical online information about ETL, the linked Wikipedia article (http://en.wikipedia.org/wiki/Extract,_transform,_load) offers a comprehensive set of information that is pulled from many original sources.  ETL processes and applications have been used for long time (in computer years) and still offer a cost-effective strategy for converting existing data to formats that can be used in and across comprehensive and collaborative applications.  The ETL process is an ideal strategy for implementing the Common Education Data Standards without incurring the costs of changing all your existing datasets and systems.

[3] XML stands for “eXtensible Markup Language,” which is a “simple, very flexible text format … designed to meet the challenges of large-scale electronic publishing … playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere” (http://www.w3.org/XML/).  See more at the World Wide Web Consortium (W3C; http://www.w3.org/) and at Wikipedia (http://en.wikipedia.org/wiki/XML).  XML provides a way to store data in a standard format that can be read by computers and, then, used in comprehensive and sophisticated software applications.  Storing your data in XML format creates capacity for many applications to access and use those data to inform teaching and learning as well as meeting your reporting and accountability needs.

[4] Operational data store (ODS) refers to a physical dataset that is stored for use in your software applications.  For implementing CEDS in your SEA, the ODS would store the data you have identified as necessary to meet your agency’s data needs.  Your ODS can exist on a server in your SEA’s secure network or it can be stored securely by a vendor with which you contract for hosting services.  The choice is entirely yours.

[5] SQL stands for “Structured Query Language” and is a programming language for relational database management systems.  SQL is a standard managed by the American National Standards Institute (ANSI; www.ansi.org).  See more about SQL at http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+INCITS+135-1992+(R1998) and at http://en.wikipedia.org/wiki/SQL.  

[6] I was high school math teacher for ten years, a federal projects coordinator for a small rural school district for nine years, a technology and data systems director for a moderately sized school district for more than nineteen years, the Chief Information Officer for the South Carolina Department of Education for more than three years, and the Strategic Initiatives Director for Information Systems and Research at the Council of Chief State School Officers in Washington DC for one year.  I have been emphasizing, since the beginning of time, the use of data to guide teaching and learning – not just the use of data to report what has already been taught and learned.  This series of papers is being created and distributed without funding from anyone else (that means, I am not being paid and do not receive any financial gain from writing and emailing these papers to you).  I believe strongly in the appropriate use of data to create personalized learning for everyone who is a stakeholder in our society and in our democracy.  This series is just my way of contributing to the conversation; so, don’t blame anyone else for any of this – it’s just me and my word processor.  And although you can’t friend me or tweet me, you can find more about me at www.LinkedIn.com and you can email me at garywwest2@gmail.com.