Data Architecture Current and Future State Architecture Current and Future State Analysis and Recommendations on DMPS’ Information Assets January 2016 Version 0.21 Center for Educational

Data Architecture

Current and Future State

Analysis and Recommendations on

DMPS’ Information Assets

January 2016

Version 0.21

Center for Educational Leadership and Technology (CELT)

65 West Boston Post Road

Marlborough, MA 01752

Tel. (508) 624-4474

This booklet provides information on the concepts, roles, and tools associated with data architecture.

Center for Educational

Leadership and Technology

Center for Educational

Leadership and Technology

Des Moines Public Schools

Data Architecture Recommendations v0p20

© Center for Educational Leadership and Technology (CELT) 2015 Page 2 of 19

Table of Contents

Section 1.0 Introduction ......................................................................................................... 3

DMPS Eco-Systems ...................................................................................................... 3

What this document does not deal with ......................................................................... 3

Section 2.0 General Architecture Principles and Concerns .................................................... 4

Categories ..................................................................................................................... 4

Centralization vs. Federation .............................................................................. 4

Homogeneity of Interfaces .................................................................................. 5

Data Interoperability Standards ........................................................................... 5

Persistent Data Storage ...................................................................................... 5

Sources of Truth ................................................................................................. 6

Navigation ........................................................................................................... 6

Reporting ............................................................................................................ 7

Security Operations ............................................................................................ 8

Privacy ................................................................................................................ 9

Enterprise Architecture Resources ................................................................................ 9

Section 3.0 Current State ..........................................................................................................10

Component Summary ..................................................................................................11

Connection Summary ...................................................................................................11

Section 4.0 Future State Recommendations .............................................................................12


Connection Summary ...................................................................................................13

Key Observations: ........................................................................................................14

Learning Management System (LMS) ................................................................14

Blended Learning Strategy .................................................................................14

Section 5.0 User Interface and Security ....................................................................................15


Key Observations .........................................................................................................16

Section 6.0 Definitions ..........................................................................................................17




Section 1.0 Introduction

Des Moines Public Schools (DMPS) is working on building out and upgrading its data systems to support

21st century pedagogy, tools and strategies. The key is to balance being able to support modern

methods that are sustainable and achievable given current resources and environments.

This document is designed to provide an initial set of recommendations for a future state for the DMPS

to take with regard to their data systems and managing data in motion as well as data at rest. It

contains a primary section on data architectural principles and concerns, a view of the current state, a

view of a recommended future state, a user interface view, and a definitions section.

DMPS Eco-Systems

THINK. LEARN. GROW.

DMPS has a sophisticated, forward looking plan and has a large and diverse population of stakeholders

in its education system:

64 Schools

32,400 students

o 30% student mobility

o 68% free/reduced lunch

o 55% minority

o 75% ELL increase over ten years

3,400 educators

Devices:

o 26,000 HP computers

o 9,000 Apple devices

o 3,200 projectors

Any architectural design needs to account for the principles and assumptions DMPS is going to utilize to

provide sustainable support for the system and to accommodate the current state.

This document will lay out recommendations to frame these strategic issues for DMPS leadership so the

next tactical steps can be taken to put a new system in place.

What this document does not deal with

Content strategy: This document does not deal with where the district acquires its learning

resources, OER or proprietary content and the applications that serve that up.

Infrastructure: This document does not detail the wireless or internet infrastructure required to

support an enterprise architecture.

Device Strategy: This document does not deal with the edge devices used by the administrators,

educators, students or parents.




Section 2.0 General Architecture Principles and Concerns

There are many ways to design an architecture. A key starting point is to identify the principles and

concerns that will guide the architecture. The following categories represent the areas around which

CELT recommends that principles and policies be established for DMPS. These in turn will drive

technical standards and design principles for the future state.

Categories

Degree of Centralization vs. Federation

Homogeneity of Interfaces (one portal vs. many)

Data Interoperability Standards- Requirements vs. Suggestions vs. Recommendations

Structure of Persistent Data Storage (Data Warehouse, Operational Data Store, Application-

embedded)

Sources of Truth (Source systems of record)

Navigation

Reporting

Security Operations

Privacy

Centralization vs. Federation

The centralization question is an especially important principle to establish. With some schools going

toward blended learning, this implies a lot of local/site autonomy. If this is the case, then a good

integration strategy and strong purchasing guidelines become very important.

The recommendations in this document do not propose a single orientation towards centralization or

federation. Rather, we are suggesting a hybrid approach that allows DMPS to leverage the advantages

and security and privacy benefits of centralization while retaining the flexibility and local control of

federation.

Certain functions like Single-Sign-On (SSO), Directory data, Navigation control, and Institutional Data

should be centralized since they will be used over and over again across all the services and applications

in the eco-system.

On the other hand data interfaces, reporting and specific user interfaces are best federated. Particularly

if the school district chooses to adopt a blended learning approach, or may adopt such an approach in

the future. This approach requires capacity to connect to the centralized directory services referenced

above and some form of data brokerage to allow school district data to be federated while maintaining

privacy and security rules.

In DMPS’ Current State Architecture Infinite Campus and SunGard Business Plus are the primary or core

sources of data. Any discussion of Future State Architecture will need to consider the business drivers

and concerns to determine if it is kept that way or switched to a third-party centralized repository such

as an Operational Data Store or a Data Warehouse.




Homogeneity of Interfaces

A fundamental design principle that must be decided early in the process is the degree to which the

system owners wish all of their user interfaces to be homogenous, similar in their design and navigation.

It may seem obvious – of course you want everything to have a similar look and feel for branding

purposes, but also to reduce training time by having users more easily able to navigate among the

interfaces. However, if you force every application, service, and interface to have the same look and

feel you create an IMMENSE execution bottleneck and add a huge cost to implementation. It means

you will need to touch and possibly redesign every interface any of your stakeholders use. This is

practically impossible to do unless you have huge resources available to dedicate to that.

Section 5.0: User Interfaces and Security is designed to map out those interfaces so that decisions can

be made on which interfaces need to be homogenized and which can be managed more loosely.

Data Interoperability Standards

One of the key elements that needs to be in place to support a digital AND/OR a blended learning

environment is data interoperability standards. Every time a new application, service, or function is

added to the system it needs to get data from the system in order to operate and provide data to the

system in order to be useful.

Different data standards serve different purposes and there is a lot of marketing hype to cut through in

order to understand which ones make sense for which purposes.

In General:

For connection to Content (CMS) and Learning Management Systems (LMS) the IMS Global Learning

Tools Interoperability (LTI) specification is the most common method all LMS and Content -interfacing

systems must integrate a LTI tool consumer in order to operate in the DMPS eco-system.

For connections to the Student Information System and rostering the Access For Learning Community’s

Schools Interoperability Framework (SIF) specification is the most common and most complete method

of automating data interoperability. This is particularly true for DMPS since they are already using that

standard to have Infinite Campus speak to the Iowa Department of Education reporting system, TIER

and other systems.

For storing content such as assessment items and similar data IMS Global’s Accessible Portable Item

Protocol (APIP) and Question & Test Interoperability (QTI) standards are the right choice.

Many districts are using the Ed-Fi specification to support their dashboards, but this may not be the right

choice for DMPS’ since they are using Tableau. If DMPS decides to build out an Ed-FI Operational Data

Store (ODS) then DMPS will want to make sure its Data Broker solution includes interfaces for Ed-FI as

well as SIF and Comma Separated Value (CSV).

Persistent Data Storage

When moving from a system with a single application or a small number of applications to a more

enterprise ecosystem that includes applications from multiple sources, it is important to consider the




question of separating data from applications. Data will be generated by multiple applications and

access to that data will be needed across multiple other applications, including roster data, demographic

data, assessment results, grades, competency, etc. It is no longer practical or sustainable from an effort

or a cost point of view to have the data locked in each of the individual applications.

One of the core functions of an Operational Data Store (ODS) is to create a centralized store of the data

that can that act as an authoritative source of truth for all the applications, services, and reports in the

eco-system.

While some might label Infinite Campus as an operational data store, in this context where data and

apps are in separate layers, we would label it an application-embedded database. CELT recommends

thinking of an operational data store as the persistent, independent, multiyear data structure that

receives and shares data from application-embedded databases, and subsequently moves it into a

longitudinal data warehouse and then archives as appropriate.

The ODS and data broker (a traffic cop for data) in the future-state-architecture have an additional

function of integrating data across applications.

Sources of Truth

This is really a function of data governance and stewardship rather than architecture but it is so

fundamental that it needs to be addressed here as well. As data becomes more and more distributed

and used in multiple locations and possibly generated in multiple sources, it becomes essential to lock

down which application, service, or database is the authoritative source of truth for which data element.

What complicates this is that there may be:

time periods involved (start of year and end of year might need to both be retained),

permanency (some data elements are, such as the student ID, not allowed to change barring

errors in data entry),

context (the name a student penciled into an assessment sheet might need to be maintained

for tracking and vendor management purposes),

function (the transportation app may have a slightly different drop-off address than the SIS has

as a home address), and

ownership (the Free and Reduced metric of the student may be owned by the Child Nutrition

application but persistently stored in Infinite Campus)

This is a function for the data governance process but will drastically effect the data brokerage and

interoperability rules of the enterprise architecture.

This ownership metadata can be stored and tracked in the “Data Domain” tab of the Data Management

Architecture Workbook.

Navigation

A key thing to determine is the user experience your data users will have as they enter the school

district system(s) and perform their daily work. Essential pieces of this is determining:

how many hops a user has to make,

if they need to enter redundant information,




if they have to learn duplicative processes in different applications or even worse in different

screens of the same application

how many steps are needed to perform the most common functions.

It is essential to manage a “Portal Gateway” to the system. Most frequently that involves role-

based portals that organize links and entry points to the applications, services, and links that a

role can access.

Some districts try to use their SIS or their LMS as the “navigation integrator” but this tends to fail as the

vendors tend to discourage users from going to anything but their resources. A District owned neutral

portal is usually more successful. Another option is a very strict customization agreement with the

appropriate vendor. Controlling navigation is controlling the user experience and so this is a critical

question to resolve.

This is related to the security question of SSO, access, authentication and authorization. Any navigation

structure needs to be able to recognize the user’s identity as they move through the system and only

allow them access to the data they are authorized to view or edit without making them re-authenticate

constantly.

Reporting

One of the fundamental functional elements of an education enterprise system (besides operationally

supporting district policies and processes) is to generate data, information, understanding, and wisdom.

This supports school district leaders and educators in making tactical decisions and guides strategy that

supports the vision and goals of the district.

There is a strong governance part of this issue in that the questions that need to be answered by the

system need to be framed by its leaders, defined by its data governors, and specified by its data

stewards. But there is a data and technical part of that as well, once the questions and data elements

have been defined by the leaders, governance and stewards, the system needs to be able to:

Display the answers in tables, graphs and visualizations that communicate the answers in a way

that is useful and quickly understandable to the consumer of that information;

Allow users to be able to navigate to those displays; and

Be 508-compliant or have alternative table-driven versions for sight-challenged or access-

challenged users.

Currently DMPS uses Tableau reporting software to build its static reports and application-specific ad-

hoc reports are built inside the Infinite Campus application.

The questions DMPS needs to ask is:

Do we want to continue to use Tableau?

Do we want to continue to rely on Infinite Campus for ad-hoc reports?

Do we want to invest in an independent platform to consolidate static, and ad-hoc reporting?

o Could Tableau be that platform?

Do we want to build a Data Warehouse with reporting built on that?




o Currently native ad-hoc and static reports live in individual applications (IC, B+, LMS).

Each tool has their own built-in reporting functionality with no consistency or

homogeneity.

o Do we use Alteryx or some other data interoperability method independent of Tableau?

Are there reporting types not represented in the current Tableau interface?

Security Operations

Security is essential and tied directly to directory, navigation and role-based access. In this scope of

work we will focus on the security of the data in motion more than the security of data at rest. As a

result we will focus on user access and application to application data transfer.

The key architectural issues surrounding security of data in motion have to do with four things:

1. Authentication: Answers the question “Who is this?” It is the process of a user identifying

themselves either through a user name and password, two-factor authentication, biometric

indicators (fingerprints, retinal scans), hardware (ID card with RFID tag, USB plugin), or

secondary validation (another user validating).

With a distributed user base like education has, it is almost impossible to use any authentication

outside of user name and password since many users of the system are not employees

(students, parents, outside educators). It is possible to use a multi-tier structure with the

majority of users utilizing one level of authentication, while more secure users have a more

rigorous/secure method required to get at more secure data.

a. Common methods for this include local login (Windows certification), OpenID Connect,

Security Assertion Markup Language (SAML) interfaces, or OAuth.

2. Single Sign On/Access: Having users only authenticate once in the system and then having the

system “remember” who they are for that “session”. This can be done by a variety of methods.

OAuth and OpenID Connect are the most accepted standards for doing this today.

3. Authorization/Access: Answers the question “What can this user do or see?” It is the process of

connecting the user to roles in relation to institutions or groups and applications or services.

OAuth and OpenID Connect are the most prevalent way to pass this kind of “trust” data in a

secure fashion, but many systems still use homegrown SAML interfaces.

4. On-The-Wire Security: This is the process of securing the bits as they flow from one computer to

another. Secure Sockets Layer (SSL) 2 and 3 are the most common ways of encrypting and

securing the “pipes” but these standards are being deprecated and browsers will stop

supporting them in 2018. All long-term systems should use the Transport Layer Security (TLS)

Protocol. An excellent beginner’s guide to this topic can be found here:

https://www.sans.org/reading-room/whitepapers/protocols/ssl-tls-beginners-guide-1029.




Privacy

Privacy does not really live in the domain of architecture, but rather governance and policy. However

those people designing interfaces and database structures need to know some extremely important

facts in order to design those structures correctly:

Personally Identifiable Information (PII) Data: What does the district consider to be PII? What

context makes those data sensitive? Under what conditions does policy allow those data to be

released?

What are the identifiers that can be used by the system to uniquely identify each entity? Where

is the potentially PII data used to generate that identifier stored? How can it be validated?

Vendor Use Governance: What kind of controls do vendors need to put in place on their

interfaces to be consistent with school district policy? What retention and access policies do

they need to encode to be compliant?

Many interfaces in their raw state have no privacy controls. This needs to be explicitly included in

contracts and designs with all third-parties.

Enterprise Architecture Resources

An excellent resource for public education agencies in grappling with enterprise architecture issues in

education is the Education Architecture Guidebook

(http://www2.ed.gov/about/inits/ed/implementation-support-unit/tech-assist/education-architecture-

guidebook.pdf). Although it is oriented around state systems, it is applicable to any school district

enterprise as well.

http://www2.ed.gov/about/inits/ed/implementation-support-unit/tech-assist/education-architecture-guidebook.pdf

http://www2.ed.gov/about/inits/ed/implementation-support-unit/tech-assist/education-architecture-guidebook.pdf




Section 3.0 Current State

NOTE: There exist many data transfer processes in DMPS currently that rely on Excel sheets on both

sides of the process. They are fairly prevalent but are not represented here since they are entirely a

manual process. It is assumed these will never entirely disappear but they should be replaced with

sustainable, documented automated processes to whatever degree possible.




Component Summary

Key Title Description

1 Infinite Campus

Application Data Store

Database which holds all student information for district. As mentioned earlier

this is not really an Operational Data Store but really an Application Data Store

designed to serve Infinite Campus' functions.

2 Infinite Campus SQL

Replicated Data Store

Database which holds student information related to district reporting. It is a

replica of the IC Application Data Store.

3 SunGard Business Plus Enterprise Resource Planning Software for managing district financial and

employee information.

4 Transportation SQL

Database

Database which holds bus route related information for the district.

5 MIS Application to manage the food service sin the district.

6 Other Applications A wide variety of applications used throughout the district.

7 Alteryx Data blending and transformation software used prior to visual analysis by

Tableau 8 Tableau Business Intelligence and data visualization software.

9 State Reporting State reporting application that accepts SIF and/or CSV data from Infinite

Campus.

10 IC Student/Parent

Portal

Portal for Students and Parents to access Infinite Campus resources.

11 AppliTrack Application for tracking applications in the district

12 Battelle Human resources management software for improving HR process effectiveness.

13 TIER RTI Application fed from IC

Connection Summary

Key Type Description

A SQL Replication Maintaining consistency between database objects by copying and

distributing all tables and elements as well as synchronizing.

B SQL Read-Only Alteryx and Tableau read the desired data from the data structure and use

that to populate the report. Data is not persisted.

C Proprietary Interface Alteryx and Tableau have a proprietary connection between their systems

which allows for easy integration of data between the two.

D Manual Upload Manual Process of moving data into Battel.

E Data Elements Pulls Individual Data Elements are pulled from Administrative Apps to populate

selected fields in the IC application.

F SIF/CSV State reporting from Infinite Campus. Can accept SIF or CSV. In current

state – most often CSV.

G CSV Connection from Business Plus directly to State Reporting via Manual CSV

upload

H SIF SIF interface to TIER system from IC.

I Native Connection Infinite Campus native connection to IC’s own Teacher/Student Portal




Section 4.0 Future State Recommendations




Component Summary


1 Learning Management System Software(s) used for the administration and delivery of electronic

educational technology.

2 Teacher/Parent/Student Portal Point of access to district learning management system for teachers,

students, and parents.

3 Instruction Content Content available online which relates to in class lessons.

4 Instructional and Curriculum Apps A wide variety of applications used throughout the district for

instructional learning. These can be district, school or classroom level.

5 Infinite Campus Student Information System - holds attendance and roster information

for district.

6 SunGard Business Plus Enterprise Resource Planning Software for managing district financial and

employee information. 7 Alteryx Data blending and transformation software used prior to visual analysis

by Tableau 8 Tableau Business Intelligence and data visualization software.

9 Administrator Portal Administrator's navigation access point into the eco-system.

10 Administrative Applications Software used by district leadership to track and oversee school system

activities. This includes MIS Food service, Library, Transportation… 11 Data Broker Aggregates data between applications across the school district

12 Data Warehouse/Operational

Data Store

Integrates multiple data sources in order to further data analysis.

13 State Reporting State reporting application that accepts required State and Federal

reporting data from Infinite Campus.

14 TIER RTI Application fed by SIF (currently and in future) from IC

15 Professional Development Software used by district for teacher and faculty professional

development.

Connection Summary

Key Type Description

A SQL Replication Maintaining consistency between database objects by copying and

distributing all tables and elements as well as synchronizing.

B LTI Standard method for integrating LMS and other systems with online

learning apps and content resources.

C, D,

H, I URI A unique identifier which helps one understand a point of entry into an

online resource. A "link".

E Read-Only Currently this is a read-only SQL operation to generate visualizations in

Tableau.

F Proprietary Interface Alteryx and Tableau have a proprietary connection between their systems

which allows for easy integration of data between the two.

G Data Warehouse to

Alteryx TBD

J, P Data Broker to LMS Should use either SIF or LTI depending on the LMS.

K, L,

M, O,

Q, R

SIF An interface with standard object and element names to connect two

systems and maintain consistency in data between them. State reporting

can be done with CSV but in future-state should always be done by SIF.




N SIF or EdFi Either EdFi or SIF could be used for this connection depending on a further

discussion.

Key Observations:

Learning Management System (LMS)

Although the LMS is shown here as a single entity that is only for ease of depiction. Depending on how

the LMS project in DMPS develops the functions traditionally associated with an LMS may encompass a

set of applications and services that are designed to work together or it could be a monolithic system.

There is an issue in K-12 education today around the LMS and what it is exactly. The label of LMS which

implies one, monolithic, all-encompassing system is neither necessarily accurate nor helpful. Rather,

there are categories of applications and data stores that collectively can fill the need of teaching and

learning. Some of the objects shown here– like the LMS- could be both at the District and/or the School

level or possibly only in one or more classrooms.

Some of these applications that are not included in these diagrams could include:

standards reference framework;

learning resource discovery engine;

learning maps;

learning registry;

observation/feedback function;

assessment system;

reporting system;

content libraries;

recommendation engine; and

artifacts of learning library.

Blended Learning Strategy

This suggested architecture is designed to give DMPS maximum flexibility in future direction and

maximum sustainability. The design of the LMS project will become very important to ensure that it

supports the pedagogical and strategic goals of DMPS. If DMPS is pursuing 21st century pedagogy and

blended learning (which it is), this typically means that the classroom teacher has a lot of freedom in

selecting their tools. A hybrid strategy that includes a federated integration strategy and a centralized

ODS together with the site-based autonomy of blended learning tends to work. This suggested

architecture will support any of those paths moving forward with the minimum of future adjustments.

It will also allow the system to start relatively small and grow as need demands rather than do

everything at once which is operationally challenging and probably fiscally impossible.




Section 5.0 User Interface and Security




Component Summary


1 Administrative Applications Software used by district leadership to track and oversee school

system activities.

2 SunGard Business Plus Enterprise Resource Planning Software for managing district

financial and employee information.

3 Learning Management System Software used for the administration and delivery of electronic

educational technology and to manage the pool of instruction,

curriculum, and assessment software.

4 Instructional & Curriculum Apps A wide variety of applications used throughout the district for

instructional learning.

5 Infinite Campus Student Information System - holds demographic, attendance,

roster, and other information for district.

6 Instructional Content Content and learning resources available online.

7 Administrator Portal Point of access to district systems for administrators.

8 Teacher Portal Point of access to district systems for teachers.

9 Student Portal Point of access to district systems for students.

10 Tableau Data blending and data analytics software.

11 Directory -

Student/Teacher/Parent/Administrator

This is the source of identity/authentication data for all key entities

in the district. Connected to the portals via an SSO standard of

some kind (like OpenID Connect or something similar).

12 App/Role This is the source of authorization and access data in the district.

Deeply connected to the Directory.

13 Parent Portal Point of access to district systems for parents.

Key Observations

Each of the source applications has their own non-homogenous user interface, controls, and admin

interface. This diagram represents the interfaces that represent district interfaces that are not

application specific: the teacher, admin, student, and parent portals and reports generated through

Tableau.

Most of the links to the portals will be URI or “links” that when clicked on will bring the user into the

source application’s interface. A Universal Resource Identifier, or URI, is a string of characters used to

identify the name of a resource. A URL is a sub-set of a URI. A URI may include LRMI–metadata as part

of its structure. The School District can centralize that to a certain extent- it can drive most traffic to IC,

B+ and Tableau. But there will be other interfaces.

The Portals represent a coherent navigation structure to make sense of navigating to the many District

data, service, and reporting functions.

The Portals also should directly link to the Directory, security, and SSO services (Interface M) so as to

allow role-based access/control over which links get exposed to which users.




Section 6.0 Definitions

The following terms and acronyms are used commonly in this area and need to be defined.

These definitions (or similar terms) should be adopted by the organization to facilitate

understanding of the system.

Alteryx - Data blending and transformation software

API or Application Programming Interface – this is a description for how computer

applications interact with each other. Adopting a standard set of APIs can help reduce

the costs of interfacing (or integrating) different applications that need to share data.

Application Sponsors – experts maintaining the tool/product that collects and stores

data elements.

Business Plus - SunGard's Business Plus (DMPS’ Business Application). Enterprise

Resource Planning Software for managing district financial and employee information.

Current-State Architecture – a visualization of the district’s applications and data

structures as they exist in the current state. Such a visualization can be accompanied

by descriptions and issues that exist with the current set of applications and data

structures.

Database – an electronic structure and mechanism for the storage, description, and

management of discrete data elements and bodies of information.

Data Category – see also the definition of Data Domain – a data category is a grouping

of related data elements within a data domain and entity.

Data Collection/Reporting Event – a required collection of data from the schools to the

district and/or a required reporting of data to the State, federal, and/or other authorities.

Data Dictionary – a system to keep track of the specifics (source system, etc.) of the

data elements within an organization and the metadata (data about the data) for all the

data elements.

Data Domain and Data Entity – data is organized in a hierarchical structure for the

purpose of assigning data stewards and for capturing metadata about the data. Domain

is the highest level of the hierarchy. Each domain is broken down into a set of data

entities. Typical domains and entities include those found in Table 5.1. The hierarchy is

further broken down into categories and data elements.

Data Element - a discrete piece of data, e.g., “age,” “ethnicity,” “test score”.

Data Owners – designated by the Data Steward as the caretaker of a set of data

elements on behalf of (e.g., delegated by) the Data Steward. (These may be the same

as the Process Stewards in DMPS)

Data Management Steering Committee – a council made up of the Data Stewards of

the organization.




Data Policy Committee – Executive management and appropriate external

representatives who approve data procedures for the organization.

Data Stewards – the individual owners/caretakers of the data categories. There should

be one, and only one, Data Steward for each data element.

Data Store – as used in this report refers to a combination of operational and

longitudinal data stores.

DW - Data Warehouse (see “LDS”)

Edge Device- Any technology that a user would utilize to access the Internet: a game

console, phone, a laptop, a table, a desktop computer.

Future-State Architecture – a visualization of the desired future architecture for all

district applications and data structures. Such a visualization can be a roadmap to the

acquisition of future systems to address the deficiencies documented in the current-state

architecture.

Governance (as related to data) – a combination of procedures, organizational roles

and responsibilities, committee and team charters, and job descriptions that collectively

describe how decisions are made, monitored, and enforced regarding the management

of the organization’s data.

IC - Infinite Campus (DMPS’ SIS)

Longitudinal Data Store (LDS) – also frequently referred to as a data warehouse. The

LDS sits behind and receives data from the ODS. An LDS is updated less frequently

with snapshots of data that are timed, cleansed and organized to support long-term

retention, analysis over time and external reporting.

LMS - Learning Management System

LRMI- Learning Resource Metadata Initiative. A federal project to create a web-based

set of keywords that can allow learning resources to be identified and located using web

protocols.

LTI - Learning Tools Interoperability specification

Metadata – refers to data about data. In the manner in which it is used in this document,

metadata refers to data that describes assessment results. For example, in addition to

the assessment results that can be sorted by school, classroom, teacher, etc. it is also

important to know additional information about the assessment data that will be helpful in

interpreting the results. This might include the instructional standard(s) that the

assessment measured, the subject and grade level of the assessed material, and the

level of difficulty of the assessment. This metadata can be stored with the assessment

itself.

Operational Data Store (ODS) – a collection point for an organization’s data from

various source systems. An ODS receives the data from the source systems, often in

near-real time. The ODS has the latest data from the source systems and may also




retain a history of the data elements. Data may not be fully vetted for external reporting

to the public, but rather is used more in an operational mode by internal staff. Generally

an ODS is not to be used for ad hoc queries and analysis.

Process Owners – designated by the Process Steward as the caretaker of a set of

processes on behalf of (e.g., delegated by) the Process Steward.

Process Specialists – experts serving in a consultative role for the Process Stewards.

Process Stewards – the individual owners/caretakers of the district processes. There

should be one, and only one, Process Steward for each district process.

SIF - Schools Interoperability Framework

SIS- Student Information System

Source System – typically a transactional IT system that collects and stores data and is

considered the originating source for certain data categories and is also the provider of

that data to other systems. Examples include a financial system, human resources

system, student information system, or assessment management system.

TLS- Transport Layer Security Protocol

URI- A "URI" is a more generic term for a URL. It encompasses more connection types.

It is a "Universal Resource Identifier"-a string of characters used to identify the name of

a resource. Such identification enables interaction with representations of the resource

over a network, typically the World Wide Web, using specific protocols.

URL- A "Universal Resource Locator" (URL) on the other hand refers to the subset of

URIs that, in addition to identifying a resource, provide a means of locating the resource

by describing its primary access mechanism (e.g., its network "location").

Documents

Data Architecture Current and Future State Architecture Current and Future State Analysis and Recommendations on DMPS’ Information Assets January 2016 Version 0.21 Center for Educational