It was common knowledge that Microsoft was releasing a new version of its communications and collaboration suite this year, but behind the traditional development cycle, the Microsoft marketing machine was operating at full speed as well. The name “Communications” has been replaced by “Lync” broadly across the traditional OCS product line, reflecting in my opinion, the fact that enterprise communications and collaboration is all about linking the people, processes, and thoughts that drive creativity. I am fond of saying that there is the verb “to collaborate” (what humans do to create new and better ideas together) and the noun “collaboration” (what many tech vendors sell in the form of collaboration platform software). By adopting the name Lync, I believe that Microsoft is taking to heart the requirement for communications software to link people, processes, and ideas, while SharePoint remains the place where those ideas are stored and shared on enterprise networks for companies that have adopted Microsoft’s unified communications and collaboration (UC&C) products broadly.
Beyond the name, I believe that the most compelling news is that Microsoft is now getting serious about its Microsoft Lync Server being ready to replace the private branch exchange (PBX). Many Microsoft execs — from Gurdeep Singh Pall, corporate vice president for the Office Communications Group, through BJ Haberkorn, OCS senior product manager responsible for voice — have spent extensive time telling me about the reliability and scalability of Microsoft’s voice services within its UC&C solutions. Microsoft continues to expand its feature set to compete robustly with other communications vendors. New capabilities of the Microsoft Lync Server include:
Rich presence providing access to things like location or user skills.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)