Using third party tools in SharePoint

Growth in third party tools

I have worked with SharePoint as a framework since its first full scale release in 2001. Since then I have witnessed the steady growth in third party tools to provide either enhancements to weaker functionality provided ‘out of the box’ (OOTB) by SharePoint, or new features to complement existing core functionality.

Most third party utilities or web parts started to come out with the previous release of SharePoint (SharePoint 2003 & WSS V2). But with the release of Microsoft Office SharePoint Server (MOSS) 2007 (and WSS V3), there has been an exponential growth in a whole variety of end user or administrative focused tools.

Entire businesses have in fact emerged over the last few years with their sole business model aimed at meeting the clear demand for list aggregators, backup & migration utilities or reporting enhancements, to name but a few. Not forgetting the MVPs, Open Source efforts over at Codeplex and the work by specific individuals, often referred to in posts and blogs within the SharePoint community.

Growing pains

The growth in third party tools and expanding SharePoint community, whom also provide a vast array of often ‘free’ downloadable utilities, means businesses deploying SharePoint have never been better served and can arguably gain even more out of their investment in by using the latest Microsoft SharePoint technology.

However, my experience over the last few years with third party utilities, in particular with the very nature of new and often immature utilities and add-ons, has led me to believe that these tools can be fraught with issues for the unwary.

Issues encountered include:

• Code developed and tested in a MOSS environment, not specifically WSS (but released for both types of platform anyway, causing key functions purported to be available, that fail to work as they are not supported or available in WSS)
• Tools and utilities often unsupported and provided for download on an ‘as is’ basis
• Poor documentation to allow for effective and safe configuration and setup
• Little or no testing prior to release, hence tools are ‘buggy’ and unstable
• Unproven usability and functionality across load balanced environments
• Poor or non-existent end user support.

Even some of the better known third party tools on the market have, in my experience, been quite poorly developed, therefore the development companies are unable to respond to even basic support related queries or product bugs. The tools and utilities often have been clearly developed on and for MOSS environments, but advertised for WSS as well, with the originating developers knowing very well there will be problems with its lesser feature set. I suspect these are just growing pains of small businesses and hopefully their development processes and support services will improve over time.

Is your selected third party product really the right choice?

It is clear many of the tools available are extremely useful, otherwise they wouldn’t have been created to fill a gap in the first place, or sold so well. I do think however that businesses, or rather inexperienced individuals, often forget (or just don’t know) to consider fully the issues involved in deploying 3rd party products that have been developed outside of certified Microsoft and other core platform environments.

What was once your relatively clean, core and stable environment has now been ‘dirtied’ by dlls’, web .config changes and registry settings. This provides you with the risk of a potential level of instability that is unacceptable, resulting in endless hours trying to troubleshoot and resolve issues that could have been avoided in the first place. Hence embark on deploying such tools without the proper due diligence at your peril!

Questions regarding third party tools I would suggest you consider are as follows:

• Supportability – Does the organisation provide timely updates and bug fixes to the components? Will it be supported in 64 bit platform? Does it need to and actually work across different browsers? What do others say about the product in the community? Who will pay for supporting it internally? What if the person whom installed it leaves?
• Code updates – Do you need and hence have access to the source control for your developers to make and support changes in-house? What is the roadmap for product updates following service pack updates issued from Microsoft? Will the product be affected by service pack updates from Microsoft?
• Robustness/Stability – What type of testing has been carried out prior to release? Was the code developed on both MOSS and WSS platforms? Has the product been tested on load balanced farms? Does it work across multiple farms? Are there any performance issues on lists or indexing? Does it impact on existing OOTB features or other third party tools deployed? Will it affect existing pages and data? How is it installed, WSP, STP and or DLLs?
• Scalability/Security – What level and type of security access does it need in your farm? Will it scale as your deployment grows from single to multiple servers?
• Cost – What are the overall costs for deploying third party tools on your live, pre-production and development environments? What is the true annual cost of support?

Ultimately then, organisations can and do gain a tremendous amount of value for money from their investments as long as they invest wisely. However, I think a sizeable amount of businesses will have had numerous issues to do with performance, functionality, reliability or stability when using third party tools.

Due diligence

To reduce your exposure to such issues when purchasing third party SharePoint tools and utilities, you should carry out an appropriate review and justification process with these products.

I recommend the following as a guide:

• Understand in detail what it will take to provide an evaluation & test of the third party tool(s) assuming you will set up an separate environment to do it
• Document a list of business and or technical requirements you need to fulfil, matched by a list of product features stated. Compare & evaluate
• Review if possible on ‘pre-production’ evaluation environments in as close to a ‘like for like’ scenario as you can afford (UAT preferred)
• Read the specialist SharePoint forums and appropriate feedback from others who have used a particular product before deploying and essentially gauge a view on others experience of using the product
• Ensure you have a backup/restore approach that works (and has actually been tested), if you need to rollback following a tool/product deployment due to issues or other constraints
• Ensure you have considered your pre-production and disaster recovery environments in your planning, testing and budgets
• Consider documentation needed to not only install, but to provide support to your helpdesk team responsible for support and overall governance
• Before you embark on the process of introducing 3rd party tools really do look at the feature set provided out of the box and understand if minor changes to existing requirements can be made to avoid introducing such products or bespoke changes
• Where a third party tool is to be made available to end users, ensure the appropriate business testing and training is planned and made available in advance of any trial or pilot deployment.

Conclusion

The simple reason for this post is to make you aware of the dangers of introducing third party tools into your SharePoint environments and to recommend a series of steps to take to help you understand and decide if a third party tool is right for you. Third party tools can and do add real value, but be sure that these tools do not interrupt your core SharePoint environment.

In summary, you must ensure that you have some factual assurances that deploying any third party component is truly going to save you money or provide some other worthy and tangible benefit.

Measures must also be taken by you to ensure that uncertified tools are not going to damage your existing core SharePoint environment and that they are manageable and acceptable costs in terms of support longer term.

Finally, as I posted in the SharePoint Magazine recently, you potentially ‘pay’ for your bespoke changes and arguably 3rd party tools, to some degree, several times over. Consequently, do your homework before you download that evaluation web part and press setup.exe!

Regards,

Andrew