The SharePoint Paradox - Too Many Hammers

It happens with each new custom development I am involved with on the SharePoint platform - that initial temptation to write custom code, to head down the technical and complex route to a solution. Comes from having a background in software development, I guess!

The process of firing up Visual Studio and starting to code against the SharePoint APIs can thus become the "hammer" used to fix every "nail" (for "nail" read "business requirement").

But that is missing the point of SharePoint - there are plenty of built-in features that can greatly reduce the need for custom development. And hence reduce the cost to the client. Take one recent example from my work - a client required a web part that displayed documents created or modified by the current user, with some particular requirements around the way the metadata was displayed. Some of the functionality in this web part had me hovering the mouse over the Visual Studio start program link, but a little further design work revealed that the good ole' Data View (Data Form) web part could satisfy their needs.

The web part took around an hour to complete, with the necessary XSL jiggling. And one of the real benefits of taking this approach is the deployment - no WSP files to install on the server, no interruption to service. A simple text file to export and import.

Perhaps this is a paradox with SharePoint - as a development platform of significant breadth, it offers lots of different hammers for each nail. Me, I try (often have to remind myself!) to pick the lightest-weight hammer possible for each task. Lightweight = quicker development cycle = more agile and more responsive to customer requirements.

There is a proviso, of course (quite a major one) - the size of the client and their deployment/integration process may choose that hammer for you. The fast, lightweight approach that may be appropriate for clients with small, simple sites and a handful of users on a single server is unlikely to fit major organisations with strict control over the staging/QA/production environments. But even in that instance a Data View web part could be enveloped inside a SharePoint Feature and the deployment needs likely satisfied.

One step missing from the process when using this lightweight means of solving IT needs is the testing, or rather the inclusion of automated, repeateable testing. Someday I'll get a chance to look at the web test various frameworks around and to see whether NUnit combined with, say, WebAii or WATIN will help.

Visio Stencil of SharePoint Design Shapes

When creating site and application designs for SharePoint, I have wanted to illustrate the elements that comprise the solution's architecture.

Diagrams at this level are very valuable for explaining the proposed design to a client, and also for summarising the elements involved ("a picture is worth....").

So I have created a Visio stencil containing a few useful shapes.

See an example of the shapes, and download the stencil, from here

Email and SharePoint are not Competitors

A discussion following on from a presentation I recently attended (on the use of SharePoint in business) raised the opinion that email is a competitor to SharePoint in terms of business use. The basis of the argument was that people in an organisation either can use SharePoint for their collaboration or they can use email.

I disagree. SharePoint is now very much email-enabled, with the ability to send alerts or emails from custom code, and to receive emails into lists. The ideas in the discussion may have been based on the belief that users are required to interact with the data contained in a SharePoint site only through the site's web pages.

Certainly the users will need to perform some actions through web pages, but it is possible without much work at all to implement a business process in SharePoint in such a way that the users can continue to use emails for many of the operations they perform. An email sent to a SharePoint list can be interpreted by event handlers on the list, which could act on information in the email and add or edit data in the list.

What I have found is that architecting solutions in SharePoint requires a different vision than when developing in ASP.Net. One of the key points is to build on SharePoint's strengths - think about using lists for storing data (for example, store temporary data for an application in a list rather than in a database table).

Why Use the Custom Zone for Administrators

The model logical architecture released a while ago by Microsoft for a corporate MOSS deployment includes a configuration that really had me wondering "Why?" - that is the use of the custom zone for administrative access to all the sites.

One answer I have come up with - by assigning a policy to the custom zone for the SharePoint administrator user group, and granting full control in this policy, then the administrators are guaranteed to have full control over all sites and content in the delpoyment. Note that this is assuming an AD group named "SharePoint Administrators" exists in the domain.

The permissions applied in a policy override all other permissions in sites, so even if a user with site admin rights had removed all explicit permissions for the SharePoint Administrators user group from their site, the policy enforces access.