Why SharePoint Scares Me

This post was originally published on the Idealware Blog in July of 2009.

For the past four years or so, at two different organizations, I’ve been evaluating Microsoft’s Sharepoint 2007 as a Portal/Intranet/Business Process Management solution.  It’s a hard thing to ignore, for numerous reasons:

• It’s an instant, interactive content, document and data management interface out of the box, with strong interactive capabilities and hooks to integrate other databases. If you get the way it uses lists and views to organize and display data, it can be a very powerful tool for managing and collaborating on all sorts of content.  As I said a year or two ago in an article on document management systems, it has virtually all of the functionality that the expensive, commercial products do, and they aren’t full-fledged portals and Intranet sites as well.
• Sharepoint 2007 (aka MOSS) is not free, but I can pick it up via Techsoup for a song.
• It integrates with Microsoft Exchange and Office, to some extent, as well as my Windows Directory, so, as I oversee a Windows network, it fits into it without having to fuss with tricky LDAP and SMTP integrations.
• All pretty compelling, and I’m not alone — from the nonprofit CIO and IT Director lists I’m on, I see that lots of other mid to large-sized organizations are either considering Sharepoint, or already well-ensconced.

So, why does Sharepoint scare me?

• What it does out of the box, it does reasonably well.  Not a great or intuitive UI, but it’s pretty powerful. However, advanced programming and integration with legacy systems can get really complicated very fast.  It is not a well-designed database, and integration is based on SOAP, not the far less complicated REST standard, meaning that having someone with a strong Microsoft and XML programming skill set on board is a pre-requisite for doing anything serious with it.
• MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app.  As with a lot of immature Microsoft products, they seem to have been more motivated by marketing a powerful app than they were in making it actually functional.  Sharepoint 2013 or 2016 will likely be a good product, kind of like Exchange 2007 or SQL Server 2003, but Sharepoint 2007 makes a lot of promises that it doesn’t really keep.
• Sharepoint’s primary structure is a collection of “sites”, each with it’s own URL, home page, and extensions. Without careful planning, Sharepoint can easily become a junkyard, with function-specific sites littered all over the map.  A number of bloggers are pushing a “Sharepoint invites Silos“ meme these days.  I stop short of blaming Sharepoint – it does what you plan for.  But if you don’t plan, or you don’t have the buy-in, attention and time commitment of key staff both in and out of IT, then silos are the easiest things for Sharepoint to do.
• The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption. I don’t want to take my org’s critical work product and put it in a box that could easily break.
• Licensing for use outside of my organization is complicated and expensive. MOSS access requires two or three separate licenses for each user – a Windows Server licence; a Sharepoint License, and, if you’re using the advanced Sharepoint features, an additional license for that functionality.  So, if I want to set up a site for our Board, or extend access to key partners or clients, It’s going to cost for each one.  There’s an option to buy an unlimited access license, but, the last time I looked, this was prohibitively expensive even at charity pricing.
• Compared to most Open Source portals, Sharepoint’s hardware and bandwidth requirements are significantly high. Standard advice is that you will need additional, expensive bandwidth optimizing software in order to make it bearable on a WAN. For good performance on a modest installation, you’ll need at least two powerful servers, one for SQL Server and one for Sharepoint; for larger installations, a server farm.

I can’t help but contrast this with the far more manageable and affordable alternatives, even if those alternatives aren’t the kitchen sink that Sharepoint is.  Going with a non-Microsoft portal, I might lose all of that out of the box integration with my MS network, but I would jettison the complexity, demanding resources, and potential for confusion and site sprawl.  I’m not saying that any portal/intranet/knowledge management system can succeed without cross-departmental planning, but I am saying that the risk of a project being ignored — particularly if the financial investment was modest, and Sharepoint’s not cheap, even if the software can be — is easier to deal with than a project being fractured but critical.

If my goal is to promote collaboration and integrated work in my organization, using technology that transcends and discourages silos, I’m much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to match Sharepoint’s smorgasbord of functionality, but are much less complicated and expensive to deploy.

After four years of agonizing on this, here’s my conclusion: When the product matures, if I have organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a budget for consulting, Sharepoint will be a great way to go. Under the conditions that I have today — some organizational buy-in; modest budget for servers and no budget for consulting; a decent network, but other priorities for the bandwidth, such as VOIP and video — I’d be much better served with the alternatives.