Speakers : Oleg Kofman, Jon Epstein

The goal of a SharePoint governance is to keep both IT and users happy and to set some processes in place. It should involve a broad range of people, from the business (really important to get adoption) to the network people. Legal and compliance becomes also even more important teams, as data and files are going online and licensing concerns.

SLAs should be published, in order to limit the number of escalation and helps explaining the expectations.

So far, there are 3 models : Farm solution (since 2007), sandbox solutions (deprecated) and SP Apps. Sandbox solution, even if deprecated, it is not yet gone. Recommendation is to convert the Sandbox solutions. App is the preferred option for multi-tenant Office 365. It is easy to deploy, maintain and reuse, but there is no server-side code. Even if an App does not have server-side code, it can be an umbrella on top of an other solution having server-side code.

Process to determine if an App can be used : 1st, check if there is already something existing in the Enterprise Catalog and if it can be done without code, just to avoid a reinvent the wheel. Then, check the SP Store or 3rd party vendors in order to have a build vs buy thought. Then, check if TimerJob is needed to be developed or if any server-side code is needed. Will is save time and who will maintain the solution (once the developers have gone) ? The last step is to define who will publish the App in the store.

Different hosting models : SharePoint-hosted, when a user deploy an App a subweb will be created. So, if 10000 users request to install the App, there is potentially as much subweb created ! No server-side code is allowed. Provider-hosted, to host the App on your own infrastructure that can be also completely separated, enabling to use other languages, such as PHP, for App development. Autohosted, where a Windows Azure Web Site and SQL Azure DB will automatically be provisioned when the App is installed.

So far, every developers needed his own SP farm. With the new App model, therefore this is not really required as the developer can stay in a single site.

Publishing an App needs to make a choice between two App Scopes : Web Scope, on site per instance, or Tenant Scope, one site per tenant. This can’t be defined by the developer (no manifest entry). It is important to publish the evaluation criteria for App permission, so that the developers know what is expected and what is allowed in terms of App permissions. High Trust Apps (for On-Prem) require more scrutiny. New Apps versions may also request for different permissions. So, it is important to check, from a governance perspective, what are the permissions are requested and challenge them. Plan for publishing requests SLAs. Someone has to proactively look for the requests and approving them. Plan who will highlights, adds and review (technical) Apps. It is possible to have one App catalog per Web Applications. It is not possible to share an App catalog across Web Applications. Therefore, define whether the Apps should be published in all the catalogs or not. Such process should then be in place.

On the operations side, it is important to monitor the usage, errors and the licensing. It can be done from the Central Admin and Apps monitoring information is stored in the Usage database.