Monday, August 13, 2007

Making sense of Microsoft collaboration

Now that I'm in a Microsoft shop I've been trying to wrap my head around Microsoft's collaboration offering for the past couple of months. Microsoft's marketing says one thing, analysts and experts say something else, and the people I know who actually do collaborative applications with Microsoft tools tell me something entirely different. Then my own research may or may not match up with any or all of the other sources, so I try it out first hand and get a whole different set of results. Yeah, it's been a little frustrating.

During my research I stumbled across an article on which really helped. It's from December 2006, but it's still pretty relevant. Here are some interesting bits from the beginning of their discussion.
Microsoft's ambitious collaboration strategy is just beginning to take shape, and it's still confusing. Some products and features are far more ready for prime time than others. IT pros are faced with a portfolio that's voluminous, lacks complete unification and, quite frankly, fails to sidestep a rash of redundancies....

"Being a stack architect is very difficult these days. It used to be so simple to pick the right Microsoft technologies and build a stack," says Tim Huckaby, CEO of InterKnowlogy, a custom .NET development shop. "These days, it's overwhelming."
So what's the scope of the product line we're talking about to implement Microsoft's vision of collaboration? The official list from Microsoft includes:
  • Microsoft Office SharePoint Server 2007
  • Office Communications Server 2007 (formerly Live Communications Server 2005)
  • Exchange Server 2007
  • Office Communicator 2007
  • Office Groove 2007 (formerly Groove Virtual Office 3.1)
  • Office Outlook 2007
Note that those are only what is needed for the official Microsoft collaboration platform. Both of the Sharepoint seminars I have attended made heavy use of Infopath 2007 for online forms, and you would be hard-pressed to work in this environment without the rest of Microsoft Office. Microsoft SQL Server 2005 and Windows Server 2003 with Active Directory are considered infrastructure components and not included in the list. To do any custom development (and you will do a LOT) you need to add Microsoft Visual Studio 2005 to the list.

But do you really need all that? Let's get to the root of what collaboration is. According to Merriam-Webster, "collaborate" means:
  1. to work jointly with others or together especially in an intellectual endeavor
  2. to cooperate with or willingly assist an enemy of one's country and especially an occupying force
  3. to cooperate with an agency or instrumentality with which one is not immediately connected
In the business view of collaboration the first definition fits best (although you may also engage in the second and third :-P ). For collaborative business applications this means we need:
  • A user interface for collecting, displaying and generally working with data and information
  • A place to store the data and information
  • A rules engine for notifying others about changes to the data
  • A delivery mechanism for those messages
Continuing from the article:
Herein lies the problem: While Microsoft talks about building a seamless, pervasive collaboration platform, many analysts and users complain that the company has done a poor job of clearly sorting out and positioning the many product pieces that constitute that strategy. They believe there are some pieces that overlap each other in terms of core functions and they don't get an adequate feel for the company's long-term commitment to some components.


"They have been dropping the term 'collaborative' for a few years now, but they only talk about it in piecemeal fashion or as part of some point product discussion. [Microsoft] could do a better job helping the market understand what is really a multi-faceted story, and how these different technologies address very different problems," says Dwight Davis, vice president at Ovum Summit Inc., a market researcher in Seattle."
The experts largely agree that deploying the full Microsoft collaboration stack is difficult, confusing and there is overlapping functionality. You can create workflow apps using Infopath 2007, Sharepoint Server 2007, or even ASP.Net. When you look at the punch list of functionality required to do collaboration it quickly becomes apparent that Microsoft's portfolio lacks cohesion, focus and direction.

Okay, so peeling back the layers and getting down to brass tacks, what Microsoft tools do you need to build the same kind of basic collaborative applications that are delivered on Notes and Domino day in and day out? All you need is a form for users to enter data, a view for them to navigate through documents, and some workflow notifications with doc links. It's a surprisingly short list:
  • Visual Studio for creating a user interface
  • IIS to host the ASP.Net application
  • SQL Server to store the data and notify people about the changes
  • Exchange to deliver messages and
  • Outlook to read them
Once you get those basics in place there is still a lot of work to do. A key benefit of using Notes is the use of document links. Microsoft doesn't have a rich client like Notes (yet) so that functionality is much more difficult to achieve unless you go with an ASP.Net web-based solution. For security you can map Active Directory users or groups to SQL Server security at the object level, and you can create roles in SQL Server that encompass groups and individual users. Something like Readers or Authors fields is more difficult to implement, but it is still doable. With all that addressed then there is offline data access to consider and finally you can start thinking about application deployment and updates.

The online colleague who outlined the above strategy to me said that Microsoft doesn't provide a seamlessly integrated solution because that isn't the business they're in. They are in the business of building up integrators and resellers who will do the hard work of creating the seamless solutions. By Microsoft keeping things disjointed and hard to understand it ensures the BP's have business, and also ensures that MS will sell more product. I can't argue with that logic from Microsoft's perpective, and seeing Connections and Quickr on the horizon I can't help but wonder if IBM might be heading more strongly in that direction, too. That's a topic for another post, though. ;-)

In conclusion, if you ignore the hype and the marketing you can develop collaborative solutions on Microsoft technologies without ever touching anything Microsoft lists in their collaboration portfolio. It can be a tough uphill slog, fraught with difficult architectural decisions that can't easily be changed later, but it is possible. If you do decide to go with a pre-built solution framework then Sharepoint is Microsoft's answer. However keep in mind that Sharepoint is more comparable to Quickr and Connections than Domino. Microsoft has no direct answer to Domino or Notes.


  1. Charles, thanks for the analysis. Your perspective (having one foot in both camps) is priceless. I've heard that my previous employer (Blockbuster) has been looking at moving their Notes apps to Sharepoint... and now that I've read this (and previous posts on this issue), they have my sympathy!

  2. Great overview, Charles! Thanks for your unique insight. I am watching this space with interest...

  3. Great observation and I know you know what your talking about. Here's a link to an article I have printed on my desk that talks about the same subject.

  4. I've read that before, Curt, and I have too many problems with it to list here. I'm all for comparing things side by side, but this writeup was done with an extreme bias that it is basically FUD.

    My point here is that you don't need the full MS product portfolio to create collaborative applications. You only need three: Visual Studio 2005, SQL Server 2005, and Windows Server 2003 (which includes IIS and Active Directory).

    Microsoft has no direct competitor to Domino; in order to build comparable functionality using their applications you end up with something more like Domino + Quickr + Connections.

    Nathan has said he doesn't really see the point in Connections because most of it can be done in Notes and Domino today. The same holds true on the Microsoft side. The majority of applications don't require the full portfolio to be deployed.

  5. Nice post Charles. I'll be pointing people in this direction!

  6. In my mind, aside from the RAD part of Notes Development, the key piece for me will continue to be the integrated security infrastructure that Domino has. I can't imagine having to build a workflow application without Author and Reader fields or Roles. And without them, how can you ever really take an application offline?

  7. Sean, I agree with you. The security model is the biggest weakness in the Microsoft portfolio, and that contributes to the ... difficult ... offline experience.

  8. This comment has been removed by the author.

  9. Hey Charles,

    I got pointed here by a Lotus extrimist today that works in 'my' unit. Your view upon the matter is somewhat more technical then mine is from a managers point of view ( but I agree with your conclusion. It can be done more simple, and is overhyped. I wonder what one would need to add to your shortlist to integrate with things such as MSN, PDA's, GSM's and more.

    Regards, keep it up.

  10. Charles,

    If I can help in any way clarifying things let me know, Or have I confused things already too much in the past ...

    I'd be more than happy to setup a LiveMeeting with you to clarify some things and demonstrate Microsoft's capabilities in Communications and collaboration, unless your intentions with this post have a different objective.

    This morning I ran into a good article on MOSS 2007. It may not cover what you refer to as 'the collaboration platform / strategy, but then again ytou've also not provided the context / scope of your quest clearly.

    The authors are going to also publish 3 additional articles on the Servers in the 2007 Office Systems :

    "... We'll start by looking at MOSS on its own, enough for a solid summary of its purpose in life. In the next three articles, we'll look at the other servers in the Office Server family, examining how they work with their Office client counterparts and what advantages they gain when paired with SharePoint on the back end. We'll start with Groove and Groove Server, hit InfoPath and Forms Server, and last we'll look at Project and Visio and how they work with Project Server". ..."

  11. sorry copy pasting is not my expertise :-)

  12. @Peter - My primary intent here was to show that you don't need MOSS to do collaborative apps with MS tools. The marketing will tell you that you do, but I've spoken at length with developers who code workflow apps very similar to what I do in Notes without ever touching anything in the Microsoft collaboration portfolio (and they're not using Workflow Foundation, either).

    I am interested in seeing a real world use case for Sharepoint, so I'll read the Infoworld article ;) and look forward to the rest of the series.

  13. Charles,

    I do not have the intention to fully "spam" your post, but today in my inbox I received the link to an 'on topic' TechEd video on MOSS 2007.

    As you seem to question SharePoints relevance in a 'make or buy' comparison, it seemed approporiate ...

    "Microsoft Office SharePoint Server 2007 is much more than an upgrade to SharePoint Portal Server (SPS) 2003 and Content Management Server 2002. This session covers technical fundamentals, feature overviews, new sets of server functionality and implications for developers and IT professionals alike."

    O, and Tom does not represent our marketing department, nor does his use glossy folders in his overview ;-)

  14. Charles, can't you do the same thing that you can do with VS, SQL & Win 2003+IIS in J2EE server + Relational Database with some form of AD replacement?

    Why do you then require Lotus Notes/Domino?

    I think you miss a need for messaging server in you list.

  15. This was specifically a comparison for the people coming from Domino world view. I don't use Java so I have no idea what the capabilities are in that area.

    I included Exchange in my list of MS products needed:

    # Exchange to deliver messages and
    # Outlook to read them

  16. "I included Exchange in my list of MS products needed:"

    > I was ref. to your comment #4, where you said. I think any basic work flow, will require email product.

    "My point here is that you don't need the full MS product portfolio to create collaborative applications. You only need three: Visual Studio 2005, SQL Server 2005, and Windows Server 2003 (which includes IIS and Active Directory)."

    "This was specifically a comparison for the people coming from Domino world view"

    > I felt you unintentionally/unknowingly characterized MS collaboration offerings in poor light and it was even somewhat misleading to read you can build them with just 3 products. But, how much time would it take to build it?

    What Lotus or SharePoint provide you, however is a platform to build sophisticated collaboration and easy forms based workflow application. How many products it takes to build in MS is a different story.

    SP/WSS come up with some interesting out-of-the box collaboration features as well.

    I completely agree to your: "Microsoft has no direct answer to Domino or Notes"

  17. Mr. Anonymous - I don't disagree that using pre-built frameworks puts you further ahead than doing everything yourself. However, doing that in a Microsoft environment has two consequences. First, the portfolio is voluminous and products overlap a lot. For example, BizTalk does workflow and so does Infopath. Figuring out when one is needed over the other is equal parts science and art. (I don't want this to become a debate about Infopath vs. Biztalk. That's not the point I'm making.) Second, many of the products require their own servers, which means a simple application can span as many as half a dozen servers. Each of those products requires some highly specific knowledge, so you end up with a team of administrators and a team of developers.

    Any characterization of the Microsoft collaboration portfolio in a poor light was absolutely intentional. In my opinion the products overlap too much and it's exceedingly difficult to deploy them. Until the Microsoft portfolio becomes more cohesive I'll go the build my own route. The real-world non-Fortune-XXX developers and managers I have talked to advocate doing the same.

    You may have some sources that refute this (I'm sure Peter does), but I truly don't care. I don't mean to be disrespectful, it just really doesn't matter to me what some corporate marketing machine tells me is true when I can see it for myself.

    This isn't a ringing endorsement of the IBM/Lotus portfolio, by the way. Their approach makes more sense to me, at least as far as Notes and Domino go, but beyond that it's too Java-centric for my tastes. But that's just me.

  18. And there is this SharePointDesigner

    I feel MS has a lot of integration work to do - but, thats just from a Notes developer perspective. I guess MS developers won't complain so much; they should be used to dealing with multiple MS products to create a solution ;-)

  19. Henry BestritskyThu Aug 23, 03:44:00 PM


    Great assessment and I absolutely agree with your findings.

    I do have one question thought...

    Ed Brill mentioned a few times in his blog that there will not be many Notes developers in 10 years and the focus is to do a platform shift into composite applications.

    Frankly, this comment does not sit well with some of my clients. They start comparing IBM's J2EE collaboration stack and it's not that great.

  20. Henry, what is your question? I agree with your observation about the J2EE stack being uninviting and difficult to get started with.