Time they are a changing. For some, these changes have already taken place. For others, they are pushing back and sticking with their existing development plans. Microsoft is certainly pushing a different approach / model for those of us who have made a living customizing and building on top of SharePoint. I for one do prefer this new model for many reasons I try to adopt it where it makes sense. However it does not work for everyone and every situation. Part of this is due to the implementation of the model (it’s still relatively new), part is due to breaking the way we have all been thinking about customizing and extending SharePoint for over a decade.
Looking Back
For the longest time, really starting with SharePoint 2007 when the platform gave us the features and solutions framework (but it could be dated back to the SharePoint Portal Server 2003 release), we’ve been building applications of some sort on top of SharePoint. The key phrase there is “on top of” SharePoint. We kept the data within our applications within SharePoint lists and libraries, we built things like timer jobs for scheduled tasks, we created event receivers and custom workflows. Our applications were clearly “SharePoint Applications” in that they could not be decoupled from the product.
This caused some challenges over time. Once an application was built on top of SharePoint, it was tightly coupled to that install. When the company wanted to upgrade to the latest version of SharePoint, it wasn’t uncommon to see a mission critical line of business application build on top of SharePoint be the bottleneck or the thing that held a company from upgrading. Why? The application codebase needed to be tested against the new version.
Another challenge it created is that the application was tightly coupled with SharePoint so if there was an error or exception in the application, it commonly affected SharePoint as well… in a negative way. This was one of the primary root causes for SharePoint outage support cases with Microsoft: our custom code.
Looking Forward
Today Microsoft is pushing this new app model for multiple reasons. They needed a new extensibility model so customers could deploy customizations into hosted SharePoint deployments like SharePoint Online in Office 365. The SharePoint App Model represents a very big change in this approach as instead of building applications on top of SharePoint, they are more built beside SharePoint and then talk to SharePoint in this loosely coupled architecture using the client-side object mode (CSOM) or the REST API. You can build apps that either run in the client (and are not touching SharePoint directly) or server-side as long as they aren’t the SharePoint process.
Now, I’m not saying you have to buy into this model. there are plenty of customers who are not fully sold on the concept and are still building solutions. There are even plenty of options as to why you should create solutions over apps because apps don’t do everything that you can do in with solutions.
I Prefer Building Beside, Rather than On Top Of, SharePoint
However for me, I really like this model. This new approach of building beside SharePoint rather than on top of SharePoint. As a developer, it frees me up from the limitations of SharePoint such as not being able to support ASP.NET MVC or the latest version of the .NET Framework (ok, not it does support the latest version, until there’s a new version). I can now build using any technology I want, the coolest and most cutting edge library I’ve found on today’s Hacker News.
As the owner of the app or the SharePoint deployment, I also really like the fact I don’t have to worry too much about the health of SharePoint or when SharePoint is getting a patch, service pack or upgrade to a new version. As long as I work decoupled, I should be in good shape.
This approach does involve taking a different perspective on SharePoint. Rather than it building an application development platform as I saw it starting back in 2007, I now look at SharePoint and the bigger Office 365 as a provider of services to my application. Do I need to leverage user profile data? What about taxonomy? Search? Workflow, document management or even collaboration? Why should I build that into my application rather why not just leverage the same services (taxonomy, search, user profiles, etc) that are already being used within my organization’s SharePoint deployment.
I encourage you to just run through a thought experiment the next time you have a custom application you need to build and the bossman says “it’s going to run in SharePoint.” Ask yourself: what does SharePoint have to offer? Would it be better to build this so it runs outside of SharePoint but my users simply think they came from the corporate intranet or extranet? If so, maybe this approach works for your situation! But make sure you don’t misunderstand me: I’m not saying this is ALL you should be doing. In my experience, this is the approach I default to and try to make work for the custom applications I’m building for people these days… both those in the cloud or on-premises and even those who fall somewhere in the middle.
