SharePoint FUD... Spreading Far, Wide and Fast

The last month or so I've been a casual observer to a bit of a train wreck. It's the train wreck that we collectively know as the SharePoint bashing exercise. I'll admit fully and upfront. I'm a SharePoint MVP and there are times SharePoint (at a micro level) frustrates me enough to go postal on my co-workers. However from a macro level and as a corporate tool, it's a pretty darn good piece of software.

For the past month I've been watching people on Twitter endlessly blather on about how bad SharePoint is and how great <insert cool tool of the day> is so much better. The latest of the "SharePoint Killers" is Google Sites. I look at all of these complaints and competitors and scratch my head. What is all the bruhaha about? If you look at things seriously, you're comparing apples to gasoline and never the twain shall meet. The latest moronic dribble is from Computer World UK where they call SharePoint a "Fortress" and elude to Google Sites being able to get your "locked content" away from the prying arms of SharePoint. I have no idea what Glyn Moody is talking about. If I put my data/documents/etc. in Google or Drupal or some other more "free" system, how is it not locked away there? If by locking away your data in SharePoint you've made a decision to use SharePoint then sure, call it that. However it's no different than choosing any technology and storage platforrm. SharePoint doesn't nothing to trap or lock your data up anymore than any other system out there. But yes, SharePoint is a fortress which eats your data, pollutes the environment, and kicks puppy dogs.

I started to go down this path with an adventure looking at various SharePoint-like alternatatives and I have a 10-page draft post comparing SharePoint to WordPress (which I think is a kick-ass blogging platform) along with ideas and notes for Drupal, Box.net and other comparisons. Maybe someday I'll publish them but I'm not seeing a value in doing that right now. However I wanted to take this opportunity to sit down, filter through the FUD that is spreading, and give my take on things.

SharePoint sucks for content managment

Suckage is always a relative term. What CM do you have today? Drupal? WordPress? Joomla? CMS? MOSS 2007 folded the old CMS capabilities into it so now users create "Pages" that can go through workflow, multiple edits, etc. all to be published at some point. I've setup many intranets that were primarily focused on just creating content and they've all been pretty successful. Where's the suckage here? Is it fabulous at copy 'n' paste from say Word or a web page? No, but then neither are those other products. There are some supplemental tools available to help this (Telerik has a nice RAD editor that plops into SharePoint with minimal effort as a replacement). Pages can be moved around at will (without breaking links) and assets can be centralized for everyone to use. SharePoint 2010 enhances this even more as we'll see in a few weeks. Perhaps SharePoint sucks compared to something but I'd like someone to come forward with some real world issues they're having. Perhaps SharePoint does have problems with specific issues, but overall MOSS is pretty good for content management.

InfoPath Forms is Hell

Again I'm waiting for someone to come forward here. We've built many forms all working well and were easy to build and deploy. Yes, if you get into complex forms with lookups into backend systems and complex decision tree logic it starts to get ugly. However why are you building something like this in InfoPath then? One of the main failures I see in SharePoint is misuse of technology. "Oh we have a forms engine with InfoPath so let's build all our business logic in forms". Uhh, no. No developer with half a brain would do that. Would you code SQL statements and database connections in the code-behind page of an ASP.NET form? Then why are you trying to do the same in InfoPath. Stop blaming tools for your own idiocy. I've used so called "form engines" from all kinds of products and short of building forms in ASP.NET and Visual Studio, InfoPath is pretty slick and simple. However it's a developers tool not something you hand over to a business user to create an IT mess out of.

SharePoint is idiot easy to install without any planning

Yes, yes it is. And leaving for the moon without a plan will probably get you killed on takeoff. Any fool that follow SharePoint for dummies to setup an intranet without any planning is exactly that. A fool. And a fool and his money are soon parted (along with your sanity and any sense of credibility you might have at your job). Even in Agile projects you plan. SharePoint installations are pretty simple when it comes down to it, but you still need to sit back and talk about what you're about to do. Are you over-architecting your solution (i.e. building a medium farm for 100 users) or are you under-architecting it so it doesn't scale (installing Basic mode on a stand-alone server for 10,000 users). It takes some expertise and understanding of a whole ream of technologies to pull off a good sized SharePoint deployment but as long as you don't jump in head-first without any idea of what you're doing, you'll probably do fine. Its when people think running setup.exe, sending out an email to everyone saying "Go use SharePoint", then wondering why they have storage/capacity/performance issues after the fact.

SharePoint is big and expensive

I hear this all the time and yes, it *can* be bloody expensive. In fact I was looking at external MOSS sites and the price tag was in the 10s of thousands of dollars. Compare that to the price of some open source software where you're basically paying for hosting or a machine sitting in the DMZ and you'll scratch your head. However a few things here. Comparing the price of WordPress ($0) to SharePoint is nonsense. It's the apples and gasoline issue. They are not the same product and thus you can't put them on a level playing field.

I think this is one of the biggest issues with the whole compare and contrast argument with SharePoint. SharePoint does have wikis and blogs and content management and document repositories and all that jazz. However it has a whole bunch more. Need your OOTB SharePoint to have one little extra menu to direct users to a FAQ? That's a small bit of JavaScript or a feature deployed. Need it to consume web services and format the output, again something that can be built as a feature and deployed. The point is SharePoint is a platform, one that which Microsoft has come up with some basic templates to get you started but people haven't grasped the bull by the horn and gone nuts like they have with other platforms. It's true that building themes is for the birds in SharePoint and not as flexible as templates in say Joomla, but again themes and skins are not the same. In SharePoint themes, you don't have control over layout. With master pages you do but only for the overall site. Application pages provide additional layouts. One has to understand how these three come together to provide that user interface and experience and realize it's not just a simple text file like a DotNetNuke skin.

The other major issue is integration. Sure MediaWiki is far superior to SharePoint when it comes to wikis but ask MW to handle versioning of Office Documents and exposing metadata (then searching on that metadata) and it falls flat. Alfresco for document storage? Sure, but then what about creating a custom list with business related fields, grouping that information, then creating views to display say sales from a division over a period of time. That's the thing about SharePoint. It does *all* of that, plus more. Does it do all of that exceptionally well? No. It does a lot of things pretty good, some things very well, others really crappy but that's like life. Nothing is the be-all tool for everything and you make compromises to get the best of most worlds. Trying to cobble together the best-of-the-best tools for content management, wikis, blogs, unstructured and structured data, document management and a wealth of other things is just going to create a big ball of mess.

It's Highly Complex to Install

So is installing (almost) any Enterprise tool. But let's take a step back here. What's so hard about a) download wss.exe b) run msi c) run config wizard and answer a few questions [e.g. where is your db server, account names, etc.] d) start central admin and create web app and site collection. Okay, that's 4 steps but in reality to setup SharePoint for a brand new environment (assuming WSS) you need about an hour (that's soup to nuts install). MOSS is a couple of hours depending on how your architecture is setup (i.e. multiple front-ends). Highly complex? You're not installing a desktop app where you run the setup program and click a few buttons. Grant you, I think *nothing* beats WordPress and it's 5 minute install (which actually takes about 30 seconds) but again, WordPress isn't SharePoint. I really wish SharePoint would install like this, but something people forget is that while it takes a few minutes to install WordPress you're still spending hours configuring your site/blog, installing plug-ins, downloading and trying out themes. The base install of WordPress isn't much different than SharePoint. It's the devil in the details afterwards that will suck your time. Highly Complex is realative. If you're building a 10,000 user system with 5 or 6 servers sure there are a lot of moving parts. If you're installing WSS for a small company to do collaboration it's a breeze.

So what makes SharePoint successful?

I don't know. Your modern ways frighten and confuse me. However what I do know based on experience is two things. If you're a Microsoft shop and use Office and there's a need for some form of departmental or corporate collaboration, SharePoint is probably your best bet. If this is true, install it. Sit down, plan out a way to use it (maybe starting small only with sharing documents). Then set it up. Do not release it to the world or get people on board that have no idea what to do with it. Get some people that are passionate about sharing and have an IQ higher than the temperature of the room you're sitting in right now. Try things out, see what works and what doesn't and get some champions behind it.

SharePoint success is not about ripping it apart to see what makes it tick then reassembling it (because like that old map in your glove compartment, you'll never fold it up the same). If your first instinct is to crack open Visual Studio then you're probably not thinking in the SharePoint space. VS is an option as you can't do everything in the browser or SharePoint designer, but it's not the only option. There are people that will tell you that to make SharePoint useful you *have* to extend it with features your developers build (or you can get from CodePlex or other places like that). These are the same people that will probably want to sell you hundreds of hours of high priced consulting time and might even give you some magic beans for your troubles. OOTB SharePoint *is* powerful and quite business-enabling. You just have to think about the problem space a little differently and in some cases adjust the practice. If that's not going to happen then maybe creating custom Workflows or Web Parts is the answer, but ask yourself if you're solving the right problem first before you starting writing using(new SPSite()) statements.

Once you do start using it the most successful factor to help you along is to empower your users. Don't lean on the IT department (whether it's 1000 experts or 2 guys and a small dog) for every little thing (like setting up permissions for users). During your eval, try things out and work out a governance plan for how users are going to access things, how you'll manage security, and how site creation and structure will work. Microsoft has hosted scenarios so you don't have to invest in infrastructure and there are virtual labs where you can spin up a SharePoint instance to give it a whirl. Don't unleash the beast unless you know what's behind the smoke and mirrors. And be careful what you ask for. Passionate users that think SharePoint is da bomb might actually turn your little collaboration experiement into a success.

Again, caveat lector as I'm a SharePoint MVP so you can take my word in whatever way you want. I may be one that screams and yells at the SharePoint machine on a daily basis, but I'm not lining up with pitchforks and burning torches like some people have been.

11 Comments

  • While I don't necessarily agree or disagree with your various points, I don't think that the way you expressed yourself is going to change many people's minds.

    "Don't unleash the beast unless you know what's behind the smoke and mirrors"

    In my limited experience with SharePoint projects, "Passionate users that think SharePoint is da bomb" are not the people who get their hands dirty.


  • You're so right!

    No other server product at Microsoft is so useful out-of-the-box, and at the same time, so modular and extensible. And as the platform matures we will see even better extensions on top of the free WSS core platform: MOSS, Project Server, Commerce Server, ...

  • Bill,

    How you ever could combine .Net ALT (reverse;) and SharePoint is a mystery for me. SharePoint is a really great platform built on a patch work that you abandoned several years ago ;)

  • @Anon: Whatever I wrote isn't here for people to change their minds about something. If someone has it in their head that SharePoint sucks and they have valid reasons for it, all the power to them. I'm just pointing out some misinterpretations of the tool and it's capabilities and what it should be used for.

  • @Peter: Interesting points and I agree with some of them. However I don't see any alternatives (other than RYO forms with ASP.NET/PHP/JSP/etc.). Is that really better than InfoPath? Not sure but I certainly wouldn't leap to those solutions because something apparently seems inadequate. Everything has it's flaws and you choose your battles. While you state InfoPath is "terrible" I don't see from your points how bad it is compared to alternatives.

  • I will say that InfoPath breaks the Pareto principle--instead of the 80/20 rule it's more like 8/2 rule: 8% of what you want for 2% of the effort.

    * Business users who try to solve their actual, real-world problems with InfoPath forms + OOB features fail, about half the time, due to limitations with InfoPath's non-code capabilities. There's supposed to be a sweet spot where business users create their own InfoPath forms and throw in a touch of workflow, and it does everything they need...this sweet spot is smaller than everyone seems to think. I've seen it over and over and over, where the business user assumes InfoPath can be used to do X, spends the first day or week making the form, then X weeks trying to mangle InfoPath to do what they want, without code. Or, at the beginning, they ask "can InfoPath do X?" and inevitably, it can't. Lack of real field-level security is a huge limitation, for example.

    With my own ears I've heard the phrase "we told her to [solve the problem] with InfoPath because she doesn't know how to code." The implication is that InfoPath allows you to solve complex problems, without the need to code--apparently this is a common belief.

    * Forms Services is even more restrictive, and assuming you stay away from code, is almost no better than creating and using a custom list. And I don't say this to be mean, I say this because there isn't much differentiation between browser-based forms and custom lists.

    * Getting to the code: true InfoPath developers (i.e., those not afraid to code) could have better success with ASP.NET and something like SubSonic or Dynamic Data or ActiveRecord or whatever. To be fair, I think people have a lot of success here, especially once they've mastered the craft of InfoPath development, but I think anyone able to choose should just master web development instead.

    Anyway, have an excellent day everybody :)

  • Nicely done, so nice to hear someone defending SharePoint for a change. Thanks.

  • Infopath is flat out a terrible product. I have worked on a large and complex solution using infopath web forms and its limitations and flaws make it unusable. Yes you can use it for simple scenarios but what happens when you need to add features later on? Start from scratch again? Try and do something simple like restrict how many characters a user can enter in a multi line text box client side. Try and make your form multi-lingual. The problem is you have no control over the html which gets spat out so doing simple javascripting is a challenge.

    The problem with Infopath is that Microsoft is still hung up on smart clients and selling office licenses. Infopath should be purely a web technology so it can drop restriction of having to make forms work both as a web form and a rich client form.

  • You can't make SharePoint repeatable, reusable and deployable without developers in SharePoint unless you have hundreds of cheap labour to do things repeatedly in SharePoint Designer.

  • great post - I know barely anything about Sharepoint although I do have a vague interest in it for helping "something" at our company when I have time to investigate it. It was an interesting article and I like the style that you write with - it flows nicely

  • hey i will look into .NET again (i.e. programming it) because of sharepoint server. I do java apps on linux right now, but have a c++ background (win32 mfc/qt). the capability to extend such an important app as sharepoint is a reason I would use such a proprietary toolchain. At some time you have to make a decision there is always some kind of lock-in. It seems to be usable and really valuable from a customer perspective and extensible from a develeoper perspective. I would like to see another product that offers similar capabilities.Sharepoint server will be everywhere in a few years, because real life people want it..

Comments have been disabled for this content.