Many people think about the Student Information System (SIS) as one system and they want all of their data from the entire school in it. Conceptually this makes sense and it's easy to understand why people think this way. Practically, this is a very different situation though.
Independent school may have substaintial needs in most of all of these areas: Admissions/enrolment, Attendance, Timetable, Boarding, Academic reports, Government reports, Co-curricular, Events, Finance, Electronic forms, Newsletter, School App, Parent, Student and Teacher Portals, Calendar, Alumni, Libary, LMS, HR, Payroll and lots more!
No SIS in Australia excels in every area mentioned above, and it's hard to envision a time when this will change. Silicon Valley recognized this challenge 25 years ago and shifted their approach. Instead of trying to make their systems do everything, they chose to partner with others who could excel in specific areas. They focused on creating standards for connecting systems together, allowing each system to specialize.
Example diagram of best of breed systems connecting and forming an independent school IT ecosystem.
What is best-of-breed?
Instead of relying on a module within a SIS, a best-of-breed approach uses a seperate application that is focused solely on one area. In this case, we might think of Digistorm funnel, or EnrolHQ are two best-of-breed choices for admissions. While most SIS can handle admissions to some degree, they often do so at a level that may not meet all of a school's needs.
How do Systems Connect?
In the past (or present if you have old systems), you would run all of the software on your servers at your school. Your IT staff would directly connect to the database. They would interact or write simple programs to extract or modify the database, often using SQL queries. While most IT professionals may not know what the acronym SQL stands for, they understand its use for database queries.
With cloud-based servers, database accessibility is restricted due to security requirements so SQL queries aren't an option. To read or write data in a cloud-based server; instead, APIs (Application Programming Interfaces) are used. For an API to function, the vendor must create a window, called an endpoint, which allows access to specific types of data. There must be an endpoint for each piece of data you want to access. Having APIs in an SIS doesn't mean the work of getting data in or out is eliminated; it simply means it's possible.
REST (Representational State Transfer) is a standard for APIs that simplifies these interactions. When someone says, "We have REST APIs," they mean they follow a standard, which is a promising sign.
Limitations to API integrations
API's work like a conversation between two people.
One Party is Unwilling to Communicate: If one party is unwilling to engage, the conversation goes nowhere. This often happens when one party doesn't have an API or treats the other as a competitor, creating a hostile rather than a collaborative relationship.
One Party Doesn't Listen: Sometimes, one party is willing to share information (allowing data reading) but not to receive it (restricting data writing). This is common with SIS's, which often allow data reading but not data writing.
Both Parties Want to Communicate: Ideal integration occurs when both parties engage in a two-way conversation. For example, Timetabler or Edval connect to various SIS endpoints, pulling student and teacher details from the SIS and later pushing back a list with specific classroom assignments.
Deep Integration: The best integrations occur when two software companies invest significant resources to integrate their systems in a way that enhances both products. For example, Schoolbox and Sentral have announced a deep integration allowing teachers to take attendance in Schoolbox as if they were using Sentral. This means teachers using Schoolbox can stay within the platform for most of their tasks, benefiting from Sentral's features through a more accessible interface. Similarly, Toddle - Your Teaching Partner and Veracross are expected to have a deep integration.
Indications of a SIS Provider's Integration Approach
Published Partnerships and APIs:
Check if the SIS provider lists their partnerships and available APIs on their website. This transparency can indicate their openness to integration.
Examples of SIS Providers with Open APIs:
Veracross, Sentral and The Alpha School System (TASS) have published APIs that are accessible to the public.
Edtech Companies Advertising Integrations:
Many edtech companies actively advertise their integrations and partnerships, showcasing their collaborative efforts. Examples include:
FACTS, EnrolHQ, Digistorm, Clipboard, Schoolbox, Canvas LMS, Toddle - Your Teaching Partner, Wonde, Synergetic, EdSmart, Operoo, Paperly, Timetabling Solutions, Edval, StudentNet, K12 Solutions and lots of others.
Examples of Detailed Integration Descriptions:
Intellischool and Orah are notable for providing detailed descriptions of their integrations, clearly explaining their functionality and benefits.
Areas for Improvement:
Compass Education does not currently publish information about their APIs, partners, and integrations. This lack of transparency may be interpreted by other companies as a reluctance to encourage partnerships and integrations. To match their success in the public school sector, it would be beneficial for Compass Education to adopt a more open approach and actively seek partnerships to enhance their offerings.
Beware of the "We Have APIs" Comment
While I welcome open API's based on the REST standard. I have sometimes heard the phrase "We have APIs" often used by sales people to imply that integration with another system is possible, and easy. This statement often comes from someone without experience in the actual integration work, making it seem easier than it is.
Exceptions to Consider:
Existing Integrations: If an integration exists but needs improvement or customization, additional effort may be justified.
Unique Requirements: If your school has unique needs not shared by others, the SIS company may reasonably decide that it's not worth their effort to develop a solution at this time.
In these cases, it's understandable why the SIS company might not prioritize the integration. However, for more common needs, it would be more efficient for the company to handle the integration centrally.
Conclusion
Old systems used SQL queries to directly connect to databases, while new systems utilize APIs. As schools grow more complex, they are likely to require multiple best-of-breed systems, each focused on a particular area. This complexity makes it increasingly important to work with software suppliers who collaborate well, promote their partners, integrations, and APIs.
To truly future-proof your SIS needs, focus not just on the SIS itself, but on its current partnerships and the potential for these partnerships to expand in the future. The ability to integrate seamlessly with other systems will be crucial in meeting the evolving needs of your school.
Comments