When Marketing Hype Meets Reality: ArcGIS Server
Posted by Dave Bouwman | Posted in Uncategorized | Posted on 01-04-2008
8
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.
Good post and I’m glad you verbalized it at the dev summit.
Unfortunately I can’t help but think that Steven Sales and Martha Marketing would feel that Tim the Technologist knows how to close a deal about as effectively as having Steven crank out C++.
Also, don’t get me started about Patricia Professional Services who provides the company yet another revenue stream so that the customer can get something, anything working.
Terrific Post -
we had to do exactly what you wrote – build special mxd and geoprocessing
tools.
I wish ESRI (which knows all of the above) would spell it out and save a lot of time to it’s clients.
Dave,
This falls into the category of Public Service Announcements. I’m going to name my firstborn child after you, so I hope it’s a boy. I go to meetings and hear a lot of people (IMO) overestimating what they can realistically expect from AGS.
Good post. We’ve been working this issue with ESRI for a couple of years. One of the "solutions" our regional office offered was to have their sales staff go in and convince our clients that buying more hardware and expecting less performance and scalability was better than sticking with ArcIMS as the mapping engine. It’s been an awfully tough sell.
This reality is not exclusive to the ARC GIS Server environment. This is also happening in other mapping technologies that are taking project initatives and selling "enterprise" concepts that they are not prepared for the tuning nusiances. The true enterprise concepts leverages the strength of the oracle processing server side implementation. We are still in the vision stage and too much chatter with non techies selling the concept it will be OK if we cut this corner until the bandwith and processing log jams. Only then do people here the "true enterprise" architecture and stop selling project concepts as enterprise solutions.
Re:Steve
Yeah we’re seeing the same thing here. Plus we also host multiple services for our clients which they than use our custom viewer to access them. Right now we have a streamed line process where our GIS Analyst’s setup the axls, posts them to the server and than just updates the data in SDE. With ArcGIS Server they would need to be trained on creating custom mxds and understanding the labeling and cartographic limitations, the difference between tiles and dynamic maps. Than for the data to be updated the tiles would need to be recreated which will take some time and a lot of space.
I do really like the new javascript api and REST api. You could build some interesting sites with them. Plus the geoprocessing and kmz support is very cool.
I think they need to break ArcGIS Server into modules. So that the price isn’t so steep and make it more approachable. They also need to improve the dynamic map feature so that its at least as fast as ArcIMS.
I’m not a programmer, but I’ve been using ESRI products for more than a dozen years. I’ve noticed this marketing vs. reality issue with more than a few products and it has been pretty painful with ArcGIS Server. I’m just tickled to think that we’re probably going to spend all kinds of time on a model that’s going to be scrapped in the coming years due to the failure to live up to expectations. So what is an organization to do? Are there other families of products that can help users accomplish these types of tasks? Are they more cost-effective to develop and deploy? Lie if you have to (I’m used to it), but please don’t tell me "no".
ESRI is really (that I know of) the only company that offers the total pack when it comes to server gis that offers geoprocessing, multiple api options, tile mapping, editing, etc… Now you could go with an open source approach like, GeoServer,Map Server,SharpMap,MapGuide and OpenLayers. But what you get in free software your going to have to spend in time. Time to put together a system you can use and is reliable. The nice thing about the open source route is you control when the system gets updated and what pieces you want to use. A lot of these do support SDE also.
There are 2 companies that compete with the ESRI stack. But I’ve never used them myself. Manifold and MapDotNet