Tag: Policy

Integrating Open Source Software and Components

Over the past few years there has been tremendous progress in making many components and solutions available in the open source markets like CodePlex, SourceForge, or even individual blogs and sites.  Many of these are community driven projects supported by individuals, with some by commercial companies.  For some reason many companies avoid or strictly limit allowing these solutions to be installed or used.  When approached properly I think these solutions should be considered.  This article will cover the advantages as well as outline an approach to make take when evaluating which solutions to install and how to test them.

Advantages

The first advantage of implementing any solution is that it should make it much quicker to solve a business problem.  In some cases it might be a complete solution, like commercial software components, but at the very least it should act like an “accelerator” offering you a springboard to the final solution.  One advantage that it has over commercially packaged systems is that you have the source code in case changes, additions, or fixes need to be made. 

Another advantage is that it can expose the development team to different coding techniques so that they can better address similar problems in the future.  Microsoft has been providing sample databases and applications for years for this very purpose.  People tend to learn more by seeing examples in action versus class diagrams.

Review Project Status and Activities

Not all solutions are of the same quality and grade.  In some cases there are a few quick samples while in others there was a more formal project with full QA that has gone through multiple release cycles.  It is therefore important to review things like the product status and release number.  It is also important to review the Issues log to see how much activity there is and how quickly issues have been addressed.  You can typically get a good idea about how widely it is used.  In some cases you may be familiar with the developers which offers the advantage of discussing questions and issues directly with them.

Approach to Testing

To increase your chance of success and mitigate risk, it is important to always fully test the components to meet both functional and performance testing.  With commercial software the expectations are normally pretty high, but I would approach this as if a member of the project team produced it even if no changes were made.  This includes specialized testing like the “DisposeCheck” tests typically done to custom code that interacts with SharePoint’s API. 

Final Notes

When expectations are properly set, and the solution is fully reviewed and tested, including these open source solutions can contribute to the team’s ability to effectively deliver solutions quickly.

Related Articles

Managing SharePoint Solutions and Extensions

One of the great things about SharePoint today is the incredible traction that the platform has gained. The depth and range of solutions now offered by vendors along with open source solutions offered by the community really is amazing. It was a different place when I first installed SharePoint Portal Server 2001 back in early 2002.

Browsing the CodePlex I often feel like a kid in a candy store. So many great solutions, I cannot wait to install them all! Well not so fast, it might be a good idea to take a step back and consider the consequences.

Deciding What to Install
One key to maintaining a well run environment is to have a process in place to review, approve, and manage customizations. This should be part of your formal governance plan, but if you do not have one do not let that stop you from looking at this particular topic and working out some plans.

Special care should be given to non-commercial solutions. They should always be tested in a non-production environment before being deployed to your production environment. When downloading community code, be sure to take notice of who is contributing it and what the official release is. CodePlex for example does a great job of showing build info and release notes. If an item is marked as Alpha or Beta it probably has not been put through rigorous testing yet. If you want to use it then make sure you are comfortable with the risks and test it in your environment.

Testing Environment
Your test environment should be as similar to your production environment as possible. You do not necessarily have to put it on the same quality of hardware, but the configuration should be similar. It is critical that the patch levels are the same. On this note, you should be testing any KB Patches, MS Cumulative Updates, or Service Packs anyway.

Make sure that the test environment also includes the full catalog of Solutions, Web Parts, and other customizations. This is important because it is possible that one might conflict with another. Unit Testing is not enough, you will want to see how it will react and interact with your environment.

Potential Problems or Conflicts
Depending on what functionality the solution provides, the problems or conflicts can range quite a bit. Knowing what is installed is a good start.

While there is a chance that something could break independently, most of the issues I have seen came from trying to migrate, patch, or upgrade a site.

Site Migration – When migrating a site from one environment to another, it can be a pain to find out half way through that you need to install additional site templates or web parts on the target server.

Patch – When completing the installation of a Patch, Cumulative Update, or Service Pack you normally have to finish the upgrade by running either the Configuration Wizard or the PSConfig command line app. This can be a pretty stressful exercise, and no fun comes from seeing it fail along the way. I have had customizations cause problems here, particularly when changes were made directly to the web.config file as some solutions require. Having your documentation on hand will help you get through the mess and cut down on the time it takes to complete the upgrade.

Future Versions – You also need to consider the likelihood that the solution will be maintained going forward. When I made the jump from WSS 2.0 and SPS 2003 to the current version WSS 3.0 and MOSS many of the solutions I had been using did not make the jump. Some of it was because of the code base changing from .NET version 1.1 to 2.0 and some of it was because Microsoft added parts of the functionality to the platform so vendor no longer wanted to support the products. End users are not necessarily going to care why they do what they used to do, they will only care that they cannot do it. Mitigate the risk by communicating to the stakeholders the potential problems.

It has already been noted that Service Pack 2 will include an upgrade readiness check to help identify any potential problems upgrade to the next version. I would recommend taking the time to go through this check after SP2 is installed, and then checking it again after you install any new solutions before making the jump to the new release.

Summary
By putting together a plan to review, test, and approve add-on solutions you will decrease the likelihood of problems in your environment and decrease the time it will take to respond to issues when they do come up.

SharePoint Customization Policies and Change Control

This post will cover different forms of customization, discuss the need for IT policies that support customization, and then provide a recommendation for how to manage the customization through change control processes.

What is considered customization?
There are different types of customizations and different ways to apply them. They can include custom styles, MasterPages, Web Parts, Custom Forms, Site Definition or even applications built on top of the API.

Bad customizations are applied manually by adding to or altering system files on the server. These changes are not saved into the configuration database which can cause problems when applying system patches or upgrades. It can also make it much more difficult to add an additional server to the farm as those changes have to be manually applied again. Therefore this should never be done in a production environment.

Well built customizations are deployed using SharePoint’s robust deployment framework for Web Parts and Solutions. This not only produces repeatable results, but it also helps keep multi-server farms in sync and allows those customizations to be pushed out automatically to new servers joined to the farm. This method is also much less likely to produce problems when applying patches, updates or even upgrades.


SharePoint Success without Customizations?

While I believe strongly that there is a lot of value in the base solution, I think that SharePoint is set apart by the expandability and integration options. This is what can take it from an ad-hoc workgroup solution to an enterprise platform.

Too many IT shops have taken a No Customization stance when it comes to Enterprise Software. They will quote ballooning implementation costs, reliability of the changes or the difficulty that exists in performing normal version upgrades. Many of these are valid issues to some degree with packaged software, but it is not an irrefutable law. SharePoint is a platform that is intended to be molded to meet an organization’s needs, and customizing it is not the same as rewriting core sections of an ERP system.

In more than on instance I’ve seen SharePoint workflow projects move forward with the decision that no “code” can be written, which means they cannot use Visual Studio or create custom actions. The alternative is for them to use SharePoint Designer to create those workflows. While that may be a good idea for small or simple workflows, there are limitations, but even worse there is no reusability in their work. If something similar is needed somewhere else it has to be recreated.

By making a unilateral decision that no customizations can be made, you are handicapping the system and limiting the value it can deliver. Business and IT leaders need to consider this before making any policy changes.

What about Change Control?
In organizations where there is a Change Control policy in place, it is important to categorize the types of changes. I would advocate grouping changes into the following groups Content and Site Configuration, Packaged Code, and System Level Changes.
Content and Site Configuration – This includes using the toolset to add and update content in lists and libraries along with the creation and design of Sites, Lists, and Libraries. These tasks should not require approval.

Packaged Code – This includes the installation of custom or third party web parts, solutions, workflow actions and templates. Since these packages can possibly cause harm, and should be part of the system’s documentation, it should pass through the Change Control process.

System Level Changes – This includes adding an additional server to the farm, changing a servers’ role, reconfiguring personalization features or rebuilding the Shared Service Provider. These changes can possibly have a huge impact on the entire system. It is important to capture the details of those changes in the documentation, and also make sure that all stakeholders are aware of the changes being made.

%d bloggers like this: