Header Image -

Monthly Archives

4 Articles

Two Types of SharePoint/MOSS Environments

by dave 0 Comments

 

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

 

——-

This is all based off circumstantial evidence, not hard research, but given that caveat…

There seem to be two different ways organizations are approaching SharePoint, and they are diametrically opposed to each other:

Method 1: Install a server, see what it can do, use it for small apps, and expand its function and the scope of the environment based on demand.

Method 2: Assume that demand will be huge, and engineer a large, complex architecture to support that assumed long-term demand. (We did this.)

While I appreciate the strategic foresight of method 2, and the desire to not be constantly re-working your infrastructure, I have yet to talk to someone who went that route that actually has been successful. Up and running, certainly, but successful? Seems rare. More often, the end users are happy with the platform, but there are internal teams like mine pulling their hair out. Or maybe that does qualify as success, if you have the right perspective.

In any case, folks going with Method 1 seem to be doing just fine. They are getting their feet wet with small stuff, learning the technology on the fly, as needed, and letting the growth of their environment march right alongside the growth of their skillset.

Mistakes are made under both methods, but a small mistake in a large, complex environment, especially if identified after the platform has experienced immense growth into your organizations production systems, can be a real nightmare to fix. I know we’re suffering the pain of mistakes made in the planning phases that didn’t show themselves until 6 months later. And of course, politically, it is unwise to say that the consultants for whom we paid a couple million dollars just plain screwed up. So I won’t say that.

And maybe I’m just looking at the greener grass on the other side of the fence. But seeing as our environment runs about 4 brochure-ware sites, front-ends a handful of custom .NET apps, and runs a few dozen each of lists, doc libraries, and discussions…
I’m just not seeing why we couldn’t have gone with method #1, saved millions of dollars, had a simpler infrastructure, taken less IT resources to support it all, and sure, maybe added a 2nd server if needed.

So as a message to anyone else out there, when planning a new SharePoint deployment, KISS.

Results

by dave 0 Comments

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

——-

After all of my inquiries and research into real measurable data comparing SharePoint Dev and Maint costs…. there is no data.

Everyone I talked to is in the same boat we are – just getting going, spending more money on SharePoint at the moment, but with no real idea of what it will cost long-term. It is all guesswork.

I’ve seen no evidence that anyone really is having a successful migration that saves them money. If anyone does have evidence, feel free to share it.

But as I look hard at the two technologies, I see a few things… and this may show my bias, but it is what I see:

  1. SharePoint ties everyone to MS Office. Why? Most other web technologies are working to eliminate desktop products, not push your web site down into your desktop. SharePoint does not take your enterprise to the web, it marries you to Microsoft Products at a very deep level.
  2. There is no SharePoint expertise internal to the corporate world. Consultants and business partners have the majority of skills, and very few major projects are done without shelling out money to them.
  3. Microsoft does not yet have their training together. The only available training that I have found is through their business partners. I went to that training. I found it very basic.

In general, SharePoint feels like a big old marketing scam to me. It doesn’t do as much out of the box as Microsoft would have you believe, but it does give Microsoft and their partners a good chunk of money. A decision to go with SharePoint is a decision to tie yourself into their full product line.

Now, does that mean it is the wrong decision? Not necessarily. I don’t know. It depends on your requirements, I suppose. It certainly makes me nervous, though. Why shake up the status quo for a new technology that nobody is skilled in, that costs more money to deploy, that is guesswork for long-term costs, and that ties you to a specific vendor? Even if it did perform as advertised, I just don’t see justifiable answers to that question.

Soliciting Feedback

by dave 0 Comments

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

——-

I’m looking for some answers from the community…

As I mentioned previously, the status of Lotus Notes/Domino is again under discussion. To make an educated, unbiased business decision, we are looking for data on the following questions:

1) Development Effort – In General, how does development time in SharePoint compare to development time in Domino. Assuming skilled talent in both technologies, and non-trivial apps…  does anyone have any real numbers and data comparing the level of effort to write applications on both platforms? Or even any anecdotal data?

2) Maintenance Effort – How does the level of effort compare to maintain SharePoint Applications vs. Notes Applications. (Again, in general). I’m not talking about the infrastructural support for the platform – just the application support. How many developers does it take to support a 500-app Notes platform vs. a 500-app SharePoint platform?

If anyone has any real world experience, and in particular measurable data dressing these issues, please either comment here or contact me directly at migratenotes@gmail.com.

Updated Strategy

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 few months of working with both Notes & SharePoint, I have updated my strategy to the following:

Don’t try to get rid of Domino – just get rid of the Notes Client.

My proposal to do this is actually fairly simple:

  1. Web-enable all Notes Apps.
  2. Put them into iframe web parts in your SharePoint environment
  3. Share CSS on both platforms
  4. Use IIS as the HTTP stack on Domino, and AD as your authentication.

Do those things, and the end users won’t know or care what technology is driving any given app. IT still gets a cost benefit from not having to support the client, and management gets their wishes because “Everything is in SharePoint.”