Putting people first for a change

The key to Microsoft's goal of hooking Web services into Office lies in the eye of Hailstorm

AS WITH EARLIER MICROSOFT mantras (ActiveX, Windows DNA), .Net means almost everything and therefore nothing in particular. The Redmond priesthood incants XML with the same mystical vagueness. No resounding amen has yet been heard from the hundreds of millions of souls who use Windows and Office, who were recently demoted from "knowledge workers" to "information workers" and then reclassified as "first-class data objects." Instead they ask, "What's in it for me?"

The answer is a vision of computer-assisted work and play imagined by science fiction writers for decades -- by Apple in a 1987 concept video called Knowledge Navigator, and again by Microsoft two summers ago when it first rolled out the .Net strategy.

The truth is, nobody knows when, how, or even if we will get from here to there. XML and .Net are really just code words for sets of best practices that will, we hope, create an environment in which the vision can be made real. It's useful to unpack these terms and list what those best practices are.

First, consider the engine at the core of .Net: the CLR (Common Language Runtime). Already deployed on servers, and coming soon to a desktop near you, CLR unifies the two great themes of modern software: objects and components. The ideas embodied in the CLR are so unstoppable that Microsoft's open-source competitors are rushing to embrace them.

The chassis of the vehicle powered by this engine is the .Net Framework. Its design goal, first stated by Microsoft architect Dave Stutz, was to capture a wide variety of best programming practices. A work in progress, the framework also wraps consistency around a welter of legacy APIs, first by consolidating interfaces to the servers (see " Road to managed code "), then by doing the same for the client.

Parsing the meaning of XML

The .Net Framework is deeply XML-aware but, again, it's helpful to unpack the ways it is so. Empowering components to communicate using SOAP messages is the framework's most heralded use of XML. When Visual Studio .Net and its ASP .Net infrastructure shipped in February, some early adopters had already been deploying Web services based on this technology for more than a year.

More broadly, the framework enables applications to create, exchange, and store documents that represent all kinds of data using XML. Schemas that govern the structure of this data will, in theory, make it available for intelligent use and reuse. In practice this semantic Web architecture is as far behind the curve as .Net Web services are ahead of it.

In the concept videos, of course, it's a done deal. All data is smart-tagged. DNA winding its way through the core of every document governs its behavior within an information ecosystem. How that DNA got there is a question that everyone begs. Who will write the Web Ontology Language that Tim Berners-Lee and the W3C imagine as the lingua franca of the semantic Web?

The answer is everyone, and most of us will use Microsoft Office products to do that writing. Every day, we pour an ocean of information into Outlook e-mail messages, Word documents, Excel spreadsheets, and Web pages rendered in Internet Explorer. The sum of all this data vastly exceeds what is stored and managed in databases, and essentially none of it today has anything to do with XML.

Strategies that aim to change that include shipping .Net to the desktop, upgrading SQL Server's XML engine in Yukon, and converting the Windows file system to an XML object store in Longhorn. But focusing on these future plans deflects attention from what was already feasible several generations of Office ago. The .Net Framework only recreates, in managed code, the XML parsing, validation, manipulation, and transformation technology that has been standard in Internet Explorer, and therefore the Windows OS, for at least three years. Office hasn't exploited this stuff because Microsoft has been in no hurry to commoditize the proprietary file formats on which the Office empire was built.

The turning point may finally be at hand. Last month, Office czar Jeff Raikes showed Word 11 working with schema-valid XML. The enthusiasm that bubbled up on the developer Weblogs that registered this event was a measure of the pent-up demand. Users aren't clamoring for XML writing tools, but they do respond to the concept videos, and developers know that deployment of those tools will help them deliver the goods.

One deliverable Microsoft isn't promising for Office 11 is the universal canvas touted in the 2000 .Net rollout. This notion pushes embedded OLE objects to their logical conclusion. All data is represented as XML; application boundaries dissolve; users create or annotate any piece of data in any context; the self-describing XML data says which tools can manipulate it. This can't happen any time soon, Raikes told InfoWorld, because the applications' storage and retrieval algorithms are optimized in ways that preclude working with live XML storage.

For Jack Ozzie, who has labored mightily to graft Office apps onto the canvas of the Groove transceiver, it's more than a storage issue. "If it were just about the data, we'd have been done three years ago," Groove's vice president of development says. "The problem is capturing the context that surrounds the data."

The XML support finally coming in Office 11 is a crucial step in the right direction. Retooling the file system as an object database and retooling the apps to work with that database are long-term goals. They were first articulated a decade ago when Microsoft demonstrated Cairo (the original NT 5.0) and its query-driven Object File System. A few distractions got in the way -- the Internet, the transition from the Win9x to WinNT codebase -- but Cairo has not been forgotten.

Apps, docs, and people

It's a tragic fact that programmers have to think like machines. Usability expert Alan Cooper has said that from a programmer's perspective, users are peripheral devices that must sometimes be polled for input. Over the years, the focus has gradually shifted from applications to documents as the organizing metaphor, but the cluttered GUI desktop embodies little of the social fabric that knowledge, oops, information workers weave.

The gone-but-not-forgotten Hailstorm initiative was an effort to put people at the center of the software universe. When the socially inept masters of that universe try to restate their case, they utter awkward phrases like "first-class data objects." Luckily, developers all around the Internet know what that's supposed to mean, and have been busily making a trail of clues for Microsoft to follow: ad hoc peer-to-peer networking, instant messaging, presence, Weblogs, and publish/subscribe notification. For example, if you use XML, it's likely because your Weblog sports the distinctive white-on-orange XML icon that other bloggers click on to syndicate your feed.

The blog bug has bitten Microsoft, too. Twenty thousand Sharepoint Team Services sites have popped up inside the company. Now that "save to the Web" means something tangible in Redmond, Sharepoint has been invited into the Office family. Of course, people aren't always and only connected to the corporate intranet.

When Groove founder Ray Ozzie surfaced with a set of peer-to-peer, presence-aware services that enable ad hoc teams to work securely together across firewalls without full-time network connections, Microsoft sank $51 million into Groove Networks and began using the word "collaboration" more prominently in PowerPoint slides. The results so far are entirely attributable to Groove, which delivered shared editing of Office documents in version 2.0 of its transceiver and more recently enabled two-way synchronization between Sharepoint sites and Groove shared spaces.

How Groove's collaboration services will find their way more deeply into Office is something nobody will discuss, perhaps because nobody has yet figured it out. There are oodles of opportunities. The NAT (Network Address Translation)-challenged NetMeeting functions of Windows Messenger, for example, could sure use a Groove-style relay server. (Greenwich, the real-time communication server just announced by Microsoft, seems destined for that role.)

The security concerns that plague all Microsoft software cry out for the always-on wire and disk encryption that Groove shared spaces enjoy. Synchronization of data to intermittently connected users on multiple devices (desktop, notebook, tablet, PDA) and awareness in real time of users' presence on those devices are other Groove capabilities that should pervade Office.

The biggest hurdle may be cultural. A version of Office that puts people first, not applications or data, has to revive Hailstorm. Software that does what we want has to know what we want. If we want to be interruptible by family members but not team members (except in emergencies), we have to represent ourselves, our family, and our team as, pardon the expression, first-class data objects. These avatars need to live outside the realm of existing applications and directories where any authorized service can talk to them. Microsoft got smacked upside the head when it first floated this idea, and not without reason.

The most critical piece of Internet infrastructure since the DNS really shouldn't be a Microsoft business unit. Now, happily, everyone's singing in the federated identity choir. But the fact remains that to make the concept videos real, we'll have to schematize ourselves as well as our data, and we'll have to trust someone with those schemas. Assimilating XML and .Net into Office are only technical challenges that programmers will sooner or later solve. Rehabilitating Hailstorm will require what Microsoft famously lacks: social skills.