My thoughts on future of SharePoint and Office 365 Development including SharePoint 2016 On-Premises

Although my background is focused around SharePoint development, ASP.NET development and Microsoft web technologies, I don’t code any more the amount of code I used to do. If I am lucky enough, I would spend 2-3 months a year to lead the SharePoint development team and make my hands dirty with the code for 4-5 weeks along with overseeing team activities and setting the architectural direction. Even though I am not exposed to code 365 days a year, it is important to note that not only I would keep up with the latest innovations announced whether at TechEd, SPC, Build, and now Ignite, I would also continue to play with these innovations in my lab as much as I can with basic scenarios.

Luckily (or unluckily) for one reasons or another, I have been leading SharePoint development teams over the last 4 years building four different kind of traditional SharePoint intranets with each approach varied (and influenced) from each other either because of client requirements or SharePoint development industry trends.

  • Spring 2012 – SharePoint Online 2010, used sandbox solutions with code and content queries approach with Mark Anderson’s SPServices as a provider for cross-site collection communications, no content by search web parts in SharePoint 2010 and no full trust code in SharePoint Online
  • Spring 2013 – SharePoint On-Premises 2013 Standard, used full trust model approach, Apps wasn’t supported in SharePoint running on Windows Server 2008 R2, ADFS 2.0, and Sandbox solutions with code was already deprecated. Due to no Content by search web parts in standard editions and full trust model approach, we went wild with all kind of tried and tested – SharePoint 2010 full trust development best practices for the SharePoint 2013 platform.
  • Spring 2014 – SharePoint Online 2013, used no-code sandbox solutions and content queries approach, sandbox solutions with code was already deprecated, client didn’t wanted to use Apps approach. Not to mention, we as a team didn’t have enough time to ramp up with technology and Content Search web part wasn’t available in SharePoint Online 2013 at that time, SharePoint artifacts provisioned declaratively through features framework and sandbox solutions packaging and business features were written with HTML, CSS, XSLT, and JavaScript.
  • Spring 2015 – SharePoint On-Premises 2013 Enterprise, used provider hosted remote provisioning and App script parts approach, we didn’t wanted to use dreaded iframe based App Parts or extremely limited SharePoint hosted apps mainly because of responsive design, instead used script editor and content by search web parts, SharePoint artifacts provisioned through CSOM code and Office 365 PnP program, business features were written with HTML, CSS, and JavaScript.

Having bored you with my credentials, let’s get to the meat of the story. Ever since Microsoft has released SharePoint Online and SharePoint 2013 Apps Model, there has been various announcements, recommendations, and best practices from the community and the Microsoft. Rapid innovations fueled with Microsoft’s cloud-driven approach, confused both industry and developers over the time.

SharePoint Development – Where we came from

When SharePoint 2007 was released, it was clear that SharePoint Full Trust model with server side code is the future and everyone from Microsoft and community (Microsoft partnered with Ted Pattison who wrote one of my favorite books – Inside WSS 3.0) declared it as future of SharePoint development platform. After all, SharePoint 2007 remote APIs were written as ASMX SOAP services when XML and XSLT was ruling web world. Even though Visual Studio tooling wasn’t available when product was released, SharePoint community kindheartedly adopted this model.

Deployment issues of SharePoint 2007 (and BPOS, Microsoft’s dedicated cloud SharePoint offering) full trust model code running on SharePoint servers itself was evident after few years industry adoption, which forced Microsoft to release Sandbox Solutions to alleviate the problems of full trust model (mostly bad development best practices) with the release of SharePoint 2010. SharePoint 2010 also tried to enhance remote framework as proprietary CSOM and industry standard REST APIs. If you have attended SPC09, there was a pretty impressive session from Scot Hillier on why admins should allow only Sandbox solutions from then on. Even with Microsoft’s push for Sandbox solutions as future of SharePoint development, restrictions of this model was never adopted by both developers and industry. Many of us thought that Sandbox solutions was Microsoft’s brainchild to support future version of BPOS, which was released as SharePoint Online 2010 (first version of multi-tenant architecture powered as Office 365) in May 2012.

Apps Journey

Fast forward to July 2012 and SPC12, Microsoft announced it’s next wave of SharePoint development platform – Apps Model. Again, Microsoft partnered with Andrew Connell, Ted Pattison, and Scott Hillier to onboard traditional SharePoint developers to the Apps model. SharePoint 2013 continued its investment in remote APIs to please both traditional developers and open source web developers with Unified REST and CSOM APIs. All the issues related to Full trust model running on the SharePoint servers causing upgrade issues, limitations of Sandbox solutions which would run only at the Site collection level under strange resourcing system, and Microsoft’s own cultural transition to adopt web industry best practices, Microsoft decided to offer Apps Model which means code will run outside of the SharePoint servers, in it’s own domain, which would not only make SharePoint deployment stabilized and upgradable but allow SharePoint developers to adopt latest and greatest innovations in web technologies including ASP.NET MVC. Now, it’s been 3 years since Apps Model has been released and in most cases – industry and community has formed their opinions – although everyone agree on running customization besides the SharePoint rather than on the SharePoint, industry is not keen on adopting Apps Model. So why adoption is slow? Faulty architecture again? – Answer is partially YES.

Microsoft initially announced three Apps model – SharePoint hosted model (extremely limited), Provider hosted model (standalone Apps), and Azure Hosted Apps. Microsoft killed Azure hosted apps within 2 years stating scalability and manageability concern. I wasn’t surprised. I am yet to meet someone who had invested in Azure hosted apps. In general, any one who has configured Apps Model on the SharePoint 2013 on-premises farm wants to avoid it all together because of it’s complexity and additional hardware cost. While provider hosted model does provide some benefits (at the expense of complex infrastructure, most of the benefits comes at the remote provisioning patterns from PnP library), SharePoint hosted model is joke in most cases. Like they says, if there is smoke, that means there must be fire. Although there is no verdict on Apps model judgement as of May 2015, rumors are already out there. Industry is already trying their best to avoid complexity of Apps infrastructure for SharePoint On-premises. Majority of the SharePoint developers are not willing to adopt this model and continue to invest on SharePoint full trust and sandbox solutions. If that’s enough, there has been sarcastic (and partially true) blogs stating Apps Model is dying.

Fast Forward to SharePoint 2016 and future of SharePoint development

As far as SharePoint 2016 development platform, here are the key messages and clarifications from various Microsoft speakers at the Ignite 2015 for future of SharePoint on-premises development.

  • Farm Solutions will be still supported
  • Sandbox Solutions with declarative code will be supported, there will be no further enhancement in Sandbox code service.
  • Microsoft will continue to invest in Apps Model, both SharePoint and Provider hosted Apps model would be supported
  • InfoPath Form Services will be supported and will work with InfoPath Form Designer 2013,  there will be no further enhancement in InfoPath forms service but Microsoft has no replacement story for forms.
  • SharePoint Designer won’t be released for SharePoint 2016 and Office 2016, SharePoint Designer 2013 will work fine with SharePoint 2016

My take on these announcements are there is nothing here which would make SharePoint developers to change what they are doing right now on the SharePoint on-premises. They may continue to develop customizations using farm solutions (although it’s not necessary after Office 365 PnP guidance and reusable code) or invest in unspoken sandbox solutions rather than leaning towards equally fatal Apps model. Smart developers may not build any code on top of SharePoint platform but as happened in past, everyone wants to take short cuts and develop fast without thinking of maintenance in future. As long as there is SharePoint on-premises software and unless there are Apps model innovations (both infrastructure complexity and iframe UI), people will continue to develop using Full trust model (and unfortunately using sandbox model).

Trends on Office 365 development platform

Let’s turn our eye to other side of the SharePoint development world – SharePoint Online and Office 365 development. Ever since Microsoft started upgrading all the Office 365 tenants with SharePoint Online 2013 in Q1 2013, innovations in the Office 365 development platform is mind-boggling. If Microsoft ever wants to control the future of the SharePoint development, this was the platform for them. From the get go, they have made it very easy for anyone adopting SharePoint online Apps development by preprovisioning Apps services infrastructure (arguably one of the most complex infrastructure configuration in SharePoint history along with User Profile Sync Service Application in SharePoint 2010 and 2013) and enabling Azure PaaS and ACS for apps hosting platform. Developers who were early adoptors and lucky enough to work on the SharePoint Online customizations projects were flying in blissful world of SharePoint Online Apps development including Azure PaaS development and web technologies innovations like ASP.NET MVC, Angular JS, Knockout JS, and Node.JS.

Ever since Chris Johnson and Jeremy Thake embarked their journey on Office 365 developer program after SPC14, Microsoft gained huge momentum on not only onboarding reluctant SharePoint developers on the Apps platform from many fronts including weekly Office developer podcasts (in parallel efforts from Vesa Juvonen and Steve Walker’s Office 365 Patterns and Practices program) but also innovated on Office 365 development platform itself. Throughout Summer of 2014, Apps model marketing was at its highest peak which culminated into amazing Office 365 and Office Graph APIs innovations announced during TechEd Europe 2014. Annoucements of Office 365 and ADAL APIs were probably first glimpse of Microsoft’s vision of Office 365 as developer platform. In the meanwhile, Microsoft continued their effort on Office 365 PnP program on MVA throughout winter to continue winning SharePoint developers, making it more of community efforts on GitHub and delivered through Nuget packages.

O365 PnP

Fast forward to Ignite 2015, out of all the new innovations Microsoft have announced including APIs for Groups and NextGen portals, Office 365 Unified APIs are probably one of the most strategic APIs came out from Microsoft after Win32 APIs in early 90s, ASP.NET released in 2001, and SharePoint solutions and features framework released in 2006. For traditional SharePoint developers, this might be the time to look back and start shredding all their SharePoint server development methodologies and start adapting Office 365 REST APIs, Azure Active Directory as Auth platform, and Office 365 PnP program for code transformation for both SharePoint on-premises and SharePoint Online customization.

O365 APIs

Parting Thoughts

In short, my final takeaway here is future of the SharePoint development community would continue to divide depending on what kind of hosted environment they would work and we may experience the trend of traditional SharePoint 2007/2010 development and futurastic world of the Office 365 development.

Personally, my approach and my quick guidance to all the developers would be:

  • For SharePoint On-Premises:
    • Avoid full trust and sandbox solutions what so ever. Administrators should plan to disable Sandbox code services on the SharePoint farms. Administrators should plan to have governance policies to avoid deployment of custom solutions from the Central Administration.
    • Plan to provision SharePoint artifacts using remote provisioning pattern – CSOM APIs reusing Office 365 patterns and practices code. Start investing in the provider hosted apps for remote provisioning and custom business applications. If Apps infrastructure and High Turst (S2S) configuration is not your cup of tea, you may want to use console applications (code based approach) to provision all the SharePoint artifacts from the remote servers.
    • Plan to build customization using OOB web parts like CEWP, CSWP, and SEWP using HTML 5, CSS 3, JS Link, and Javascript frameworks. Avoid CQWP as far as you can.
    • For fully integrated custom applications, in extreme cases, if you want to avoid provider hosted model, you can plan to just build ASP.NET standalone web applications and interact with SharePoint CSOM and REST remotely.
    • Adopt Office 365 Patterns and Practices for ShaePoint On-premises development and avoid features and solutions framework.
  • For SharePoint Online and Office 365:
    • Avoid sandbox solutions what so ever.
    • Start investing in the Azure PaaS or on-premises provider hosted apps over low trust (OAuth) configuration to host ASP.NET web applications
    • Start building custom apps using Office 365 Unified APIs and Azure AD consent framework to build your NextGen customizations.

Last but not least, I would leave you with some of my must have SharePoint and Office 365 development resources. It sounds like road ahead for traditional SharePoint developers is more fun, rejuvenate their careers, and chance to get back to roots of innovative web technologies. Good luck!!!

This entry was posted in Uncategorized. Bookmark the permalink.

21 Responses to My thoughts on future of SharePoint and Office 365 Development including SharePoint 2016 On-Premises

  1. Reblogged this on El Blog del Programador and commented:
    Comparto con todoso vosotros este interesante artículo sobre el futuro del desarrollo sobre SharePoint. Saludos

  2. Eric Skaggs says:

    Great post, Nik! I agree on all points and am seeing that trend become more prevalent. My own goal is to leverage the power of remote code execution for both on-premises and Online environments. The Branding.ApplyBranding sample in the OfficeDev PnP project is a decent example of this. Also, given that SP2016 is a snapshot of SPO, I’m always going to push that we develop for the cloud first and adapt to on-prem where needed.

    • Nik Patel says:

      Yeah, that’s a mantra I have been following.. develop for the cloud first and adapt to on-premises wherever needed.

      • Thanks Nik ,I am also completely agree for SharePoint Road Map Cloud and Mobile First but some government organization they have some reverse strategy , On premises first then cloud. so how do we handle this situation?

      • Nik Patel says:

        For the on-premises approach, I would still prefer to stay with cloud-first model. What that really means is avoid full trust and sandbox solutions. You will still able to do everything with Apps or remote provisioning approach what you used to do with full trust code. Decoupling your code is better approach anyways. With the recent updates in CSOM/REST APIs, Microsoft’s commitment towards making remote development compliant with full trust code, and community projects PnP, I don’t think I feel like I need full trust code anymore. It might be easy. It might be something we have used to but remote application model has lot more benefits than just cloud ready. Hope this helps.

  3. jthake says:

    Thanks so much for explaining all your thoughts. It is great to hear your journey and we certainly understand your concerns back in Redmond.
    I’d love to hear more in a post around your concerns on SharePoint Provider Hosted add-ins. You make a suggestion to host ASP.NET web applications to CSOM APIs but I don’t understand how this is any less complex architecture wise than Provider Hosted set up? What bit pushes you over the edge?

    • Nik Patel says:

      Jeremy, thanks for the comments. And, thanks for reading it.

      As far as SharePoint hosted add-ins, in addition to specific Apps infrastructure needs, it’s all about it’s limitations of using HTML and JavaScript and not able to use C# Code. Also, App Parts are big concern especially if you want to build responsive web parts.

      As far as provider hosted model, it’s configuration of High Trust, creating Apps domain, and developing/publishing approach puts off many organization adopting this model. Don’t get me wrong. This is my preferred model for remote provisioning SharePoint artifacts but if I can get away using console application, it would remove the dependency on complex infrastructure. Many of my clients after reviewing both approaches, opted for second option.

      For full blown business applications, provider hosted model is a great approach and probably should be preferred approach. Again, problem here is complex infrastructure. If you can just build stand-alone ASP.NET applications to interact with remote SharePoint REST/CSOM APIs, it would make maintenance easy for many organizations.

      • Marwan Tarek says:

        I agree with responsive design limitations. All clients are expecting any web application to be mobile accessible and SharePoint online is not.

  4. Pingback: Office 365 Developer Podcast: Episode 046 platform dev with Mike Fitzmaurice and Andrew Connell |

  5. Pingback: Office 365—monthly Dev Digest for May » PC Portal

  6. Good article. I would extend the concerns to the Document ID Service – not customisable in SP Online, Workflow – which is still missing many features in Workflow Manager v’s SP2010 WF, Remote Event Receivers – should be much easier to implement and work more reliably. With the death of SharePoint Designer, seems like the WF model is in danger. Finally, adding a developer referenceable CDN for all the SP js files to reduce latency.

    • Eric Skaggs says:

      SharePoint Designer’s not dead. SharePoint Designer 2013 can be used with SharePoint 2016. There just won’t be client product called SharePoint Designer 2016. The same applies to InfoPath Designer 2013.

      • Nik Patel says:

        My take here is SharePoint Designer is not dead but there are no investments either. Many of using SPD (which we use a lot) for master pages, page layouts, and workflows will have alternative option. If there are no investments in designer level tools, like Eric mentioned, SPD 2013 can do the job for the next version.

  7. I wonder if there will ever be a day in the future where we look at SharePoint development and say the entire story is equal to or better than the results of the original Solutions and Features framework approach in its heyday?

    As the owner of one of the earliest SharePoint ISVs, I’ll have to say that what I observed over the years was that the Solutions and Features framework supported the solving of millions of business problems for thousands of companies around the world, and also helped make hundreds of successful SharePoint ISV businesses.

    Not saying that there haven’t been problems to overcome over the years with the Solutions and Features framework, but the reality is that it has proven to be able to be made to work, from both technical and business standpoints, if customers and ISVs work at it.

    Don’t hear me saying that I think there is any future for Solutions and Features. I understand that the approach is not workable in Cloud environments.

    I just wonder if the overall SharePoint development story will ever be as good again as it once was from a customer business problem-solving and SharePoint ISV-enabling standpoint?

    It seems to me that not as many business problems are getting solved with SharePoint these days and not as many SharePoint ISVs are thriving (even if they have already transitioned their add-ins to the new App Model) and part of it could have to do with all of the turmoil when it comes to how to develop and market\sell SharePoint applications. It all seems like a huge mess to me.

    • Nik Patel says:

      Jeff, great response. Yes, it’s been 3 years and App model is still not wide stream. Looking back how we adopted 2007 full trust model, app model still have some issues. Don’t get me wrong. Microsoft is moving in right direction but their rigid SharePoint API and framework, doesn’t give them much options, Many things are changing fast in Office 365 world but it would take time for SharePoint on-premises space. My intention of this article is simple – stick with Microsoft direction with minor adjustments/deviation and keep informed your business users on those choices.

  8. Hi Nik,

    Thanks for the detailed info. I’ve worked on both the on-premise and Office 365. But I do have a doubt how to overcome the security issues if we use JavaScript to code in our apps or webparts?

  9. Hi Nik,

    Great article mate! What I don’tndertand is your approach on provisioning. So if I wanted to provision a new site page for a client and provision a few site assets (images maybe), instead of using a package like SPMeta2, you’re suggesting doing a remote provisioning, instead of sandbox solution.

    Isnt that overkill?

    • Nik Patel says:

      Yes and No – it depends. There is nothing wrong with full trust or sandbox modes but if you are adopting add-in models, it does make sense to adopt all the way. Typical use cases would be remote artifacts provisioning, remote widget deployments or full fledged applications. There are plenty of examples available in Office365 PnP guidance to get you started. Hope this helps.

  10. Pingback: The Future of SharePoint (Uncensored) – Dock Intranet Portal

  11. Pingback: THE FUTURE OF SHAREPOINT (UNCENSORED) – Global Infonet Inc. Blog

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s