February 5, 2012 Leave a comment
Well, quite hard actually.
In my job, I am often engaged in design review and troubleshooting assignments, and I have met quite a few clients that have different issues with their SharePoint-based solutions, such as performance, bugs and maintainability issues. These issues unfortunately prevents them from utilizing the platform to its maximum potential and gives SharePoint a bad reputation both within and outside the organization.
In this post I would like to spend some time discussing what I believe are the criteria for a high quality SharePoint solution and some considerations that has to be made before moving on developing and deploying the solution to ensure a greater chance of success.
1. It just works!
The first obvious quality criteria is of course that the solution works as expected from a functional point of view – without bugs that prevents users from performing their daily tasks. This is true for all IT solutions, independent of the underlying platform. In addition to skilled developers and product specialists, you need a proper QA process to ensure this. If the project budget or timeframe doesn’t allow for proper testing, the scope of the project should be cut or you might even consider if the project should be carried through at all.
However, in my opinion, there is more to quality than just having a solution that works as expected.
2. The solution solves the business problem in a cost effective way
While SharePoint provides a fantastic array of features and services out of the box, it can be quite tough sometimes to adapt it to requirements that are not quite in line with the standard functionality. Designing a solution that solves both the business requirements, while being cost effective and maintainable is quite often a challenge.
An important key to making the right design decisions is really try to understand the problem you’re trying to solve for your client, not just reading and following the requirements specification exactly. In SharePoint there are often many ways to achieve the same goal and as a solution designer, you should always try to find an approach that solves the clients problem and at the same time is cost effective to develop and maintain. As some wise person have said before – the requirements are always open for negotiation.
SharePoint has a huge amount of features and services built into the platform – good knowledge of these and knowing how to apply them for solving different business challenges is crucial. It’s equally important to know the limitations of SharePoint – it’s not the right choice for everything!
3. The solution is easy to maintain, develop and troubleshoot
The flexibility of SharePoint can actually become quite an issue once the solutions has been deployed and up and running in the production environment. While customizations with SharePoint Designer can be made without much effort, doing proper QA and moving the changes from a test to production environment is not as straight forward as one could hope for. It’s very important to keep these issues in mind when defining the policies for how and when changes should be made.
In my opinion, the way Microsoft is marketing and selling the SharePoint platform can be a bit problematic sometimes. Need to pimp up the look and feel of your intranet? Easy, just fire up SharePoint Designer and do it! Sounds great, eh? Who wouldn’t want to be less dependent on those expensive consultants and specific developers who are the only ones that knows how to do even the simplest change in the systems?
As many of us are painfully aware of, the reality is not quite that simple, at least if you consider your application to be critical or at least somewhat important for your business. If that is the case, doing changes directly in your production environment without a proper QA and change management process is just unacceptable. I certainly hope that Microsoft provides us with better guidance and better tools for moving changes and customizations between environment in the next version of SharePoint.
What needs to be done before every SharePoint solution is deployed to production is to find the right balance between flexibility and manageability. What changes needs and can be delegated to site owners to perform and what needs to be done by developers? And how does the change management process look like in your specific organization? There need to be very clear guidelines for this in place, and the right way to go depends on many factors, such as how business critical the application is, the amount of custom code that depends on i.e. certain columns and lists being in place, where the responsibility lies if something goes wrong and end user knowledge of the platform and tools.
Hopefully, there is a governance plan in place that addresses at least some of these issues.
And also, if your solution consist of a fair amount of custom code, good coding standards and design principles needs to be applied, as in any type of development project.
4. The solution is easy to upgrade to future versions of SharePoint
The upgradeability factor is always important to keep in mind, but it’s becoming more and more important as the next version of SharePoint (SharePoint 15) comes closer to public beta.
In general, the SharePoint Team puts a lot of efforts to ensure the backwards compatibility of the platform. Upgrading an out of the box size or a site with a few customizations to the next version of SharePoint is often a very straightforward process (at least from my experience from upgrading solutions from 2007 to 2010). UI customizations and custom developed components will add additional effort though. This is particularly true for CSS “hacks” on top of the out of the box styling, so it’s wise to minimize this as much as possible if an upgrade to the next version of SharePoint is on the roadmap during the expected lifetime of the application.
Make sure that all customizations and changes in your SharePoint environment are supported and in line with best practices.
5. The solution has a low impact on the SharePoint farm
It’s important to keep in mind that SharePoint farms are shared between many applications and sites and typically grow significantly as more and more users adopt the platform. When building full trust solutions, it’s extremely important to make sure that your code performs well and has a low impact on the shared server resources so it doesn’t risk sinking down performance for other applications hosted in the farm. Sandboxed solutions are less of a problem, since they run in isolation and the resource usage is limited by quotas, but the limitations of the sandbox often forces developers to go for a full trust solution.
Performance testing is the key to ensuring this – it’s basically the only way to know for sure that your solution performs well in a real world scenario. Take your time to set up and run scenarios with both realistic load and volumes of data. It’s well worth the time to learn and master a good performance testing tool such as that provided with Visual Studio.
During the performance tests, make sure to observe the CPU and memory usage of both the SharePoint and SQL Servers to ensure the CPU usage is ok and there are no memory leaks. You should always aim for good response times, as well as an impact on the farm that’s low enough for allowing growth over time in both usage and number of applications. If the results are not good enough, consider performance optimization and/or scaling up the farm before deploying to production.
I hope that some of you might find these points helpful, and hopefully don’t intimidate you too much to refrain from taking on the challenge. Building successful SharePoint solutions might be challenging, but it’s well worth the effort to try to get it right when considering the great impact a good solution can have on your business!