It seems like SharePoint is all the rage these days – and if you believe the hype coming from Microsoft – SharePoint is a silver bullet for organizations to manage and publish web content in a way that doesn’t break the bank. Recently, Farallon has had a number of clients asking us to develop GIS applications that integrate with their existing SharePoint environments.

I don’t have a strong opinion as to whether it’s a good solution or not, but I have been intrigued a new piece of jargon that seems associated with the SharePoint vernacular – “GIS Web Part”. The moment I heard the phrase, I knew that I had my next blog.

So what is a web part? According to Wikipedia, it is “a server control that enables end users to modify the content, appearance, and behavior of Web pages (SharePoint-driven web pages) directly from a browser. It can be put into certain places in a web page by end users, after developing by a programmer.” Translation: a user can drag and drop stuff (content) onto a web page that he or she wants to see. By extension, “ESRI Web Parts” are controls that allow users to add map-based content sourced from an ESRI data source. By further extension, “GIS Web Parts” are map-enabled content that isn’t necessarily published by an ESRI service.

As part of SharePoint-specific application development work we have done for the Bay Area Air Quality Management District and the California Emergency Management Agency, Farallon did some benchmarking of ESRI Web Parts against GIS Web Parts that we developed using SQL Server Reporting Services to determine what is the best way to develop and deploy some specific SharePoint-driven workflows. Here’s the condensed version of what we found:

ESRI web parts are much easier for a typical GIS Analyst to deploy and administer, but the downside is that they are difficult to customize and functioned slower than the Microsoft purist’s counterpart. Native MS tools, on the other hand, require much less technology (no ARC anything), perform faster, and provide a more robust programming toolset so you can more easily create and customize the “parts” (no yearly ESRI licensing is an added bonus).

If you have access to the programming chops, I recommend you try out the Microsoft route to developing your GIS Web Parts. See how it performs relative to ESRI tools for the types of Web Parts and customizations that you typically develop. If you have any interesting results to share, I would love to hear from you.