Editor’s Note: Tal Klein of Adallom explains why he wants to kill “cloudsourcing”….with fire. Simply, he says it’s a terrible term for SaaS adoption — AW.
For my first post on The New Stack, I want to euthanize a pet peeve of mine: Using the term “cloudsourcing” to describe SaaS adoption. Actually, euthanization is too kind. The truth is, I want to kill cloudsourcing. With fire.
Correlating a corporate subscription to a SaaS service with cloudsourcing creates a fundamental perceptual problem with ramifications to both security and compliance. Specifically, referring to SaaS adoption as cloudsourcing creates an analog to outsourcing, which SaaS adoption is anything but.
Let’s presume that you are outsourcing the administration, support, and maintenance of some corporate application like email, CRM, ERP, etc. to Acme Global Outsource Services (AGOS). The expected contractual obligation of AGOS would be not only to administer and support the environment, but also to commit to uptime targets, and security.
Specifically, part of the AGOS outsourcing benefit would be the transfer of accountability and liability for data compliance and security from your company to AGOS. That’s outsourcing 101.
Enter SaaS. In the cloud, the expected contractual obligation between customer and vendor reads more like that between a car owner and a parking garage. This is the “Shared Responsibility Model.” Your SaaS vendor is providing you with a safe place to park your data, but you are accountable and liable for protecting your valuables. That’s the polar opposite of outsourcing where transfer of accountability and liability is part and parcel of the value proposition.
Some analysts may tell you that the onus is on you to do a better job negotiating your MSA with the SaaS vendor, but we all know that the purchasing decision for procuring the SaaS service happens outside of IT, and that’s another big difference between outsourcing and SaaS adoption. I would challenge you to try negotiating the terms of a parking garage contract, “No, I want you to protect my valuables”.
For the purposes of this discussion, I’d like to put aside “consumerization” or Shadow IT, defined as a single employee using some SaaS application for their own needs, and instead talk about what I call “departmentalization,” which is when a business unit subscribes SaaS service as an officially sanctioned corporate application without consulting with IT.
Let’s imagine that the VP of that business unit sees the CIO in the hallway and says something like, “we’re saving a ton of money using this app in the cloud as a service, so we’ve bought licenses for the entire org.”
Now, I’m sure an elite few CIOs in companies with megabucks do get some concessions as part of their SaaS MSAs, but you’ll never see a SaaS vendor take on liability for data exfiltration or compromise. The most you’ll likely get is some service credits, and that’s only if the SaaS vendor itself was the source of the problem. If one of your users gets pwnd and corporate data is exfiltrated, the SaaS vendor has complete indemnity.
Does that mean SaaS is bad? Absolutely not.
SaaS is a great and secure way to increase workforce agility and shed cumbersome application maintenance. But there’s a reason SaaS is so much cheaper than outsourcing. The business models are completely different. By shedding the correlation between the two, you can begin to make decisions that aren’t poisoned by an unreasonable expectation of vendor accountability and liability.
Tal Klein is Vice President of Marketing at Adallom
Image by Jesus Solana