I’m defecting from SharePointistan

SharePointistan, a world coined by Nate Nash, is a place I believe where SharePoint is the end all be all of business solutions. It’s the sales and market hype world of “Yes It Can” solution spinning that professes that SharePoint can cure cancer and end world hunger.

Yet SharePoint still fails to solve business problems…

To be honest I was never a true citizen of SharePointistan, I have merely visited there on several engagements. As a professional developer I can say it’s a nice place to visit, but I wouldn’t want to live there.   Please read this as more of a plea to Microsoft to fix some of the usability and development challenges within the product. 

As consultants of the trade we get questions like these quite often: “what can we use SharePoint for”? “Can we use it for X” “Can you provide us a proof of concept”?

SharePoint is a content management system that, with each version is becoming increasingly extensible.  It is also extremely easy to use as a content management portal, and is designed to do most of the real work by putting administrative settings in the browser.   In a couple weeks you can get familiar with the tasks you’ll do most often as an administrator. That is, using or administering SharePoint is dead easy — it is designed for “non-programmers”.

The moment you try to create a true business application, or address specific business needs that fall outside of out-of-box functionality, SharePoint becomes unreasonably difficult.  Many things can be done via web parts and workflows, but the time required to create a truly useful, robust web part/workflow in a business context requires a level of effort that is not practical for most organizations, it’s more like the effort required to develop commercial components.   Once you embark on this extensibility, it quickly becomes clear that SharePoint was never intended to be a true application development platform, it is simply an extensible content management system.

Take a look around for InfoPath and what users are finding out about it in real-world scenarios.  It is one of those technologies that is misleading, because it’s so easy to get started with the out of the box, but when you start to modify things to work the way you really need them to work, the truth becomes clear.

Anyone that claims SharePoint to be a truly viable development platform is deluded or dishonest. I’m an advocate of SharePoint development, and in the right hands it can do some great things, but I’m honest enough to admit its (many) faults.

I know of several companies that have implemented or more appropriately “stood up” SharePoint only to have it languish on the corporate network infrastructure unused and unloved. In most cases SharePoint becomes nothing more than a glorified file share server. It’s a classic case of putting the cart before the horse. The customers go in with the promises and marketing hype only to find that six months down the road they are burdened with more administration, more effort for their users, and no real solution to their real business need. They were better off pre-SharePoint with a network file share and simply clicking File -> Save in their Office application.

We can do better! With the right processes, plans, and implementation many of these “dead” SharePoint sites could have been saved.

So what do SharePoint users really get? A development framework or platform to which they can quickly apply those business idea’s and collaboration? Many will claim that is exactly the case, that the company now has an platform and environment to build their solutions with; whatever those may be.

Unfortunately, like most technology, there is no silver bullet.

SharePoint isn’t something you can just plug in and it makes toast.

SharePoint is designed for a particular type of application (content management) and does that at an above average level with the right business processes in place. Without those processes, like most technology implemented over bad processes, it will fail to deliver. SharePoint is a nightmare for multi-environment (i.e. Dev, Test, Production) migration and custom development. Debugging in SharePoint is a hair pulling exercise. More on my Infopath Online Services adventures in another post.

Another question we often get asked by clients is along the lines of “Do I have to upgrade from Office [insert old version here] to use the latest version of SharePoint?”  SharePointistanians often mention the “Fair, Good, Better, Best” mantra when explaining the intricacy of integration with Office client tools and the Office Server (SharePoint). You can read it for yourself via the latest version of the white-paper can be found here.

To sum up:

• Fair = Crap
• Good = Unbearable
• Better = Barely Tolerable
• Best = Good

 For Reference that’s:

• Crap = Office 2000
• Unbearable = Office XP
• Barely Tolerable = Office 2003
• Good = Office 2007

Do yourself a favor. If your Office deployment (or a large part of it) currently falls into the “Crap” or “Unbearable” categories, STOP NOW! Don’t waste anymore time on feasibility studies, strategic/planning meetings, governance, etc. Just put together a business justification and upgrade to the latest Office. Failure to do this renders the vast majority of the SharePoint benefits null and void.

Once you “get” the fact that SharePoint provides a lock in for the Office tools for Microsoft you may see the light. If you aren’t keen on keeping Office around you may want to look at Joomla, an open source alternative content management system.

SharePoint is also designed as a collaboration tool for Web 2.0 (wikis, blogs, collaboration); which it does pretty poor job of compared to other tools on the market. Because of poor implementations, SharePoint can actually convince people that Web 2.0 initiatives are too hard to deliver on, or deliver too little value. What they might not realize is that it’s the fault of the system, not the idea.

While I’m defecting from SharePoint, this post shouldn’t be summarily construed as a “SharePoint is crap” post because it is a great product in it’s area if used in the way it was intended.  There are some really cool things you can do with SharePoint that indeed are faster than developing it on your own, which I hope to illustrate in future posts. 

There are also a number of things that Microsoft could do to improve the collaboration aspect and development usability of the product and I’ll also get to those in future posts.