The Difference between SharePoint and Lotus Notes
If you're familiar with Lotus Notes/Domino, I'm sure SharePoint, in many ways, feels like a
déjà vu. But because we don't cover the Notes client or the Domino server (well, not on its own, though we cover several IBM Lotus products that run on top of Domino), I've never really compared them head-to-head.
I was discussing this with my colleague Apoorv Durga today, and rather than focus on the resemblances,
we tried to think up the most essential differences. Of course, this is comparing apples to oranges; but if you're willing to think of both as "grown in orchards" and "considered a fruit," you can, in fact, compare them:
- Notes/Domino comes with a mail server; with SharePoint, you need to add Exchange (but SharePoint and Exchange are much less integrated with each other than the Domino components, and in fact, they sometimes compete for the same collaborative scenarios.)
- A technically inclined person can quite easily build impressive forms-based processing in Notes/Domino. In SharePoint, you really need a .NET developer much more quickly than you'd think.
- But if you do start developing things, it's hard to get your Domino applications past the initial "rapid prototyping" stage -- most custom applications in Domino start out as something that's quickly whipped up, and then keeps being modified. (They're also notoriously difficult to maintain once the original creator has left your company.)
- SharePoint is much more developer friendly; Visual Studio is a very capable development environment, and though Notes/Domino does have development tools, they're comparatively basic.
- And on a very technical level: the Lotus NSF "databases" are not relational. There is no way to do a JOIN with Lotus "tables" (they're called "views" in Domino). Really. It's impossible to do a look-up in a list field to another field in another list. If you think that's some incredibly technical detail that's not very crucial, well, try to create a view of all of your employees, with one field that displays their phone number (taken from another list). You can't, and I've seen several Notes/Domino developers on the brink of a breakdown trying to get around this. By contrast, SharePoint stores everything in MS SQL; it's really easy to do lookups within a list field.
This is just what we came up with in one afternoon, and by no means as comprehensive as the comparisons in our Evaluation Reports. So what do you think? I'd welcome any additions or corrections in the comments below. Lotus Notes/Domino may be yesterday's news compared to SharePoint, but it's still alive and well in many enterprises -- and I have a nagging suspicion Apoorv and I are not the only ones comparing notes.
[Update: 07 December] Sorry about the comment on IBM phasing out Notes/Domino, which obviously didn't come across as it was intended. I've therefore decided to delete it (or rather, for the sake of transparency, to leave it there but to strike through.) My colleague
Meanwhile, thanks to those who contributed technical insights in the comments. I have some follow-up questions that I'll address there.
Lotus and SharePoint - a mea culpa and other thoughts
My colleague Adriaan mis-spoke when he said IBM was "slowly phasing out" Domino. IBM is doing no such thing. For that, I apologize. We have corrected the original post.
One has to be very wary about generalizing about Lotus, since that brand extends from the likes of Lotus WCM and Connections (which are really more closely tied to WebSphere), through Quickr, to e-mail and other groupware services, down to the Lotus thick client -- with much more in-between.
Nonetheless, I think it's worthwhile debating the larger issue of the relative profile of the Lotus/Domino stack in one of its capacities -- as a broad collaboration platform -- which was Adriaan's original intent.
Among those enterprises that have made a major commitment to Domino and Lotus for collaboration and knowledge management applications, in my experience they fall into three broad categories:
1) Those actively enhancing existing implementations across the board.
2) Those supporting their existing implementations, but not advancing them much, and retiring applications as they no longer serve their original purpose (usually over the course of many years).
3) Those pro-actively replacing Lotus/Domino collaboration and KM applications with various alternatives (also a multi-year ambition).
Although it varies by country and with enterprise size, from what I can see, the 2nd group above is the largest, and 2) and 3) together appreciably outnumber the first group in size.
This is not a blanket indictment of IBM. It is simply a recognition of a collaboration platform that has suffered competitively in the marketplace, however much Big Blue has modernized it and continues to support an impressive partner channel. As Adriaan pointed out, Domino and the Lotus stack more broadly have some advantages over SharePoint for collaboration, but Lotus-Domino is simply not matching SharePoint's growth in this part of marketplace.
If there are lessons here, they are really for those new SharePoint customers with stars in their eyes. Turning over omnibus information management to a single vendor brings higher lock-in risks. Allowing custom teamspaces and collaborative apps to proliferate willy-nilly becomes unsupportable over time. Upgrades become increasingly fraught. Availability of experienced talent can become haphazard. Big-time platforms require long-term planning -- and suitable hedging.
ts ease-of-use and availability under an Open Source license. The page editing interface enables authors to lay out content exactly as it would appear to the website visitor. Under the hood, Magnolia contains best-of-breed Java technology based on open standards to allow for tailor-made solutions. Enterprise-grade support and services are available by the vendor and partners world-wide. 
