I'm pretty familiar with this problem space having worked in both a state department of education and a school district.
I would not expect this to be a long term success. Virtually every district of reasonable size starts with a homegrown and maintained solution and ends up going with one of the big guys for lots of reasons.
1. Security/liability. You have to have pretty damn good systems here and definitely want to point at someone else's assurances and contract that allows for recourse.
2. Rapidly changing business requirements. This is everything from state and federal reporting requirements to the expectations of end users. It's hard enough to maintain these core systems and keep folks around who are good enough to do it. Now deal with changing technology (oh you want a parent portal? Oh, you don't want to use Flash/Java for iPads? Oh you want ...) and you really can't attract and retain the kind of software people you'd want to continually redesign, refactor, rebuild, extend, and expand. Development on these systems never stops, which is why it's often easier to just drop off the old and buy the new hotness. It's also why scale is so helpful with these systems. If your users want this, someone else already requested it or will shortly. A lot of the improvements in these systems happen because of how many users they have and can be made because the cost is spread across all those users.
3. Interoperability with other systems. Most of these systems are not omnibus catchall solutions for the entire business needs of a school district. That's probably for the better-- the folks who try to do that end up doing it very poorly. But you will want your HR and payroll to talk to your student information system that should probably talk to your assessment system that should talk to your curriculum management system that should talk to your special education IEP case load management system, etc. It's hard to do this and even harder when your solution is built to work in one context. Standards here have only barely helped. Middleware is expensive, shitty work. Again, not easy to attract killer talent and it is a constant need. The big boys have everything else built and just focus on middleware and have probably already worked with and written what's required for all of the popular systems you are using in these other areas.
This is just the smallest fraction of reasons it's a huge PITA to write and maintain these systems. That's not to say that it can't be done but it is to say that this is not a small, well-defined problem space with just a few distinct end-user types and functional requirements that can be built once and then monitored and tweaked over time. Not if you want to do the real stuff that makes collecting and maintaining all of this data worthwhile.
While all three of your points are excellent concerns, I think you may be giving off-the-shelf systems a little too much credit.
The SIS systems I know (US, K-12) do a mediocre job of updating quickly to new technologies/requirements (#2) and do a terrible job of interoperating with other systems through APIs (#3).
Doubleplus agree. Have been working with a state department on a student registration system for the past few years, and now everything's going to be placed under one of the 'big commercial' players in this space. No interop specs have been delivered/offered, and the integration team seems wholly unaware of the complexities of the requirements laid out by the state for the types of processes we have to comply with. And talk about 'not adapting'? We have processes in our system relating to HR and the commercial team flat out said "we don't want to deal with that", but also balked at offering us any sort of integration service points (REST/SOAP/anything) to keep doing what we need to do next year.
I've never met a software vendor in this space that has a freaking clue what they're getting into when they sign these contracts. They never think about interoperability despite signing on to the requirements, they assume too much when it comes to their customers defining requirements, and hate offering up the goods to work with other systems you have in place (but can usually be twisted to offer bare minimum integration).
That's why I think you're better off with something you can sever ties with when it falls behind on #2 and use clear RFP and contract requirements + in-house dev talent to drive #3. The hardest to deal with is always going to be #3 because everyone always is trying to get you to use their whole architecture, even thought most of the time they suck at some or all of what they sell.
I think that #3 will also get a lot better with commercial software. The reality is that most of these guys have spent the last 5-10 years buying up competitors who built other systems their customers were interested in as an attempt to get all that business under one contract. Their efforts integrating software from acquisitions has been pathetic, at least in part because they haven't had a services-oriented architecture even though that's what really is called for. So I think this is a major area where we'll see changes in the next 5-10 years.
That being said, I think pretty much all off-the-shelf systems suck, but you're better off being able to hold someone else responsible for dev and sustainably meeting requirements and use in-house talent to hack around and problem solve so that users end up getting what they need fast.
You also want to chuck systems every few years and get something a lot better without having to pay the upfront costs of a rewrite like you would with a BYO-SIS.
And while I think this goes without saying, though these days I've seen districts screw this up, no matter how hosting is taken care of you need to own that data. You need nightly backups on servers you control and full access to your own information.
I'd add that your suggestion for #2 (migrate from one system to another every handful of years) has some pretty painful costs associated (PD/training, re-implementing customizations, data migration costs). At least when you've taken care to own your data/backups, this kind of migration is possible.
5-10 years is far too long to wait for system interoperability. My company (Clever - getclever.com) has bolted a read-only API onto a dozen of the top SIS systems today, would love to hear your thoughts (I'm dan@).
another good point. Our district has gone through five, count them five, commercial student information systems because the company has either gone bankrupt, been bought out by a larger vendor or depreciated. We just get our data converted, staff trained and somewhat comfortable and then the rug gets pulled out from under us again and we have to start over.
Anyone who think that commercial vendors are there to support education is dreaming. Commercial vendors are there for two reasons only - earnings per share and profitability.
while it may be a point that they may have to rewrite it down the road, the advantage is they retain the logic so they don't have to start again from square one with a new vendor trying to get their system to work.
Also they could opensource it or sections to get help in hardening the code, create interoperability APIs, or anything they choose. Such an option is usually not a possibility with a private vendor.
Another issues is when you do have a significant change in law or policy getting the vendor to get those updates out in a timely/inexpensive manner may not be so easy.
Interoperability is overrated, what happens when HR decides they to get a new system? ...and that new system doesn't work with your current tracking system X but only with the much more expensive and over complex Y pro system?
I guess it comes down to is how important is it to have your hands on the data and process? I know some schools are really tiring of the "new system every five years or so" cycle that they go through (this can include, besides software, new hardware, training, reassigning staff responsibilities - all depending on the systems needs,) having control of costs and process might help them in the long run.
"2. Rapidly changing business requirements. This is everything from state and federal reporting requirements to the expectations of end users. It's hard enough to maintain these core systems and keep folks around who are good enough to do it".
In mid 2011 our state passed some new laws as to how funding would be applied for virtual school enrollments across the state. We had a model in place, then code rolled out, within a few weeks - we had one bug that reared its head a few months later that was patched in a day and it's been fine since.
I'm not convinced the 'commercial player' that's taking everything over even understand the concept of our funding model, much less will be able to reliably integrate it with their existing systems, in the next 6 months. That's after handing over the code (with some, but certainly nowhere near complete, tests).
They may still pull it off, but I've yet to see them react quickly to 'changing business requirements'.
We will absolutely not be moving to a commercial vendor with this product. Right now we are creating a not-for-profit society which will be the vehicle to ensure this is maintained as a shared-service dedicated to support IT initiatives in our school districts. We are very tired of being tied to commercial vendors whose sole focus is earnings per share and profitability. In any case please have a look at our business plan and see what our focus is in doing this.
It is a model which could easily be adapted by other jurisdictions whether in Canada the US or anywhere else for that matter.
We are always open for questions, suggestions or comments.
I would not expect this to be a long term success. Virtually every district of reasonable size starts with a homegrown and maintained solution and ends up going with one of the big guys for lots of reasons.
1. Security/liability. You have to have pretty damn good systems here and definitely want to point at someone else's assurances and contract that allows for recourse.
2. Rapidly changing business requirements. This is everything from state and federal reporting requirements to the expectations of end users. It's hard enough to maintain these core systems and keep folks around who are good enough to do it. Now deal with changing technology (oh you want a parent portal? Oh, you don't want to use Flash/Java for iPads? Oh you want ...) and you really can't attract and retain the kind of software people you'd want to continually redesign, refactor, rebuild, extend, and expand. Development on these systems never stops, which is why it's often easier to just drop off the old and buy the new hotness. It's also why scale is so helpful with these systems. If your users want this, someone else already requested it or will shortly. A lot of the improvements in these systems happen because of how many users they have and can be made because the cost is spread across all those users.
3. Interoperability with other systems. Most of these systems are not omnibus catchall solutions for the entire business needs of a school district. That's probably for the better-- the folks who try to do that end up doing it very poorly. But you will want your HR and payroll to talk to your student information system that should probably talk to your assessment system that should talk to your curriculum management system that should talk to your special education IEP case load management system, etc. It's hard to do this and even harder when your solution is built to work in one context. Standards here have only barely helped. Middleware is expensive, shitty work. Again, not easy to attract killer talent and it is a constant need. The big boys have everything else built and just focus on middleware and have probably already worked with and written what's required for all of the popular systems you are using in these other areas.
This is just the smallest fraction of reasons it's a huge PITA to write and maintain these systems. That's not to say that it can't be done but it is to say that this is not a small, well-defined problem space with just a few distinct end-user types and functional requirements that can be built once and then monitored and tweaked over time. Not if you want to do the real stuff that makes collecting and maintaining all of this data worthwhile.