SharePoint Customizing Governance

PLAN BEFORE CUSTOMIZING

2013, Alexander Ahrens | MCPD exxlence exxlence.com

Why a customizing governance?

Complex customizings require a lot of Know-How and experience

Some customizings are not cloud compatible

Some customizings block system updates

Complex customizings are expensive in development, testing and operation

Avoid unnecessary customizing

Migrating a SharePoint with serverside customizings is a lot more expensive than migrating a SharePoint without serverside customizings

Types of Customization

User Customization

Lists, Libraries, Views, Columns, Metadata, Fields, Page Layouts, Web Parts, formatting Text and Graphics, Site Pages, Wiki Pages

Power User Customization

Connected Web Parts, SharePoint Store Apps, HTML in calculated fields, Workflows, JavaScript

Developer Customizaion

Farm and Sandbox Solutions, Apps, Client side development

Microsoft:Use OOTB whenever possible

While designing the next wave, our team met with hundreds of customers and partners around the world which influenced not only the evolution of the product but also the guidance that we will update in this blog and on MSDN and TechNet. I wanted to emphasize two points as we roll-out the new release:

Use SharePoint as an out-of-box application whenever possible - We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.

Be thorough in custom web design, development and testing – We know many SharePoint sites are published portals or custom web apps and are excited about the new features we designed for these scenarios. We encourage you to review the new features and guidance to reduce the amount of custom work you need to do. But even there, code is code and we encourage you to validate your design early in your development cycle and with particular focus on peak usage performance testing for how your customizations impact HTTP and SQL Server roundtrips. We have guidance and page and object caching techniques that can help here.

Source:

http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=1012

Golden rules

Learn SharePoint features and capabilities before going with customizing.

Start client side customizing and app development before going with farm solutions.

The levels of customizing

I defined 5 levels of customizing that…

describe what types of solution elements are allowed

allows to classify every solution

describe what the consequences are by allowing certain levels of customizings

100 500

Levels of SharePoint Customizing

Simple

Complex

500 Farm Solutions

400 Provider Hosted Apps, Silverlight Solutions

300BCS Solutions, Masterpages, Page Layouts, Designes and Themes, SharePoint hosted Apps (HTML5 + JavaScript)

200 Access Services, InfoPath, SharePoint Designer Workflows

100 Browser based solutions

Level 300 Governance

What? No server side customizings

No provider hosted apps

JavaScript as programing language

Deployment via Sandbox Solutions

Rollout via PowerShell

Why? High system stability

No maintenance due to customizings

No separate infrastructure for testing of customizings required

System remains on upgrade path

Cloud compatibility is kept

Requires less Know-How for testing and operations than level 400+ governance

300

Level 400 Governance

What? Based on Level 300 Governance

Allows Hosted Apps and Silverlight

Silverlight is hosted within SharePoint

Hosted apps are hosted outside of SharePoint

Hosted apps integrate in look and feel and navigation

Why? Keeps all benefits of level 300

governance

Allows more complex applications without affecting system operations

Requires more Know-How for integration and security during operations

Requires more Know-How for development and testing

400

Level 500 Governance

What? Based on Level 400 Governance

Allows Farm Solutions

Allows maximum of customizing

Why? Complex solutions that cannot be

realized with level 400 governance are now possible

Requires a high level of Know-How in operations, development and testing

Requires seperate infrtastructure for testing of customizings

500

Coding conventions and Developer Guidelines

What? Define allowed features

Exclude features

Define rules for feature use

Define naming conventions

Capture good/best practices for reuse

Documentation rules

Examples:

InfoPath cannot be used because of licensing conditions

Apps may only use JQuery UI Version 1.7.1

Why? Ensure that others can

understand and improve custom solutions

Ensure that technologies are used for their purpose

Avoid unnecessary costs in support and operations

Customizing levels in a multi farm farm architecture

Collaboration and Service Farm Publishing Site Farm

Level 300 Customizing

Farm Solutions are used for Master Page deployment only.

Stays on upgrade path.

Level 500 Customizing

Farm Solutions for heavy customizing and deployment of artefacts.

Needs a lot developer assistance during upgrade.

It makes sense to assign different levels to different farms: