customizing governance
TRANSCRIPT
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: