8 Characteristics of an Ideal SharePoint Customization

I’ve been working with SharePoint for the last eight years. In that time I’ve built many SharePoint solutions using nearly every available approach. Eight years is a long time. It’s long enough to give, hear, and read a ton of ‘best practices’ advice. It’s long enough to learn from the lifetime of too many design choices to count.

This post is my attempt to enumerate the qualities of an ideal SharePoint customization based on what I’ve learned. Keep in mind that these are ideals and the real world involves trade-offs. What do you think?

  1. It meets the needs of the people who use it without limitations imposed by the platform
  2. It doesn’t interfere with the operation of the underlying platform
  3. It uses SharePoint functionality as much as possible
  4. It depends on things other than SharePoint as little as possible
  5. It cedes runtime control to SharePoint as little as possible
  6. The other things it depends on are provided only by using supported mechanisms other than directly editing SharePoint Master Page or ASP.NET files
  7. Runtime or configuration faults in a customization can only impact the customization
  8. It is manageable and governable

Ideal #1: It meets the needs of the people who use it without limitations imposed by the platform

This is the most important thing. Does it do what people need it to do? If someone asks if the system can be made to do something is the answer ‘yes, it will cost x‘ or ‘we can’t do that because…’? Is it available when they need it?

Sometimes what people need will be the underlying factor that drives decisions that result in successful but far from ideal customizations.

Ideal #2: It doesn’t interfere with the operation of the underlying platform

SharePoint is built to be a shared resource. It’s in the name. Customizations should be polite and let the shared services do their work unhindered by external customizations. Customizations that integrate directly with runtime processes have the potential to cause general denial of service conditions for an entire SharePoint property. Customizations that directly integrate with the platform might not cause issues in the present, but are later discovered to be significant obstacles to moving or upgrading a farm or site.

Ideal #3: It uses SharePoint functionality as much as possible

This may seem to go without saying, but often people recreate the wheel. Creating custom functions for out of the box features directly affects a system’s ROI by increasing the investment required and potentially its ongoing cost. SharePoint is a rich resource. Ideal customizations marshal the available resources to full effect.

Ideal #4: It depends on things other than SharePoint as little as possible

Sometimes people try to fit a square peg into a round hole. The more a customization requires things other than SharePoint the more likely a customization is a square peg. Of course it is often necessary in the real world to integrate with other systems and it is even more common to use third party components. Just the same, a customization that meets Ideal #1 by using nothing but out of the box functionality is, by definition, an ideal SharePoint customization.

Ideal #5: It cedes runtime control to SharePoint as little as possible

While an ideal customization makes deft use of SharePoint’s functionality it should do so in a way that works independently of SharePoint. For example a customization that fully controls an area of a page is better than one that consists of many hooks into SharePoint by depending on particulars of the HTML generated by SharePoint. The former can function as an atomic unit, the later can break any time the details of the page deviate from the original. It is better to provide an entire form than to hook into a button’s click event based on the ID of the element or a class name on the day the customizer did View Source on a page.

Ideal #6: The other things it depends on are provided via supported mechanisms other than directly editing SharePoint Master Pages or ASP.NET files

Meeting Ideal #1 may require you to directly edit SharePoint master pages or ASP.NET files. Doing so has a cost and it potentially requires ongoing maintenance. At times it might violate Ideal #2 if the customization lacks as of yet un-invented elements that later will come to be expected. As it stands, SharePoint provides a large number of supported integration options out of the box including Web Parts, custom actions, and a wide variety of API’s. Be aware that some supported mechanisms are counter to Ideal #5.

Ideal #7: Runtime or configuration faults in a customization can only impact the customization

This one is simple. If your app breaks for a user does it break SharePoint? Breaking SharePoint includes denial of service conditions at the server as well as client side problems that prevent pages from rendering or operating as intended. It is possible to meet Ideal #2 but not this ideal. For example, introducing a syntax error into JavaScript in the body of the default master page will not interfere in any way with the underlying platform but will still break a site.

Ideal #8: It is manageable and governable

Once created or deployed, an ideal customization is manageable and governable. It offers appropriate configuration surfaces and respects SharePoint’s policies, throttles, and security. It isn’t obscure, but rather easily discoverable. It is possible for it to be known and accounted for to the degree that is required. One example of a customization that is not ideal in this regard is a user custom action created by hand. At present out of the box there is no way other than interrogating the SharePoint object model via one of many APIs to determine a user custom action is present or modify the user custom actions associated with given object. Conversely, a customization that includes the same user custom action can be ideal if it includes the same custom action as long as the customization provides appropriate management features such as the ability to remove the action if the customization is removed or disabled.

Why is this important?

We have more options available for creating SharePoint customizations today than we’ve ever had before. We need a framework to help evaluate these approaches to make good design choices. Over time I will be writing about our designs here at InstantQuick. IQApp Central supports a number of different design approaches. I designed it to be respectful of people’s decisions by playing well with SharePoint. Still, there are some designs I encourage that I’d like to teach you about. When I say that something is better I’d like to do so in the context of concrete criteria. That way, when someone disagrees it is easier to engage in productive dialog!

–Doug Ware