|
 |
 |
640KB ought to be enough for anyone
Of course, it's most likely just an urban myth that he actually said this, but the quote certainly evokes imagery of a simpler time ... and repeatedly serves as a wake-up call to the short-sighted. Over the past couple of weeks, based on what I've said post-PDC, a number of people have said to me, "I just don't get it. What's the big deal about WinFS? Who really cares? There's already a "Search" item on the Start Menu - all of this, just for that?" IMHO, in order to appreciate the potential importance of WinFS, I believe you have to look further than what you see on your desktop today. "Beyond 640K", if you will. So please bear with me while I ramble a bit. To begin with, consider an analogy to Web Services. To some, Web Services means enhanced systems modularity and scale through a service-oriented architecture. To others, though, it means something much more significant: the creation of "independent party transaction network effects" through domain-specific protocol agreement, based fundamentally on common message schemas and conversation patterns. Agreement on common formats and protocols can yield powerful network effects and unintended positive consequences: this is already quite apparent in how people are beginning to leverage Amazon's Web Services, and in the innovation surrounding RSS (and of course HTML). On the PC client, however, it's a different story. Even after many years of client-side innovation on the PC beginning with VisiCalc, we've failed to create a commercially ubiquitous environment in which multi-party, component-based network effects could or would naturally happen on the client. The industry made valiant efforts with "compound document" initiatives such as OLE and OpenDoc, but to this day PC applications largely remain stovepipes with only very coarse-grained interaction - through largely-closed file formats and the clipboard. In the meantime, we've been teasing ourselves and our users with the power of componentized function, rich object models, schemas and persistent storage in the form of integrated application environments. Lotus Notes enabled powerful form-based applications and solutions on top of its own rich client-side object persistence mechanism. Microsoft Outlook elegantly integrates tasks, messages, and calendar functions based on its own internal object model and persistence mechanisms, while Chandler promises to do the same - likely with richness genetically inherited from Lotus Agenda - again with its own object model and persistence methods. Userland Frontier has had its own sophisticated and leveragable object store for quite some time, and even RSS aggregators such as SharpReader have private object and relationship persistence mechanisms. Each is very cool in its own right, and each such application environment implemented its own object and storage model for good reason: a rich model is needed in order to accomplish sophisticated user experiences. Each has persistent application-specific objects and sophisticated persistent inter-object relationships, custom views, and so on. In each case, the designer encountered requirements that made it difficult to build their application on top of standard relational databases or file systems. And in each case, the designer ended up saying "now that we've invested in this framework, let's offer it as a platform so that other developers can plug in their own modules and custom schemas, and a powerful ecosystem will naturally emerge!" But it hasn't happened. No single framework has achieved PC-like or browser-like ubiquity; as powerful as they are, these environments have and will likely remain islands of function and islands of users. Outside of the PC mainstream, we've seen many sophisticated demonstrations of the power of network effects fundamentally based on client-side object models and dynamic binding of independently-created components. From the power of piped unix commands, to the elegant and incredible sophistication of language-derived Lisp, Smalltalk, and Squeak environments, we know that the power is there to be had. But again, none of these environments has become mainstream - each perhaps having remained niche by drowning in its own idealism. Which is the basis for why I'm excited about the potential of Longhorn - and in particular, WinFS - to significantly change the game. As noted above, much of what has been written about WinFS is around the value proposition of "Find My Stuff". Most people think of "Find My Stuff" as "Search" - as in "Google for my PC". But if local search itself were such a dramatic pain-point for all of us, wouldn't Enfish Tracker have been the one about to have a $decabillion IPO? Hmm. No - the "big deal" about WinFS IMHO isn't "search". Like Web Services - it's about the fact that it's an attempt to get a higher level of interoperability between programs through agreement on schemas. Hopefully, toward the goal of bootstrapping network effects, and unintended/innovative consequences, on the client. WinFS defines an extensible object model and persistence mechanism, as well a rich and extensible "relationship" mechanism that can be used to intertwingle objects with that are somehow related to one another. Some kinds of stock relationships are obvious: common Author, common Artist, common Location, common Priority, etc. Some may be more subtle or domain-specific: common Project, common Client, common Contributors, or even manual and thus not-easily-described ties. In a pre-WinFS world, each application has managed its own "documents" and "records" and "collections" as an island unto itself - each with its own indexing and interaction mechanisms, each with its own solution-building mechanisms. Good 'nuf. But in a WinFS world - just like in a Web Services world - we have the opportunity to explore what would happen if we dared to "deconstruct and refactor" our concepts of traditional client-side applications into a mesh of separately-built application components that "meet" at the level of common persistent objects and relationships. Imagine what a traditional PIM might look like if it were possible to build it in a modular fashion, with each modules' underlying object schemas, store, and methods exposed as standards so that others could build upon them? Imagine building custom domain-specific client-side CRM/SFA solutions that might leverage these common standards. Imagine the deconstruction and refactoring of traditional desktop applications so that higher-level domain-specific applications and solutions could be built from components currently embedded in larger integrated packages. Imagine what "content management" might become in an era where collections of objects can be created, retrieved, cached, replicated, published in conjunction with service-oriented systems, yet one in which a variety of content creation and manipulation applications can effectively leverage common storage and synchronization mechanisms. Of course, this cannot and will not happen overnight. It's unlikely that anyone will make the investment necessary to deconstruct and reconstruct mainstream applications unless there is an actual "fundable pain" that is clearly addressed by the new methods. But I do indeed think it will happen before too long - particularly in applications related to collaborative productivity and content management, and the "mobile" components of enterprise applications. Again, using the WS-* analogy, developers will start to standardize from the ground up, with basic agreements on "envelope" (the most basic "item" schema) and, slowly but surely, domain-specific schemas for richer object and relationship types. Microsoft will obviously drive the initial schemas required by the core system - such as Contact - but where will it go from there? What will a refactored Adobe Photoshop Album look like in this environment? Or an iTunes for Windows? Or the mobile client for Siebel, SAP, Great Plains, or salesforce.com, with all client-side data now open and available to VARs and other solution developers? We should applaud Microsoft for taking the initiative in doing Longhorn and WinFS for two reasons: they can uniquely afford to make the staggering investment required to build this stuff, and they are uniquely in a position to create client-side network effects - not only to their sole benefit, but also openly to the benefit of the customer and solution ecosystem. But the latter will only happen if other developers actively participate in leveraging common WinFS schemas, extending them in domain-specific ways, and standardizing additional types. It will be interesting to see whether this activity ultimately comes from the big players (as has the more recent WS work) or from smaller players/disruptors (as has RSS). One other note, while I'm rambling. I continue to hear remnants of the "thin" versus "rich" client debate, and I frankly can't understand why. It's not an absolute; there will be both. A cute phrase that I heard from someone was that it's an issue of "rich vs. reach": if you need ubiquitous reach, you will clearly always target a browser. You'll of course also do so in kiosk situations, or in the enterprise where per-seat management cost is high as compared to the business value generated by a specific class of information worker. But let's get real: the rich are getting richer. The pendulum has swung back - and on the client side, you ain't seen nothin' yet. There are two significant factors working in favor of the future of the rich client: storage and communications. On storage: Jim Gray and others have spoken at great length about the trends in storage capacity, and before long we will find our commodity PC's coming standard with terabyte (1,000+ GB) disks, or more. There's no longer any question that the very meaning of "PC" is rapidly shifting from Personal Computing toward Personal Communications and Personal Content. Without going as far as MyLifeBits, it's not difficult to imagine saving, on your PC's disks - all interlinked at least in terms of who, what, where, when, and why; and subsets of which will be replicated across many devices,
And you'll leave it all to your kids. And their kids' kids' kids. Surely we will want and will have many ways of creating, editing, viewing, publishing and otherwise manipulating this vast array of content - particularly over the course of many, many years - and will demand and embrace the fact that such content is stored, indexed, and searchable in a way that is standardized, long-lived and open to our choice of application. On communications: Rght now, many in the mainstream are just getting their first taste of "broadband" - generally asymmetric, in the low single-digit megabits-per-second in one direction, and the low hundreds of kilobits-per-second in the other direction. This feels truly wonderful as compared to where we came from - dial-up. But before too long, this "fat pipe" is likely going to feel progressively slower, and slower, and slower. Why? Just think about it: Increasingly we're generating "personal content." LOTS of it. We're needing to share content with our families, friends, and dozens upon dozens of people with whom we need to work and interact. 30MB PowerPoint presentations. Huge sets of digital photos. We're replicating TiVo'ed and cached copies of media across multiple PCs that we own, and soon we'll be automatically replicating subsets to a variety of other highly-capable mobile viewing and interaction devices. If indeed we've got terabyte disks full of our stuff, that stuff had to somehow get onto those disks - which means not only "downloading" from websites, but also "crossloading" via peer-to-peer inter-device communications. As we drag & drop gigabyte stacks of digital photos from PC to PC, and as we drag & drop gigabyte collections of records from centralized services to our laptops so we can do some ad hoc business analytics, the 256KB crossload speed (or even a megabyte download speed) is almost certainly going to start feeling like dial-up, and the multi-PC home LAN will feel more and more like a "fast cluster". And as powerful laptops and wireless mobile use becomes more and more prevalent, taking huge collections of information "with you" will become more and more commonplace. Always on? Well, frequently ... except in the hills of Woodside. Always fast download? Always fast streaming? Always fast remote user experience? Unlikely. Multi-core CPUs? Wicked GPU? Vast storage? Integrated connectivity? Many form factors? An appropriate operating environment and apps? Yeah, I do need "reach" to Google. But "rich" never felt so good.
|
