It’s the mobile device, not the server

Richard Vedyard posted an interesting collection of blogs on the subject of fat vs thin clients.
A key quote struck my eye from Phil Wainewright’s post:
“…what matters most is being able to tap into network resources…”
This is exactly the wrong way to look at things. We’ve been thinking about mobile devices as clients tied to servers, and this is backwards from reality. Mobile devices are computers in their own right, with their own resources. What matters most is the resources on the mobile device and being able to use them to best advantage. I’m sorry, but the thin client paradigm falls down on this every time.


3 responses to “It’s the mobile device, not the server

  1. I would be the first to agree that it’s wrong to look at mobile devices as thin clients dependendent on servers. My original comment wasn’t talking about being dependent on network resources; it was about being able to tap into them in a loosely coupled way. A mobile device yes of course has its own resources. When it’s connected, it can supplement those local resources with network resources, and simultaneously make its local resources available to other network participants as network resources. Who said anything about thin clients??? I had in mind a completely different paradigm altogether.

  2. Who says that the mobile device is always going to be the client? Why not becoming a provider of services to other remote (or not so remote) devices, as well as to the user?
    I actually have two colocated devices – a phone and a SIM card. (I think the phone has more software than the SIM card – it’s fatter.) I can choose to store phone numbers on the phone or on the card. I am not currently offered the option to store my frequent numbers on the network (why not?)
    If I’m designing a set of services to be physically located on a mobile device, rather than invoked remotely, I’m going to make a tactical judgement, based on the current state of the art, current pricing structures, and so on. Or perhaps I’m going to make a strategic choice, depending where I want the control to sit. It’s a complex situation-dependent design judgement, not a simple ideological principle.
    But the service is a service, wherever it may be located. The architecture should be location transparent, possibly even migration transparent. Hence my point: abstract away from location, abstract away from fatness/thinness.

  3. First, apologies to Phil if I misunderstood something. Perhaps it was because I came in through Richard’s blog, which featured a summary of thin/thick client debate posts.
    And yes, of course services can and should exist on mobile devices, and they can be shared with other devices – now that the portable computers are all “freed from their cradles” by WiFi etc. and are true Internet citizens.
    But I started off my own entry more about mobile computer paradigms than SOA. I realize these are not necessarily orthogonal and can overlap.
    However, the main point I’m trying to get across is that we need to think about designing applications for the mobile world differently than we’ve thought about applications for the tethered world.
    And by this I mean the user interaction part of the application, not the service-oriented (or object-oriented or database oriented or whatever) plumbing.
    The user interaction models we need for mobile workers carrying their laptops, tablets, PDAs, and smart phones is very different from what we needed in the office environment. We can’t expect a mobile worker to navigate five levels down on menus to find the information they’re looking for, for example.
    The thin client paradigm (and again apologies if I made the wrong assumption here that anyone was defending the browser if they weren’t) is very much a server oriented paradigm. The application is based on the server. The data is organized centrally, for portals in a corporate way not a personal way.
    Information needs to be organized and presented in a way that makes sense for the mobile worker, and supports the interactivity characteristics of the device(s) they’re using. One size does not fit all.
    I welcome the idea of mobile devices as peers in a SOA or P2P network, but that really isn’t the point I’m trying to get at.