There is also the issue of how do you control how much x third party thrashes the server or services if tapping directly into the database, regardless of they are core tables or not. What if x third party wants to poll every 10 seconds for the entire database which in a new cloud installation could be for an entire LA so 100000 kids full records...
I'm not saying that design consideration should be put in to make the MIS resilient but there needs to be check in place.
Last edited by GREED; 16th February 2014 at 10:15 AM.
No, it is the MIS developer's fault if the API allows the third party to kill the DB performance.
Should you be able to ask for a list of all student marks per class from the student, course, and grade book tables? Yes.
However next time you want it that day you the (API user) should be asking only for "what's changed since I last asked"
The api behaviour should enable and encourage that, and discourage poor behaviour of the consumer (by weighting the priority of repeated request for full dumps such that day to day operations have precedence, for example).
Furthermore the MIS provider will be able to see what the 3rd parties are asking for and optimise database (tables, stored procedures, indexes etc) to maximise performance for both their customers and their 3rd party API consumers.
Last edited by psydii; 16th February 2014 at 11:18 AM.
Coulda Woulda Shoulda... It should only ask for but doesn't guarantee a cheap app won't be poorly built.
So you are back into the old territory of having an MIS validate every integration, which of course there is a cost for (so third parties loosing out), then there is an overhead with constantly changing and managing the API to suit all, likely passed back to the third party, and then there will inevitably be losers when things need to be changed to balance performance and availability.
Again, it can and even would ENCOURAGE good behaviour... doesn't mean it will enforce it.
As an MIS supplier my first and foremost priority is to provide a good service to my customers with my software.
If too you have read that there is a changing ideal in the way providers work their API/integration model, then the procedures you have described do not fit, or mean a waking great loss for the MIS company if not passing costs onto third parties (which is the current model with a few supplier, and is crippling to some thrid parties and is actively discouraging innovation and choice in the market... not my opinion but the opinion of several I spoke too at BETT).
Is good to hear different arguments on this topic, exactly what I was looking for!
I'm advocating the MIS providers get into the 21st century and build 'web scale' api's to the enable their customers to pick best of breed applications to meet their needs.
What I see is MIS providers hunkering down in the 1990's model and trying to shifting the balance of power towards themselves and away from the customer.
Also I know at least one MIS provider who has an API (they need it as a marketing tool) but 3rd party will not build against it because the potential customer base is currently too small, even when the school has offered a months worth of developer-sallery scale money to get it done.
Lets be honest here, a "cloud MIS system" is essentially a hosted SQL database and front end. There's not that much secret sauce in that, and neither is it very difficult for the provider to monitor access and highlight anything that's being done in a 'non-approved' manner that is causing problems.
Last edited by Roberto; 16th February 2014 at 06:33 PM.
GREED (16th February 2014)
Someone is... well, was... well still is but not here....
Fair enough and my apologies. I thought you guys had a cloud MIS offering as I live in Bedford and keep seeing Capita advertising for someone to herd clouds locally.
I think my statement about SLAs can still stand if you change where I said "you" to "a general cloud MIS provider", if you see what I mean. A cloud-hosted MIS system is really no different to a locally hosted MIS or other CRM-style app.
As for cloud providers being multi-tenanted, that's something I would regard with horror. I know we need direct 'back-end' access to the tables storing our data in our MIS system and therefore any solution that had us sharing a database either wouldn't fit our needs or would be running a massive risk.
This comes back to what I've said about cloud and virtualisation in the past - nothing magic happened just because someone said "cloud" or "virtual" during a meeting. A MIS product is still a MIS product no matter where it's hosted in the same way that Microsoft's Office 365 product is essentially 'just' Exchange, SharePoint and Lync hosted by Microsoft instead of the customer.
If I connect directly to the database behind any product and run DROP DATABASE then that's not the vendor's fault, especially if I was warned about it (provided, of course, that all the info in the DB was mine)... That doesn't change just because something is hosted in the cloud, though I don't doubt some people who didn't get the "cloud's not magic" memo would disagree :-(
Last edited by Roberto; 16th February 2014 at 08:17 PM.
There are currently 1 users browsing this thread. (0 members and 1 guests)