Two Types of SharePoint/MOSS Environments
March 28, 2008
Welcome to all the new readers. I guess getting Brilled is somewhat similar to getting Slashdotted, if the 5000% increase in traffic is any indication. Thanks, Ed. 
I’m mildly amused that when I start to border on ranting, the level of attention increases, but I won’t worry about that today. I have other things on my mind.
Now, 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.
March 29, 2008 at 8:52 am
I think what is going on with this, that that folks aren’t 100 % sure what the technology can do for them and end user training is key.
March 30, 2008 at 7:21 am
I used method 1. But I have baked-in some serious flaws related to information architecture, so now I’m going to go back to the drawing board and use method 2 to REBUILD everything.
My method 2 build, while annoying, will certainly be much better having already done my experiments with method 1. But nothing says you can’t do both from the start. Have two site collections: one uses loose permissions and ad-hoc architecture while the other remains closely guarded and rigid.
Companies just starting with MOSS should consider two projects running in tandem with different SLAs and requirements instead of trying to force all requirements into one site collection with the most aggressive SLAs.
March 31, 2008 at 11:22 pm
Notes apps started KISS with many companies in the old days. The demand grew and the number of notes DBs grew biting all of these companies years later – some of whom created such a mess that they happily threw Notes out, but of course, would never admit to screwing up, especially since it was over many budget cycles. This will happen to Sharepoint – but the wasteland will be larger and any attempt to fix (there will be a proliferation of 3rd party tools) will cost more in time and material. But that is another budget cycle … excellent business model for MS and partners – so stick with this mess – you are going to make a fortune from other peoples stupidity for a year or 2 of hair loss – a bargain, so milk it while it lasts.
April 1, 2008 at 5:08 am
Lesson learned.
Ensure your esteemed 3rd party has both the knowledge and experience to deliver the promised $zillion system “As Described”.
Take References, go and visit reference sites. Actually see it working and see how complex the final solutions are to deliver and maintain.
This is not just common to Microsoft software, just IMO “More Common”.
In the long run I doubt that you’ll be able to walk away from the decision and investment. However you won’t be able to walk away from Domino either any time soon …
Better start planning that sale now. The better planning you have the better it will sound when it has to be delivered….
April 3, 2008 at 10:23 am
I have been on several Notes to Sharepoint pojects as a consultant. None of them have been successfull for the client (yet) and none have brought any cost savings (unlikely to ever happen).
What everybody seems to underestimate is also the fundamental shift in network architectire that such a migration requires. If you are going from a distributed Domino model to a centralized Sharepoint model then massive Network upgrades can result from that (depending on company and infrastructure). These are usually costs that don’t get captured in the original project estimate.
Also, another reason why allot of these projects happen is that MS actually foots part of the bill; they know when to spend a buck to make 2 bucks back later …
May 2, 2008 at 3:44 pm
I’m curious as to the dimensions of your deployment. How many users ? How much infrastructure (think I saw 24 servers mentioned somewhere) ?
Can you provide more details on the architecture and, if possible, how that compares to your Notes/Domino environment ?
May 8, 2008 at 4:23 am
@6) 24 servers for SharePoint vs. 3 Servers for Domino. But it is also much more robust in terms of load balancing and full dev and test environments.