Data in Schools: Approaches to Data System Architecture
This blog post is part of series entitled Data in Schools, where I investigate the elements of using data, building data systems, and analyze data for decision making.
Data in Schools:
Approaches to Data System Architecture
When schools build their data ecology, or the combination of data and data system, they have to make some key decisions. They must address several elements of their systems from user access and security to the data dictionary and analytical tools. However, at the core of any data ecology is the Data System Architecture.
The Data System Architecture is system or combination of systems schools use to meet the data and operational needs for all its departments. It is the fundamental design for how data comes in and out of the school, where data is housed, how data is accessed, and through which conduits people connect to their data.
Sadly, most schools will neglect this key aspect of their data systems and they will end up with a mish-mash of products, all of which are managed separately and none of which interconnect.
For the long term health of the school operations, the security of school data, and to be prepared for the analytical and big data needs sure to come to schools in the next decade, it is critical that schools take a forest level view of their Data System Architecture. That is to say before they plant the trees (the data systems and the interfaces) they should know how they plan to layout the forest (the architecture).
There are three types of architectures that schools can adopt:
- Custom solution
- Combination of systems
With the all-in-one architecture, the school manages a single data system that meets all of its need. As opposed to the common approach of different systems for different needs or departments, an all-in-one is a unified system that covers all the schools operations and data needs.
Typically, a school will have 1-3 all-in-one systems: one for finance and operations, one for academic and stakeholder data, and one for communications. This is due to the fact that no single system is available to cover all operational and academic needs for a school…though a few try.
Commonly, the finance and operation all-in-one systems are called Enterprise Resource Planning (ERP) systems and they will manage everything from budgeting to accounting to procurement and assets.
- A central data storage – a single database will host all the data
- Unified user interface – A single look and feel of the system interface
- Large amount of control over configuration – the systems are customizable to meet many needs of the organization or departments therein
- All (or many) operational departments using the same system – By using the same data system, departments will have a hard time fracturing or siloing.
- Very expensive – Major ERP systems alone can run in the hundreds of thousands of dollars
- Very complicated – With so much control over customization, the configuration will be complex
- Large maintenance costs – Personnel (IT and operational) will be needed to manage the system within the organization
- Inability to change the system – With large scale product changes for individual clients are rare.
- Single point of failure – All data is housed in one place
A custom solution is a data system or set of data systems specifically designed and developed for the school. A developer will take a list of requirements from a school and create a solution to addresses each of those needs. These developers are usually companies easily accessible to the school, rarely large scale in their operations. The systems they create can range in complexity and usability based on the quality and diligence of the developer.
- All of the pros found in an all-in-one data system architecture
- Solution that meets the school’s needs – The system will do what the school wants it to do rather than altering its practices to meet the capabilities of the system
- Full ownership – The school will own the design, software, and data.
- Ability to change – Needed changes can be made by the developer to meet specific requests
- Personal communication – The school will have direct contact with the engineers and designers making their solution
- All of the cons found in an all-in-one data system architecture
- Reliability of the solution– A custom solution will not be tested in a larger market and may have significant issues
- Higher cost – A contracted developer will cost more than a combination of systems
- Reliance on a single vendor – The school is reliant on a single entity to create, maintain, and provide support for the product. If the developer is delayed, unresponsive, or goes out of business the school could be stuck
- Slow to update – Large scale data system vendors will update their products frequently, whereas a custom solution will only add features upon request.
Combination of Systems
Through a combination of systems architectures, school will subscribe to multiple systems to meet individual needs. They will buy an overarching Student Information System (SIS) and then add other systems that meet requirements for various departments. For example, they may purchase an admissions system to manage the admissions process and move data into the SIS.
Each of the systems a school purchases under this data system architecture will be run by a company larger than the customized developers, but smaller than the all-in-one solutions providers. There will often be several options for these systems as the market is quite large. However, each available system will have unique features and requirements that may or may not align with the school’s operational practices.
- Departmental needs are met – Each department will have a system that meets their data system requirements
- Reduced cost – By distributing out cost amongst several systems the overall cost is lower than all-in-one or custom solutions
- No single point of failure – Systems operate independently so if one goes down the others are not directly affected
- Professional quality systems – Each system will be developed to meet a specific operational need. As such it will be robustly designed and tested with a large group of schools. It will take the most common practices in that field and account for them
- Siloing of departments – As each operational unit has their own system, they will naturally separate. This can result in diminished communications and information exchange
- Separated data – Data will be held in multiple systems with unification or redundancy. This can result in mismatched data, duplication of operations, and inability to report or analyze data in the aggregate
- Management complexity – Ownership and maintenance of each system will be individual. The school will need personnel to understand specifics of the systems and how they interact. Further, functional owners of each system will be required in the operational departments that use them
Regardless of how schools approach Data System Architecture, whether consciously or as the product of resultant, individual decisions, they will land on one of the three types. Knowing the pros and cons of each architecture is vital in the long term strategic growth of the school and its ability to manage costs, improve efficiencies, and develop a systemic data analysis scheme, all of which are becoming vital in contemporary education.
Follow me on TwitterMy Tweets
Powerful Models for EdTech | edtechdigest.com
2017/09/14 By mattharrisedd
It’s 10 P.M. Do You Know What Apps Your Children Are Using? - The New York Times
2017/09/08 By mattharrisedd
How school districts are leveraging Twitter to become rock stars | eSchool News
2017/08/30 By mattharrisedd
Teaching Generation Z? Start by engaging their parents—here’s how we did it | eSchool News
2017/08/30 By mattharrisedd
Learning to Think Like a Computer - The New York Times
2017/08/30 By mattharrisedd