These last few years I made it a habit to visit TCFKASPC: The Conference Formerly Known As SharePoint Connections. This year it was relabeled Unity Connect after the IT Unity initiative founded by Dan Holme and others. I think two days of conference is a good way of submerging yourself into the latest and greatest, catching up with the stuff you normally might not have the time for. This year, the line-up was as good as it gets with SharePoint and Office365 superstars like Jeremy Thake, Andrew Connell, Mickael Svenson, Scot Hillier, Mathias Einig and many more.
A personal problem I always have after visiting these kinds of conferences is that I’m usually left with more questions than answers. Most of the sessions I visit are pretty technical and teach you how to do certain stuff. The majority of sessions I visited this year incorporated techniques like Angular JS, Breeze JS and other client side goodness. These sessions were obviously targeting the developer portion of the crowd, enlightening us about how we should develop customized solutions running on the SharePoint platform. Or actually… maybe not running on the SharePoint platform any more.
A blog post (part 2) by the already mentioned Andrew Connell threw up some dust a while back, stating that devs should be using SharePoint as a Service, not as a platform. If you haven’t read the post yet, I advise you to do so. Although you might agree or disagree to this, it makes you wonder where this all is going, right?
Is SharePoint development dead?
It’s no secret that the traditional model (WSP’s) won’t get any love from Redmond. Cloud is the future (for now) and most of the web already relies heavily on client-side technology so why shouldn’t SharePoint do the same? In this sense, the add-in model makes perfect sense and provides us with the flexibility we need so we can still do development on SharePoint. But there’s always that point in your process where you need to decide whether SharePoint is the right platform to build your custom solutions on.
That’s exactly what I got out of Unity Connect this year, some more input to form my thoughts on SharePoint Development and it’s future. And the only conclusion I have right now is: it’s a dead end. Sorry to all of you (myself included) who have spent years learning on how to deal with WSP’s, content types and everything else. I now truly believe that being a highly wanted SharePoint developer (yes, the market still wants YOU!) doesn’t have a future in it’s current form. As long as we keep provisioning lists and stuff to SharePoint, there’s still a need for folks who understand how to do that in the correct way. But as applications gradually move further away from the platform, it makes more and more sense to go back to using customized databases for that kind of stuff. There will still be some room left for people who know about how to provision things in SharePoint, but it won’t be the hype thing it was ‘back in the days’.
So with Andrews blog in mind, the answer to “is SharePoint the right platform to build my solution on” will more often be “NO”. Sure, you might leverage SharePoint’s API’s for the goodies they bring, but in a lot of cases it probably makes more sense to build a web application which you surface in SharePoint via an add-in of some sort. The added benefit is that you can now also surface that application in other Office tools (Word, Excel, Outlook) via the add-in model as well. And you can build a mobile application, universal Windows application, etc., ensuring that your end-users have the integration they need depending on where they are and what they do.
The pain of migration
Make no mistake about it: this will hurt organizations. Depending on how “all-in” your org went on SharePoint, it can hurt a lot. I know a few organizations who have built custom solutions in SharePoint on massive scale. They will probably move to SharePoint 2016 on-prem avoiding the cloud and maybe an on-prem version after that. But eventually, time will catch up forcing them to move on to a different model. But let’s be honest, this happens regardless of the platform you pick, it’s the pace technology moves at and organizations should always be prepared for that. The times where you built an application that would last 10 – 20 years? Those are gone. Next to continuous deployment, organizations should start planning for continuous application upgrades too. Not only for the platforms, but for their own solutions as well.
Is SharePoint obsolete then?
You might be tempted to say; so let’s quit doing SharePoint and go all-in with web applications. Bad idea. I think there is no “all-in” when it comes to technologies, no matter what suppliers are trying to convince your of. SharePoint is still a pretty sweet product and it’s getting more love from Microsoft these days than it has received these past 2 years. NextGen portals are coming and I’m convinced we’ll see some new announcements soon. Let’s not forget it is still a kickass platform for collaboration, search, business process automation (workflow), business intelligence and lot’s of other workloads. But it’s maybe not per se the platform you should build your entire ecosystem on, rather have it be part of that ecosystem and leverage the parts you need to be productive.
The “portal” part of SharePoint portal server is still there, even getting new love from the NextGen portals. From that perspective you could call SharePoint your cloud-based desktop. It’s the place where you can find your work and (with help of add-ins) your tools as well. It can be the place where it all comes together, without making it the foundation for everything.
What will I be doing in 5 years?
It’s always good to plan your future or at least think about it. I am at peace with the thought that I’ll probably won’t be a SharePoint guy any more in 5 years time. At the moment, I find everything going on in Azure very interesting. I’ve bought 2 Raspberry Pi 2’s to get myself introduced into the world of IoT. I’m keeping a close eye on the add-ins being created for Office (365). I think my future work will revolve around making sure organizations are as productive as possible. It’s not solely about automation anymore, it’s about making sure the automation is helping the users be more productive, something that was often overlooked in the past. And organizations who do not get this will eventually seize to exist because others can do it more effectively and thus cheaper, faster or better. So as long as I can contribute to improving organisations so they can better satisfy their customers, I think I’m good 🙂