Its been a few months since SharePoint 2013 has been officially launched, and although I did not get a chance to go through all aspects of it, I did come across quite a lot of new features that customers had asked for quite a long time (and developers had wished for :)). I would publish them in a different post later, as I had done when SharePoint 2010 was released, however in this post, I intend to concentrate on one disruptive feature that Microsoft has incorporated in their latest release of their fastest selling server software and that is the Apps concept.
In case you have not heard of this feature or have gone through and are confused (I get that a lot), I’ll try to explain it briefly. The saying goes that everything in SharePoint 2013 is an App (the saying earlier was everything was a list). So lists, document libraries, web parts etc . are all Apps. So how is a list in SharePoint 2010 different from a list App in SharePoint 2013? The 2013 one is called an app. That’s it. The underlying technology for list. libraries, web parts etc. are basically the same. There was a new concept that Microsoft wanted to roll out, that they called Apps and in order not to overload end users with too much jargon (lists, libraries, web parts and Apps), they decided to just call everything an App. I suppose in this age with the boom of smart phones, everyone understands if you say Tasks App, but a lot of people would scratch their heads if you mention Task List.
So with that out of the way, from a development perspective there actually is a new concept called Apps in SharePoint 2013, and it is up to you to use it in your solution. You could just go ahead developing the way you have been so far without bothering with (actual) Apps, however Microsoft seems to be strongly advocating this, and I see some compelling reasons why they are doing so.
Before talking about Apps are and why they are so important, let me just give the context via the SharePoint road map and positioning of SharePoint the last few years based on what I have seen in the market.
I started taking up SharePoint seriously from the 2007 version onwards. Although I had worked on 2003, it was more of a part time thing, just one component of a project. SharePoint 2007 was actually radically different from the previous version; Microsoft had merged CMS 2002 and SharePoint 2003 together into one product, added a bunch of features ensure that the product had decent DMS and WCM capabilities, leveraged the same platform the .net version at that time and enabled .Net web parts to be deployed on top of SharePoint. SharePoint 2007 was a platform that had enough breadth to be leveraged as an Intranet for an organization. The positioning of SharePoint at that time (official or unofficial I am not sure) was that it was not just a document repository; rather it was a platform for application development. Which actually made sense for its use for an Intranet; since it has enough breadth, deploy it in your organization, and if you need more in depth features, you just build on top of it using .Net for which manpower is plentiful.
So a lot of people started buying and got developers to carry out heavy customizations on top of it in order to meet their requirements. I have seen projects, which we have taken over which actually had customization of default SharePoint files just to meet some demanding requirements. Well, you couldn’t really blame the developer much, after such good marketing of SharePoint by Microsoft (one argument I’ve heard a lot is ‘Microsoft says it’s possible, perhaps you don’t know the right way to do it’) , it’s difficult to go an tell a customer that there are limitations in the tool he spent a whole lot of money on and a lot of development teams just went with the flow and carried out customizations on top on, within and around SharePoint.
As any new product in the market, SharePoint did have its share of issues, related to scalability, performance, buggy code etc.. Now if you take a product such as SharePoint which is actually had a whole gamut of features, all of which could be sold as a separate product, its dependency on various other environmental components – Windows Server, IIS, SQL Server, network etc. and compound that with the product being such a runaway success and lots of customization on top of it which could be carried out by people who just took a crash course in .Net , you have a recipe for a stressed out support team.
Debugging issues, would no doubt have been a nightmare with the support teams trying to find out if they are due to problems within SharePoint itself, or if a developer had sneaked in some code component somewhere that was behaving badly. You can imagine the maintenance trying to peel through layers to other people’s code in order to figure out what’s going on, without really understanding what is happening in internals of SharePoint. Every developer would agree that debugging ASP.Net applications is far easier than debugging a SharePoint application of the same complexity.
The message for SharePoint evolved into “Do not customize”. If you customize you are carrying out a mortal sin. Unless you are careful, it could cause huge issues, you will loose support and never the less, it will be more painful if you need to carry out upgrades to newer versions of SharePoint. So that brought about a new mindset in people and people being paranoid on customization, and some IT teams just went with plain vanilla out of the box implementation, which was excellent for IT, but obviously not for business. Imagine a business team asking IT for some feature that is available in most of the Internet platforms that they use at home (Facebook, Dropbox, Google Docs), but the IT team telling them that it is not possible since the platform does not support it.
To solve this stalemate the IT teams started using different strategies, adopting third party products for customization, spinning of a different farm for groups that needed heavy customization, and charging them for it etc. Not doing customization on a generic tool was not a good approach, and that was echoed in one of the Gartner sessions on Portals and Collaboration I had attended last year. A tool comes with generic functionality; it needs to be tweaked to order to satisfy the business, else the ROI is not really justified.
To help bridge the gap, there was the Sandbox concept brought in with SharePoint 2010, however I did not see too much usage of that, primarily because of the huge customization limitations in the Sandbox, which did not fit into a lot of scenarios.
Even while all of this was going on, SharePoint really booming and gaining huge popularity. I have seen people who were ok to use SharePoint just as the UI and authentication layer, with all components on them pure .Net user controls. And also people who said they wanted SharePoint, just because the market analysts said it was the best tool around, when I asked them for requirements, they just sent a document that was a copy paste from a Microsoft site on general SharePoint features. Someone who was in the industry for a very long time told me there was a phrase that was popular quite a while ago “No one ever got fired for buying IBM”. It seems the new phrase is “No one ever got fired for buying SharePoint”.
So I suppose that the folks at Microsoft took the following points while considering SharePoint 2013
- SharePoint is currently very popular thanks to our marketing
- SharePoint without customization is not good for the Business folks
- SharePoint with customization is not good for IT folks
- Good SharePoint developers are a premium in the market
- People are realizing the above and to retain the market share we need to keep everyone happy
So the best thing that they could do was to tell people to use SharePoint and enable customization , however all customization should run outside the SharePoint engine. How does that happen? By running code in the browser (using CSOM to interact with SharePoint objects) or by writing code on a different server and exposing it in SharePoint via iframes. This was a best of all worlds type of solution – if people wanted to create custom web parts that interacted with SharePoint objects like lists etc, it had all to be carried out via client side technologies. Any more heavy customization such as interaction with DBs or external APIs, just write a normal ASP.Net forms or MVC application, host it separately and use SharePoint to expose the UI via iframes, or just linking to the application.
Pretty simple enough solution, and in fact a couple of solutions that I was involved in designing in SharePoint 2010 had exactly the same approach, which is why I feel that the evolution was natural. MS had only to provide all the plumbing around it to ensure users are authenticated across, security based considerations and allowing the same chrome to be used, so if the theme changes on SharePoint it changed on the external application as well, providing users with one seamless experience.
The Apps in SharePoint are of three types
- SharePoint hosted – which means they are deployed on the SharePoint server, however this does not allow for any server side code; it has to make use entirely of client side technologies
- Provider hosted – As good as a separate standalone application, however linked to from the SharePoint site of exposed via an iframe in SharePoint
- Auto hosted – Similar to Provider hosted, however on Azure
I am not going into depth as to how each of these work and you can get a lot of info on this from MSDN.
So now what Microsoft has provided is
a) A version of SharePoint that need not have customization on it (Happy IT folks)
b) however customization is possible (Happy Business users)
c) and even very heavy customization requirements can be met by running those components on a different server running regular web technologies, be it ASP.Net, PHP, JSP etc, without requiring specialized knowledge on SharePoint. (Happy developers and Happy Finance team)
d) Ability to sell SharePoint like never before; no more debates on if why SharePoint vs ASP.Net. Microsoft could just say , “Ya, you could do it without SharePoint, however just consider in the future you need a discussion forum or a blog to integrate this with, and of course the trend now is towards social…” (Happy $teve Ballmer)
So who has a potential of loosing out – Hardcore SharePoint developers who spent years of blood, toil sweat and tears trying to master the intricacies of customizing in SharePoint :).