One issue I seem to run into a lot is the gap between client expectations of ArcGIS Server, and the reality. Although I did bring this up at the closing session of the Developer Summit, and we were told this would be addressed, I think it's worth pointing out some specifics.

On the one hand we read "Fulfilling the Promise of Complete Enterprise GIS" in the Fall 2007 ArcNews issue.  Some quotes...

... to support fast and efficient visualization and analytics applications, regardless of the amount of data held within an organization.

Any model or tool authored in ArcGIS Desktop can be shared to a broad audience via ArcGIS Server...

It's  typical of much of the marketing. Pushing the simple author-publish-consume model, in which Joe GIS can just take his map, and geoprocessing models and fire it up onto the web in a few short clicks. To be sure this makes a great marketing story... "Wow - I can do that! Lets buy ArcGIS Server!"

But what happens when reality steps in? When Joe GIS takes his map, and geoprocessing service and publishes it?

Typically the site is slow, the geoprocessing tasks randomly fail and take ages when they succeed, and the Joe GIS gets (understandably) negative feedback from his users and superiors. So he packs up his bags and heads out to the developer summit, with one agenda: make his site faster. He drops into the "Architecting ArcGIS Server Solutions for Performance and Scalability Session". On slide 5th slide, the first golden nugget of truth is revealed:

The item in question is somewhat small on this slide, and it's not spelled out directly, so let me help out - "Design your maps specifically for server deployment".

Somehow this never makes it into the ArcNews articles or the demos. Nor do the items on the following few slides...

• only use the ESRI Optimized symbology,
• use annotation instead of labels,
• skip the fancy cartography - including highway symbols
• cache everything you can,
• and only load a few layers.

So Joe GIS now realizes he's going to have to re-work all his maps. But there's got to be some good news about the geoprocessing right?

Enter golden nugget of truth two - and nope. Seems Joe is going to have to do a bunch of pre-processing, and stage up his data differently. So much for just publishing the data as it is. What does this "Understand Performance Expectations" mean? Oh yeah - basically if it's slow in desktop, it will be slow in server. And this last bit about only one instance can update data at a time? That does not sound too good. And Joe's ESRI reps have been telling him to use geoprocessing to do everything, but if he uses Geoprocessing his site can't handle all 5 of his users at once! Maybe it's time to take a look at .NET and that ADF thing...

I could go on through the entire presentation, and point out the various inconsistencies between what we see in the ArcGIS Server marketing and the reality (aside: check out slide 28 where they tell you to disable seamless panning and drop the overview map - how many demos have you seen where seamless panning is disabled?!)

What's really interesting is this is ESRI telling you both things!  Right hand meet left hand. Marketing meet the technical staff. Take each other out for lunch. Talk. Listen. Learn. ArcGIS Server is a great product - it can do lots of great things, but it's not a point and shoot camera. It's a serious SLR, that needs professional skill to operate effectively and efficiently.

Until the large scale marketing shift happens, here are a few suggestions for the ESRI technical marketing people out talking to clients:

• Be up front about what ArcGIS server can do, and what it can't.
• Be up front about having to specifically author maps for server, and the limitations on cartography, number of layers and caching.
• Be up front about having to pre-process data used in geoprocessing tasks, and concurrency limitations.
• Be up-front about the fact that to do much beyond pan and zoom, there will be some coding needed, and the water gets deep fast.
• Be up front about the server loads and the licensing costs to scale out.

Then show some totally kick-ass demos. Show something truly amazing, and be rock stars about it, but just don't lip synch. Be up front about the reality of running ArcGIS Server, because every single one of your users are going to experience this reality. Set customer expectations realistically, and everyone wins.

Link to the presentation listed above