pwainewright

@GREED I'm happy to continue the discussion and I'm going to start off by disagreeing with @matt40k when he says: Really if that's the only reason you're doing it then you're missing a lot of the value. In the business world we're seeing that people are moving to the cloud primarily for reasons like: - they can get up-to-date functionality without a long wait to plan a physical implementation of new technology - the functionality stays fresh because of frequent updates - it keeps pace with new forms of interaction, eg mobile, Twitter, other cloud services, etc - you can do smaller implementation projects and add extra functions incrementally without being locked into a single proprietary supplier (this is a big part of why the Government Digital Service is pushing cloud first) It's probably also true that it's costing less, feature-for-feature, than older technology, but you probably end up spending the same because you get more value. In fact we're starting to see terms like 'total lifetime value' being used rather than 'total cost of ownership'. The TCO comparison assumes you have two equivalent systems and that each has a set purchase cost and running cost. What it doesn't take into account is the extra cost of not being able to stay up-to-date with a less flexible system. -

Given everything we have discussed in this thread, it astonishes me that cloud-native SaaS vendors allow themselves to be undercut by client-server SaaS competitors. Hopefully initiative like the G-Cloud CloudStore will bring more transparency to pricing matters and help ensure the public sector doesn't continue to pay over the odds for up-to-date computing resources.

Thanks @matt40k for the kind words but I do have to declare in interest in that @Bromcom-PR did originally approach me to write a white paper for them - however while I may sell my writing skills, my opinions are my own! Anyhow I have now posted a very thorough article on diginomica setting out my conclusions on this whole SoSaaS vs cloud SaaS argument as it relates to the NIST definition of cloud, which I hope @GREED will find persuasive on the differences - interested in your feedback. In @Bromcom-PR's defence, I think it's legitimate to quote the 50-fold RAM comparison as an illustration of the resource wastage that occurs when you virtualize an entire school's Windows desktops in order to deliver an antique client-server app from a datacentre instead of moving to a browser-based alternative. But I do agree with @matt40k that there are many other parameters you have to take into account when evaluating the relative value-for-money of different solutions - including a risk assessment of the security factors. Generally speaking, however, the evidence from the wider market seems to be that the entire pay-as-you-go cost of adopting a properly architected, NIST-compliant cloud application will often exceed just the running costs of a conventional client-server system for which you also have to pay a substantial upfront capital expense. The cost differences are often so startling as to seem unbelievable but it's because the resource pooling hoovers up an enormous amount of otherwise idle capacity. In addition, the cloud application will have more frequent, non-disruptive upgrades, allowing an on-the-ball vendor to rapidly add support for new requirements such as tracking Pupil Premium outcomes. Not talking about any specific schools MIS here as I'm not familiar with the detail of any of the products but speaking from the perspective of someone who's studied business adoption of SaaS and cloud for many years.

@PhillipHamlyn Thank you for joining in, interesting comments. I must say, though, the Gartner definition of SaaS you cite is so impossibly broad as to be totally useless. If all it takes is a subscription contract and remote management, then my family's Microsoft Office, for which I pay an annual subscription and which is kept up-to-date by Office Update, counts as a SaaS application - which patently it is not. The SaaS version is Office 365 although it is only partially SaaS since the client (unless you use the web version) still runs on the desktop. I believe the NIST definition often gets misinterpreted because it describes three separate cumulative layers: IaaS, PaaS and SaaS. While it's possible to host a client-server application on IaaS and deliver it from the cloud, that doesn't make it SaaS. To be described as a cloud application per the NIST definition, an application has to include core architectural features in the definition such as resource pooling and elasticity. Otherwise it's just SoSaaS sitting on IaaS, and hugely inefficient/unwieldy. I'm interested to see integration and big data cited as advantages of cloud SaaS - I think those are good points. I know I'm a bit of an interloper here but in the interests of stimulating discussion, here's a list of cloud-native SaaS benefits that I included in a recent article on client-server vs cloud SaaS:

So the guys at @Bromcom-PR told me about this thread about my SoSaaS definition (among other things) and they challenged me to sharpen up the definition as requested by GREED below. I also liked @matt40k's notion of grey and white clouds - yes there are definitely both types. The problem with the grey versions of cloud and SaaS is that people have taken existing client-server software and just put them in the cloud but they haven't adapted them for it. You may call it SaaS - "software you use you do not manage" per GREED - but it's only SoSaaS, not true/white cloud according to the widely accepted NIST definition (which the UK government uses to define its 'Cloud First' policy). The nub of the NIST definition is that cloud is a "shared pool" of dynamically allocated resources. If you don't change the software to behave like this internally then you may be putting it on top of a cloud, but it doesn't become cloud software unless you change it on the inside as well. Does that work as a definition or do I need to expand on it do you think?