When is SharePoint Customization required ?
The feature set and flexibility provided by Microsoft in SharePoint platform often gets us to this on the topic- Is it a development platform or an application suite. This is entirely dependent on the persons perspective and the ease of the person is using SharePoint as either medium. But at the heart of this question is a simple query, when to apply customization in SharePoint. This article is based on our experience executing various SharePoint projects and looks at some scenarios where its justified to customize.
SharePoint Customization scope
Trigent, being a Microsoft Gold Certified Partner and considering our extensive skills and experience in .NET development, customization of SharePoint to meet business requirements is an easier choice. However we strongly believe that just because you can doesn’t mean you should. Our primary focus is long term maintainability of the application. Design is an extensive exercise undertaken for every project where each requirement is evaluated and corresponding solution is identified. The emphasis is on utilizing out of the box features to meet the functional requirements to the extent possible. If the requirement cannot be met using out of the box features, then it is documented, informed and a collective decision is taken to use alternatives (customization). At Trigent customization is considered based on four factors
- Business value derived out of the customization
- Skill-set of the client’s IT support staff
- Effect on application performance
- SharePoint next upgrade plans/timeline
Our Views on SharePoint Customization
Trigent recommends customization only if it brings substantial benefit to the business, the impact on performance is minimal and if our client has the required support staff. If there is an immediate plan to upgrade SharePoint then the recommendation is to postpone customization until the upgrade is complete.
There are definite scenarios where customization is necessary to derive complete value by meeting the business requirements like business processes (workflows), business intelligence (insights) and integration (events on external data). On the other hand, there are identified functionalities in SharePoint that we do not recommend customization at all e.g. changing base content types.
Customization helps in faster adoption of the application as the exact specifications can be made available in the application. SharePoint projects involves considerable upfront investment in infrastructure, licensing and execution (planning, design, development, testing). Customization can help in deriving better value and therefore improves the return on investment.
Customization is discouraged for the following reasons
- Microsoft does not support extensive customizations resulting in discontinued support.
- Customizations, especially done to UI layer, can cause performance issues.
- Major impact of customization is observed when subsequent service packs are installed or when the version is upgraded. Customizations can interfere with the upgrade or can fail to work after upgrade.
- Also, in the absence of proper documentation and source code, enhancements to current customizations can be cumbersome.
Compared to this, out of the box features have undergone rigorous testing (functional and load) by Microsoft and therefore brings the required stability to the application. Out of the box features can be maintained easily by any non-technical resource who understands the working of SharePoint as a “product”.
But it should be remembered that, these features are also governed by the limits (size, structure, volume, etc.) identified by Microsoft, extending which can cause serious performance degradation. One such instance is when large volume of external data is brought into the application using business connectivity services.
If you wish to discuss any specific scenario in detail, please get in touch with us
