SharePoint Customization

Today we continue our serialization of excerpts from the forthcoming eBook, Managing and Implementing Microsoft® SharePoint® 2010 Projects (Microsoft Press) by Geoff Evelyn.

from Chapter 8

When to Customize SharePoint 2010 and Some Reasons for Doing It

When implementing Microsoft SharePoint 2010, the key to success is to keep things simple. In my experience, the business representatives on the team, who are excited about SharePoint from your demonstrations and SharePoint project mantra, are likely to go for looks as the top priority when developing an internal SharePoint presence.
There are many references and lots of information online and in paperback concerning branding, customization, programming, and automation. Coding enhancements in SharePoint are also a major plus because they show the level of modifications that can be applied to this technology, but they can also bring countless disadvantages if not carefully controlled and prioritized.

Implementation of SharePoint invariably includes customization, additions, modifications, and enhancements. You must be sure to prioritize these as part of user requirements, client requirements, or both. Your SharePoint 2010 Project Plan needs to package this SharePoint customization work into Work Breakdown Structures (WBSs) and apply them as part of the Design and Build phases of the project.

Even if you are not going to customize SharePoint to the point that it requires a developer to add functionality, you must make certain the client understands what is required in terms of technical and human resources to customize SharePoint. Acquiring the right amount of equipment and the correct personnel to carry out the relevant tasks is absolutely vital for success.

When faced with implementing SharePoint, I am usually gifted with a horde of development requirements from the customer. Sometimes, the customer is familiar with SharePoint in detail and has seen demonstrations. The Web developers in the company have also seen it and already want to modify, customize, and enhance it (usually with comments such as, “SharePoint doesn’t do X. I don’t think that’s right, so let’s make it do X, Y, and Z.”). These comments might reflect some good considerations, but to customize SharePoint to carry out some developed functionality means its application programming interface (API) must be fully understood.

As a good example of how a customization process can go wrong if it’s not properly controlled, I’d like to share a story. I received a call from a client who wanted his company’s SharePoint system re-evaluated. Apparently, SharePoint had been implemented by a Windows Server administrator, and the implementation strategy was “Just use it.” When I arrived on the scene, I was greeted by a Web developer, who said something like the following:

“I am a Web developer and know CSS and Java. I’m going to change how SharePoint looks because it does not look pretty. It’s a Web site, so it should not be difficult to brand it and make it look different and work better.”

I suggested it might be a better idea to learn SharePoint development and understand the models under which SharePoint can be customized. He disagreed, stating that he could have branding done in no time at all.

So, the following day, I came across the same Web developer, and he says to me, “I can’t do it. SharePoint is rubbish.” I replied, “No, you have not understood the platform. Web development and SharePoint Web development are not the same.”

The developer learned the hard way that SharePoint Web development is much more than using your understanding of HTML and cascading style sheets (CSS). It’s requires you to have an understanding of ASP and the SharePoint API. (Web developer skills are discussed in Chapter 5, “Building Your SharePoint Team.”) In this instance, I suggested to the developer’s boss that the developer be sent through training, ending with taking the Microsoft Certification test to prove he can handle SharePoint development.

See Also
Good SharePoint Developers really know their stuff. Typically, they possess Microsoft Certification in Application Development in SharePoint. For more information about what this entails, you can read an overview of “Exam 70-573, Microsoft SharePoint 2010, Application Development,” at http://www.microsoft....aspx?ID=70-573 and “Exam 70-576, Designing and Developing Microsoft SharePoint 2010 Applications,” at http://www.microsoft...aspx?ID=70-576.

The key is that SharePoint development needs to be controlled and managed with a great deal of care. SharePoint 2010 is feature rich, with an extremely detailed object model that covers all facets of the platform.
Let’s begin with a bold statement:

A SharePoint developer is not a high-priority requirement of a new SharePoint implementation if the SharePoint implementation does not include modification through programming.

See Also
Take a look at Chapter 5 to see the kind of people required to make SharePoint become a successful reality in an organization that has never used SharePoint.

The need to “brand,” for example, will come from user requirements, which are part of the Plan phase of the project. In the Plan phase, you define the user requirements, which might include branding. If that is the case, the tasks related to branding are packaged so that they are carried out after implementation of SharePoint, because you must first ensure that SharePoint is available.

In the Build phase, you create the SharePoint platform. If you have a user requirement to customize SharePoint, the Build phase is where the development tasks take place.
In the Deploy phase, the client signs off on the SharePoint implementation. Again, if the user requirements demand customization of SharePoint, you must have separate sign-offs for whatever customization takes place per user requirements.

Branding (for example) must go through user acceptance testing, but it is not the key requirement in getting users educated and trained in working with SharePoint if they have not used the platform before. Making SharePoint functional is all about meeting the users’ information and management challenges. That does not include the immediate customization or modification of SharePoint core features. In short, yes, customization is required and the customization requests must be prioritized before that work can take place—but customization is not 100 percent vital to making SharePoint a success.

That said, as part of the SharePoint implementation, you must devise a development platform or logical approach to providing customization when a timeframe is given for customization work to be done. This chapter will describe a design for a SharePoint 2010 development environment and how it could operate. This model assumes a development platform is built in-house—in other words, that there is a distinct possibility that SharePoint 2010 development will take place within the organization. If there is a SharePoint test environment, a SharePoint user acceptance environment, and a SharePoint production environment, they represent a good level of SharePoint resources for providing a development environment as well, which equates to a fourth environment.

In the past, development environments were restricted because, to build components, an increased level of resources would be required by the developer. SharePoint 2007 could be installed only in a Windows Server environment and not to the desktop. Developers were given either virtual environments (using Virtual PC or VMWare, for example) or, in some cases, a separate desktop to build SharePoint tools on. This arrangement could be difficult to manage and control because, generally, it was considered time consuming and sometimes problematic to connect local resources to the SharePoint virtual instance (for example, mapping local drives, USB drivers, external CD ROMs, shared drives, and so on).

Development Environment Options

A development environment is a sandboxed environment. The term sandbox is commonly used in the development of Web services to refer to a mirrored production environment for use by external developers. Typically, a developer creates an application that uses a Web service from the sandbox, which enables developers to validate their code before migrating it to a staging environment so that it can be tested by users before being published to the production environment. Sandboxing is used by Microsoft, Google, Amazon.com, PayPal, eBay, and Yahoo, among others.

In SharePoint 2007, there are three development environment options. (They are listed in the “SharePoint 2007 Development Environment Options” section that follows this one.) In SharePoint 2010, four options are available. (They are listed in the “SharePoint 2010 Development Environment Options” section.)

See Also
If you are keen on finding out more information about running a SharePoint 2010 development environment on Windows Vista, Windows 7, and Windows Server 2008, go to http://msdn.microsof.../ee554869.aspx..

SharePoint 2007 Development Environment Options

The three options available in SharePoint 2007 are as follows:

• Remote access to a shared SharePoint development server  You can use this option if your project includes people who do not need their own SharePoint server—for example, designers and technical testers (those who work with the developers and test their code).

Note
There are logon restrictions to bear in mind. Specifically, a maximum of two administrators can be logged on to the server at any one time—either two logged on remotely or one local and one remote administrator. And this assumes that different accounts are being used to log on. This means the same user cannot log on locally and remotely simultaneously.

• Run a local virtual machine (VM) and use “Boot to VHD (virtual hard disk)”  This is a recommended approach. It causes the most hassle, but it provides the best performance. (Note that this will work only if Windows 7 is the host.)
  
• Give every developer their own physical SharePoint Server There are many reasons why this is not a good idea; clearly cost is a big drawback. SharePoint 2007 can be installed only on Windows Server and most developer machines do not run Windows Server as the host operating system. Tweaks to install SharePoint to Windows Vista were available, but they were considered risky because your development environment does not fully reflect the production server.

SharePoint 2010 Development Environment Options

Here are the four options available in SharePoint 2010:

• Remote access to a shared SharePoint development server You can use this option if your project includes people who do not need their own SharePoint server. The disadvantages of this approach are the same as described in the preceding 2007 development environment options.
  
• Run your own local virtual machine If you choose this option, there are two approaches you can take:
  
• Use either Hyper-V or VMWare/VirtualBox Create a virtualized version of SharePoint 2010 running using Hyper-V or VMWare within the desktop environment.The 64-bit requirement means that you cannot use Microsoft Virtual PC, so you have to use either Hyper-V (which requires a Windows Server host) or VMWare/VirtualBox.
  
• Use “Boot to VHD (Virtual Hard Disk)”  This approach works only if Windows 7 is the host. Install SharePoint 2010 on your Windows 7 PC. (This is not recommended unless you are a competent developer who knows that the environment needs to be similar to or the same as the production environment.) In this case, you are not fully representing the production server because you are running Windows 7 and SharePoint 2010 is running on Windows Server 2008.