Over the past few years, the friction that’s developed between IT administrators and developers has diminished somewhat. But not everywhere.
In general, the adoption by businesses of process models such as IT Infrastructure Library (ITIL) and Capability Maturity Model Integration (CMMI) has increased the maturity of their operations. But one thing that has not improved is collaboration between administrators and developers in the delivery of a SharePoint offering. This is a sad irony in regards to a product that’s designed to foster collaboration.
Part of the reason for this state of affairs is that SharePoint is still relatively new and not well understood. More significant still is that SharePoint is not typically used out of the box as is. It’s a product designed to be enhanced by custom code. In this respect, SharePoint is much more than a just a product; it’s also a technology platform.
What does this mean? Let’s compare SharePoint to Exchange Server for a moment.
Email is ubiquitous, and the way that it’s used varies little from organization to organization. Although email programs have many important configuration options, you rarely use custom code to modify how the program looks or works. If you have Microsoft Office Outlook and Microsoft Exchange Server working correctly, you’re set.
SharePoint is a very different story. The way in which it’s used varies widely, and the out-of-the-box product sometimes falls short of actual business needs.
Although SharePoint is massive, it doesn’t do everything. This means that custom code is used to enhance the product by adding features such as custom Web Parts or custom workflow solutions. In some cases, a new look and feel and new business rules are used to mold SharePoint into something quite different from the RTM version of the product.
In fact, SharePoint is a powerful technology platform that’s designed precisely for this sort of customization. The ability to plug in custom code is what gives SharePoint this malleability.
Have you ever wondered why there are so many third-party software vendors selling SharePoint add-ins? It’s precisely because of SharePoint’s design as a platform.
Problems with Custom Code
You might be thinking, “How does custom code create friction?” In many ways, actually.
Did you know that the number-one factor behind SharePoint support issues is custom code? Custom code can introduce security vulnerabilities. Custom code can cause performance problems. Custom code can destabilize the farm. Custom code can complicate troubleshooting.
For example, when you troubleshoot a web application that’s throwing errors, it’s a challenge to isolate the source of the problem—whether to custom code, to misconfiguration, or to some out-of-the-box problem.
Custom code can also affect your ability to upgrade the program. Case in point: Some companies continue to run SharePoint 2003 because of the pain and effort that would be involved in upgrading. Custom code can also complicate disaster recovery procedures. Case in point: Replacing a crashed SharePoint web server is much more difficult if custom code has been introduced, especially if the code has been manually deployed.
When business units expect a customized SharePoint experience, developers do their part by building it. However, administrators must support the customization. And if the custom code introduces problems, the process creates friction.
The solution to this dilemma—and the key to a successful and harmonious SharePoint deployment—is to recognize that both the admin and developer roles are essential and interdependent. There must be mutual understanding and respect between the two.
To help bridge this gap and, hopefully, ease the friction, I’ll explain what developers must understand about administrators—and vice versa. Along the way, I’ll cover several best practices.
What Developers Must Understand
The most important aspect of a SharePoint administrator’s role is represented by a three-letter acronym: SLA. The service level agreement, whether formal or informal, is a contract between the SharePoint operations team and the business. The SLA is often described as a series of metrics, such as uptime percentage.
How do SharePoint administrators define success in their jobs? By helping the operations team meet the SLA.
The more critical the system, the more difficult and challenging the SLA. If the farm goes down at 2:00 P.M., who is the first person called? Not a developer. Whose job is on the line if the farm does not come back online within the SLA window? Not the developer.
Unscheduled downtime for even a few minutes is not acceptable for many businesses. To support their fellow administrators, developers must write quality code that ensures that the SLA is not compromised.
Furthermore, developers must understand the importance of keeping the production farm stable. Among other best practices, proper error handling must be applied to all custom code.
Without effective error handling, users are often greeted by the not-so-helpful error message, “An unexpected error has occurred.” Developers should also run SPDisposeCheck (see the MSDN article “SharePoint Dispose Checker Tool”) on their compiled assemblies (DLLs) to make sure that no memory leaks exist. The best way to make sure that your code is stable is to have other people review the code and perform thorough unit and integration testing.
When custom code is developed, it must be packaged as a .wsp file to automate the deployment. A .wsp file is a Windows SharePoint Services (WSS) solution package.This step is the single most important best practice for developers.
Without a solution package in hand, administrators must manually deploy custom code and its configuration changes. This can take an incredible amount of work and bring down the farm if the code is not deployed correctly. For this task, use tools such as WSPBuilder or the SharePoint project templates inside Visual Studio 2010. Both tools create solution packages automatically.
Use sandboxed solutions whenever possible. (For more information, see my article “SharePoint 2010 Sandboxed Solutions” [February 2011, InstantDoc ID #125632].) Sandboxed solutions are .wsp files that can be deployed by anyone who is a site collection administrator. These packages do not require a farm administrator’s involvement, and this saves those administrators time and effort.
Moreover, sandboxed solutions cannot destabilize a farm in the same way that a regular solution package can. For example, if a custom sandboxed Web Part throws an unhandled exception, only the Web Part is broken, not the whole web page.
Although there are limits to what sandboxed solutions can do, don’t let this stop you from using them where they can be used. They are still useful and relevant for many custom code requirements.
Security is obviously very important in a SharePoint environment. SharePoint often stores Personally Identifiable Information (PII) and may even hold trade secrets.
When you write custom code, be sparing and cautious in how you use the RunWithElevatedPrivileges security method (see the MSDN article “SPSecurity.RunWithElevatedPrivileges Method”). Do not write code that requires the trust level of web.config to be elevated (see the MSDN article “Securing Web Parts in SharePoint Foundation”).
If a sandboxed solution is not possible, you’re better off deploying the assembly to the global assembly cache. As a developer, you must know the organization’s security policy very well before you write any code. If a security policy doesn’t exist, help to create one, and include this policy with the governance or Application Lifecycle Management (ALM) plan.
Developers must make only those changes that are supported by Microsoft. Among others considerations, avoid changing out-of-the-box files in the SharePoint root directory (aka 14 Hive), and never change or add objects (e.g., tables, stored procedures, triggers) to the SharePoint content databases. (For more information, see the MSDN article “Support for changes to the databases that are used by Office server products and by Windows SharePoint Services.")
SharePoint developers must understand the SharePoint architecture from a developer’s perspective. This means that you, the developer, must understand the SharePoint technology platform and how SharePoint uses SQL Server, IIS and ASP.NET.
By understanding SharePoint’s construction, you will understand how it can be enhanced by using custom code. This takes time, just as it takes time to write quality code. But it also makes you a better developer. Books such as Inside SharePoint 2010 and Real World SharePoint 2010 will help. Also consider classroom training to get hands-on, instructor-led guidance.
What Administrators Must Understand
Administrators must understand that writing SharePoint code is very challenging. SharePoint’s object model (the technology platform) is expansive and contain tens of thousands of API calls.
Parts of the object model are not intuitive. Although the documentation is always improving, it still suffers from a shortage of quality explanations and examples. On top of that, many additional technologies are required in order to write SharePoint code. It’s truly an alphabet soup, ranging from HTML, CSS, AJAX, XSLT, and CAML to .NET, JavaScript, and the new client object models in SharePoint 2010. As in nearly all aspects of code writing, quality comes with a lot of experience, and most organizations struggle to find—or to afford—senior SharePoint developers.
As a SharePoint administrator, you must know how to deploy .wsp files. Although the concept is simple, you should understand what these packages do and how to retract (uninstall) them. For more information about this process, see “Solutions Overview” at bit.ly/gQchT0 and “SharePoint Powershell for Solution Deployment (WSP)."
You cannot use Central Administration, SharePoint’s administrative GUI, for all administrative tasks. Therefore, you must become proficient in Windows PowerShell, the de facto command-line interface for SharePoint 2010.
Because PowerShell lets you do some amazing things, such as making direct API calls, it gives you some of the same power that developers have without forcing you to use Visual Studio. If you’ve been holding back or just procrastinating, now is the time to get up to speed with PowerShell. The time that you invest will be paid back again and again in your increased productivity.
You must know how to read the SharePoint Unified Logging Service (ULS) log files and how to use them to troubleshoot problems. You can use tools such as ULSViewer (see the MSDN article “ULS Viewer”) to get a real-time view of log files and to consolidate log files from multiple servers.
You should know that SharePoint logs many messages to the Windows Application log as well. This is especially helpful because the messages in the Application log are less detailed than those in the ULS log, and this gives you a perspective of the problem from a higher level.
In fact, when it comes to troubleshooting, this is where administrators and developers should be working directly together. Troubleshooting the harder problems often requires different skill sets, and it never hurts to have another pair of eyes look over your work.
SharePoint administrators must understand the SharePoint architecture from an administrator’s perspective. This means that you, the administrator, must understand the different server roles (web server, application server, database server) and how each communicates with the others from a network and security perspective. This knowledge also helps you to understand (conceptually, at least) the technology platform.
You can gain more insight into this process through books such as Professional SharePoint 2010 Administration and my own book, SharePoint 2010 Administration Instant Reference. As an administrator, take a cue from developers and consider technical training if you have no formal training in SharePoint.
Stick to the Plan
Despite SharePoint’s complexity, you should stick to your organization’s ALM plan. According to Wikipedia, ALM “is a continuous process of managing the life of an application through governance, development and maintenance”.
Some people believe that because SharePoint is such a unique product that you can’t—or shouldn’t—follow existing processes. This is not true. You might have to adapt your existing processes to accommodate SharePoint. But considering SharePoint’s complexity and importance, it’s essential that you maintain the rigor and discipline of your current practices.
If your organization doesn’t have anything that resembles an ALM, administrators and developers should jointly create one. As part of this process, make sure that you have a complete test or staging environment that mimics production as closely as is technically possible.
Be diligent in deploying and thoroughly testing custom code before it goes into production. If there is any point in this process at which administrators and developers should be resolving problems together, it’s in the staging environment. Friction is greatest when you are troubleshooting actual production problems.
Finally, both administrators and developers should be tapping into the ever-growing SharePoint community by attending events such as SharePoint Connections and SharePoint Saturdays. Use Twitter, Facebook, and LinkedIn to expand your virtual network of SharePoint professionals. There is immeasurable value to be found in blogs and online forums, such as the Microsoft social forum and the StackExchange network.
Put your web searching skills to work when you need an answer. Very likely, you will get to know and respect many other SharePoint developers and administrators—which, at the very least, makes living together over the course of your SharePoint career much more enjoyable.
