Competing Goals When Choosing A New SIS

Jason Dunk, Chief Technology Officer

Jason Dunk, Chief Technology Officer

My school board recently replaced our long-serving student information system with a new SIS. It’s an exercise that, if you’re lucky, you’ll only experiencea handful of times in a career. I say that because the SIS affects every area of the organization, from student data to assessment, reporting, parent communication and business planning. Few projects haveso many vested stakeholder groups being serviced by a single piece of software, and you quickly discoverthe complexities and unavoidable compromises.

Part of the complexity is on us, and what we expect from a SIS. Consider that the RFP criteria checklist was over 120 items. That’s a challenge for any vendor’s software to address, but current SIS offerings arelarger and more complex than ever, a web of interconnected products aimed at every area of a school division. Like an arms race, vendors competethrough development and acquisitions, hoping to offer a ‘one-stop-shop’suitethat satisfies all our needs. The proposal is enticingly tidy, a single solution from a single vendor in its own ecosystem.It brings all the stakeholders into a common framework, streamlines procurement, and can readily fit into a total cost of ownership slide deckwhen you’re presenting to the CFO.

While buying into a single ecosystem is standard in aWeb2 world, our need for flexibility outside of defined ecosystemsisgrowing. Consider OneRoster as an early bellwether,endorsing the need for API’s and data fluidity. For many, that’s been .CSV exports to rosteran LMS,or feeding a separate data warehouse.This time round, on the cusp of a decentralized web, the current locked-in ecosystem with CSV exports and basic API’s seems dated.

Our users are savvy, quick to discover the limitations of‘one-stop-shop’ SIS suites. Teachers are knowledgeable about specialized alternatives, the slick parent communication appsorflexible, modern gradebook tools. In response, SIS vendors will highlight their partner market to fill gaps andtout commitments to development and acquisitionsthat willforever expand their utility. While that may sound good, the result for customers is often increased vendor bureaucracies, greater distance from the actual users,and development goals that feel like they benefit the company more than the customers. At some point, the act of trying to be everything to everyone invariably dilutes the result, as “a jack of all trades is a master of none”.

As consumers, we have influence on what the SIS market offers by way of our RFPs. Granular licensing is a start, where procurement caninsist on a la carte pricing to only pay for what we use.That should appease the CFO, but it doesn’t address the need for better access to our data. If we want flexibility to integrate specializedtools, we need the ability to move our data in and out in a modern, efficient manner. Leaving CSVs on the back steps each night won’t suffice in a Web3 world. We should be pushing for more extensive, bi-directional API’s, that allow us to better integrate other software. If data exists in the SIS, it’s both inefficient and illogical to re-enter that same data in an adjacent system.

My next SIS refresh is probably six or eight years away. In the meantime,I’ll be an observer, watching with interest as vendors respond to an increasingly decentralized web. There are already examples of niche software with extensive API’s, so I’m hopeful my next SIS RFP will have more boxes checked than not.