Measure Twice, Cut Once – Even With SharePoint

2 minute read

I exchanged a bunch of emails last week with someone named Chris who had found my blog and was just starting out with WSS.  His goal was to do a proof of concept of sorts, based on some work he had read about which was done by Provoke (a Microsoft Gold Certified partner based in New Zealand).  It’s well summarized in the article over at the Microsoft SharePoint Team Blog entitled How We Did It – Tag Driven Information Architecture using MOSS 2007 for the New Zealand Ministry of Transport.  Chris wanted to use this proof of concept to justify the expense of SharePoint (MOSS) for his company.  (Microsoft take note: another hot lead, Denver area.)

Chris is clearly very smart and an accomplished .NET developer.  And there’s the rub.  As a developer, the first thing it seemed he wanted to do was write code.  Since it was just a set of emails, I’m not fully clued in on what the process was to get to the point where they were, of course.  And, in no way am I picking on Chris – he knows what he is doing.  But the exchange reminded me that my view on using Sharepoint as a platform for the enterprise is more of a measure twice, cut once one.  By this I mean several things:

  • The big picture is more important than the smaller technical details.  A great high-level architecture and plan will beat a smaller coding win in the long run.  Be sure you understand how you want to use the SharePoint platform in a holistic way before you get too caught up in the details of the implementation.  (As a developer, I sometimes have to remind myself of this, too!)
  • In many cases, you just don’t need to write managed code to meet your requirements.  As anyone who follows this blog knows, I’m a big fan of what I call the "Middle Tier", by which I mean developing with SharePoint Designer.  Packaged managed code gives you portability and deployment capabilities that are critical for some situations, but don’t discount the middle tier for fast prototype development and real solutions.
  • Look at the inherent capabilities of SharePoint thoroughly before you decide to go beyond them.  I always say that SharePoint gives you 80% of everything it offers, but it’s the important 80%.  Don’t just decide that you have to suck it up and live with what’s there, but realize that what *is* there can take you very far.  Often that whiz-bang approach you think will be the right answer up front won’t be what you end up wanting in the long run.  Think about doing your first phase implementation using more of the out of the box capabilities, and then continually reassess.  This is not a technology where you should ever be done – it’s an evolutionary process.

For those of you in Massachusetts, Happy Patriot’s Day!


Have a thought or opinion?