On-Premise is an architectural deployment decision (On-premise vs. Cloud). It defines where your software would physically be deployed, and the access and connectivity options available to you. It’s a decision that has to be taken in context of the rest of your enterprise architecture landscape and your long-term design strategies.
Software-as-a-Service (SaaS) is a licensing model and, if you are comparing it with anything, it would be with Perpetual Licensing which has been the traditional IT licensing model for many years. This relates to how you are going to pay for using the solution: Pay a large sum (usually) up front as capital expense (Cap-Ex), and you own a perpetual license to access the solution forever. It is then your choice if you also pay and an annual support fee as an Operational Expense(Op-Ex). But the license to use the software is yours forever. Alternatively, in SaaS, you pay a much smaller amount per user/per month (all Op-Ex), which is flexible as your requirements change. In the SaaS model, you don’t actually own any licenses you are effectively “paying rent” only for as long as you are using the solution. This has nothing to do with where the solution is physically deployed.
And just to confuse the definitions even further, SaaS is also sometimes used to refer to the responsibility for administering the systems and supporting the solution. Typically, in a perpetually licensed environment, the license owner is responsible for the administration of the solution (or a third-party, if Application Management has been outsourced). In the SaaS model, the administration burden typically lies with the solution provider, not the organisation paying for the services.
The confusion has come about by the fact that, most commonly, perpetually licensed software tends to be deployed on-premise and managed by the license owner, whereas SaaS software tends to be deployed on cloud and administered by the service provider. But it does not have to be that way: Theoretically at least, there is nothing stopping you from deploying your perpetually licensed software on a private cloud, instead of on-premise. There is also nothing stopping you from negotiating a SaaS payment model with your software vendor, even if the software is deployed on-premise.
So the question of “On-Premise vs SaaS” usually implies: “On-Premise, perpetually licensed, self administered VS Cloud hosted, Pay-as-you-use, provider managed”.
And I’m not even going to start talking about what this implies for private vs public vs hybrid clouds and Single instance vs Multi-tenant architectures, which are also often lumped under the “SaaS” moniker, even though they have nothing to do with SaaS.
I know the differences are semantic but, as Information Management professionals, we have a duty to be clear about the terminology we use. Our clients have more than enough to be confused about, we don’t need to make it any worse.
P.S. As my good friend and fellow pedant, Chris Walker reminded me, the correct term is “On-Premises” not “On-Premise”. He is right of course. There is no excuse for bad English either! 🙂
I haven’t written much about cloud because, frankly, I don’t think its as revolutionary as people think and because the demand for it has been largely vendor induced. Whatever you think about cloud however, it is here, it is a driving force, and it will continue to be a conversation topic for a while.
I wrote on a previous article (Cloud and SaaS for dummies), that cloud is like a train: Someone else has to maintain it and make sure it it there on time, all you have to do is buy a single ticket and hop on it when you need it. At least that’s the oversimplified theory… For Content Management however, the reality is a bit different: When you get on the train, you don’t carry your bookcase, your briefcase and your children’s photo albums with you, and you certainly don’t leave them there expecting them to be available and in tact next time you hop on the train. You take the train to go from A to B, and you keep your personal belongings with you.
The train analogy works well for Software as a Service (SaaS) cloud models, but not for Content.
The financial argument of SaaS is compelling: Buying software capabilities on demand moves the financial needle from CapEx to OpEx; the total cost of ownership reduces, as support costs & administration skills burden the provider; technology refresh secures ubiquitous access; and economies of scale dramatically reduce infrastructure costs.
Microsoft, Google, Apple, Box, Dropbox and every other ECM and Collaboration vendor, are offering content storage in the cloud – often free – to entice you to move your content off your premises, or off your personal laptop, to a happier, more abundant and more resilient place, which is all good and worthwhile. What isn’t good, is the assumption that providing storage in the cloud (or as I’ve seen it incorrectly mentioned recently “CaaS – Content as a Service”), is the same as providing Content Management in the cloud. It is not!
We (the ECM industry) have fought for years to establish the idea that managing content goes a lot further than just storing documents in a file system. It requires control: Security, versions, asynchronous editing, metadata, taxonomies, retention, integration, immutable flags, workflow, etc. etc. Unfortunately the new fad of EFSS (Enterprise File Synching and Sharing) systems, is turning the clock back: Standalone EFSS environments, are just another way for users to bypass IT and Security controls (Chris Walker articulates this very well in his article You’re out of your mind).
Now, before you jump on my throat and tell me that EFSS came about exactly because of the straitjacket that compliance, governance and ECM have put organisations in, let me say, “I know!”. I’ve lived and breathed this industry since it was born, so I understand the issues. However, we (ECM and IG practitioners) risk throwing out the baby with the bathwater: Ignoring EFSS and all other file external sharing mechanisms is dangerous, at best. Blocking them is impractical and unenforceable. Institutionalizing them (as Chris suggests) adds a layer of governance over them, but it does not solve the conflict with the need for secure internal repositories and regulatory control.
So, what if you could have your cake and eat it too? Instead of accepting EFSS as an externally imposed inevitability, why not embrace EFSS within the ECM environment? Here’s a revolutionary idea: Why not have an ECM environment that incorporates EFSS capabilities, instead of fighting against them? An ECM repository that provides the full ECM control environment we know and love, as well as keeping content synchronised across all your mobile and desktop devices, so that you can work
I try to stay impartial on my blog and refrain from plugging IBM products, but in this case I cannot avoid the inevitable: IBM Content Navigator offers this today (I don’t doubt that other ECM vendors are or will be offering it soon).
What we are starting to see, is the evolution of proper “Content Management as a Service – CMaaS”: Not only storing content in a cloud and retrieving it or sharing it, but offering the complete ECM capability, including sync & share, offered as a cloud-based, on-demand, scalable and secure service.
Why should organisations settle for either an on-premise heavy-weight ECM platform, or a light-weight low-compliance cloud-based sharing platform, when they can combine both?