Wednesday, 27 June 2012

SharePoint: buy the platform, sell the app

In discussions with a few folk regarding SharePoint over the last couple of months I have come to the conclusion that most businesses (and Higher Education is no exception to this) purchase SharePoint on the promises of a slick, shiny demonstration to senior managers (probably at one of those Caribbean 'conferences' I'm always hearing so much about) and the annoying fact that you can, more or less, do anything with SharePoint.

For the salesperson, SharePoint must be a dream come true; you can effectively promise the world, charge the mega bucks for the easy bit (installation) and then put your fingers in your ears when it comes to thorny issues like governance, service delivery, training, expectation and change management and the real killer: app development.

This is possibly unfair on the salesperson (then again, maybe not!) and I'm sure their are some paragons out there who insist that businesses develop full governance and roll out strategies before they'll break the seal on any license key codes, but in the main, SharePoint arrives like this:

CEO: I just saw a SharePoint and I want one!
IT: er, ok, why? And, more importantly how? But also, why?
CEO: why isn't it on my desktop already!?!

Exaggeration abounds of course, but the principle is this: too often SharePoint is installed as a solution, rather than as a platform and too often this platform is installed with no clear sense (other than the standard 'intranet' and 'collaboration' side of things) of what SharePoint will deliver to the business. Of course it will do anything and everything (of course it can, SharePoint is a very, very good platform) but not without work and work here means application development and application development requires, ooh, I don't know, developers? (Maybe, it's perfectly possible your killer SharePoint app can live entirely in power user and middle tier code, but sometimes even those benefit from some applied development experience.)

The analogy here that best demonstrates this for me is when someone comes and demands you install the latest version of windows, because it's shiny (Windows 8 is very shiny btw, Tech Ed this year is all over it like a lothario, I am going to find it very difficult not to grab a new win8 tablet when they arrive on the scene.) Would that same someone then turn round the next week and demand to know why it didn't come with SAP built in? Or Diablo 3? Well, possibly, I guess it depends on the 'someone', but my point here is (I hope) obvious, an OS is a platform and, for me, SharePoint from the perspective of a business should be seen as a platform - that is something that will need development post-install to really get the most out of it.

Hence the tagline of this post: "buy the platform, sell the app". I firmly believe that the reason my institution has a successful SharePoint infrastructure lies with the development of apps in three critical business areas that immediately demonstrated real benefits from the start. They are high visibility (one of them, the dashboard environment, is extremely visible to senior management) and have driven real change alongside the delivery of genuine service improvements. Of course we use SharePoint for all of the standard collab and intranet side of things and there are users out there doing great things with SPD workflows and the like, but these things came second, not first, which meant that SharePoint was already established as a 'main player' from the outset, rather than having to go shoulder to shoulder with every other app out there.

That's what users really see, after all, apps, not platforms.

I was just lucky though, too often there is no thought beyond the "give me shiny now!" initial demand, I had the opportunity to recommend SharePoint as a platform that could deliver these apps and it's those apps that people really see, not SharePoint - which is the way it should be with all successfully deployed platforms, right?

- rob


  1. That's exactly the situation where I work. I was originally hired to develop and support web apps within our existing Java EE infrastructure, but now I am frantically trying to learn SharePoint. Our CIO suddenly wants to implement SharePoint workflows everywhere to replace paper based processes. As the resident web developer, I've been chosen to do the work. However, I have no experience in SharePoint since I spent most of my career as a Java EE web developer. SharePoint is quite different than Java EE, and unfortunately they can't afford to get me some training, so it's sink or swim for me. I've never been so frustrated as I try to learn how to build workflows with SharePoint Designer 2010, InfoPath and Visual Studio 2010.

    1. Ouch, I feel your pain, that's certainly not going to be an easy transition to make. The one piece of good news (!) is that you can do a lot in SP2010 with SharePoint Designer 2010, especially with forms and workflow design.

      My number one piece of advice would be to try and do all of your work in the SharePoint Designer 'tier' first, before going anywhere near Visual Studio. There are no performance advantages with the VS route and SP2010 gives you a lot more control when it comes to forms and workflows than SP2007 ever did.

      - rob