asked on
software change management on SaaS business applications
How does the software change management process work with regards to SaaS hosted applications. Historically with ERP or Line of Business applications that were hosted on your on-prem servers/data centre, it was often the responsibility of the ‘internal IT’ department to apply the relevant patches and system upgrades, in line with a carefully planned change management procedure, with backout plans tested, careful consideration on the best time to apply the update to minimise disruption to users, and involvement of the front end users to ensure the upgrade had not introduced any further bugs/errors etc. Sometimes IT would work with a consultant from the software company to assist with the patching/upgrades.
With SaaS hosting I suspect the actual application of the patches/upgrades is now applied by the software hosts, and as such there may be far less control/influence over certain change management risks to the customer. So I just wondered what the process involves for hosted apps, e.g. pre-warning notifications, do you still get end user testing windows etc. Or are you practically removed from the process altogether?
ASKER
- Reasonable upfront notice of when an update/patch will be applied (including any expected downtime to warn your users)
- Prior access to a test environment running the latest version, so your end users can check that the update has not introduced any new bugs into their processes/usage etc?
- Any real say/influence on the upgrade/change date & time
- Any influence on how necessary the upgrade/patch is in general?
Even though SaaS applications are less of an internal IT support problem then on-prem installed apps, there is still usually some form of internal application-by-application
Also, out of interest, do SaaS products use standard version control for their apps, in the same way you would see within on-prem business apps. And if so, in the SaaS world, what sort of 'change' amends the version numbers in this sector? e.g. can you verify as a client the version of the product you are using or is version control different with hosted apps then software they sell for clients to install and operate from their own servers. On-prem change management used to require really detailed planning and risk assessment where a committee/board would approve or reject.
ASKER
How does the back office architecture of a SaaS host 'compare' to on-prem hosting of ERP/LoB apps in terms of 'servers'? Typically with an on-prem data centre, you would establish a dedicated virtual server for the database component, and a virtual server(s) for the application component. Its location in the network would depend on accessibility requirements (e.g. public-facing or truly on-prem access only), but generally there would be dedicated servers specific to each application/function to help with security, performance, maintenance, troubleshooting etc.
Is that generally how a SaaS host with multiple clients running the same app, would also 'segregate' their customers resources, a dedicated set of servers (app/web/database/test) per customer, or are things more ‘shared’ then customers may think? I was just thinking of it from a change control perspective, maintenance may be easier if each clients version of the software was running on its own dedicated servers.
A SaaS service is just a service. How it is built behind the scenes is no different to any other service. If it's well designed it should be resilient, secure and stable.... if not it could be anything.
Some vendors provide information on how it is built, some don't. Some offer proof of security via Pen testing, some don't.
The difference is what is already covered by your SLA and thus done automatically in the background. The rest is (should be) covered by your processes.