Along the way, quite a lot of baggage had to be jettisoned. Avalon will run only on high-end PCs. A stripped-down version
might be capable of running Windows CE, Dieken says, but "the spirit around Avalon is to exploit the PC as much as possible."
Similarly, Avalon plays on the Web only in the sense that ClickOnce deployment can send partially trusted applications to
clients running the full Avalon stack. It makes no use of Web standards such as XHTML, CSS, or SVG (Scalable Vector Graphics)
and indeed invents its own counterparts to these. Some observers initially hoped that XAML would support an alternate rendering
for the Web. Clearly, enterprise developers seeking maximal reach for minimal effort would have loved that solution. According
to Dieken, the Avalon team gave it a try, spending months working on an ASP.Net-like approach before concluding that no single
model could adequately express both paradigms.
If you decide there's competitive advantage in giving rich Avalon experiences to your intranet or Internet users, Microsoft
will dramatically simplify the task. But you'll have to do everything again -- and very differently if you also want to reach
the Web. Although ASP.Net 2.0 can surely help, Microsoft is doing nothing to improve Internet Explorer's support for DOM,
CSS, SVG, or other standard ways to enrich the browser. And despite the fact that open source critics assert that XAML need
not have been bound inextricably to the proprietary Avalon stack, Microsoft sees no possibility of -- and no real motivation for -- a standard rich-client technology. "You can make an argument
that the customer will benefit from the competition," Dieken says, adding that "it will be hard for some developers who have
to make a choice."
For developers of commercial Windows software, that choice boils down to timing. Today, for example, more developers would
like to use .Net, but they refrain because there is no end-user version of Windows that includes .Net as standard equipment.
For enterprise developers, however, there's more to worry about than the center of gravity of the Windows installed base.
Microsoft is careful to point out that Avalon is not a reach technology. But enterprises need reach and can ill afford to
invest in a rich-client technology that forecloses that option.
The Whole and the Parts
Longhorn would make perfect sense in an alternate universe where the Web never happened, where phones stayed dumb, and where
Windows applications owned the edge of the network. But in this universe nothing owns the edge. We have browsers, we have
computerized phones, and we have a growing number of portable, rich-client technologies. Although Microsoft would like us
to regard Longhorn as a unified whole that's greater than the sum of its parts, its pillars will intersect with enterprise
IT in quite different ways.
Indigo, by virtue of its developer-friendly simplification of Web services protocols, could propel Microsoft into the forefront
of enterprise middleware. Although Longhorn's use of Indigo will focus on networks of Windows peers, the technology isn't
bound to Longhorn. Expect to see Indigo-powered "enterprise service bus" offerings from Microsoft and partners.
If WinFS succeeds in delivering improvements in users' ability to organize and manage local information, enterprises looking
to drive productivity up -- and support costs down -- will want it. The wild card will be the level of support for legacy
document formats and emerging XML formats. Benefits that accrue only to new WinFS-aware applications won't tip the scale.
Avalon's TV-like "presentation experiences" clearly favor the home entertainment center over the business desktop. An accelerated
convergence of voice, video, and data could alter that equation, and Avalon is designed to help drive that convergence. But
enterprises concerned about reach and lock-in will need to carefully evaluate the trade-offs.
How will things will play out? Check in in five years and let us know if our crystal ball was cloudy or clear.