We at Incentergy are often confronted with a lot of gossip around SaaS systems. That they are insecure and that on promise systems are a lot more flexible. The last few years have shown that this is not true and a lot of vendors which concentrated on licensing software are currently facing a hard time because SaaS offerings are overtaking their business.
In this blog post I will mention some of the myth that I heard about SaaS software and I will explain why they are not true.
SaaS will not return my data once it is in
Often companies say that once the SaaS platform is configured and they are using it and entering data, they will not have the possibility to export the data. This is not true. SaaS software in general has a lot more exporting capabilities then on premise systems. You are even allowed by german law to reengineer the system and write your own crawling and exporting modules. The Incentergy marketing system offers transactional interfaces (API) for all functions that are shown in the GUI. Further we have batch exporting capabilities in various data formats including XML, JSON, and CSV.
SaaS is likely to get hacked
In the past there were from time-to-time stories that big amounts of data were leaked from SaaS offerings. Although this is true compared to on-premise data attacks this number is is about 7 times lower. Companies which get hacked internally are very unlikely to speak about these incidents. Germany just created a law that they have to report these incidents. SaaS systems are updated a lot faster then on-premise installations and special monitoring software (IDS) are used to find fraudulent traffic. The incentergy had in the last year an average security-patch-apply-time around 1 hour. If you have a monthly patch day your average apply time will be 15 days. This means that you are 36000% more likely to get hacked then our SaaS offering.
SaaS has a vendor lock in
There are a lot of vendors for the same product and it is always complicate to change. Compared to on-premise installations hosted systems are very interested in supporting open data standards like OWL, RFC 6350 vCard, and RFC 5545 iCalendar. There are already companies that are offering free migrations from one vendor to another. If you every made an on-premise migration from an proprietary system to another you know how hard it is.
SaaS does not know where the data is
The german BDSG requires all company that they always exactly know where there data is hosted. Even if there are some data provider like Google AppEngine which cannot guarantee the location of the data it is possible to choose a provider which always knows where the data it. For example amazon has multiple data centers in the whole world. It guarantees for the ec2 service that machines which are started in a certain center e.g. EU Ireland will stay there.
SaaS does not scale to my data volumes
Our Incentergy system is tested with more then 6.000.000 data objects and can handle around 1.500 transactions per second. This already shows that it is easily achievable to scale to large data volumes in the cloud. The even more important point is scaling. An on premise installation is bound to the available hardware and if there are usage peaks it can not scale to these peaks. SaaS is elastic. This means that the used monitoring software is observing every component like application servers and databases. If their is a performance gap it will automatically start more instances of the component that is currently over capacity. When the peak is over the system can be down scaled to reduce costs as well.
SaaS does not support my enterprise role system
Entreprise security system are a lot more strict then personal accounts. Sometimes their are multiple organizations divided by multiple departments. Here you have to separate the wheat from the chaff. The incentergy system is based on Java EE and integrates the fine grained role model. You are able to defined multiple organizations, assign users to them and separate your data according to these barriers. Audits can be enable so you are always in charge who is doing what with your data. If this is not enough custom realms can be used to support customized security requirements.