These last few days I attended the SharePoint Connections conference in Amsterdam. Okay, it’s not Vegas, but is was cool anyway. Of course there was a lot of cloud, Offfice 365, app model and more of what we already learned from Vegas.
But one really big thing was a statement made by multiple speakers. SharePoint began as a product and slowly developed itself as a platform. Especially the 2007 and 2010 versions were seen as application platforms. We developers were creating things on top of and in between SharePoint bits and bytes. And although that didn’t (doesn’t, actually) always worked out too well, it was the way we rolled. That made the “SharePoint Developer” a breed of it’s own. You either loved it (like I do) or hated it (like a lot of .NET people do). That’s because of the learning curve, the workarounds you need to do, all the stuff that isn’t so transparant. On one hand that’s good, since it means SharePoint devs get a job real easily because of the enourmous demand. On the other hand that’s bad since there wasn’t that much interaction between SharePoint land and the rest of the world, at least not in Microsofts view.
Now with 2013, things will change. Because SharePoint isn’t seen as a platform any more. It’s an application again. An application with an extensive API, but still an application. And although that might not strike you as a big deal, it really is. I’ll try to explain why.
In the old model, developers were trying to get a lot of things into SharePoint. Solutions made use of SharePoint lists to share data, hooked into event handlers and did all kinds of funky stuff on the web where they were deployed. Sometimes good things, sometimes not so good things, but that’s not really the topic I want to discuss. The point is; the solutions really integrated with SharePoint and were built on top of it. Now with the new app-model, you’re going to create apps which are loosely coupled with SharePoint. You’re code won’t run inside of SharePoint any more. And allthough you still have the options to create lists and such; you’ll do so in the app web, not in the place where you’re app was deployed. I’m not saying you can’t do that; I’m saying the model tells you not to.
That means apps will become disconnected again, and developers and architects will have to rethink their way of working. Will I store data in a SharePoint list? Why would I? If my app is on Azure, why wouldn’t I just use a Windows Azure SQL database? Why bother with storing the data in an appweb where the user isn’t touching it anyway? Because let’s face it; storing data in a SharePoint list comes with it’s challenges too. Pretty valid questions if you ask me, and questions I don’t (yet) have an answer to.
In one of the sessions I attended, the speaker showed us how easy it was to link a web shop kind of app to SharePoint. That link consisted of the user automatically logging in with his Office 365 ID and the e-mail address box being prefilled, and an automatic post to the activity feed once an order was placed. Nice, but not that thrilling. It’s just a webshop, that’s not a real big deal these days.
My point is; apps are web applications again. And installing an app into SharePoint is basically nothing more than pointing a link to a URL and doing some nice OAuth stuff in the background. And the loose coupling means the app doesn’t depend on SharePoint, and neither does SharePoint depend on the app. I’m not saying I dislike the model or that I prefer the old way. I’m saying I have to redo my thinking when it comes to architecting SharePoint solutions. And what to do with old solutions? Yes, they will work in 2013 as well. For now. But if you want to migrate your WSP-style solution into an app, that’s going to take a lot of work depending on the size of your solution. If you don’t, you’ll end up with functionality being inside of SharePoint and apps being outside of SharePoint. How will your users react to that?
A lot of questions to be answered in the upcoming months. One thing is clear: things are going to change!