Real mobility
Musing on the meaning of mobility
There comes a time when you have to take a break. It is rapidly approaching Christmas and things in the office are winding down for the holidays. The office closes in a couple of hours, but already the staff are playing with a remote control toy car and throwing a ball. As usual, many of them are wandering around with mobile devices as they test the latest code they’ve written, or check out the quality of presentation on the numerous mobile sites we’ve helped create. I begin to wonder if we’re too caught up in the minutia of making mobile technology work to see the big picture.
What exactly is “mobile”?
If I was to ask anyone here in the office to tell me the first thing that came to mind when I said “mobile”, the answer would probably be device, or phone or something similar. Would anybody say person, or process or information? In our business, when we think of “mobile”, we think of the issues associated with the device. We think of the challenges in making all those diverse browsers work with content we have to offer, we think of the myriad of software libraries and mini applications to execute on the devices, we think of the set of network protocols and all the other nuts and bolts that make up the infrastructure.
There’s more to mobile than the device.
Looking at a system architecture diagram during a deployment planning exercise, one notices how people identify data and processes and decide where they reside. Then they work out how representations of these resources are expressed to the mobile edge devices, and the issues in getting these representations to the edge (e.g. secure transmission). We have liberated the human interface and the device upon which it executes, allowing users to move about and work freely in their physical environment. In contrast, the movement of processes and data resources only happens during the deployment planning, and thereafter they tend to remain in place. These things that we identify are now permanently bound to a concept of “where”.
This need not be the case. One can permit these processes and resources to retain their mobility. One need not think of them as having a permanent location. Like the users and devices, one can allow processes and data resources to become mobile. Allow them to disperse, and distribute, replicate or merge, and continue doing so within a dynamic environment.
Mobile everything.
Nearly twenty years ago I started working on advanced distributed computing. We called it super-computing back then. I was fascinated by MIMD/SIMD, Transputers, hypercubes and the like. I found interesting ways to split processing loads, achieve super-scale-up and even something akin to quantum uncertainty where variables held multiple values and didn’t resolve until they were collapsed at the end of the calculation. It was a great time of exploration, and it seemed natural to try to make everything mobile, in the sense of moving processes around, moving data around, moving the interconnects and everything else that could possibly be moved. One important lesson I learned is to avoid making assumptions, and for those you cannot avoid, record them so that you can revisit them. One assumption was the idea of a central processing unit (CPU), and by dropping that assumption you liberate the idea of distributed computing.
One can also drop the assumption that the identity of data is related to its location. This can be hard to do. We learn that data is held in unique locations in memory, and that high-level variables merely hide this underlying detail. When we think of files, we probably think of a file server and the physical storage in which those files are stored. When we think of a database, we also think of the machine that holds the data, and executes the queries. When we think of a URL on the Web, we may also think of the Web server that holds the pages.
The challenge is to stop thinking about those things in terms of where they are, and just focus on their identity. Let everything be mobile.
More of “what”, less of “where”.
If everything was mobile, then I could think of “my list of contacts” without being concerned about where the list was stored. Today we are too concerned about the “where”. Is it my list of contacts on my phone, on my PDA, the one in my email client on my PC in the office, or the one at home? This is wrong. What I have is a “list of contacts”, and things like PDAs, PCs, email clients and so on are just ways in which I can get to my list from where I happen to be at the time. Suppose I want a list of the people from my list of contacts with whom I have been in touch in the past 3 months. Should it matter to me if the filtering of my list is executed on my mobile device, or on a server, or in some proxy mechanism? No, at least it should not matter to me. Of course, there may be environmental factors that make the process favour one place of execution over another. Nevertheless, what matters to me is that the result. I may also have some additional requirements, such as getting a result as quickly as possible, or in the least expensive manner. These are all environmental parameters, and it should be possible to adapt the behaviour of the system accordingly.
So, as the holiday season approaches, I’m going to step back a little and start thinking more about what mobile should do for us, and less of where it does it.
Categorised as: Uncategorized