One of the things that still surprises me is the lack of interest in the ‘Uptime’ of Enterprise mobile apps during the evaluation phase. It seems to be that a mobile app is assumed to naturally inherit the Uptime of the Platform. And of course with Salesforce.com, this means all the transparency that they also provide through trust.salesforce.com.
To get us started I think it is worth understanding what I mean by ‘Platform Uptime’
There are lots of ways that Platform Uptime is worded and measured in the ‘as a Service’ world. However for me (as a customer) I think in the following terms; The availability and reliability of the platform to perform customer transactions. For transactions I would include both application data transactions as well as platform configuration requests.
It is worth noting that salesforce.com do not provide public SLAs and, as is the case with all providers I can find, they do not include ‘scheduled’ downtime in any calculations. However as with most things the proof is in the pudding and (again with my customer hat on) I am more than satisfied with the ‘Uptime’ we receive from salesforce.com.
What do I mean by Mobile App Uptime?
How I define and measure Mobile App Uptime is very clear. It is the percentage of the time the mobile application can fully function, ‘as designed’, whilst the device is powered up.
There are two crucial points to pick up on here:
The first is that the Mobile App Uptime is not tied explicitly to the Platform Uptime. By that I mean the Platform can be down and the Mobile App should still function (on the basis that the principles in MORE(s)™ Design have been followed). So we measure uptime against the availability of the device not the platform. And of course the availability of the device is tied to its ability to be powered up (battery life and available charging sockets become our limiting factor).
The second is the wording ‘as designed’ where we talk about fully functioning. Most enterprise mobile apps will surely be designed to ‘do’. Not just read. So I am explicit here. If my mobile app is not doing what I had it designed to do then it is not ‘Up’.
Of course if I am offline then I will have ‘designed’ the app to behave in slightly different ways (perhaps continuing with a process but displaying ‘awaiting sync’) but my point is that this should not ‘break’ the app or confuse the user.
Mobile App Uptime as a Requirement
I do not believe to have 100% Mobile App Uptime as a requirement is unrealistic. In fact as I sit here I have an app that have been functioning (without restart) for weeks regardless of the state of my data connection or the platform performance.
The key is in the design. To ensure that connectivity does not ‘break’ our app. To ensure that a dropped signal or full loss of signal is full expected and catered for. To make sure that our app’s performance is monitored continually, to provide baked in data efficiency. To make sure that we proactively test our app against the latest OS releases (full releases and versions) and that we assume failure in every process, system and user interaction that we rely on.
Why there is no running away from these new metrics
I think it is interesting to note that the birth of trust.salesforce.com came about after a series of outages in 2005. At the time Marc Benioff states (as in his book ‘Behind the Cloud’ Play #56) that they just kept their head down and tried to fix the problem. But in hindsight customer visibility and transparency were key. Of course no one likes an outage. But when it is visible and everyone can see what is going on through status updates etc then some confidence is restored. This also allows diagnostics to be made public which fosters ideas on how to mitigate in the future.
If we take the ‘build and forget’ attitude to anything it will come back to bite us. If we fail to prepare we prepare to fail. Just because technology is developing so quickly these basics cannot just be ignored.
A centralised outage in a warm and controlled data centre is one thing. An outage for employees spread across the globe on a variety of different devices is a very different and somewhat scary scenario. At the very best we will have to monitor and measure. Accepting that this is no different to the outages that salesforce.com had in 2005 and that their impact will be the same or even greater will mean these metrics will soon be at the top of every CTOs and possibly CEOs dashboards.
So who is responsible?
What a loaded question! But it will come up, and to be honest this will rise to the top of any organisation. It is a double edged sword really. As I have pointed out previously if a business does not move to mobile NOW, the performance and longevity of the organisation will be at risk. But if that organisation fully embraces mobile and moves as many of its processes to the mobile apps it creates, then if these apps stop functioning, function poorly or only function occasionally, then again this will be felt at the highest levels.
For now however adopt a set of rules like our MORE(s)™ Design. Give your developers the tools they need to build in the features without slowing down the app development process. This is a great start.
However to realise that on top of these things we can control there are a myriad of other factors that we need to be concerned about, then a higher level ‘holistic approach’ is needed. Continual Performance Monitoring and Continual Enhancement controls and systems will be where the best invest their resources, which in turn will pay back many fold as they outstrip the competition when the Enterprise Mobile Promise can be realised.
If you would like to find out how your organisation can deliver cutting edge, fully offline enabled apps for today, tomorrow and the future please contact me directly at email@example.com or request a live demo below.
Sign up for a demonstration
Find out how your organisation can build, deploy, manage, monitor and enhance fully offline enabled salesforce.com mobile applications