Today is another “Big Day” along the road to Office Communications Server 2007 (OCS). For those interested you can read the announcement of the private beta and of the features this new release will include. This is great news and should be very interesting for users, administrators, and generally anyone who wants, or needs, to communicate or deploy and manage an enterprise communications system. We are building a very compelling and powerful user experience with Office Communicator and a strong communications infrastructure with OCS. While I am very happy to see all the hard work the team has done come together and I love using this solution, I will not talk a lot about this solution on this blog. That is not why I am here.
To me the most interesting part of the press release is:
Microsoft is bringing the pace of software innovation to communications to deliver a people-centric experience. According to a recent Gartner Inc. report, “The ultimate driver of VoIP is not merely cost savings, but is in business process integration. Enterprises should evaluate their long-term strategy toward developing IP telephony applications beyond basic telephony, including business application integration.”[1]
That is why I am here.
I am here to participate in figuring out what “business process integration” and “business application integration” mean with respect to unified communications. There are a lot of ingredients in this soup. VoIP, Video, IM, Presence, Identity, Federation, Text to Speech, Speech to Text, Phones, Soft Phones, Applications, Services, IVR to name but a few. I don’t have the answers as to how all this will shake out over time. We are just at the beginning of the road and where this road will lead is open to a lot of possibilities and obstacles. I think we developers have a lot to learn before we will be able to get a glimpse of the end of the road.
That being said, I do have some ideas on where developers can start to develop for unified communications.
Applications today know a lot about their users. In fact a lot of the time the application I am running knows more about who I need to communicate with then I do. Reading mail is an easy example.
As I read mail my context is the message I am reading. At that point in time I don’t care about my contact list, I care about other people involved in this email thread. I need to see those people’s willingness and ability to communicate with me. If I want to change from communicating via email to a more real time mode like an IM session or perhaps a multiparty video conference then that should be a click away. When I make that click it is only polite that I let those people I am asking to communicate with know why I am contacting them in real time.
This basic idea can apply to all kinds of applications. Who entered this PO, who approves it? Who has commented on this blog post, are they able to have a voice conversation right now? Who can help me with this customer issue, who can I escalate the call to, can we conference in an onsite consultant to have them take over?
This is an area of great potential. There are a lot of services available to an enterprise user today. Users can access these services in a variety of ways. Smart client applications, browser based applications, etc. Should these services start to communicate with their users in new ways? Here are some examples:
A user should be able to send an IM to their CRM system to get a customer address or other data like current sales, while the user is out of the office and only using a mobile device. Perhaps the user should be able to call the CRM system using voice because the user is currently driving and needs to keep their hands on the wheel. An enterprise expense report system should be able find expense reports that have need to be paid to avoid extra fees and the contact the report approver when the approver becomes willing and able to communicate. The communication should work regardless of the device the approver has available. If the approver needs more information the expense report system should be able to conference in the employee over the same available media.
An enterprise using a unified communications infrastructure is able to access all of the signaling used to create communications, subscribe to presence, publish presence, instant message, etc. This means developers could write applications that change the way a communication session gets routed or log the fact that a communication was requested, accepted or rejected. Since all the text based communications, Instant Messaging, goes through this path applications could monitor, archive or even modify these messages. We had one customer who developed an application that looked at who was involved in every conversation request. If the request contained one of their employees and the other participant was a person of interest, the application would start a conversation with the employee and “help” the first conversation. For example the application would tell the employee information the system knew about the other person like how many papers they had published and in what subject areas.
I will explore each of these areas on this blog. Hopefully I will be much more helpful by providing some “how to” and pointers to developer resources so you can start your own journeys along the unified communications roadway, or maybe create your own road altogether.
Kyle Marsh
[1] Gartner, "How to Select the Right Approach to VoIP: Nine VoIP Scenarios," September 2006.