|
 |
 |
Extreme MobilityRecently, I was speaking privately with the CIO of a very large (>100,000 employee) company who matter-of-factly indicated that they've just stopped buying desktop PC's. Instead, employees are offered one of a palette of notebook or tablet PC's to suit their needs. All WiFi. Very consistent with what I read in the news today and elsewhere. Why perhaps might he have been interested in Groove?
A fascinating and rewarding viewpoint, of course: a vision of Groove Workspace on every laptop. This, on the heels of some incredible things that have been happening around the world with use of Groove by humanitarian aid workers and NGO's, armed with hardened mobile laptops, communicating via sat-phone or GSM or whatever they can get their hands on, whipping up forms and databases on-the-fly and securely disseminating critical information. Trying to rapidly assemble technology solutions toward helping those in need. Then, within the span of no more than a few weeks, a broad set of unrelated experiences came together - all related to mobility: A few weeks ago, I attended a small gathering of fascinating people ... every one of which was armed with a notebook computer, a Nokia 3650 camera phone, group blog & wiki & chat, a kind of fotoblog/fotowiki, and more. We gathered to brainstorm about how people worldwide currently use, and will use tools for augmenting their relationships online. And we were soaking in it. Many things were clear: varying sets of people used varying sets of tools, for different reasons that matched their own needs, style and culture. PC's are unmatched for people who sit down to do some work or research or purposeful activity, while handhelds are unmatched for people who seek activity to "fill gaps" in time while on-the-go - walking, on a train, in a taxi. In attendance were "phone people" whose daily activities were dominated by SMS on a keypad, and "PC people" who spent more time using Outlook or AIM on a keyboard. Throughout, blogging software & IRC and iChat and Hydra and Groove buzzed on the various PC's; SMS and photos buzzed on the phones.. By the time we left, it was clear to everyone that although the hardware, software and services are still obviously in their infancy, we're at the dawn of a new era of mobility and "connection", and we simply ain't seen nothing yet. What else happened recently to focus me on mobility? Because my notebook computer ceased to function en route, I spent a week in Europe with nothing more than my BlackBerry 6210 (and of course, as always, my Exilim EX-S3). The 6210 is a GPRS device that enabled me to keep up not only with my email, but also with many blogs - through its very crude browser. When I returned and read about the PocketPC 2003 launch, all I could imagine is a device with the size and weight and USB charging of the 6210, but with a camera, thumb-keyboard, WiFi, all-you-can-eat GPRS, email, browser, and mobile feed reader/editor, and SD card removable storage. Dream on. Then, the week I returned, I was visited by the folks from Tiqit, who came at the problem from the other direction - as a full function PC with the air sucked out of it. The same week a new Centrino Tablet PC was brought to my attention, yet again enticing me with a different vision of mobility. Then, my son's new and extremely cool (hot?) "mobile gaming PC" arrived ... with yet another vision of what mobility really means, to him. Then, today I see Tim O'Reilly's latest post on mobility, and the fact that Dave is trying to confront blogging mobility. A new platform; a new phase of the industry. Notebooks and WiFi are in a symbiotic growth spiral. Smart phones and GPRS are in a symbiotic growth spiral. Where will it all lead? In my view, the first thing to realize is that the "platform of old" is no longer the platform of the future. The PC has done us well; it's truly an incredible platform for innovation, and will continue to be so. I'm tremendously excited by what I've seen in the upcoming versions of Windows and Office, and I'm looking forward to seeing what happens as a new generation of developer explores the deep, rich capabilities afforded by this next generation platform. New programming, storage and interaction models will take us places we've not yet imagined. The PC is shifting from tethered personal productivity and document management toward mobile collaborative productivity, interpersonal communications, and media collection sharing & management. The phone is shifting toward mobile interpersonal communications and awareness, coordination and notification, as well as media playback, recording, and "squirting". It's going to take a new breed of software and services to get us from here, to there. Software born into a new era - designed specifically to emphasize media, communications and mobility. Built on top of platforms specifically created to enable these new capabilities. Think about it. If you're a developer and were around pre-GUI, you may recall how your world was rocked when you went from the old "main loop" style of programming to the event-oriented model of "modern" 80's-vintage graphical user environments. Then, when the Web came along, you had to learn a new set of skills as the programming model changed yet again to a more declarative style. Evolving technical capabilities and market requirements catalyze the emergence of new architectures; new architectures require the creation of new platforms, tools, and programming styles. Back in the mid 80's, a few of us began working on a product now known as Lotus Notes whose market requirements dictated a different model than those popular in that era - one with a form of mobility at its core. I'd refer to it as a "synchronization & security first" style of systems design. A style in which you must first, come to terms with the fact that your application and its data are going to be distributed all over the place, and second, you must deal with these two key issues as a core aspect of the application's design and operation, as opposed to being an afterthought. What do I mean by "afterthought"? Well, let me ask the following simple question with regard to synchronization: How many copies of your Contacts do you have? Did your phone come with a "sync cable" and a CD with a program that enables you to "sync your contacts with your email program"? That's an afterthought. Somebody designed the phone's firmware, and then said "OK, how do I get contacts into this thing?" How could it be different if "contact mobility" weren't an afterthought? Well, think about it: your phone is connected to a network. Why aren't your phone's contacts automatically synchronized through the "cloud" with your PC, which is also ultimately connected to the same cloud? Why does your phone's display not automatically show your next appointment or meeting, being connected to that same "cloud"? And so on. Similarly, most products deal with security as a complete afterthought, if at all, rationalizing up-front that slapping SSL onto their transport will be sufficient, or that people who care about confidentiality will encrypt their file system. Do you wonder why your eMail is not secure even though S/MIME has been around for ages? A system designed for mobility must take issues such as user-friendly key management into account from day one. The only secure systems are those largely immune to user indifference; complacency-immune security is hard, and virtually impossible if it isn't designed-in from day one. So, in designing Notes, we dealt up-front with the issues of synchronization and security. The need for synchronization was to be so fundamental to the architecture that we crafted the entire database and application meta-model around a simplistic synchronizer we knew we could build reliably - a conceptually straightforward "data replicator". The result? If you're a Notes application designer, you have a love-hate relationship with the program - hating the constraints of its application model, yet getting hooked on its flexibility. And if you're a Notes user who uses a laptop, you understand why a "synchronization first" approach enables you to work in a highly mobile fashion. Outlook 2003 when paired with Exchange 2003 has the same great feel for offline/online message handling due to its new local caching model; "synchronization first" just feels right. Then again, if not implemented properly or robustly, or if you push one architecture beyond its design center, it can also be an incredible annoyance. The product is/was indeed highly secure, but it unquestionably failed the test of being "complacency immune", being expensive and challenging to administer. The original straightforward data replication model of Notes was unfortunately too simplistic. The model wasn't well thought out with regard to synchronizing metadata kept separate from the data itself, e.g. "Folders" - a problem that we tried to correct incrementally over the years by adding code for these special cases to the replicator. (Any Notes user who has multiple computers and deals constantly with Unread Mark inconsistency can relate to this problem.) And, more critically, when building non-trivial business applications involving updates to more than one document, or tables in more than one database, Notes application designers have learned that the simple document-focused data replication model can cause multi-document relationships and references to become inconsistent. Specifically, the fundamental design decision in Notes to implement replication at a low level (e.g. the "database" or "file system" level) meant that the application's "transaction logic" didn't have a chance to get involved in deciding what to do when there was a conflict between multiple users' changes. In later years we discussed enhancing the system in various ways to do smarter conflict handling, e.g. by potentially implementing low-level application-pluggable "conflict handlers", but we stopped in our tracks when we realized the complexity of rolling back a potentially arbitrary set of changes across many databases, across many servers - some potentially offline. Fundamentally, we as the designers of Notes had implemented synchronization at the right level for documents, but at the wrong level for applications. For a number of applications - e.g. project management or business applications ... that is, applications beyond simple replicated document libraries or flat record sets - synchronization must be at the level of a transaction monitor - not in the database or file system. What needed to be replicated were the actual high-level transactions, not just the low-level data. With Groove - designed by a different set of designers in a different era (1997, vs 1984) - we had the chance for a fresh start. We also, of course, again pursued a "synchronization & security first" approach to system design. But unlike Notes, Groove is not built upon a "replicated database" or "replicated document store". Rather, it's built on a very cool "masterless decentralized transaction manager" a.k.a. its "dynamics manager" that enables virtually anything to be synchronized, by almost any kind or complexity of application. Unread marks sync'ed across your multiple PC's? Simple and flawless. Updates to multiple records or tables? Piece of cake. This makes building "mobile applications" very straightforward - that is, applications that automatically operate (without change) across multiple devices, online or offline, with no manual synchronization or user intervention required. Above, the reference to our having "nailed mobility" was related to our handling of both complacency-immune security and synchronization. The customer can use the platform services in Groove to 1) support collaborative work securely between users of, say, Microsoft Office, even across firewall boundaries, 2) as someone about to roll out Windows 2003's SharePoint services, the company's users can use Groove to take SharePoint sites offline and on the road, and 3) the IT organization can use VS.NET to connect Groove's web services to an important enterprise application (currently rendered through an Intranet Portal), enabling users take selective pieces of that application offline, working on them in a secure mobile fashion. Dimensions of Mobility What will it be like to build applications for a world in which mobility is of primary importance? The three principal dimensions that must be considered are usage mobility and infrastructure mobility and participant mobility. Usage mobility means, in essence, "you can use the application wherever you happen to be." In some cases this might mean "use someone else's computer", or it might mean "use the notebook or tablet computer that I carried with me" or it might mean "use the device that's in my pocket". For example, this might mean 1) support for multiple devices that are automatically synchronized with one another e.g. a home and work PC, or 2) support for federation of function between divergent device types, e.g. a PC and a Smart Phone, or 3) support for universal accessibility, generally although not exclusively through a web browser. Infrastructure mobility means, in essence, "the application transparently works upon whatever infrastructure it happens to be jacked into." This means, in essence, that you should be able to treat all WiFi networks, all RJ-45 Ethernet jacks, to be equal in your eyes. It should not matter whether this is your corporate network behind a firewall, or if you happen to be temporarily plugging into the corporate network of your client. It should not matter whether you're at home behind a NAT using a cable modem, or whether you're using the WiFi network at Starbucks, or whether you're using the GPRS network in New York or in Helsinki. It should not matter whether the network you're connecting to uses an old version of Active Directory or a new one, or a Lotus Notes directory, or no directory whatsoever. It should assume that there are "prying eyes" no matter what infrastructure you're connected to, because there are sniffers running continuously outside and inside of many public access points and on corporate networks. Infrastructure mobility means assuming that all infrastructure is usable yet inherently untrustworthy. Such mobility also dictates that it shouldn't matter whether you're using any of five orders of magnitude of bandwidth, from 9600bps GSM to gigabit Ethernet. And when the network goes down - which it WILL if only because of coverage gaps or network dropouts - the Smart Client mobile application should continue to function, flawlessly. It shouldn't matter whether the company or hotel that you're staying at is blocking all sorts of ports; the simple rule of thumb should be: If I can get a browser to display an arbitrary web page in a browser, no matter how slow it may be, then my Smart Client mobile application should Just Work. Participant mobility means, in essence, embracing the fact that a mobile environment is inherently one in which applications are focused on communications and coordination and collaboration with others, and thus means answering the question "with whom is this application being shared?" Answering this question fundamentally comes down to two dimensions: processes and people, meaning that an application should be mobile with respect to interacting with one or more individuals, or one or more systems or processes or agents. Architectures for Mobility Inevitably, when considering how to use applications in a mobile environment, one must confront the fact that different things are possible with different system architectures, and there are real tradeoffs in the choice. Call me an architecture astronaut, but I feel that understanding and building upon the right architecture matters deeply. Importantly, there is no single architecture that is right for all applications or usage models. Consider the following high-level aspects of mobility: Interface Mobility. This is probably the most straightforward to conceptualize: in general terms, it means "keep running the application on a server, and remote the user interface". The UI remoting technologies might vary from X-Windows or Remote Desktop to DHTML in a browser. Of course, this form of mobility is restricted to a "tethered" mode of usage, and the specific choice of technology is subject to other real-world factors such as bandwidth and latency. Data Mobility. This type of mobility support assumes that you're moving data objects, e.g. files, documents, contacts, or records between a server and a mobile device, or perhaps between mobile devices. Again, it's fairly straightforward to conceptualize, and it might be asymmetric (e.g. dissemination with caching, such as RSS or HTML) or symmetric (e.g. check-out/check-in, or synchronization/replication with conflict handling). Metadata Mobility. This type of mobility support attempts to deal with the synchronization of references to data objects - potentially rich references with their own tagging and structure - concurrent with the actual movement of data. Metadata or references might be in "sets" conveniently located in a database that can be synchronized, or it might be spread all across the Internet, in which case the owners of the references must be notified or otherwise "fixed up". Application Mobility. This type of mobility support attempts to deal with synchronization of the intended behavior of an operation or transaction within an application that may be broadly distributed and operating asynchronously in parallel. For example, a "Change Task Status" operation being done offline or concurrently by multiple users in a distributed project management application might change information in a number of database tables that will need to be reconciled, or a "Schedule Appointment" function in a group scheduling application might involve making complex queries and changes that span many different servers, again needing to be reconciled if several potentially conflicting operations are done concurrently in a distributed manner. With these aspects in mind, consider that there are at least five distinct system architectures for mobility commonly in use today, each with varying tradeoffs:
Ultimately, it must be recognized that each of these architectures uniquely supports some aspect of mobility not addressed by the others. Architecture matters. In that individuals and businesses empirically have requirements covering multiple scenarios, the key question becomes deciding in which circumstances to use which type of product, and how to best integrate products with different architectures. Where's it all going? I believe we're currently in a transition period for personal computing: from a tethered, desk-bound, personal productivity view, to one of highly mobile interpersonal productivity and collaboration, communications, coordination. We're focused right now on devices and networks because we're coming at the problem bottom-up: preoccupied by gizmos and technologies' capabilities rather than focusing on how our lives and businesses and economies and societies will be fundamentally altered. If technology, molded into any of a variety of forms, can ultimately give us continuous awareness of the geo-location, activity, interruptability, and even potentially "state of mind" of those with whom we wish to "be close to", what will it do to the nature of the nuclear family unit? The local community? The collaborative work team? If technology, molded into forms such that teams of individuals can virtually and dynamically assemble into highly productive organizational units, what will ultimately happen to the large-scale enterprise? In what industries will the mega-corporation continue to exist as a large scale employer, versus being more-or-less an aggregator and connector of highly productive smaller companies? Regardless, one thing seems certain: with the notable exception of a small number of truly visionary CIO's such as the one mentioned above - exceptional individuals who are willing to move their enterprises forward by taking risks - discovery and innovation in mobility and interpersonal productivity & communications - in "relationship superconductivity" - is being driven primarily from "the edge": from small businesses, organizations and individuals who are experimenting with new communications technologies and software. Innovation now works its way into the enterprise; it no longer migrates outward. The technology leaders of the past - enterprise IT - are now focused (for very good economic reason!!) on cost reduction and efficiency, on "fast solutions", and on a very tough regulatory environment, through strict controls. Liability, and the sheer mass and difficulty of managing broad ICT deployments encourages conservatism, and this won't be changing anytime soon. The new leader in ICT is the fast-moving, pragmatic yet open minded ultra-small business or virtual organization. And you.
|
