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?
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.
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.