There are a wide range of reasons why SharePoint has been customized by organizations looking to make the most of their investment. These range from the almost compulsory requests to make “SharePoint not look like SharePoint”, to coding to adding functionality that just wasn’t included out of the box.
This ‘custom code’ and ‘custom functionality’ has traditionally been achieved in several different fashions.
The Beginning of a Revolution: SharePoint 2007
SharePoint 2007 was a real game changer as it was the version that really opened up customization options for developers. For the first time in the product’s history, Microsoft made an official API available.
Other facets that SharePoint 2007 introduced were the ability to package up modifications into packages called “features” and to allow a newer, more effective mechanism for applying branding customizations; i.e. master pages.
For the sake of historical clarity, it may help if we offer up a quick summary as to what the important changes were:
- SharePoint Feature: A SharePoint feature is a way of packaging and making available new features and web parts in an easy and straightforward fashion. Features can be easily packaged and deployed by developers. They really opened up SharePoint to adding new third party functionality.
- SharePoint Master Page: Master Pages dictate where all the common parts of a SharePoint site sit including the header, navigation links, Site Actions menu, and so forth. It provides a vehicle for consistent branding.
- SharePoint Web Part: This is a single, reusable function that can be deployed across many sites. For instance, in SharePoint 2003 it was common to see developers deploy their own RSS web parts over and over. SharePoint 2007 changed this.
Lastly, the unifying aspect for all of these customization options is that they are all dependant on the .NET platform. It wasn’t possible to cater for any SharePoint customizations with any other language. This made sense as .NET was, and still is, a Microsoft technology.
Back in the time of SharePoint 2007, Microsoft’s attitude was very much that SharePoint should ‘eat its own dog food’.
Introducing the SharePoint App Model: SharePoint 2013
Everything changed again with the release of SharePoint 2013, and its inclusion of a brand new ‘App Model’. This is an evolution in how SharePoint customizations are catered for and applies to both Office 365 and On Premise SharePoint. It is a huge difference between the SharePoint of old, and more modern SharePoint we have today.
The App Model tries to do a few things. As the name implies, it aims to replicate the App store concept that has been introduced with great success by the likes of Apple. Users in SharePoint and Office 365 can now dive into the store to purchase pre-approved third party tools and functionality. It is easy, quick and simple. Companies can even select which apps are available to users in their own instance of a store.
The App model also radically changes how third party code is written, managed and deployed in SharePoint. This post isn’t a technical look in depth at these features, but there are a few really nice touches we want to look at.
No Longer Lost in Translation
The App model makes it possible to code SharePoint customizations in non .NET languages, common things like HTML and CSS. It also makes it possible to host apps on external services, hooking them into SharePoint in new and interesting ways.
Non SharePoint hosted applications are commonly labelled “provider hosted” and contain at least one remote component, whether this’ll be a service or database. This is normally hosted outside of the SharePoint farm / Office deployment. More importantly they can be hosted on any web hosting technology stack, including the like of Apache and Linux.
This works as a distribution model as the developer will be responsible for hosting the remote components that they can then sell on or make available to multiple firms as needed.
These apps can also use the SharePoint API to connect and integrate with SharePoint features. This offers a huge amount of flexibility to developers, and means greater quality and choice for end users.
The alternative to provider hosted applications are SharePoint hosted, which are applications typically centered on SharePoint components and utilize only client side code. Limiting the user of server side code means third party apps and tools now integrate with SharePoint in a much more secure and stable fashion. Again great news for end users and systems admins alike.
How Does This Affect SharePoint?
The shift away from web parts and master pages has several positive changes for SharePoint customization. Firstly, it encourages stronger and more effective use of the native “out of the box” product. As list, libraries and other components become more integral to solutions, the need to wrap up external data should eventually diminish.
Furthermore, the app store itself does allow for local or global distribution and is a world away from earlier methods of code deployment that typically needed full trust access to the GAC. With either SharePoint hosted or supplier hosted applications no longer needing to deploy server side code, security and stability will only benefit.
Lastly, the increased flexibility the app model affords developers shouldn’t be undersold. The ability to use any development language, alongside different web technology stacks and whatever hosting option is appropriate is a massive plus. Your developers no longer need to be .NET savvy and will only have minimal work to do to learn how to access the SharePoint API.
A Real Game Changer
SharePoint 2013 is certainly a game changer for those looking to make cosmetic and functional modifications to their platforms, and a leap forward from SharePoint 2003, 2007, 2010.
By taking the concept of an app store that rivals such as Google and Apple have utilized so well, Microsoft have cleverly opened the product potential up. Increased security and stability are on offer for these customizations as well as the ability for developers from a non-Microsoft or .NET background to contribute.
Office 365 takes all of these good developments and wraps them up in the Cloud. So users of SharePoint 2013 On Premises or via Office 365 are in a win-win situation!
from Sharegate’s Blog http://ift.tt/1JPSKQq