Joe, Sometimes upgrades are assumed as part of the process. Just like a smartphone app, some upgrades are free and some are complete rewrites that you need to pay for.
If a complete rewrite then there is the consideration of moving data and mapping fields from one system to another or even possibly a different app with a different vendor. We've done that recently as well. Dave On Feb 25, 2014, at 6:11 PM, "Joe D'Souza" <[email protected]<mailto:[email protected]>> wrote: ** Thanks Tauf, Chris, Terry, David for all your views you’ll expressed. The assumptions I made were considering an ‘ideal world’ definitions of the two strategies. @ Tauf: Good point about internet connectivity. So that gives me the 4th disadvantage to SaaS subject to internet connectivity which could be a real life situation sometimes even for a number of days such as in the event of a natural disaster such as a hurricane or a storm. @ Chris: Good point about co-ordination between internal and external system administrators – you pointed it out in terms of integrations, I think it could be extended to other scenarios as well such as coordinating changes in internal systems that interact with SaaS systems. As a matter of fact I recently experienced one such minor issue recently where contact to a SaaS based system (not Remedy or any of its competing products, but a product we integrated Remedy to that was SaaS based) was lost for nearly a full business day after an upgrade on the SaaS system. I think it turned out to be a firewall issue from their side. Luckily it was in the development environment so it was a lesson learnt for migration to production to make sure the firewall settings were changed accordingly. @ Terry: Didn’t even think about the vendor being outside the country ☺. I was only thinking about where a vendor is within the country. In reality they could be anywhere. I can see how that could be a big NO to customers like the Department of Defense or similar entities. That would extend my Disadvantage #2 a little. @ Dale: I was not too worried about exceptions such as developers given a VPN access to a on premise solution assuming that such an access is given to individuals after security considerations of both the network as well as the individual given such an access. The security risk I was addressing is where the data is stored outside the organization and not within. VPN is only a means to access the data or application irrespective of where the application and its data resides. And yes with limitations to customizations when on SaaS I meant what you stated as well as there may be application level limitations. Such as in Remedy you are limited to not being able to run direct SQL’s or any system processes through run process. Other SaaS based systems may have some limitations too if they have a On Premise counterpart as well. You are also in a way right about possessing data itself is a risk irrespective of where it is stored. Its just that having it onsite, you, your data security team and your management may get a better feel of having better control on the security as opposed to when it is off site, where you have to build a trust relationship with an external entity to protect your data. Its like keeping your money in the bank. Yes its safe. Would it be safer if you kept it with you? Disputable, but yes you may perhaps feel it is safer if it was with you even though it may be disputed as a false sense of security – you could apply that bank analogy to SaaS vendors. I’ll need to add your points about cost, the business focusing on their business rather than administering a system that helps their business, etc to my list of advantages and disadvantages.. Thanks for your views.. @ Dave: I was assuming vendors conducted an internal test before rolling out updates thus bringing downtime to near 0. Guess I was wrong on that if you have experienced otherwise. Also didn’t know that there could be cases where you are paying for upgrades but its not actually materialized. That’s a good point. Again thanks for all your insights. Again this was not to discuss Remedy on Demand vs the AR System on site but a SaaS vs On Premise solution approach in general. Any more suggestions or inputs are most welcome. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Shellman, David Sent: Tuesday, February 25, 2014 9:49 AM To: [email protected]<mailto:[email protected]> Subject: Re: Slightly OT: Saas vs On Premise... Joe, Since this is a general discussion concerning SaaS, assumption 2 and 3 can be dependent on the vendor and the software. You cannot assume that the software will always be up to date or downtime. I have seen situations where a company is locked to a particular version of software while the vendor charges for an upgrade. Also have seen recently downtime for maintenance. The downtime window needed to be extended past the original schedule. Then additional downtime was required on a later date to complete the tasks. Dave From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe D'Souza Sent: Monday, February 24, 2014 6:14 PM To: [email protected]<mailto:[email protected]> Subject: Slightly OT: Saas vs On Premise... ** What are the advantages and disadvantages of one over the other? I am asking about any generic system in general and not particularly the AR System, when used On Premise vs SaaS.. which is why I prefixed the subject of this email as “Slightly OT”.. I’d like to know about the hidden advantages and disadvantages that are not so apparent other than the obvious. The obvious advantages and disadvantages of SaaS I would percept are: Advantages: 1) No onsite administration – lowers cost of ownership 2) You are almost always up to date on versions etc. 3) You do not risk downtime when a system is upgraded, or during system maintenance, or bug fixes. The vendor usually has a faster planned route to rollback. Disadvantages: 1) No onsite administration – reduces flexibility in some areas of customization. 2) Your data resides off premise so it poses some kind of security risk 3) You are vendor/manufacturer dependant – the manufacturer goes out of business, so would your solution. And the obvious advantages and disadvantages of an on premise solution I would percept are: Advantages: 1) Onsite administration – You could do what you want, when you want, how you want to the system as you please with no rules whatsoever apart from system limitations 2) You can choose when to update if at all or stay on whatever version works for you as long as you wish to. Lowers user training costs to a certain extent. 3) Your data is as secure as you want it to be. 4) Your solution life lasts beyond the manufacturers – if they go out of business, you can continue to run their solutions for a while until you have a better solution. Disadvantages: 1) Onsite administration – You usually face higher maintenance and running costs. 2) You risk downtime during maintenance or upgrades or bug fixes even with a good rollback strategy. Any other advantages and disadvantages to the two strategies that I may have not listed here? Joe _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
