Will Mobile Partnerships Address the Mobility Opportunity?

Red Hat’s deal with Samsung to co-develop mobile applications for business (and of course for Red Hat and Samsung hosting) mirrors in many ways a deal made last year between Apple and IBM.  As I said in an earlier blog, I think it’s very likely that the next wave of productivity improvement that will drive IT spending to grow faster than GDP will come from mobility.  Of course, everyone who makes ice cream at home doesn’t end up being Ben and Jerry.  What is it that’s actually needed to drive mobility to its full potential?  Again, I would suggest we need to focus on the differences.

A mobile worker is different from a desktop worker primarily in that they are literally on the job, meaning that the mobile device is with them at every point of activity.  It is not there to support planning for work, researching stuff for later action, but to support current action.  It’s a portal through which the worker gets what they need, the things that will help do the job.  The worker, naturally, will come to regard the device as a kind of companion or co-worker—“Hey, Siri/Cortina, can you help me with this?”

I think this point is the starting point for mobile empowerment.  In order for a mobile application to be effective the mobile app has to be humanized.  The interface with the device/application has to look as much as possible like a human, conversational, interface.  I’m not saying that it has to be speech recognition and speech output, but the option to do that has to be available, and the alternative to speech has to look more like SMS than like traditional PC forms input.

If humanization is the key to mobile empowerment then Samsung should be trying to push forward its rumored deal with Nuance (whose Dragon engine is the functional core of Siri) to acquire better personal assistant technology to replace its own S Voice, widely seen as a poor competitor to Siri or Cortina.  They could easily kill their long-term chances in the Red Hat deal without a strong UI.

Another thing that could kill the Red Hat deal and also hamper Apple/IBM success is my next point, which is that mobile applications have to be totally mission-driven.  While you can at times have a mobile application that takes you through steps, you have to visualize this process of leading as though a co-worker was setting the scene.  In that situation, the primary worker could interrupt to ask questions, go back to an earlier process, ask for confirmation, and so forth.

To me this introduces the notion we could call “taskflow”.  A worker’s “job” is divided into a number of “tasks”.  Traditional IT tends to support the “job” and mobile empowerment should be aimed at supporting the “tasks”.  When a worker begins to use a mobile device for empowerment, they must be able to quickly identify the task they’re undertaking, and the mobile application(s) have to then frame themselves around that task to provide the support.

Tasks have step, hence the “taskflow” concept.  I can visualize a taskflow engine, designed to support the sequencing of steps in a task, based on a kind of process flow chart.  “Is Valve A on?  If YES do THIS, if NO do THAT.”  You could probably author this sort of thing in BPEL or a similar language, or view it as a kind of web page that just isn’t shown directly.  The important thing is that above all the specific sequencing, you still have to support things like “WAIT” or “STOP” or “BACK” or “CHECK” in some form.

Within taskflow, a mobile user has to have the steps in the task supported in a way that balances the need for specific visual/audible interaction needed for that specific step with the need to present the step in a contextually relevant and functionally similar way to the steps around it.  An example here is that if you’re driving a worker through the process of tightening a big greasy nut with a big dirty wrench, you probably don’t want to ask the worker to touch “continue” when the step is done.  You also don’t want the worker to signal completion explicitly on one step in one way and on the next in a different way.

Feedback is critical for mobile empowerment, and the most useful feedback of all is where the app can sense the result of the task’s progress in some way.  If a worker is turning a valve, is there a way to tell whether the fluid pressure or flow is responding as expected?  If so, feedback can be provided like “That’s working—keep turning” or “I’m not seeing any change; let’s turn that back and check the valve label again.”

I think that taskflow management is likely to be done in the device itself, meaning that there’s a taskflow interpreter there and an outline of the task steps.  When a process has to be invoked, the interpreter would message a partner agent in the cloud to ask for the step support needed.  If something happens external to the worker, the cloud partner agent would signal the taskflow interpreter to take an action like the “that’s working” or “I’m not seeing” or even “STOP!”

We’re not hearing about this sort of thing from the mobile partnerships so far, and that has me worried.  Most of the IT revolutions we’ve had were hampered at first by the fact that we took old practices and transliterated them into new IT technology form without any regard for whether the practices themselves were suited to the technology.  Mobile empowerment isn’t about giving a worker a mobile version of a desktop screen.

We do get some useful insight from some of Google’s work, particularly with its “Andromeda” project for network virtualization.  I think the lesson of Google’s SDN and NFV evolution is that you really have to consider both at the same time, and also that you have to include the cloud in the mix.  Only a combination of the three can generate dynamism at the application/user level.

I also think we have to get out of the label-inspired boxes and understand that this is about the general challenges and opportunities of virtualization.  We should not be talking about “SDN” or “NFV” but about function virtualization (FV).  We can virtualize routing/switching functions, or we can virtualize firewall and NAT functions, or we can virtualize application functions.  We can mix all this virtualization into a highly personalized vision of the world, or of corporate information and human resources.

The mobility-inspired partnerships are on the right track in that they recognize that mobility is likely the demand driver for all of our revolutionary technologies.  They’re on the wrong track if they think that assembling a lot of legacy parts is going to create a revolutionary whole.