Will Microsoft Control Presence?

In an earlier post on Microsoft's RTC Presence Toolkit announcement, I pointed out several benefits and areas of concern. Today, Microsoft has made these controls and sample code available (note the revised name -- Presence Controls For Microsoft Office Communicator) and announced some partnerships as well (Siebel being the most interesting). The controls and sample code can be downloaded here.

Presence-enabled applications represent a new way of looking at communication, collaboration and productivity. Done correctly, presence becomes meta data that can be associated in real-time to a variety of application objects. While the buddy list of today is still relevant in terms of a user's personal networking, being able to surface a list of people associated with an particular application context is very powerful. Microsoft continues to attack this space very aggressively. RTC-enabled applications will help build the business case that pulls out infrastructure for IM, Web conferencing and IP Telephony. This has tremendous potential for improving process performance and reducing business latency.

While that sounds good, it should also (hopefully) raise a red flag someone within architecture and infrastructure groups. Before developers start running off to build presence-enabled applications they should consider the following:

1. Are there certain UI interface and design guidelines that should be established for presence-enabled applications? What are the policies and procedures that might need to be defined if people suddenly find themselves being identified as experts or as a support resource? These types of questions deal with organizational, cultural and social aspects of presence and IM.

2. Does this application-level decision commit the enterprise to a particular infrastructure platform? Does this decision map back to an architecture model that itself links back to broader business requirements? What derivative impacts are there from presence-enabling applications around IM to other RTC services such as IP Telephony and Web conferencing? Are there certain applications (e.g., call centers) where this type of application enablement is already available through packaged application providers?

3. What are the programming guidelines and reference models to support developers? Some may chose to go through Communicator (requiring it to be on the desktop) while others might chose to use interfaces that connect directly back to LCS.

Presence-enabled applications require a cohesive developer environment and corresponding infrastructure and should not be made on a case-by-case basis. Overall, I'd like to see more separation between the client and server implementation to avoid a system that is too tightly coupled. In this world of Web services, you would think that there would be a discovery and registry service for RTC-enabled clients to federate and bind to RTC back-ends.

Finally, support services need to be clearer. IT groups should make sure that Microsoft and partners clearly identify support levels (to avoid finger-pointing if problems arise) and community site(s) for internal developers (hopefully one that is better than the seemingly dead WSRP Web Part Toolkit for SharePoint Products and Technologies: Workspace Home).

So while this is a good move by Microsoft and valuable to Microsoft customers committing to LCS, due diligence is still required. And I still believe that organizations need to consider an  architecture that includes a presence discovery/aggregation/brokering/syndication hub to avoid single-vendor lock-in at this phase in the maturity of RTC technologies.