What are we talking about when we say ‘data interoperability’? Consider this analogy…
You’ve got a kitchen and you mistakenly buy a whole lot of appliances from different countries, which means they all have varying power plugs. The toaster is still a toaster, the blender is still a blender, and a kettle is still a kettle. Individually and in the appropriate environment, they’ll work perfectly. But, in your kitchen with your power points, they can’t function.
Therein lies the problem with interoperability with technology in any situation, school or otherwise. If you’re establishing an office with a bunch of computers that can’t talk to each other, or can’t effectively connect, then what you have is data inoperability, rather than interoperability.
In the case of schools, each school has a source of truth: their student management system. It will be a central database of some sort that holds all the key and associated data about any given student (their name, contact details, information about guardians and, increasingly, their academic information).
The database may hold all that information but the database does not do everything. So schools buy all different types of software – for organising school lunch payments or selling tickets to the school play or sending online forms to parents or managing medical records, etc. – to increase the functionality of their central management system. Generally, we refer to this as a ‘stack’ of software.
But back to the kitchen analogy…
Let’s say you’ve got a core student management system (the kitchen) and you’ve bought five tools (blender, coffeemaker, toaster and so on) but you can’t plug them into your core management system. That means you’ve got six or seven ‘buckets’ of data floating around your school, all of which relate to your students and parents but which don’t talk to each other. That’s not a very viable situation but that’s exactly the kind of situation found in a lot of schools.
Mostly, this comes down to data exchange, which is the interoperability of data or data moving between all of those applications. If the school lunch system knows who the students and parents are, then it is able to help maintain a proper record for a student regarding how much lunch money they have remaining. If they know a student has left the school, then they know they shouldn’t be able to buy lunch. The core system gives the lunch system that information through interoperability.*
There are many student management systems on the market, and each one has its own eccentricities around providing access. As a rule, most abide by a closed system approach (i.e. they are bad at providing access) due to their foundations in technology from around 15 years ago. Today’s software is browser-based and cloud-based, which makes it far more interoperable. Previously, however, they were designed as standalone boxes that ‘you put stuff in’ and ‘you take stuff out’. In other words, they were never expected to ‘talk’ to other software.
As we’ve seen more software coming into schools, the stack has got taller and the older student management database companies are gradually learning to open up their data. They are realising they are never going to be able to have a set of features that deals with every single piece of functionality a school requires. Instead, they’re starting to see the inevitability that a school will have a stack of software and, therefore, those pieces of software will need to talk to each other.
What should a school be asking a potential software provider in order to ensure interoperability?
1. How does it integrate with other products?
2. Does that interoperability exist?
3. Is there an API** available?
Software developers need to remember that a school’s data does not belong to them; it belongs to the school. Accordingly, all schools should be able to access their own data freely and the multitude of uses and benefits that data provides.
* With EdSmart, we make it our business to know the details of all students and guardians and, therefore, who’s allowed to do what and who’s allowed to see what. We do that by reading data directly out of the student management database. That’s interoperability. If the student database knows something, then we know it too.
** An API is a programmable interface for software that enables it to talk to another computer and exchange information.
Find out more about EdSmart’s interoperability by speaking with one of our team.
“Our parents love the immediacy of EdSmart and we now average between 95% and 97% response rate within a week of sending out a notice.”
Burnside Primary, South Australia
