Blog
Why many SAAS and PAAS providers leave you at the mercy of the gods
When a SAAS application is so slow that your employees experience more annoyance and lost work time than that the application supports them, you have very few possibilities to turn it into a properly working application. And SAAS applications that are under performing – often seriously under-performing – are the rule rather than an exception. And for PAAS the situation is not a whole lot better, although you have a few more options to solve the issue.
When a SAAS or PAAS application is hindering your business and your growth you can complain to the supplier. They’ll often present you some graphs that shows they’re meeting the SLA or SLA’s, so there’s no problem at all. That your users are the problem. SLA's are nice, but most of them tell you exactly nothing abou how fast or how slow the application is for users. Doesn’t sound very nice, because it’s not. Fortunately there’s a solution.
You and your supplier don’t share common interests
SAAS en PAAS suppliers lure customers with lower cost through shared usage. They can actually deliver at a lower price point. But … their focus is on increasing their turnover and profit with the same or a lower effort. It’s understandable that we all want to make money, but you need to realize that your interest and theirs don’t align.
Sometimes you’re forced to move to SAAS because a new version of an essential application will only be delivered as SAAS. Your supplier isn’t making that switch to save you money, but rather to increase their income. Not entirely shameful, but the consequences for you … you get the picture.
Because the suppliers have different interests they’re not inclined to make structural improvements to the software or to add extra hardware. That will cost them money without any benefits. Paying extra is not always possible and if you pay extra you rapidly lose the cost advantage that led to the choice for SAAS in the first place. The bigger the SAAS provider, the smaller the willingness to fix anything. That’s not jus our experience, it’s what many business are dealing with every day, a burden for so many IT managers.
Savings by sharing are very limited
If it sounds too good to be true, it usually is. Sharing (virtual) hardware with others will give a small gain because your peaks will not completely line up with the peaks of other customers. But if you’re all in the same tome zone then all the users will be logging in at 9:00AM and you run into the same log in and day start peak that you had on premise. And the peak is probably worse because the SAAS supplier saves on hardware compared to your old on premise situation. And the after lunch peak at 1:00PM is also still a burden for your employees. Sounds a bit sour? It is, we just don’t pay enough attention to it.
Distance will become a factor
A SAAS application is at a greater distance from your users than an on premise application. That distance causes longer delays – technically that’s called latency. That delay is 10 to 20 times as big in the cloud as it was on premise, if you’re in the same region as the cloud data center. If your business is in Charlotte, NC and the SAAS provider is in the NYC area, that becomes 40 to 80 times. |Many SAAS applications are old on premise applications that jus got ‘dumped’ into the cloud. They were never designed for cloud use and that means they were never designed to handle serious network delays. Resulting in long waits for your employees.
Agree on an XLA, not just an SLA
To stay in control on the experience and the delay your employees experience you need to agree on an eXperience Level Agreement (XLA) with your provider. In an XLA you agree on the standards an application must meet on the users side. You’re agreeing on how well the application must support and accelerate the work of your employees. And you can enforce those standards. We can help get an XLA set up properly.
With an XLA your standards must be accurate enough. If you agree, for example, that measured over a year, the application must meet the standards 95% of the time and you make no agreements on times, the application is allowed to not meet the standards for 2½ months (!) if all the issues are during office hours.
Get objective numbers
A SAAS supplier measures what his servers deliver, but that’s not the same thing as what users experience. Between his servers and your users several networks need to be crossed that can slow down the application. Part of what your users experience is is determined by how the SAAS application uses your browsers.
By taking objective measurements of what the user experiences, and Sciante can help you do that, you find out how much delay (and often unseen annoyance) your user is really experiencing with your SAAS applications. With objective data you can prove that an application is not meeting the standards. And that your users are not whining, but have a real problem, is also shown. And you’ll know when your users are whining, even though in our experience, that’s quite rare. The experience of your users must also be the basis for the XLA, not the response times of the supplier’s servers.
We’ll find the cause, even if the supplier doesn’t cooperate
I’ll give you a real life example. At a SAAS supplier that completely refused to cooperate we immediately saw a number of bad configurations that slowed down the application needlessly. Solving them was possible without a need for this supplier to make extra hardware investments. We also immediately saw which functionality of the application was needlessly slow and we also found out what the cause of the delays was (retrieving much too much data). All that without any access to the environment of the SAAS provider. We can see all that from the user’s browser.
Due to the complete lack of cooperation from the supplier, our customer switched to another SAAS solution. It wasn’t their first choice, but it fixed the problems. The employees can work fast again, the annoyances are gone and the new SAAS application accelerates their work. Of course Sciante screened the new application before they migrated.
My SAAS application is also too slow, what now?
Book an appointment with me, no strings attached, and we’ll discuss what your problems are and your options for fixing them.
We usually use our Frozen Screen Scan for this. In no time flat it will determine if you objectively have a problem, how much money and annoyance the problem is costing you and whether or not it’s your SAAS supplier’s fault.