Sunday 13 October 2013

Update from OpenWorld 2013

This post is a bit later than I had hoped to publish, but put it down to pressure of work.

This year's OpenWorld coincided with the America's Cup races, so there was a real buzz in San Francisco as the Oracle (sorry, US) boat clawed back victory from the jaws of defeat.

As far as Fusion Applications went, there wasn't so much excitement.  My specific interest, Fusion HCM, was relegated to the Palace Hotel (PR speak would say it was given prominence in its own location).  I really don't think this worked because not all sessions were there, some were still in Moscone and the round trip of half an hour was valuable time lost, not to mention it often meant missing the start or end of a session to get to the next one.

There were no significant new announcements on Fusion Applications either.   The presentations seemed to be tightly controlled and on-message.

Hence, not much to report really.  All the news for 2013 had already filtered out at previous conferences earlier in the year.

Still, looking forward to the HCM event in Las Vegas in February.  Let's hope there is more of interest there.

Saturday 5 October 2013

The Importance of Configuration Management in SaaS

When you have a traditional on premises application, you take a certain amount of responsibility for the patch management of your system. 

The software vendor will provide details of patches to you and you choose when to download them and when to apply them.  You are responsible for testing that they work.  Often, you have multiple environments, perhaps even 1 dedicated to patch management, so you protect your production environment until the patch is 100% tested and proved.

Sure, the software vendor will be responsible for delivering a working patch, but the final test comes from the customer and if there are faults, and if there are any faults found you send the patch back.

In the SaaS world this is different.   When your applications are in the cloud, the SaaS service provider has much more responsibility.  Again, I'm taking the the service provider I work with as an example, but the concept applies to all service providers.  Patches are delivered on a regular basis, either ad-hoc or in 'patch bundles'.  Small customers may not have the luxury of multiple environments (as they have to pay for each additional environment they use).  Often, you will only have 'stage' and 'production' environments. 

The patches are applied to the stage, then there is a small window to test and the patches are applied to production.  The customer has to test the patch because despite all the rigorous testing that the service provider might do they cannot know what data is on your system and the patch may encounter conditions not seen before.

Notice the use of the words "software vendor" and "service provider" in this article.  A SaaS service provider is much more than a software vendor.  The service provider is the initial customer of the software vendor.  It has to take responsibility to ensure that its service is 100%  reliable for its downstream customers.

Business applications have long suffered from a rather blasé attitude by vendors and even customers, that leads to an acceptance that software can be shipped even if it doesn't completely work.  Think about that concept in the flight control system of a plane, or the control systems in a nuclear plant - it is completely different and is far more rigorously tested and controlled by robust configuration management.  Business applications vendors / service providers in the cloud take note!

Customers should expect that patches and upgrades will work first time and will not introduce other problems.   It is vital that SaaS service providers understand that the old model, which everybody complacently accepted, cannot work in the ever growing world of the Cloud.