Friday, October 10, 2014

The High Cost of Deep SharePoint Customizations


The Challenge
SharePoint is a powerful and diverse enterprise content and collaboration management tool.  As such, it can quickly generate sites, supporting information, and dynamic lists to support various business processes.  However, the advantages of using a tool such as SharePoint can be negated when deep customizations are part of the business requirements for the SharePoint specific solution. 

Optimizing the usage of SharePoint within your organization is going to have to include the ability to determine which processes are SharePoint support appropriate, and which processes require other alternatives.  How do we determine that?  How do we determine, up front, whether the effort put into a SharePoint solution is the best usage of our time, or whether in fact a custom development tool, such as .net, or a custom site developer, such as WordPress, would be a better answer?
 
Out of the Box vs Custom Development
The line that divides low effort from high effort solutions in SharePoint is the amount of required functionality that can be gleaned “Out of the Box”.
“Out of the Box” means any SharePoint configuration that can be done with SharePoint itself, or with SharePoint Designer’s built in tools.  So, for example, you have a customer list.  “Out of the Box” we can create and populate that list, and provide that information in one of a number of SharePoint provided views.  In designer we can further modify views and sorting options for custom data extraction using the built in features on the office ribbon.

If however the functionality we require means changing markup, that is, the html/xml/xls components that make up the page, then this is now deep customization.  We are bypassing the built in abilities of designer and SharePoint itself by creating custom markup to meet our required functionality.

Out of the Box” as far as design is concerned is using built in master pages or themes, or even importing a custom master page and applying it.  As soon as you move into custom styles, custom master page markup, and dynamic elements such as Javascript or JQuery, you are once again deep into customization.

The more features, functionality and appearance required by the business process that can be covered by Out of the Box functionality, the less your effort to make those elements work is going to be.  Deeper customization greatly increases the amount of time needed to meet end user requirements.

The simplest way to determine if something is "Out of the Box" is this question, "Did you push a button to do it?".  If you pushed a button on SharePoint itself or within designer to configure, its out of the box.  If you had to make markup changes, it is deep customization.

The Difference, Quantified


I am in the fortunate position of being able to look back on 7 years of custom solution development to see in a very literal sense the difference in development time the two approaches can take.
I took a look at two system that were very similar in basic functionality.  These two systems both have:
1.       External Content Types
2.       External Lists
3.       Internal Lists
4.       Workflows
5.       Site pages

One of these systems, a vacation request system, was developed solely using out of the box components.  The end result has the default appearance of lists and items being used, and built in view abilities and permissions used to control the look and feel of the data exposed to the end user.
The total amount of customization time from start to completion for the vacation request system was 6 weeks.
The second system was, at its core, almost functionality identical.  External lists were used to pull information from an external system, internal lists were used for support, workflows and site pages are used to present information.
Except, the second system is very different than the first in two key ways:
1.       The system was designed using wireframes to finalize look and feel without SharePoint specialist consultation.

2.       The functionality of the system is highly constrained to the wireframes; there was no flexibility around controls and functional flow that allow tweaking of the design back to a more SharePoint centric default control flow.  The wireframes are to be replicated exactly.

This process is more typically associated with custom development.   How long does it take to develop a system in SharePoint this way?  How much extra time does customizing SharePoint to this level take?
The total amount of development time for this system was 28 weeks.  How could a system that is nearly equivalent in core functionality take 5 times as much time to develop as a similar system?  Let’s take a look at where the time was spent.


The “Out of the Box” System


The out of the box vacation request system described above uses no customized markup for functionality, and no customized look and feel.  So, the time spent on the system configuration is as follows, 100% of configuration time using SharePoint and SharePoint Designer to develop the system using out of the box components:

 



The Customized System


The customized system was instead configured from web based wireframes describing functionality in detail.  Configuration consists of working through the required functionality, accomplishing as much as possible using Out of the Box components, and then using custom css, Javascript, JQuery and xsl to further modify look and feel and functional flow.
The time spend on this system was spent in three areas:
1.       Out of the Box configuration
2.       Custom functionality supporting user access and application flow.
3.       Custom look and feel.
How much time was spent on each?  If we look at the pie chart below, we can see the amount of time being spent on Out of the Box configuration is only 30% (8 weeks) of overall time.  Custom functionality takes an additional 30% (another 8 weeks) and applying style based changes, ranging from custom data view web part xsl to deep master pages changes has taken an additional 40% of time (about 12 weeks). 


 
As you can see by this Chart, imposing design and functional restrictions onto a SharePoint system comes at a high cost.  In some cases, extending the amount of configuration time by 4 or 5 times over what a core system would have been to develop.  In this case, it would probably be more efficient to design the same system in .net and embed the application in SharePoint after the fact.

Achieving a Balance


As you can see from the above two examples, imposing functionality and look and feel changes on SharePoint that are not “Out of the Box” can have a significant impact on the configuration time of any SharePoint custom solution.
So, when working with clients, we have to be very aware as SharePoint specialists what SharePoint can and can’t do out of the box.  And be able to advise during the design phase on what amount of effort various components will take.
As SharePoint Specialists, we typically prefer using a process where the client describes the business process(es) they want supported, and we then align SharePoint tools with those requirements to the best of SharePoints ability.  This way, the client is not tied into a specific interface or look and feel.
However, in some cases, this is not the situation we are placed in.  We are instead provided with a client who is more used to a traditional development model, such as .net, or web tool, such as wordpress, and so therefor is used to providing detailed interface wireframes and having a reasonable expectation of delivery within a predictable amount of time.  In this case, we have to be sure that the client is made aware of the cost of these level of changes, and we even have to be prepared to say:
“SharePoint is not a custom application development tool.  Out of the box, I can create a system that will support your business process effectively and well.  However, we have to accept that there are certain limits to interface and functionality that are provided by the platform.  If we decide that the required functionality and look and feel are far enough outside of the “Out of the Box” sweet spot, then perhaps this should not be a SharePoint developed solution.”
Ultimately, we will only see the rapid solution development advantages provided by SharePoint if we can meet most of the client’s needs using the Out of the Box tools.  If clients are insistent on specific functionality and look and feel, then the best solution may be to steer them to custom solution development, the second best and considerably more time consuming solution is to attempt to implement it in SharePoint anyway, making it very clear to the client the significant additional cost this will entail.
SharePoint is not a custom application development tool.  If the out of the box components do not meet the majority of your needs on a SharePoint system, then it may not be the best way to achieve your required solution.
Knowing the difference between a couple of tweaks and major customization however is key in being able to correctly set client expectations on configuration time duration.  Any time the client defines specific look, feel, and functional flow, we are probably moving into the major customization area.
I would always advise my clients away from deep customizations within SharePoint to allow more rapid application development and focus on aligning what SharePoint offers with what they need to support their process.  And would also advise them that custom application development using a product such as .net may be better suited and faster in development for highly specialized systems.  If, knowing all of that, they are still prepared to accept the costs, then we move ahead with custom configuration.  At least here we can avoid surprises and sticker shock when they see the cost of the specialized system, and allow them to make an informed decision up front.