Don't get hit by a 'bad comms day'
What happens when it all goes wrong?
When people get issued with their first mobile email device, they invariably get obsessed for a period of time with the novelty of the thing. A few, sadly, remain addicted and never move on from this phase, giving rise to the "CrackBerry" label among BlackBerry users, the occasional divorce, and perhaps the odd nervous breakdown.
Most, however, progress through the stage of realising the dangers of mobile email taking over their life, then get some kind of control and emerge into a steady state of using it simply as a work tool.
For anyone whose use has matured in this way, the chances are you don't really give much thought to just how much you take mobile email for granted and come to rely on it being there. Then you get hit by one of those "bad comms days" - you're out of the office, with a bunch of stuff going on back at the ranch that you want to keep an eye on, and people are sending you messages in the sure knowledge that you are an "always on" kinda person so will respond relatively quickly – then you suddenly realise you haven't received anything in your inbox for hours – the system is down!
Right now, many people reading this are probably shaking their heads sadly asking themselves what can be so important that it can't wait till you next log in from your PC. After all, everyone managed fine before mobile email, so why all the fuss if your executive or techie toy isn't working for a while?
It's a frequently heard argument, and similar thinking has been applied over the years to cars, telephones, computers, email systems, mobile phones, laptops, and many other new technologies.
Philosophical objections and yearnings for a simpler past, however, don't change the reality that technology advances often have a significant impact on both user behaviour and the way businesses work – to the point where if you take them away, even temporarily, the result is disruption, distraction and cost. That's why it is important to protect against failures and/or have suitable contingency in place for the inevitable moment when things go wrong – and of course IT departments spend a lot of their time taking care of this.
What's interesting, though, is looking at how realisation of the organisation's dependency on a newly adopted technology often doesn't dawn until some time after the dependency itself has developed. In the early days of email, for example, it was just a communication convenience to many, so downtime or loss of data associated with it was viewed accordingly, just an inconvenience. But how many organisations got a wake up call at some later date when their casually managed email system went down and suddenly, users were screaming and certain business functions became crippled? Today, we know from research that email in its traditional "wired" form is regarded as business critical, and the job of managing and protecting the email infrastructure is generally taken very seriously.
Looking at all this in adoption lifecycle terms, we can consider technologies going through the stages of being irrelevant, convenient, important then critical. Of course, not all of them reach the point of being regarded as business critical, or even important to the business, but the danger is that some sneak between the convenient and important stages without being noticed, and this is the point at which disruptive failures can occur because the organisation is ill-prepared.
Coming back to where we started, mobile email is, as we speak, starting to go through the transition from convenience to importance in more mature user environments. Indeed, anecdotal feedback from a recent Freeform Dynamics study confirmed that users have in many cases already adapted their working patterns to take advantage of mobile messaging. So when the service isn't working or accessible, that "bad comms day" can be much more disruptive than many perhaps realise.
This is definitely a development to look out for if your organisation has a population of mobile email users, and it's well worth considering where you are on the adoption and importance curve. The areas to consider are pretty obvious – prevention of downtime and mechanisms to get users up and running again quickly in the event of a failure, not just reconnected, but back in action with the right configuration parameters, user preferences, rules and so on reinstated.
Those using native Microsoft Exchange to drive Windows Mobile devices in a well managed environment probably already have the server fault tolerance and recovery in place for the core email system (you do, don't you?), which is likely to take care of the needs of mobile users as an implicit spin-off. Even so, it is worth considering the process side of the equation, e.g. user support, preventative maintenance of devices, and the rapid replacement/repair of lost or damaged devices. If you use middleware to enable mobile users, then you potentially have an additional point of failure that needs to be taken care of separately, e.g. by acquiring something like the Neverfail solution, which currently seems to be the only well-established high availability offering for BlackBerry Enterprise Servers.
The other option is the outsourcing route. Companies like Cobweb will take the whole problem off your hands if you want a completely hosted Exchange and BlackBerry capability, for example, while players like Blue Sky will do the same for Domino and BlackBerry. There are then the emerging middleware-only hosting offerings from both independent service providers and, increasingly, mobile operators, who see this area as a big business opportunity. The advantage of the hosting route, especially for smaller organisations, is that service providers typically have state of the art technology and processes in place to deal with availability and recoverability that would be prohibitively expensive to set up in house.
The bottom line is that the dependency of many businesses on mobile email for the smooth operation of emerging processes and practices is increasing, so the availability and recoverability requirements in this area are probably best dealt with sooner rather than later. And as a final thought, if the first time you find out how important the chief exec's BlackBerry is to them is while you're standing there staring at a dead BlackBerry Enterprise Server, things could get a little stressful.