Do I Need to Develop Custom Web Parts for My SharePoint Implementation?

Share on FacebookTweet about this on TwitterShare on LinkedIn

Share on FacebookTweet about this on TwitterShare on LinkedIn

Web Parts are the basic building blocks for all SharePoint sites; they allow you to customize a page’s appearance, view and interact with data stored in SharePoint lists or libraries, and they’re the primary window to deliver additional functionality to your sites. (For more information and an introduction to SharePoint Web Parts click here)

segue-blog-do-i-need-to-develop-custom-webparts-sharepoint-implementation

 

The Need for Custom Web Parts

With over 75 standard Web Parts included with SharePoint Server 2010, modern SharePoint installations provide a vast amount of functionality and flexibility without the need to develop custom code. In addition to the variety of standard Web Parts, SharePoint Server allows you to integrate   many of them with different back-end data connections, add simple yet powerful customized form solutions built in InfoPath, display data from various Office document formats directly on your site, and even connect Web Parts to each other so that they can dynamically interact with your systems environment and your users.

As with any set of tools though, there are always some specific features that you may need which are not included in the out of the box configuration. If you do run into a situation where no existing capability satisfies your need, SharePoint provides a framework to develop your own solutions from the ground up, using custom code that can be extended to meet virtually any of your Content Management System needs.

Within SharePoint, the decision to develop custom code typically translates into developing custom Web Parts. Web Parts can be packaged as WSP files and deployed across your entire SharePoint environment, where they easily plug into SharePoint’s Web Part Page framework. This allows you to develop Web Parts that focus on providing functionality, while allowing the rest of your site settings to provide the visual appearance, security settings, and data management policies that your organization requires.

The Disadvantages of Custom Web Parts

While custom Web Parts provide nearly limitless flexibility, this approach does have some drawbacks. Developing custom Web Parts requires a different set of personnel expertise, a different set of development tools, and a significantly greater time and resource effort than implementing solutions based on built-in functionality. Custom Web Parts also typically require a long-term maintenance effort to ensure the underlying code continues to work properly as the programming environment changes over time (e.g.: Windows/.NET framework updates & security hotfixes, internet browser updates, SharePoint version updates, etc.)

Because developing custom code is relatively time and resource intensive, you should always assess whether existing functionality will solve your needs first. With the wide variety of customization supported through SharePoint Designer, and an inventory of powerful yet exceptionally flexible built-in web parts (especially the Data Form Web Part (DFWP) and Content Editor Web Part), SharePoint’s existing capabilities can typically be tailored to meet the vast majority of an organization’s needs. Unfortunately, this approach can have its own disadvantages; taken to extremes, site/page specific customization (especially with Content Editor Web Parts and some features in SharePoint Designer) can prove to be a maintenance problem for your Farm Administrators and a governance nightmare for your Site Collection Administrators.

Useful examples of custom or third party Web Parts include: integrating custom or proprietary (non-Microsoft) systems into your SharePoint portal (such as custom developed line of business applications, SAP Business Objects reports, Oracle ERP solutions, and many others), extending security or management features to meet specific/specialized needs (like column level security within lists or managing exceptionally large pools of users), and enhancing built in document management features (batch edits, tagging, etc.). There are, of course, other business cases where you might decide to develop a custom web part to fulfill a need, but caution should be taken to ensure that enough value is being derived from the effort to build a re-usable, customized solution to make it worth expending your organization’s resources.

Ultimately, SharePoint provides a great framework to build your business solutions on. Once properly configured, it takes care of much of the infrastructure (security, back-up and restoration, document policies, etc.), while allowing you to focus on developing solutions to solve your business problems. Most solutions will not require you to develop any customized software at all, but the SharePoint environment is exceptionally flexible for those problems that do need a unique approach.