I didn't attend Microsoft's annual TechEd conference last week, but I did manage to pick up a catchphrase making the rounds there. Microsoft repeatedly used the phrase "contextual collaboration," originally coined by META Group analyst Matt Cain, in its presentations about where Microsoft .NET and other technologies are taking us. META defines contextual collaboration as "strategies enabling customers, employees, and partners to plan, share, clarify, negotiate, brainstorm, coordinate, build community, and exchange information within operational applications." Earnie Glazener, product manager in the .NET Enterprise Server Division at Microsoft, puts it more directly: "Contextual collaboration means the consumption of collaboration data or services in the context of some other solution—usually a LOB [line of business] solution."
Contextual collaboration is access to just-in-time (JIT) information—for example, plugging someone's contact information into an overall plan without having to leave your project planning tool and do an awkward copy and paste. Glazener cites the example of purchasing a new satellite television system over the Internet and being able to schedule an appointment on a technician's calendar. Last year's Microsoft Enterprise Conference (MEC—formerly Microsoft Exchange Conference) demonstrated just such an application—a Web page where customers could state their preferred installation time and schedule an available technician, based on free/busy information from the Exchange server at the technician's company.
Contextual collaboration makes good sense and has the potential to yield a more productive, more satisfying workplace. People want to get their jobs done, not spend time learning to use yet another specialized computer program to look up particular information. Through its emphasis on integration into existing applications, contextual collaboration implies a move toward components that can reach out for collaboration data. Smart tags in Office XP are a good example of such components; they can pull data from Exchange or from a shared database or document repository.
But the big contextual collaboration technology for Microsoft is XML Web services, a key element of the .NET strategy. Exchange is uniquely positioned to be a huge provider of such services. The servers are in place, the data is there, and Microsoft is providing a toolkit to show companies how to expose their Exchange data as XML Web services to customers and partners. The Exchange 2000 XML Web Services Toolkit, announced at TechEd last week, includes sample code to build XML Web services for free/busy inquiries and scheduling, contacts, and workflow.
At first glance, contextual collaboration seems to be at the other end of the spectrum from what I call "living in Outlook," or the widespread practice of leaving Outlook open all the time and integrating other applications into the Outlook framework through COM add-ins, Exchange public folders, third-party Messaging API (MAPI) providers, digital dashboards and folder home pages, and Outlook Web browsing. Does Outlook have a future in the world of contextual collaboration? I think so. There's no technical reason why you can't plug LOB information into multipurpose programs, such as Outlook, Microsoft Word, and Microsoft Excel, that users have open all the time. In fact, Microsoft has released an Office XP Web Services Toolkit with documentation and sample code to show how Outlook and other Office programs can be "consumers" of XML Web services. One Outlook sample shows how to pull current book-price data from Amazon.com and Barnes & Noble.com into an Outlook item.
Whether you pull collaboration data into an LOB application or business data into a collaboration application such as Outlook, the future is likely to be one of integrated components. And therein lies the challenge: It's hard enough today to troubleshoot problems with individual programs. As contextual collaboration advances, determining whether the problem lies with the base application or with one of the many components with which the application collaborates will become more and more difficult. Developers must ensure that their smart tags, XML Web services, and other components are simple, well-documented, thoroughly tested, and well-behaved applications that can play well with others.
Exchange 2000 XML Web Services Toolkit
Office XP Web Services Toolkit
End of Article
Register
