At the Enterprise 2.0 Conference, I asked all of the vendors, "SaaS or on-premise?" The assumption, because this conference was all about modern 2.0 stuff, was that everyone would say, "SaaS, of course."
Wrong. At least 50% of the vendors were deploying primarily on premise. Even some of the pure SaaS crowd would admit to an occasional on-premise deployment. Anecdotally, even some of those who say they are pure SaaS will deploy on premise quietly. Why are enterprise customers telling vendors that they want on-premise deployment?
Some of the vendors selling on-premise solutions are bang-on up to date in the two ways that really matter:
For example, Atlassian sells only primarily on-premise. Note: this corrects an earlier version of this post. Atlassian has told us that they do in fact sell both on-premise and hosted versions of some of its software.
There are some red herring issues. For example, security. There is no reason that cloud-based systems should be less secure than on-premise ones. But some high-profile lapses by cloud vendors have given enterprise decision-makers sweaty palms. "Having it in our data center just feels more secure, right? No one could hack our data center, could they?" Let people keep their illusions if it makes them happy.
The concern about application integration is a bit more valid. Sure, a cloud vendor could integrate just as easily with in-house apps. But all that data transfer comes with a cost.
But the figure that really tells the story is 6%. That is the percentage of server utilization in enterprise data centers, according to McKinsey. That is a lot of wasted cycles. It would be much better to use them up with new applications, and to bring in virtualization technology to use them more efficiently.
Why rent more cycles from a SaaS vendor when you are swimming in excess capacity?
So, why the big fuss? Because customers want on-premise, and the customer is always right.
As long as the vendor can deploy the whole solution stack really simply, there is no deployment cost issue.
The problem is that words like "SaaS" and "cloud" loosen investors' wallets. As one entrepreneur put it to me, "The moment I admit to selling on-premise, I lose the VC." Anecdotally, even Salesforce.com, which is religious about being pure cloud, has deployed on-premise when the customer is big enough. But saying so ruins a good story. UPDATE: we sought independent verification of this and it was not available. So we assume that this is currently incorrect ie we assume that Salesforce.com is still pure SaaS.
Google is one vendor that seems to be sticking to its pure-cloud approach. It can afford to forego a few mega-enterprise accounts because it makes so much from consumers and small and medium-sized businesses (SMB).
Small companies don't have the scale to run their own data centers. And an awful lot of small companies are out there. Department-wide deals in which the decision maker does not want to "go through IT" will still go with the cloud.
But the really big enterprise-wide deployments seem to be going with on-premise.
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteEnterprise posts
From an ROI point of view, I have to disagree with most of the article. SaaS can be delivered without IT and without an IT maintenance staff.
There is significant ROI attached to having less people in IT manage applications for which they do not have expertise. SaaS vendors have the application expertise and a full time dedicated staff in charge of maintenance, upgrades and support.
For complex applications, it makes little sense to have a corporate IT department manage an on-premise application. One, they usually don't have domain expertise. Two, they don't know the right questions to ask in order to set it up the application properly. Three, they don't have the experience necessary to realize how it will impact the other systems in the enterprise.
Please note, there are some exceptions to above of course. I know quite a few CIO's that will disagree with me and claim to have the in house expertise. I'd argue based on my experience however, they are the exception rather than the rule.
"For example, Atlassian sells only on-premise."
Not a good example. Atlassian offers hosted versions of their products, not just on-premise.
http://www.atlassian.com/software/confluence/hosted/
http://www.atlassian.com/studio/
@Mark I think you are just trying to argue with reality. Small businesses don't have IT staff so no contest. Medium and Large businesses either would like to think their staff either know this stuff or are good enough to learn it. In most cases it's just putting the application up on a server and running it - not writing it - so they don't need domain knowledge.
Companies don't trust external parties completely with support since many companies either charge a lot for small items (new email addresses) or are very slow to resolve issues like RedHat and Oracle.
In regards to the security mentioned in the article - I would think in a good IT department of 50 people the security of the datacentre is better than a 5 person startup which mostly consists of programmers/business people not sys admins. (a very different skillbase)
Also in many cases the IT department is evaluating the options and it's not likely to pick one that puts them out of a job.
Also, forgot to mention that many saas services get pretty expensive when you get to 1000s of users compared to running your own server. E.g. 1000 users on Yammer $36,000/year
As a CIO who has served at several different firms with IT departments in the 50-100 people range, I disagree quite a bit with Richard's remarks above.
The secret to scaling and leveraging as few IT people as possible to do the maximum possible is, in fact, to simplify the environment and run fewer applications yourself wherever possible. Richard writes, "In most cases it's just putting the application up on a server and running it - not writing it - so they don't need domain knowledge." Incorrect. Learning to administer a new app -- even a relatively easy one such as Atlassian's JIRA or Confluence -- takes someone to figure out the nuances, find the hardware, handle the twice-yearly upgrades, etc. And they end up in essence adding one more card to a teetering house of cards that is the application portfolio. I've seen firms misimplement in-house vendor applications time and time again. Turnover in the staff makes things even worse, but it's hard enough even if the same people stick around.
With today's broad application portfolio, and ever more things being added to it, I want, as a CIO, to keep my staff maximally focused on core competencies, not the grunt work of application upkeep.
Hey, your posts have inspired me! - I love the way you directly get to the point, and then work outwards. I’ve been trying to do figure out what I want to say about ,that would allow me to do exactly the same thing.
I did not know that Read/Write Web had security expertise. Care to qualify the statement " There is no reason that cloud-based systems should be less secure than on-premise ones."?
Here are some security (confidentiality, availability, integrity) risk raised by SaasS.
Where is your data? Is is commingled on the same system/database as other companies data?
http://www.datacenterknowledge.com/archives/2009/04/03/fbi-seizes-servers-at-dallas-data-center/
What is the disaster recovery plan if/when the cloud service suffers an outage? Can you spin up a new system on another vendor?
http://www.techcrunch.com/2008/02/15/amazon-web-services-goes-down-takes-many-startup-sites-with-it/
Learn more here: http://www.rationalsurvivability.com/blog/?p=1031
Posted by: http://khurt.com/blog/
|
June 26, 2009 7:00 PM
One more INFORMED opinion: http://www.schneier.com/blog/archives/2009/06/cloud_computing.html
Posted by: http://khurt.com/blog/
|
June 26, 2009 7:24 PM
No doubt Clouds are ideal for SMB. But only when security issues are addressed and a legal deal is entered with SaaS provider.
which large salesforce.com customer(s) are on premise??
Too many people seem to break down SaaS v. on-premise into good v. bad. Saas for what? On-premise for what?
SaaS can be a brilliant application structure in some niches, but it's clearly silly in others. No matter how slick cloud technology gets, whole classes of applications will never make sense within the limitations of mass cloud computing over the Internet. Long and high-variance communications latencies, best-effort consistency guarantees, dependency on distributed infrastructure across comm links that nobody can guarantee are insurmountable obstacles to cloud deployment for whole classes of applications. Still other applications have sufficiently stable usage patterns that it is hard to imagine how it will ever be cheaper not to host the servers locally. One of the big elements that never seems to make it into the projections one reads of the miraculous cost-benefits of the cloud is how inefficient these architectures often are. Many of the benefits suggested by back-of-the-envelope calculations evaporate when the second-order costs are taken into account. IT doesn't go away---some IT goes away. One server in the cloud doesn't equal one server in the data center, the extra communications cost for doing everything across link, etc...
One sees this same pattern of over-selling every time there's a major shift in the relative cost of some element of computing---some class of solutions become more feasible, and the industry stampedes off, largely because that's where the VC money concentrates. The current SaaS frenzy reminds me of the off-shore software development frenzy that is now so little heard of in the media. That "revolution" rapidly shrank to something much more marginal as the realities of development across 10 time zones and two languages set in, and demand upped the cost of the foreign workers. There are always mammoth hidden costs and inconveniences that don't make it into the marketing hype. It seems almost certain that the over-selling of the cloud will be similarly be corrected by experience.
There are several reasons to think very hard before opting for a cloud based SaaS. So with the risk of sounding like
1. Security standards like Safe Harbour, HIPPA or PCI. How will I go about auditing the SaaS vendor and it's data centers? Where is the data to begin with? Who could theoretically access it? What standards do they live up to and do they promise to continue to do that? Are the data always inside our outside a Safe Harbor-country? I can let PCI auditors check whatever I want in my data center, but who do I call to let them audit Google?
2. Man in the middle. Whatever security that may or may not be in place at the SaaS vendors data center isn't the only security issue at hand. The simple fact that we're dealing with a remote data center automatically means that internal company data will travel over external networks where more people will get a theoretical chance to look at my data.
3. Vendor lock-in and integration. Any application that requires the ability to access my other database or application servers in my environment would require much more complicated integration methods. If not all my applications are from the same SaaS vendor, it can be impossible. I've experienced having to pay a SaaS vendor twice the monthly fee just to be able to access my data via a protocol (ODBC) required by another application.
4. Government surveillance. Running too many applications as SaaS would increase the probability that one or more government agencies legally or illegally sees my data. That may be unavoidable for some applications (email) but do I really want it for virtually all my internal company data?
5. Power balance. I can ask/beg/force my local IT-dept to make whatever changes they are capable of over the next day/week/month. There is absolutely nothing I can do in that time frame if my SaaS vendor thinks my current or future busniess isn't worth the effort.
I'm not saying SaaS doesn't make sense, but there is a whole lot more to it than just "There is no reason that cloud-based systems should be less secure than on-premise ones".
I completely disagree with most of the things in this post. 6% capacity utilization might be true but that does not justify the decision for a on-premise solution. Deploying a new application is much more than infrastructure alone. I just completed a post on On-premise v SaaS today about the reasons that Sales should use to quantify the benefits of SaaS.
http://www.prudentcloud.com/saas/saas-sales-saas-onpremise-28062009/
I can understand the IT reasoning on why on-premise is better. It undermines their very existence to some extent. But I think they get it wrong.
Subraya Mallya
I agree with Andrew's question...on premise salesforce.com deployments needs some proof points, is this speculation or known fact?
For me the risks with putting data out on the cloud are whether the company you're trusting with this data will secure it from a) hackers, b) their competitors, c) other customers (my competitors), and d) it's own employees.
Hackers are the high profile risk, and the one that even average web development often fails at. Good security is hard. Being a remote service means that even denial of service could prevent me from accessing my data, which is less likely if I go with an on-premises solution instead.
Competitors of the Service Provider don't need to resort to hacking to get data - the SP may just get bought out. Even if the SP had a good terms of service, that could be worthless when the new owner rolls in, esp. if the new owner bought the SP after bankruptcy. Similarly, the SP may be forced to sell off some of its assets as it tries to stave off bankruptcy, and it can be very hard indeed to keep your data from being treated as one of these saleable assets. You can't sue when there's no money to extract. This is a non-issue for an internally hosted service - there's no way the data can be sold without me having a say in it.
Writing a service so it provides nice, clean divisions between the various businesses its servicing can be tricky. If the developers get it wrong, then my competitors may get an inside edge on what we're planning. This isn't an issue if only my employees can get to the service.
A disgruntled employee is the biggest security risk to a company, and if your data is at risk of some other company making its employees disgruntled, that could be a big problem for you. At least for an internally hosted service, its just my own sysadmins I have to worry about.
To balance all these potential drawbacks, the service provider needs to be providing either a service I see as a nice-to-have for my business (so the data can disappear and I'm only a little put-out), or be as safe as a bank (or safer, given what's happened to so many of those) if the service is vital to the continued existence of my business.
Lastly: Am I the last person in the world to still spell it "premises" for the place? Or are these companies installing things to draw conclusions from? If the spelling changed, then please let Merriam-Webster know...
A disgruntled söve employee is the biggest security risk to a company, and if your data söve is at risk of some other company söve making its employees söve disgruntled, that could be a big problem söve for you. At least for an internally söve hosted service, its just my söve own sysadmins I have to worry about.
This is a harsh but true that people still not willing to accept SaaS. Saas do get costly with large users but the advanatges it has over others is also great. People should slowly adopt SaaS as it will give them chance to gain competitive edge over others in the business. The sooner the better.
Sonal Maheshwari
USourceIT:Riskfree IT outsourcing/sourcing partner for small and medium businesses
1. INEVITABLE
Saas is inevitable. Lets make some observations about services that are not software based but are in the "cloud" : air travel, postal services, rail services, electricity generation, newpapers etc. etc.
Furthermore to this, since we are talking about taking software services to the cloud, there will, after evolutionary process, emerge singular (or very few) architectures to support these SaaS offerings. So, even in the cloud there will be concentration and unification. Eventually, we, the humans, will construct a unified structure for all the information/knowledge services that we will call the global brain - and it will have its brains in the cloud :-) (SaaS).
2. SOME EXPERIENCES
We have been deploying end to end insurance enterprises first one by one on premises. Now we almost always do it in the cloud. The experience has given us an insight into risks and effecacy of such approaches. Due to concentration, or rather lack of dilution of expertiese level in SaaS setting, one can deliver much better service. Often the large enterprises talk about their redundancy, security etc policies but in reality they are never going to be as strong as what is required in SaaS offering. Continuity risk is also much reduced with SaaS offerings: often few developers in enterpises hold these enterprises to ransom. When these developers resign leads to serious problems. Subsequently the software is degraded by developers that takeover as they do not understand the intentions or the architectures of the original software.
3. WHAT SHOULD ONE DEMAND FROM SAAS OFFERING.
Often SaaS enterprises talk as if they do have all the necessary infrastructure & processes - but this has to be verified.
1. MIRRORING or REDUNDANCY - crucial (in case of failure must in real time switch over to redundant nodes)
2. REAL TIME BACKUP
3. ENCRIPTION ON ALL TRAFFIC
4. GOOD SECURITY AND DATA ACCESS PROCEDURES
Pawel Lubczonok
ThoughtExpress
Much depends on to who you are selling and how your sales process is structured: sell the benefits.
If you sell to the business owners or the process then they are happy to get a solution without the involvement of CIO or IT manager.
don't you mean on-premises?
http://en.wikipedia.org/wiki/On-premise_software
on-premise is equivalent to saying on-assumption software, not on-site software.
Thanks to some great comments. First, a correction that # 2 pointed out about Atlassian. I have corrected that in text as well.
To the people who ask about which company uses Salesforce.com software on premise, I was careful to say that this was "anecdotal", meaning that I was told this by somebody who I consider a reliable source who asked this their name not be used as a source. So take that as unverified. I would be happy to get more data to either verify that or prove it incorrect.
# 7, I would like to see some balanced reporting on the security issue. Almost everything I see seems to defend one point of view or another. There needs to a commonsense guide - no baffling with BS - that lays out the issues clearly for those among us who don't plan to make IT security our career. My one issue with the "cloud is insecure" argument is that of course it is, so is the internal data center. It is a question of degree, not black and white.
Enterprises requiring on-site deployments is not a surprise. They prefer to keep their data behind their firewall for many reasons. If a SaaS App has to be deployed Enterprise wide, in most cases we are looking at an on-site deployment.
SaaS vendors choosing on-site deployments for large customers is the way to go if they want enterprise-wide deployments.
Bernard,
At the end of the day it is about balancing risk and oppotunity. Cloud Computing is more risk than hosting in a data center because the cloud vendors have nor/are not responding to the risk raised by the IT pros. I raised some of those issues in my earlier comment. #12 also spelled out a lot of the risks. Cleary solutions will be found to reduce (not eliminate) that risk to a level acceptable by the business (not the IT security). Until the cloud vendors start offering solutions I can not recommend any large enterprise move any critical data or application to the cloud.
Khurt Williams, CISSP, ITIL
Posted by: http://khurt.com/blog/
|
June 30, 2009 4:10 AM
UPDATE: we sought independent verification of the story that Salesforce.com was deploying on premise. While people were telling us this and and were even naming names of clients and and we regarded these people as credible sources, we sought independent verification from people who were willing to go on the record. This was not available. So we assume that this is currently incorrect ie we assume that Salesforce.com is still pure SaaS.
" everyone (vendors at E2.0) would say, 'SaaS, of course.' " -- Everyone but us at www.tractionsoftware.com, perhaps. And the enterprises represented at E2.0 followed suit. Of the 7 or so folks from large enterprises that I met at E2.0 (including 2 of our customers) were unambiguously seeking on-premise solutions.
We offer on-premise software, primarily, and SAAS as an exception, albeit an important one. It's a rare day when a large enterprise seeks to host their collaboration software, or even ask for an appliance. In fact, I've yet to encounter a large enterprise customer that wants to stay on our SAAS offering longer than a pilot or preparation period, in anticipation of re-deploying internally when resources are prepared.
Untangling the issue: large enterprises - like any enterprise - want software that's easy to deploy and manage. If software is hard to deploy or is aimed at a small user community, SAAS or Appliance options start to look attractive. So the secret to designing software for the enterprise is more about designing software that's easy to deploy (no pre-reqs), easy to manage (simple upgrades) and simple to use (low training).
Salesforce, as an example, is the sort of software (ERP, CRM, etc...) that is heavyweight and hard to deploy but is for a small dispersed community in an organization rather than something like E2.0 Collaboration software which has massive appeal. So, Salesforce may be the exception rather than the rule.
The types of use cases around which customers deploy E2.0 Collaboration may involve the types of contribution and discussion that is considered to be exceptionally company confidential, leading them towards on-premise solutions where they own the license, data and software that runs it. SAAS options, by contrast, carry security risks (not that enterprise intranets are impenetrable) and business continuity risks (we don't dwell on them but plenty of SAAS vendors aren't with us any longer - or transformed into a business model or merged into another company in a way that left their customers behind).
Bernard,
I think it really comes down to who the SaaS vendor is selling to. If they're selling to business (as most are), then it boils down to the business decision maker's preference rather than IT. Unless there's a strict policy against SaaS (i.e. the Fed's DOD), on/off premise is has not nearly as important as the business value, user adoption, and ROI. We market to the mid and large enterprises and have found a substantial switch to SaaS acceptance and preference over the past year. If selling to the IT director, than I see more discussions around owning the infrastructure. As the sale gets closer to finalizing, the business discussions do cover reliability, scalability, etc. And that's where the vendor needs to provide believable service and delivery confidence. I assume a SaaS vendor hosting their own infrastructure would have a harder sell than a vendor leveraging a hosting partner such as Rackspace (even though no one hosting service is perfect as we saw earlier this week).
if you want to become jewelry daren,you must know tiffany which make you bright,if you want to become a shoes daren ,you must know ugg boots which make you omfatable,because it make you fashion
if you want to become jewelry daren,you must know tiffany which make you bright,if you want to become a shoes daren ,you must know ugg boots which make you omfatable,because it make you fashion
Despite all the life danger, with one selfless act from one common person, someone is saved, A hero is made.
http://www.trendyedhardy.com/category.php?id=18 ed Men Long Sleeve
Despite all the life danger, with one selfless act from one common person, someone is saved, A hero is made.
http://www.trendyedhardy.com/category.php?id=18 ed Men Long Sleeve