Header Image -

Notes vs. SharePoint Analogy

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

After a couple days of fighting SharePoint, and spending hours getting small details into just the right place, an image came into my mind.

Imagine Notes/Domino as a trainyard – while it has a lot of power, and definitely needs some technical knowledge, once you are set up properly, you just need to know which switches to throw to get the results you want. Your ‘train’ smoothly goes in the direction you desire.

Sharepoint is quite similar. Except that instead of a trainyard, your train is sitting in a big open parking lot, and you have lots of monkeys throwing crowbars under its wheels, and you need to see what happens and keep giving the monkeys new directions until you get the result you want.

SharePoint is fun. Really.

Migration Status

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

I have not been posting very often in the past few weeks…. mostly because I’ve been swamped with working solely within SharePoint, learning some more of its details, and how it was configured in our environment. But I’ve been working 100% within the browser-based areas of SharePoint, so I haven’t written any code to share or devised anything profound.

I do have a stronger sense of how to “think SharePoint”. If you recall, a while back I wrote out a list of analogous Notes and SharePoint components to help me wrap my head around SharePoint, but I’m now getting past that. I’m beginning to think of SharePoint as if it were Legos. No single feature within sharePoint is very complex. You need to build them on top of each other to reach your goals. You have some moving parts that you use to connect your pieces and make them move in some limited ways. The more creative you are, the more you can make it do. To work with the out-of-the-box features, you almost have to stop thinking like a coder — it isn’t code.

Its security is also more open-ended. While Notes/Domino has many layers of security, they all come down to the same IDs and groups. Not so in SharePoint. While you do often use your Windows Login as your primary identification and authentication, it gets blurry after that. You can use SharePoint groups, you can use AD Groups, you can use LDAP queries, you can write your own membership provider. In some places, you can mix and match, while in others you cannot.

I’ve always maintained that a Notes/Domino system is exactly as good as the people who design it. There are world-class systems out there and there are catastrophes. I think SharePoint is going to exaggerate this trend even more. You will find elegant, wonderful implementations, and you will find utter disasters, and the key will be the people behind it.

The problem is the level of expertise in the industry – Domino has been around a long time, each new version compatible with its predecessor. This has built a core group of developers who have well over a decade (or two) of experience, and can really put together a nice architecture. SharePoint 2007 is brand new. There is no expert with 10 years experience. The most senior folks out there are still working out the kinks of the latest version. And as each new version is its own beast, and not built upon the previous version, I fear that this will always be the case.

Traversing a SP hierarchy in C#

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

At the risk of being mocked for my lacking C# skillz, I thought I’d post another code snippet.
(And at the risk of losing traffic, because it seems that whenever I post code, Google stops sending me traffic for a couple days.)

One thing we have encountered as part of our migration is the need to make a change to an entire environment. (Modifying ACLs, etc.) In Notes, AdminP can do some of this for you, but when the change needs some calculated logic, you need to script it. Notes has the NotesDbDirectory object which handles this nicely for you.

But it got me thinking – what if you wanted to traverse your entire SharePoint environment? What would that code look like? So I sat down this morning, and spit out the code below.
It is just a recursive call to each site’s subsites, which gives you an opportunity to do something at each site.

static void Main(string[] args)

{

SPSite rootSite = new SPSite(”http://yourserver”);

SPWeb site;

SPWebCollection children; site = rootSite.OpenWeb();

DoYourStuff(site);

//Traverse SP hierarchy

children = site.GetSubwebsForCurrentUser();

if (children.Count > 0)

{

ProcessChildren(children);

}

}

static void ProcessChildren(SPWebCollection sites)

{

foreach (SPWeb site in sites)

{

DoYourStuff(site);

SPWebCollection children;

children = site.GetSubwebsForCurrentUser();

if (children.Count > 0)

{

ProcessChildren(children);

}

}

}

Why Notes shops don’t match up to Microsoft’s recommendations

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

Once again, comments and emails have given me some insight into questions and false assumptions that some Notes people may have.

Namely, they assume that the recommendations given by Microsoft partners will apply to a Notes migration. And while certainly much of their technical advice is valid, the underlying viewpoint of a Microsoft partner is going to miss an extremely important piece of information about a Notes shop:

The current collaboration in a Notes shop is NOT based around Microsoft Office. Notes people do not email spreadsheets back and forth. They do not use Access databases, or share documents via email. They already have a collaboration infrastructure in place, and are not starting from scratch.

Sharepoint was designed to give organizations their first stab at collaboration. Its primary strength is to take Office documents, and share them on the web. While I am sure this is a great help to many organizations, as a Notes professional, it just doesn’t impress me that much.. SharePoint is an immature product. It has flaws and weaknesses, and we have already addressed some of them on this blog.

But those weaknesses get exaggerated when we go out deliberately looking for flaws, and this type of exaggeration is exactly what I want to avoid here. Let’s call out the weaknesses, but lets not spin SharePoint’s faults into something worse than it really is.

With that in mind, lets talk about MOSS. MOSS is the “Microsoft Office SharePoint Server.” It adds functionality to SharePoint. But not as much as people think. the plain old freebie SharePoint install is what gives you most of the programmability of SharePoint. And because a Notes shop is already used to doing a certain level of development for their apps, that is the level of complexity that most Notes shops really need.

So when you see lists of the technologies from Microsoft that you must install and learn to run a SharePoint environment, take them with a grain of salt. Maybe in the future, your organization will reach that level of complexity. But to start a migration, you really just need a few things, most of which you probably already have:

  • Web Server (IIS/ASP.NET, with SharePoint services installed)
  • SQL Server  (technically optional, but realistically you need it to have any scalability.)
  • Exchange Server (and even this is optional)
  • Backups for the above.

What I am finding is that because SharePoint has limitations and weakness on its programmability, most Notes professionals do not accept its built-in functionality. So they step down into C#, and write custom .NET code. And while people will tell you that this is much harder than using the rest of the Microsoft platform, it greatly simplifies your infrastructure needs. (Not to mention costs.)

Again – as your Microsoft platform grows, you probably will add on more tools and end up with a more complex infrastructure. But the assumption  that it takes a  ton of effort to get going on SharePoint just isn’t correct.

What should not migrate?

by dave 0 Comments

Standard disclaimer – the ‘migratenotes’ posts come from a Notes Migration blog that I wrote from 2007-2010.  More Info

——-

A question has indirectly risen, both in online and offline conversations, of how we would define which applications should NOT be migrated to a new platform. Assuming that a small subset of Notes functionality will remain in the organization, what features or functions would lead you to  not even attempt a migration?

My answer would be the following:

1) Any application that truly needs offline access, and therefore replication. In my particular organization, surprisingly, nothing fits this category.
2) Any app that requires field-level encryption. The other granular levels of Notes security can be emulated with some skilled development efforts, although I acknowledge they are more difficult in Microsoft technologies. But I know of no way to set encryption on individual fields other than through the use of the Notes  client.
3) Any app that is business critical, directly generates the revenue for the company, and also well-loved by the business users. An app that works, that makes the money, and that isn’t a source of pain for people…. it should just be left alone to do its job.